Ethernet for the TI

[matthew180]

That is true, the Internet is "a sea of information, knee deep". However, you can find depth in some places if you look hard enough. No one said it was easy.

 

Marc: I was not trying to blow you off, but even a simple explanation of TCP/IP is too big a topic to even try to generalize. And for that kind of stuff, the Internet is pretty good at giving up the info.

 

IMO, a TCP/IP implementation is not trivial, and even trying to maintain a port of something small like ConTiki, or another, would be a pain. And, once working, that is about *all* the computer would be doing, you would have almost no CPU or RAM resources left for your application. Letting a dedicated hardware device deal with all of that is more practical, and lets us simply deal with how we interface it, either in parallel on the bus, or via a serial connection (which does not necessarily mean RS232.)

[lucien2]

Wikipedia has answers: http://en.wikipedia.org/wiki/Ip_stack

[danwinslow]

once working, that is about *all* the computer would be doing, you would have almost no CPU or RAM resources left for your application. Letting a dedicated hardware device deal with all of that is more practical, and lets us simply deal with how we interface it, either in parallel on the bus, or via a serial connection (which does not necessarily mean RS232.)

 

While I agree with most of what you say, there really isn't that much going on in terms of CPU...you don't even deal with 99% of the packets that are on the wire because they aren't addressed to you. You don't have to listen to broadcast if you don't want to, although I do on my home network and its very easy to throw them away. Of course, if you were on a subnet getting slammed by the open internet or some large corporate network you could def have problems, but behind a nice little home router its pretty quiet.

 

There's no way in H&ll you could keep up with any thing like modern transfer speeds, but then I wasn't expecting that. IP was designed for slow lines and most protocols have throttling mechanisms.

 

RAM certainly is an issue though. All in all I think offboarding the whole stack is absolutely worth checking out, as long as you have a fast polling and transfer mechanism available. RS232 isn't going to cut it probably, but high speed IC2 or something probably would.

[marc.hull]

That is true, the Internet is "a sea of information, knee deep". However, you can find depth in some places if you look hard enough. No one said it was easy.

 

Marc: I was not trying to blow you off, but even a simple explanation of TCP/IP is too big a topic to even try to generalize. And for that kind of stuff, the Internet is pretty good at giving up the info.

 

IMO, a TCP/IP implementation is not trivial, and even trying to maintain a port of something small like ConTiki, or another, would be a pain. And, once working, that is about *all* the computer would be doing, you would have almost no CPU or RAM resources left for your application. Letting a dedicated hardware device deal with all of that is more practical, and lets us simply deal with how we interface it, either in parallel on the bus, or via a serial connection (which does not necessarily mean RS232.)

 

I know you we not blowing me off. It's just a lot of heady info for your typical wood butcher to absorb. After a little reading I will say that I am surprised the system works as well as it does (or at all.) I am going to bow out here as this stuff is obviously over my head and I'll wait until one of you more qualified. I'll go back to games and muzak but keep a keen interest on this topic. Telnet from the TI seems a very worthwhile project IMHO.

[RXB]

Even a Windows 98 can stil see the Google main page and you can do a search. So as long as you have enough video RAM and RAM to get the page on the screen you could do a Google search.

 

If you go into a DOS screen only you can get a return of data from GOOGLE with data. Hard to see what is going on but again you can do a search with it.

[idflyfish]

Ok..where do I pre-order?

[Tursi]

The AVR GROM code that we'll be releasing will support TTL Serial interfacing, you could take one of the XPORT embedded devices, wire it directly to the AVR, and the AVR to the GROM port for a nearly glueless memory-mapped ethernet device. It was one of the things I wanted to demo probably won't get to now.

 

Does this mean no project or your simply delayed ?

 

It was never intended to be part of my project, it's just a simple thing that could be wired up - same way as I wired up the Linux board last year (in fact, the same circuit and the same software would communicate fine with the XPort). Hooking up to an embedded Linux board is just much more useful. The only reason I was going to demo it at all was there was an air of doubt around the value of the GROM project's extended uses (and I had the parts anyway).

 

My Linux board project is pretty delayed, I don't expect I'll have it for the faire this year. I'll be lucky to the get the MPD done, since I'm having motivational issues on the GUI shell. The Linux board was my proposed solution to the ethernet issue - I've been poking at this since about 2000. Embedded Linux actually solves a lot of things on my personal wishlist.

 

Back on topic, there are plenty of embedded ethernet controllers available, but the price to feature to ease of implementation ratio of the XPort was the best of any that I came across. http://www.lantronix.com/device-networking/embedded-device-servers/?tab=0 (I think it's the XPort Direct that I evaluated). I would have released something with that about 3 years ago, but I didn't have a serial port to talk to it with - that was when I moved over to the AVR GROM project, since I could get the serial port out of that, hehe.

 

For actually running IP on the TI, uIP was the best choice back then, and it was absorbed into Contiki (it apparently even supports IPv6 now). It only needs a couple hundred bytes of RAM to run. Now that GCC is starting to stablize, using it may be a lot easier than before. Even if not, UDP as a protocol is pretty easy to implement, especially if you aren't 100% compliant, it's just a few headers and a checksum. the AVR port is nicely broken out and stripped down, and may be a good starting point: http://code.google.com/p/avr-uip/

 

