Tashtari
PIC Whisperer
While I've been mostly talking about this project in the IRC channel, it occurred to me that 68kmla has (or, by some definitions, is) a forum, so I thought I'd better make a thread about it to document it and see what folks think.
Introducing... TashTalk!
Elevator Pitch
It's a LocalTalk interface, contained entirely within a single Microchip PIC12F1840 (8 pins, ~$1.50) microcontroller.
It handles all the time-sensitive aspects of LocalTalk, bidirectionally bitbanging the SDLC and FM0 (a.k.a. differential Manchester) based protocol at the data link and physical layers, sending and responding to control frames with CRC calculation and checking, and collision avoidance and retransmission. It can also respond to any number/combination of node IDs for use in bridging applications. It can be interfaced directly to user-mode software on a Raspberry Pi or BeagleBone or full PC, or it can be part of a larger embedded system. It slices, it dices, etc.
Project Status
Code-complete and passing basic testing, but not yet rigorously tested. What I've seen is encouraging, but I'm not yet ready to say there aren't game-breaking bugs.
Caveats
Because of the PIC12F1840's limited memory and the way its UART is used, the host's UART needs to be able to handle a baud rate of 800 kbps. Conventional UARTs don't expect to be pushed beyond 115.2 kbps. In addition, the PIC has a 128-byte receiver queue, which is considerably smaller than the largest possible LocalTalk frame (605 bytes). As such, the host needs to respect when the CTS hardware flow control line is deasserted so the queue doesn't overflow and be quick about resuming transmission when CTS is reasserted so the queue doesn't underflow either.
Also, "single-chip" doesn't include the separate and necessary driver/receiver chip for RS-422/485. Sorry. =)
What's Next
For testing, I'm using a PIC I knocked together as a crude serial bridge that receives at 115.2 kbps and then retransmits at 800 kbps, but there are limits to how much I can do with this, so I have an FTDI breakout (https://www.sparkfun.com/products/10275) on order, with the idea that I can use it to fashion a protocol bridge of some kind on the host - either to EtherTalk frames on the host side or to LToUDP for use with minivmac. I'd like to eventually be able to build this (probably with some help) into a Raspberry Pi 'hat' board that can be used with a purpose-built image to run macipgw and netatalk 2.x, forming an accessible turnkey solution for getting one or more vintage macs on the internet as well as accessing a file server.
Code
github.com
Shoutouts to @cheesestraws and everyone else on the IRC channel (many of whose forum IDs I don't know, sorry!) who gave advice and encouragement along the way! Would love to hear from anyone interested in using this or working it into another project, referrals to relevant projects or prior art, questions, comments, well-wishes...
Introducing... TashTalk!
Elevator Pitch
It's a LocalTalk interface, contained entirely within a single Microchip PIC12F1840 (8 pins, ~$1.50) microcontroller.
It handles all the time-sensitive aspects of LocalTalk, bidirectionally bitbanging the SDLC and FM0 (a.k.a. differential Manchester) based protocol at the data link and physical layers, sending and responding to control frames with CRC calculation and checking, and collision avoidance and retransmission. It can also respond to any number/combination of node IDs for use in bridging applications. It can be interfaced directly to user-mode software on a Raspberry Pi or BeagleBone or full PC, or it can be part of a larger embedded system. It slices, it dices, etc.
Project Status
Code-complete and passing basic testing, but not yet rigorously tested. What I've seen is encouraging, but I'm not yet ready to say there aren't game-breaking bugs.
Caveats
Because of the PIC12F1840's limited memory and the way its UART is used, the host's UART needs to be able to handle a baud rate of 800 kbps. Conventional UARTs don't expect to be pushed beyond 115.2 kbps. In addition, the PIC has a 128-byte receiver queue, which is considerably smaller than the largest possible LocalTalk frame (605 bytes). As such, the host needs to respect when the CTS hardware flow control line is deasserted so the queue doesn't overflow and be quick about resuming transmission when CTS is reasserted so the queue doesn't underflow either.
Also, "single-chip" doesn't include the separate and necessary driver/receiver chip for RS-422/485. Sorry. =)
What's Next
For testing, I'm using a PIC I knocked together as a crude serial bridge that receives at 115.2 kbps and then retransmits at 800 kbps, but there are limits to how much I can do with this, so I have an FTDI breakout (https://www.sparkfun.com/products/10275) on order, with the idea that I can use it to fashion a protocol bridge of some kind on the host - either to EtherTalk frames on the host side or to LToUDP for use with minivmac. I'd like to eventually be able to build this (probably with some help) into a Raspberry Pi 'hat' board that can be used with a purpose-built image to run macipgw and netatalk 2.x, forming an accessible turnkey solution for getting one or more vintage macs on the internet as well as accessing a file server.
Code
GitHub - lampmerchant/tashtalk: An interface for Apple's LocalTalk networking protocol.
An interface for Apple's LocalTalk networking protocol. - lampmerchant/tashtalk
Shoutouts to @cheesestraws and everyone else on the IRC channel (many of whose forum IDs I don't know, sorry!) who gave advice and encouragement along the way! Would love to hear from anyone interested in using this or working it into another project, referrals to relevant projects or prior art, questions, comments, well-wishes...