Long have I wished for a computer-free globalCALCnet bridge to link CALCnet, my inter-calculator networking protocol, over the internet. The current solutions use direct USB to a PC or an Arduino plus a PC connected to multiple calculators' I/O ports to provide gCn access. However, with my discovery of a $4 Ethernet + PHY board available from Chinese electronics sellers, I believe that a cheap, powerful, PC-free bridge is possible.

I have started by setting up the hardware below, based primarily on the documentation here, here, and drivers here. The components are an Arduino Duemilanove, the ENC28J60 breakout board, and a simple TTL AND chip forming a cheap 3.3V-to-5V DC-DC buffer. Thus far I have had no success getting the EtherCard demo programs to function; I believe that the SPI communication is failing. I am thinking my HD74LS08P chip might be too slow compared with the SN74HCT08D my primary source recommends.

Updates will follow as I get scattered time to work on this.

This would be awesome! I'm excited to hear how this progresses.

Thanks, elfprince, I'm intrigued as well. This mini-project actually started because I wanted to make my coffee maker internet-controlled, but with a calculator running a custom CALCnet-enabled program as the brains and screen for the operation.

On my technical issues, this page suggests that my 74LS is not too slow for SPI:
http://www.kpsec.freeuk.com/components/74series.htm

This does sound cool! I think that this will really enhance the power of calculators as mini-computers, especially since they can access the Internet cheaply now. One question, though: how would the user set settings like the web hub name, the client hub name, and the server name? Would we use another 83/84 program, or set it on the computer?

A good question. I was thinking of first having the bridge pre-programmed with a few hubs (eg, FTPHub, IRCHub, WebHub, and <Username>Hub), that you would switch between with the press of a button on the device. Since the Atmega328 needs to be programmed with firmware anyway, users could edit the constants in the firmware before loading it. Another option would be a small ASM program on the calculator to communicate with the bridge out-of-band and set its username and hub(s). Yet another option would be CALCnet 3, which I have begun planning for including with Doors CS 8 which may be TI-84+CSE, which will include hub information inline in frames, requiring that bridges not bind to specific metahubs at all. This will also allow multiple programs to run over the same network at the same time, for example CALCnet Chat happily coexisting with Obliterate.

I think you should have two versions of this device, one that uses the ASM program to set Cn2.2 settings, and one that uses CALCnet 3. And I would love to embed hub information inline in frames, by the way.

Compy: Yes, it's something I've been trying to think of how to do for a while. I wanted to add special bit(s) to the header of a Cn2.2 frame to mark it as Cn3 and make Cn2.2 clients ignore it. It occurs to me, however, that I have such a long network-inhibit before frame sends occur, that I can shorten that without breaking the network. Cn3 clients will recognize that the shorter inhibit means a Cn3-style frame, while Cn2.2 clients will simply ignore the frame.

Everyone: Thanks to a helpful comment on the first source I linked, my Arduino can ping Google, and I can ping my Arduino:

That sounds like a good idea, especially if that means we don't need to reprogram Cn2.2 at all. And while we're on the subject of Cn3, I just wanted to make a feature request for it of allowing you to queue packets for send and/or recieve, so that we can get a lot more throughput at once without forcing the user to remember where they were and come back and change things. I know that this would probably be pretty hard to do, but I had an idea for how we could do it:
- For sending, instead of the default buffers in saveSScreen, we have 16 bytes for 8 frame pointers, each of which are intended to point to a frame with the same structure (ID, then size word, then buffer). Essentially, Cn3 would cycle through these pointers, and if the pointer is not null and points to a pending frame (one with the flag set), it will try to send the frame, else it will skip it. A subroutine would also be offered to get the most recently encountered skipped frame index (null or already sent), so that you can create a new frame and store the pointer at that point.
- Receiving would be more difficult since you'd be forced to implement some kind of heap to store both the frames as well as the frame references (using a linked list). Basically, the user initializes CALCnet by stating what buffer they wish to use to store their received frames stored, which would become the root node of a memory manager tree. When we get a frame, we first attempt to malloc() it as well as the frame entry (sticking it at the front of the linked list). The CALCnet interrupt would look at this front entry of the linked list, and if the frame it points to has its flag cleared, it will free() the list node and the frame itself.

Is there a better place I can post this?

That's encouraging I would imagine the hardest part will be implementing DHCP?

Say you wanted to implement HTCPCP

Newer Arduino models would make your life easier, the 2009 is an ancient model by now.

Why would they make my life easier? I'd still be dealing with an Atmega328 either way, would I not? I don't believe that I need the power of the 644 (Arduino Mega), so I'm perfectly happy with my Duemilanove board.

I was mostly thinking of the recent http://arduino.cc/en/Main/ArduinoBoardDue
It's Arduino's first ARM-based design, heads and shoulders above all previous models of the Arduino family. Quite possibly too late and too little, as many others have done Cortex-M designs before Arduino did, and the Due is, at least here in France, more expensive than a RPi while being much less powerful (!)... time will tell.

Maybe the Arduino ADK derivative of Arduino Mega 2560 board, whose advertised USB host capability makes me think of ability to plug in a USB/Ethernet adapter, could do the job as well.


Addendum: Samir Ribic implemented a simple TCP/IPv4 stack on the TI-68k series, in less than 8 KB, more than 10 years ago; but in 2013, IPv6 support is becoming a must for the IoT, so as far as I'm concerned, I'd rather port tried-and-true, modern stacks such as lwIP (which has IPv6 support in a development branch) - and that requires much more RAM than the Arduino Duemilanove or Uno have

So this means I don’t even need bluetooth. This means I don’t even need the gcnclient. Just soldering skills, the right stuff, some firmware, and crossed fingers?
I’d buy a prebuilt one without any userservicing agreements whatsoever from you. Cost for labor, man hours, supplies, and for the software. I’m quite serious.
Of course, only after they really work and liability won’t be an issue.

Is there a schematic to follow somewhere?

We're pretty entitled, aren't we?

I have far from enough time to manufacture these for other people, but someone else in the community might be willing to do it.

That certainly would make something simpler, but I'm perfectly happy with 16MHz, 32KB of Flash, and 2KB of RAM. If I can't fit a simple Ethernet-to-CALCnet bridge in that, I must be doing something wrong.

OK, if the code running on the Arduino is "just" a simple Ethernet/CALCnet bridge, the code base can definitely be smaller and require less RAM than lwIP, indeed

Speaking of lwIP, though, I've wondered if it would be possible to cut out the Arduino entirely, and connect the ENC28J60 directly to the calculator. Unfortunately, I just don't think it can bitbang SPI fast enough to make that feasible.

The master (which would be the calculator) generates the clock so speed is fine, the issue is that you need at least three I/O lines for SPI (SCK, MISO, MOSI) and the calculator only has two.

Ah, fair enough. I must admit that I wasn't thinking clearly about the differences between I²C and SPI. That's a shame. On a happier note, I was able to magically get DNS resolution working, discovered that EtherShield has some capacity for multi-packet TCP sessions despite documentation to the contrary, and was able to open a connection to the gCn Metahub on its default port. I was even able to get an RST on an incorrect port, which was nice.

Well from everything I hear, this project is a dream come true.