USB2LT TashTalk Usb to LocalTalk

I did! but apparently that trace was inserted while I was preparing the board for production? I have no idea how, I can't draw it again! This time to be sure I printed out the gerber file :D
 
First 5 prototypes are mounted! It seems to work quite well, I'm very happy :)
I want to finish my modtashtalk so it can be used with netatalk, but I'm wondering if it is worth.
Ooo... nice & congrats! Will they be going in sale somewhere/time? 🙂
Yes! My plan is to produce some and sale them. The project is also on git so people can build their own if they want. I will look into having these built and the costs, now I soldered the ICs by hand but it takes a bit and it is a quite fiddly to test them.
 
Waking this thread up again...

It'd be great to make a version of this that supported an onboard transformer (discussion in this thread) and went directly to PhoneNet or LocalTalk miniDIN-3 connectors. I love the idea of having a USB LocalTalk dongle that looks like a vintage PhoneNet/LocalTalk dongle (with a 3D-printed enclosure, even!) but plugs into a modern machine via USB.

Putting a DIP-8 footprint on the board and shorting together pins 2-3 and 6-7 would work for the token ring transformers that I've found to work and likely for a range of other through-hole transformers too; a similar set of SMT pads in the same place would expand the compatibility further still...
 
I think it should be doable, there was also a transceiver + transformer in a package IIRC mentioned in previous thread?
Time for me is quite limited now, but I can have a look in a couple weeks.
 
Comments are welcome and keep in mind this is just the first draft :)

I was just looking at this while knocking up my own similar thing for my own use and noticed something very belatedly - you've crossed over the CTS signal to the RTS pin on the USB-to-UART, but RTS is a signal from the DTE to the DCE - the FT230X data sheet duly shows it as an output. The CTS signal on the tashtalk is a DCE-like CTS signal - that is to say, it's an output from the tashtalk to the DTE to tell it it can send more data. Therefore, the RTS/CTS here should not be swapped over, by wiring the tashtalk's CTS to the FT230X's RTS, you're wiring two outputs together and nothing sensible will get done with the CTS signal, probably leading to buffer overflows.

@Tashtari could I have a second opinion on this, just to make sure I'm not hallucinating? I hate dealing with UART flow control
 
by wiring the tashtalk's CTS to the FT230X's RTS, you're wiring two outputs together and nothing sensible will get done with the CTS signal, probably leading to buffer overflows.
Your read is correct: the CTS pin is a flow control output used to signal the other end of the connection whether or not it should hold off sending data to TashTalk, and if it isn't respected, TashTalk is virtually guaranteed to get into a bad state.

I'm realizing that I likely helped to confuse this issue by labelling Tx and Rx on the TashTalk pinout as though it were a DTE (Tx as an output, Rx as an input) but labelling CTS as though it were a DCE (as an output). Sorry for that!
 
I'm realizing that I likely helped to confuse this issue by labelling Tx and Rx on the TashTalk pinout as though it were a DTE (Tx as an output, Rx as an input) but labelling CTS as though it were a DCE (as an output). Sorry for that!

Well, while tashtalk pin labelling is perhaps non-optimal, it's just a drop in the sea of awful terminological decisions related to UARTs, so I don't think you need to be too apologetic...
 
Well, while tashtalk pin labelling is perhaps non-optimal, it's just a drop in the sea of awful terminological decisions related to UARTs, so I don't think you need to be too apologetic...
This is true. Still, maybe I ought to rebrand it to "flow control output" or something more generic, if for no other reason than "RTS" and "CTS" are also used by LocalTalk to refer to control frames, further muddying the waters...
 
Back
Top