TashTalk: Single-Chip LocalTalk Interface

[mactjaap]

Hi Andrew,

I did see you question about the tashtalk setup. Unfortunately I have two problems

One: my RPi seems to be broken. Two. I dismantled my setup. I was cleaning up my hobby office….

So I hope someone else can help you for now!

 

[tashtari]

This is sort of a non-announcement since there's no binary change from the 20210914 release, but I'm sufficiently satisfied with the positive reports from AirTalk users to release a v1.0.0 of TashTalk:

Release v1.0.0 · lampmerchant/tashtalk

Binary identical to 20210914

github.com

I'm contemplating making a breaking change (which will be released as v2.0.0) to mux the LocalTalk in and out pins onto the same pin (RA5), freeing up RA3 to act as !MCLR, which is the PIC's reset pin. Tying this pin high will see the chip acting the same as before, but pulling it low will hold the chip in reset and tristate all its pins, allowing for TashTalk to share its RS422 transceiver with other circuitry. @bdurbrow was interested in such a change a while back, but I was at the time contemplating implementing it with another serial command, a solution that I didn't like as much because it added too many states to the firmware and increased the chances of getting the chip into a bad state. With a hard reset pin, though, you can't miss - plus it gives another way to force the chip to a known-good state.

...We'll just have to see whether I understand my own code well enough to pull this off. =)

 

[tashtari]

Aaaaand no sooner mentioned than managed! It even worked on the first try.

I guess I go forward, as I said, with putting this on track to be released as v2.0.0, but of course it's incompatible with v1.0.0 and designs that use v1.0.0 (@cheesestraws 's AirTalk and @bdurbrow 's TashTalkHat).

It'd be neat to come up with a new RPi hat that only uses one transceiver (I used the SN65HVD08). It could be pretty slim considering it mainly needs two ICs and a mini-DIN connector. I might take a crack at this myself, but as with most circuit-based things, I'd be much more comfortable working with someone else... any volunteers?

 

[tashtari]

My test setup. I love these little mini-breadboards... like circuit McNuggets.

Rather than use separate drivers/receivers like before, I have RxD+/TxD+ and RxD-/TxD- shorted together on the PhoneNet dongle and it seems to work. I don't know exactly why it works, though... part and parcel of not being an electrical engineer, I suppose.

 

[tashtari]

The hats are here! I have enough parts to put together a handful of kits, which I'll sell (at cost) for $12 each. Send me a DM if you're interested.

 

[tashtari]

Aaaaand they've all been snapped up! Anyone else who's interested, be sure to contact me anyway, if there's enough interest, I'll make more.

 

[Phipli]

How come you don't use the MAX488? It has RxD+, RxD-, TxD+ and TxD-?

 

[tashtari]

How come you don't use the MAX488? It has RxD+, RxD-, TxD+ and TxD-?

I suppose because I didn't feel like it should be necessary given that LocalTalk is just one differential pair instead of two. Of course, as long as the transceiver has an active-low receiver enable and an active-high driver enable, this should work fine too.

...And because I have an irrational love of 8-pin DIPs, that too. =)

 

[Phipli]

I suppose because I didn't feel like it should be necessary given that LocalTalk is just one differential pair instead of two. Of course, as long as the transceiver has an active-low receiver enable and an active-high driver enable, this should work fine too.

...And because I have an irrational love of 8-pin DIPs, that too. =)

They are 8 pin dips

It's the active-low receiver enable and active-high driver enable that are missing I guess.

 

[tashtari]

Oops, I was looking at the wrong chip. Hmm. I thought a driver enable would be necessary given that LT is a shared bus, but because it has transformers at every node, I suppose you could use a MAX488 with the 1.x firmware (since it has a separate input and output line)? Or I could produce a version of the firmware that didn't have a driver enable output at all, just an input and output line... I don't know. Is there an advantage to that?

 

[Phipli]

Oops, I was looking at the wrong chip. Hmm. I thought a driver enable would be necessary given that LT is a shared bus, but because it has transformers at every node, I suppose you could use a MAX488 with the 1.x firmware (since it has a separate input and output line)? Or I could produce a version of the firmware that didn't have a driver enable output at all, just an input and output line... I don't know. Is there an advantage to that?

Oh, I'm starting from a position of ignorance - the question was "forgive my stupidity, but I see the 488 has two pairs and you're using two single pair chips, what drove this choice?" Rather than "you should be using a 488".

I've been using some MAX488s but for a single device, rather than something working as a bus.

 

[tashtari]

Ohh, I see. I was using two SN65HVD08s (single-pair chip with driver/receiver enable) in my early prototypes, but the TashTalk hat only uses one, with the TxD and RxD pins shorted together, and it works fine.

 

[robin-fo]

Is tashtalkd already compatible with the new Raspberry Pi hat?

 

[tashtari]

Is tashtalkd already compatible with the new Raspberry Pi hat?

It is! TashTalk v1.x and v2.x both have an identical UART protocol, it's just the pinout that's different.

 

[tashtari]

I should note here that some debugging with FinkRMT on the IRC channel has shown that the TashTalk 2 hat won't work with an Apple serial cable (not a use case for which I planned), you need to use a LocalTalk or PhoneNet dongle.

 

[robin-fo]

I should note here that some debugging with FinkRMT on the IRC channel has shown that the TashTalk 2 hat won't work with an Apple serial cable (not a use case for which I planned), you need to use a LocalTalk or PhoneNet dongle.

Thanks! That‘s why my setup didn‘t work!