It's worth adding that people who want to work on the software side need not wait for hardware. If you can get your TCP/IP stack to work, you can communicate over Serial to most dial-up systems (Linux is easy, Windows is even possible) using SLIP, though of course you'll need to code that layer as well: http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol

[marc.hull]

Even a Windows 98 can stil see the Google main page and you can do a search. So as long as you have enough video RAM and RAM to get the page on the screen you could do a Google search.

 

If you go into a DOS screen only you can get a return of data from GOOGLE with data. Hard to see what is going on but again you can do a search with it.

 

 

 

whaaaaaaa............... Is this Eric ????

[RXB]

Even a Windows 98 can stil see the Google main page and you can do a search. So as long as you have enough video RAM and RAM to get the page on the screen you could do a Google search.

 

If you go into a DOS screen only you can get a return of data from GOOGLE with data. Hard to see what is going on but again you can do a search with it.

 

 

 

whaaaaaaa............... Is this Eric ????

 

 

No running Virutal PC or VMware with a Windows 98 I can get to Google and do a search. The host computer has the Ethernet connection so the Virtual PC just accesses the device and works fine.

 

 

Hardware wise this is a hell of a problem in comparison on the TI99, but not on a emulator at all. Cost wise would be really tough to overcome.

[+InsaneMultitasker]

The AVR GROM code that we'll be releasing will support TTL Serial interfacing, you could take one of the XPORT embedded devices, wire it directly to the AVR, and the AVR to the GROM port for a nearly glueless memory-mapped ethernet device. It was one of the things I wanted to demo probably won't get to now.

 

Does this mean no project or your simply delayed ?

 

It was never intended to be part of my project, it's just a simple thing that could be wired up - same way as I wired up the Linux board last year (in fact, the same circuit and the same software would communicate fine with the XPort). Hooking up to an embedded Linux board is just much more useful. The only reason I was going to demo it at all was there was an air of doubt around the value of the GROM project's extended uses (and I had the parts anyway).

 

My Linux board project is pretty delayed, I don't expect I'll have it for the faire this year. I'll be lucky to the get the MPD done, since I'm having motivational issues on the GUI shell. The Linux board was my proposed solution to the ethernet issue - I've been poking at this since about 2000. Embedded Linux actually solves a lot of things on my personal wishlist.

 

Back on topic, there are plenty of embedded ethernet controllers available, but the price to feature to ease of implementation ratio of the XPort was the best of any that I came across. http://www.lantronix.com/device-networking/embedded-device-servers/?tab=0 (I think it's the XPort Direct that I evaluated). I would have released something with that about 3 years ago, but I didn't have a serial port to talk to it with - that was when I moved over to the AVR GROM project, since I could get the serial port out of that, hehe.

 

For actually running IP on the TI, uIP was the best choice back then, and it was absorbed into Contiki (it apparently even supports IPv6 now). It only needs a couple hundred bytes of RAM to run. Now that GCC is starting to stablize, using it may be a lot easier than before. Even if not, UDP as a protocol is pretty easy to implement, especially if you aren't 100% compliant, it's just a few headers and a checksum. the AVR port is nicely broken out and stripped down, and may be a good starting point: http://code.google.com/p/avr-uip/

 

It's worth adding that people who want to work on the software side need not wait for hardware. If you can get your TCP/IP stack to work, you can communicate over Serial to most dial-up systems (Linux is easy, Windows is even possible) using SLIP, though of course you'll need to code that layer as well: http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol

 

So... is it as "simple" as interfacing a chip like the IP Dragon and writing code similar to uIP? Would that be enough to connect the TI via ethernet?

[matthew180]

If you use the IP Dragon, you don't need uIP. They are doing the same thing.

[danwinslow]

If you use the IP Dragon, you don't need uIP. They are doing the same thing.

 

The IP Dragon ironically has no IP stack. All it does is the transport layers ( 1 and 2 ). I started with uIP 1.0 as an example and reworked it from there.

Edited August 10, 2011 by danwinslow

[matthew180]

Really? Wow, nice name... Seems like the Xport would be a better option.

[apersson850]

A much simpler task, but now when I fired up my old TI 99/4A, I wanted to do some printouts. I do have a Seiko impact printer, but using that with its old, dried out ink ribbons - well, no.

 

However, equipping my netbook with a USB <-> RS232 adapter, then connecting that adapter to the 99/4A, I can communicate serially with the netbook. Then it just takes running HyperTerminal, which is included in that old XP implementation, and set it to capture incoming data to the printer. Voila, and my old TI prints over wireless Ethernet to my network connected laser printer.

 

For the moment, I'm happy with that.

[matthew180]

Yup, I did the same thing with an old plotter. Added a bluetooth-to-serial adapter to the mix and now I have a wireless plotter! The main advantage to the network is multiple devices vs. a single direct communication. Plus networking gear (NICs, cable, switches, etc.) are cheap and easy to get.