Now I've seen everything
<plug type="soapbox" language="Forth">HAH! You obviously don't know the power of the Forth!
</plug>
Seriously...
It depends on your application. If you're only doing one thing at a time (not to be confused with running one program at a time), then a terminal interface is fine. Otherwise, you will need to multiplex multiple data streams over that single cable. For utter simplicity, I'm a fan of ATM, but you'll need to write a custom ATM switch on the PC. Probably not what you're looking for.
IF, and I repeat this, *IF* you do go with TCP/IP over the serial interface, you can use PPP or (preferably, since it's simpler) SLIP, both of which I know Windows supports via its dial-up networking support. You may need to install it separately on modern versions of Windows, since few people have modems anymore.
For Linux, it's the same thing -- you need to set up a PPP or SLIP driver.
I wasn't thinking of making my little box multitask, it seems like overkill for something with less than 64KB of user memory (I may have 2 tiered device drivers, but that's it).
Not sure what you mean by two tiered device drivers, but if you use something like Forth for programming it, the compact code representation offered by Forth when compiled definitely allows for TCP/IP to be implemented. Contiki is an OS for the Commodore 64 that supports TCP/IP.
Note that you're not going to get Unix Workstation Class Networking
. But it is doable.
The "beauty", if you can call it that, of my idea is that it lets you multiplex a moderately complex UI and binary data transfer over a single cable, and I can access all that from a PC/Mac using a standard-ish app (a terminal emulator) without the overhead of something like an X server.
Well, if you're going to provide *graphics*, then RFB is the protocol to use. RFB is the Remote Frame Buffer protocol, and that's what VNC uses to transfer graphics back and forth. I've found that, for many applications, it's actually faster than X.
But there is nothing preventing a text-mode UI from being used with TCP/IP. In fact, I encourage you to "telnet uncensored.citadel.org" if you don't believe me.
If I used that instead of USB or RS232, how would I access my little box from a PC?
I used the PacketWhacker on a ATmega project once, but I *never* got the poor thing to actually work. The documentation in the $20 book that accompanies it is woefully inadequate to debug it with as well. The actual device datasheets were thoroughly unhelpful as well.
That being said, let's suppose you find one that you can get working at all, let alone well. The simplest method of accessing the device is through telnet. A telnet connection is just a dumb socket connection -- no encryption at all, and unless the *server* on the other side asks for it, no need to password authenticate either. Yeah, there are options you can support to communicate things like terminal size, echo settings, etc. But those are extra credit items. Telnet is, at its core, an otherwise unadorned TCP stream that delivers raw bytes (usually with VT100 escape codes if it's text) from the device, and whatever you type in goes the other way. In other words, Telnet emulates a modem.
(Note that HTTP, SMTP (e-mail), POP3 and IMAP (also email), FTP, etc. all are just glorified telnet sessions. In fact, you can do this:-
and when it responds, type this:
And you'll get the Google homepage, expressed as raw HTML, and all the MIME headers to go with it. Yes, folks, that's what your 5MB to 10MB Internet web browser abstracts away from you! Want to check your mail? OK:
Code: Select all
telnet mail.yourdomain.com 110
USER <your username>
PASS <your password>
STAT ((tells you how many messages are waiting))
RETR n ((fetches message #n))
DELE n ((deletes message #n))
QUIT
But, I'm really digressing now.
)
