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 
USB2LT TashTalk Usb to LocalTalk
- Thread starter twelvetone12
- Start date
New boards arrived this week and I'm Happy to report they work very well!
Ooo... nice & congrats! Will they be going in sale somewhere/time?
Cool, congratulations! I'm looking forward to having another TashTalk product out there.
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.
I want to finish my modtashtalk so it can be used with netatalk, but I'm wondering if it is worth.
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.Ooo... nice & congrats! Will they be going in sale somewhere/time?
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...
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.
Time for me is quite limited now, but I can have a look in a couple weeks.
bomp
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
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!
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...
"I THIRST FOR BYTES", active-low? :-D
0 = both feet on accelerator
1 = both feet on brake
A 128-byte buffer that must never, never, never overflow or underflow while conveying frames that can be up to 605 bytes (well, 1023, actually) in length, with "here be dragons" as the stated consequence... really, sometimes I'm amazed it works at all, but I've seen scope traces that confirm that the RPi and FTDI UARTs start and stop sending data almost immediately in response to CTS, so I'll not argue.
Mmh I haven't touched this in a couple years, when I tested it it worked pretty well, but right now I have no capacity to work on this anymore.
totally understandable.
Similar threads
