Feature request: native support for TashTalk UART protocol
Opened this issue · 13 comments
There was some talk about this a while back, but it'd be great if this tool could subsume the capabilities of tashtalkd and speak TashTalk's UART protocol natively, for to serve as a bridge between LToUDP/EtherTalk and physical LocalTalk networks.
Sounds reasonable. The code doesn’t look too different from multitalk’s udp.Multicast() implementation. In the short term, I think it would just be a matter of splitting the part of it that does LocalTalk/EtherTalk translation from the part that does LocalTalk specific things (address tracking).
On the other hand, it might be a little more tricky because of networks. In order to bridge LToU and TashTalk on the same network, it would be necessary to bypass the LT→ET→LT roundtrip that currently happens. In order to bridge them on different networks, multitalk would need to implement the router features discussed in #1.
The main issue is how to check my work. I don’t have any TashTalk PICs to test with. Would you be able to write out a few test cases? A few of them would be:
- CRC calculation (empty, long, and short byte sequences and the corresponding CRC)
- Frame encoding/decoding (various control frames and data frames; corresponding values with and without LocalTalk framing, and with and without CRC; some invalid frames)
Would you be able to write out a few test cases?
Sure, I'll see what I can do.
CRC calculation examples are easy enough to come up with (and I'll happily grant permission for you to lift the relevant code directly from tashtalkd to cross the BSD/GPL3 line). For frame encoding/decoding, am I correct in assuming you'd be looking for a handful of examples for which you have (1) the output from TashTalk's UART, escape sequences and all, and (2) the resulting LT frame? I ask because the other direction is pretty much just the raw frame with an 0x01 prepended to it.
As an alternative and/or an addition, though, would you like a TashTalk PIC or two to play with? I'm more than happy to hook you up at my own expense. If you've got a Raspberry Pi and are comfortable with breadboarding something and have some parts on hand, that's all you need... if not, I might be able to fill in some of the blanks. I'm also working on a run of my own TashTalk Pi hats that I hope will be available soon (though I'm not sure I'd recommend waiting for them...)
Would you be able to write out a few test cases?
Sure, I'll see what I can do.
CRC calculation examples are easy enough to come up with (and I'll happily grant permission for you to lift the relevant code directly from tashtalkd to cross the BSD/GPL3 line). For frame encoding/decoding, am I correct in assuming you'd be looking for a handful of examples for which you have (1) the output from TashTalk's UART, escape sequences and all, and (2) the resulting LT frame? I ask because the other direction is pretty much just the raw frame with an 0x01 prepended to it.
Right. I guess for the host-to-TashTalk direction, it may not be needed. I can probably come up with invalid frames to check; I figure the sending code should ensure that CRCs are correct and the actual frame lengths match TashTalk’s inferred length.
As an alternative and/or an addition, though, would you like a TashTalk PIC or two to play with? I'm more than happy to hook you up at my own expense. If you've got a Raspberry Pi and are comfortable with breadboarding something and have some parts on hand, that's all you need... if not, I might be able to fill in some of the blanks. I'm also working on a run of my own TashTalk Pi hats that I hope will be available soon (though I'm not sure I'd recommend waiting for them...)
Thanks for the offer. Now isn’t a good time for hardware experimentation, as I’m expecting some shuffling in the next month. I do have breadboards and SP3485 breakouts handy; are those appropriate for the voltage shifting? After things settle for me, I was considering buying a couple AirTalks and asking about some extra PICs with them.
I do have breadboards and SP3485 breakouts handy; are those appropriate for the voltage shifting?
The SP3485 looks like it should work. You'll probably also want something that breaks out the pins of an 8-pin mini-DIN for a LocalTalk or PhoneNet dongle (unless you want to cut the connector off of one).
I'll come up with some test cases for you soon. Let me know (here or on 68kmla) if you decide you want some pre-programmed TashTalk PICs, though cheesestraws should be able to provide them as well.
Yeah, if you're willing to brave the slightly dubious international shipping from the UK at the moment, I've got about a hundred preprogrammed tashtalks ready here. Can pop a couple in the post for you no problem at all.
Some test case packets: test_cases.tar.gz
Wrote some code for this.
Is the large_data_all_zeroes-packet.bin test case you provided well-formed? It looks like there is a mismatch between the declared size (598/$0256) and the actual size (600/$0258).
Is the
large_data_all_zeroes-packet.bintest case you provided well-formed? It looks like there is a mismatch between the declared size (598/$0256) and the actual size (600/$0258).
Oops! Right you are, I made a mistake, it should be 600/0x0258. Updated testcases here:
test_cases2.tar.gz
I merged a preliminary implementation. I doubt it works; for all I know, I’ve broken the existing code while I was at it (I’m not set up to test at the moment). However, I tagged it so that the documentation for the new module can be published.
Cool! Thanks for getting on this so quickly. I have boards and parts hopefully arriving this weekend for a small batch of TashTalk Raspberry Pi hats, I'll earmark a couple of them to send to you whenever you're ready.
Tried out the hat, and had some serious confusion due to the serial port’s configuration changing and becoming invalid during operation. Eventually figured out that I need:
$ sudo systemctl stop serial-getty@ttyS0
$ sudo systemctl disable serial-getty@ttyS0
(oh, and also enable_uart=1 in config.txt)
Here to be a tester - "DiskJockey" on 68kmla forum.
Tested this last night.
TashTalk bridged to LToUDP: Works, but unreliable. tashtalkd seems more stable.
TashTalk bridged to EtherTalk: Completely broken. errors out with the following on all packets:
ERROR serial/tash.go:90 send failed {"bridge": "udp", "device": "/dev/ttyAMA0", "error": "invalid packet type: $02"} github.com/sfiera/multitalk/internal/serial.(*tt).write /home/user1/go/pkg/mod/github.com/sfiera/multitalk@v0.2.0/internal/serial/tash.go:90