Yeah--I can turn the internal pull-up off when my program runs (it's a volatile setting though, so the next power-up it will be on by default again). Since this pin is being sampled internally when the processor first boots up, the pull-up is always active when it matters, unfortunately. So my pull-down has to win against it. After the system boots, it is probably a good idea to shut that pull-up off though for sure.
I don't know if I'm reading the datasheet right, but it looks like the input current is typically 0.5 nA, and maximum 10 nA. Definitely miniscule.
It's fully working! I adapted my LPC1769 code to work with the LPC11U68. It actually wasn't very much work.
The biggest problem I ran into was that my Linux code wasn't expecting a raw socket to give the Ethernet frame check sequence as part of an Ethernet frame, and the BBB includes it. So I fixed that, and now everything works great.
I also ran into weird UART-related problems which were mostly fixed by upgrading to the latest BeagleBone Black image. I still occasionally see weird issues while flashing the LPC11U68, but it's not that big of a deal. This whole process also allowed me to move to Debian, which I'm a lot more familiar with than Angstrom (the BBB default).
All of the code, with the exception of a few BeagleBone-specific things for setting up pins that I will eventually put together into a root filesystem image, is available in the mac68k.info SVN repository.
I was opening a screenshot I took a while back from when I was messing with the EtherWave.
Unfortunately, I'm finding that my adapter board is behaving very intermittently. It was working great on the first night, but I started messing with it some more last night and ran into all kinds of problems. It gets hung up polling an SCC register bit (TX FIFO full) that never clears. Occasionally I'll reboot it and it will work fine. I never saw anything like this on my breadboard, and the code was literally copy/pasted except for the GPIO pin accesses and a few other small hardware-specific things. I'm setting it aside for a while to get my mind off the project and will come back to it, hopefully with fresh ideas about what's wrong. I suspect it's a hardware problem, but can't rule anything out yet.
I'm also a little frustrated with the BBB--decided to upgrade my kernel, and found out that things have changed in the newer kernels that will make it more difficult for me to set up the 2 GPIO pins on the BBB's header that I use. The Device Tree Overlay stuff is not compatible with newer kernels.
I certainly hope I think of something...nothing yet, but it's only been a few days
No, I don't have a logic analyzer. I do have access to one at work though (Intronix LogicPort). I've heard good things about the Saleae analyzers. You're right, it would be very helpful. At work we just ordered a Rigol MSO1104Z, which has a 16-channel digital input port built in. I'll be interested to see how it performs when it arrives...
Sometimes the light stays on until I touch the Ethernet jack too. I also verified that the SCC is sometimes giving me the wrong info back when I read registers. This effect combined with the SCC sometimes giving me the wrong info led me to believe that one of the SCC's input pins was probably floating.
Sure enough, I accidentally left the A/!B pin floating. It should be tied to +5V to keep the SCC on channel A. I think the reason it worked the first time is that it had already been turned on for a long time, and it seems like the longer I leave the board on, the more likely it will start working. Somehow that floating pin's voltage is probably creeping up slowly.
I just took a look and sure enough, I actually did try to hook up the A/!B pin in the schematic--mistakenly to ground! But somehow, I screwed it up and Eagle whined about "supply pin GND overwritten with more than one signal", so it didn't work. Eagle's ERC also whined to me about the A/B pin only having input pins connected. Bottom line is that I forgot to run the ERC before sending the board off. The moral of this story? Always run the ERC check! On the bright side, it did make for a fun video, and a great learning experience!
Edit: And, it's fixed with some patch wire! The LocalTalk converter project is back in operation.
Progress update: I'm working on integrating this board so it can work with netatalk. The strategy I've chosen is to do the necessary steps to make it appear as a real LocalTalk network interface in Linux (lt0), so netatalk will be able to talk with it directly and it will work seamlessly with any program that creates AppleTalk sockets. Basically, it's a network interface driver that talks over the serial port to send/receive packets to/from my LPC11U68 board. It's implemented as a TTY line discipline. A user-space program tells the serial port to use the special LocalTalk line discipline instead of the regular N_TTY line discipline. After this happens, my network driver handles sending and receiving data on the serial port instead of the normal Linux serial routines.
I found a driver (drivers/net/can/slcan.c) that uses a similar strategy for CAN-to-USB-serial adapters, so I made a new version of it that can do LocalTalk with the protocol that my LPC11U68 board talks with. The driver appears to work and netatalk can send and receive packets, but I don't think LocalTalk is fully working anymore in the Linux kernel. The common Linux AppleTalk code is doing some bizarre stuff that causes it to crash running out of room in a socket buffer unless I fake it out by saying that LocalTalk headers are 50 bytes. I think I'm going to have to do some serious debugging inside that part of the code to verify that everything it does is correct. I doubt that code has been tested on hardware interfaces other than Ethernet/WiFi in a long time. It's also possible I'm doing something wrong in my driver, but the actual problems I'm seeing are occurring inside the common AppleTalk DDP stuff where for some bizarre reason it's prepending a SNAP header (which only applies to Ethernet/WiFi). We'll see.
With the hack, I was able to get my IIci to see my Mac mini through the BBB and cape, with netatalk's atalkd acting as a router between Ethernet and LocalTalk. Each interface had a separate zone and both zones showed up in the Chooser. Unfortunately, I couldn't actually connect to the Mac mini though. I think I'm almost there, and there are just a few glitches that need to be resolved with LocalTalk in the kernel.
I figured it out and everything's working great! The problems were half my fault, half Linux's fault.
There's a bug in net/appletalk/ddp.c introduced somewhere in the kernel 2.6 era I presume. It seems that outgoing broadcast AppleTalk packets are being looped back onto the same machine...not totally sure why, but it does it on purpose. A change somewhere between Linux 2.4 and 3.8 changed the way the loopback worked, and now it's trying to prepend too many header bytes onto the loopback packet. I fixed it by hacking in a "+ 16" to a few places where the packet is created, but I'd like to eventually figure out the "correct" way to fix it and submit a patch. So yeah, that part was Linux's fault.
My mistake was that when I saw my Mac mini show up in the Chooser, everything was working fine. It's just that the Mac mini's netatalk server needed to be restarted because I had changed zones and routers and stuff. After doing that, everything's working great. So the BBB is acting as a router between the LocalTalk and Ethernet interfaces. I went ahead and gave each side a different zone name just for fun. Here's a screenshot:
So...yay! I have a kernel module that communicates with my cape over the UART and creates a real LocalTalk network interface called lt0 on the BBB, and it works! No patches to netatalk needed -- I'm using stock netatalk 2.2.2 from the Ubuntu repository. All the code for the kernel module and the userspace line discipline setter utility is committed to the SVN repo. I think I'm getting close to the point where I need to make a full bootable SD card that has everything needed for a working setup.
Absolute fanatastic! This is REALLY a big achievment.
I have been struggling with a PC LocalTalk card under Linux some years ago. Not simple to get it working!
I'm looking forward to test or try your solution.!!!!
If Netatalk is added to the device it would be a good idea to consider Stefan Bethke's macipgw also.
Then it would be the perfect blackbox for connecting your LocalTalk only device to the network. You can have LocalTalk communication for connecting to your Apple Shares and TCP/IP for Internet apps.
Thanks for the link! I have actually already read your article, and it was a huge help in figuring out how to bring things up after I wrote the LocalTalk driver.
I think there are some bugs in Linux with LocalTalk interfaces, which isn't too surprising considering we are probably the only two people in the world who have even tried LocalTalk on Linux within the past five years (LOL). nbplookup doesn't find anything on the LocalTalk side, for example--and my Mac should be showing up. So there are some bugs to work out. Also, the drivers for the LocalTalk cards are really old and could have problems--I'm not surprised that you had trouble with Linux 2.6.
I definitely plan on getting a MacIP gateway working. I was looking at macipgw, but it looks like Linux has a lot of the MacIP capabilities built into the kernel, and it just has to be activated with MacGated. I was playing around with MacGated last weekend, which I know you have also played with from the Google results I found. (No, I promise, I'm not stalking you! LOL). I think before I mess with it, I want to ensure that LocalTalk is working 100% reliably inside of the kernel.