68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
USB2LT TashTalk Usb to LocalTalk
Posted by: twelvetone12 on 2023-11-11 06:42:13 I'm wondering if adding a buffer that selects R or D makes any difference, but I'm not sure, since the datasheet says R is high Z when RE/ is high, and D is ignored with DE low, so it really should make no difference. I'm confused.
Posted by: bigmessowires on 2023-11-11 07:48:22 I haven't followed all the details of this, but could there be an output that's supposed to be open-drain and you're using push-pull outputs? That could cause problems in a two-transceiver setup where two sources could potentially drive the same signals.
Posted by: Tashtari on 2023-11-11 07:57:59 GOOD NEWS! I reproduced it with a two-transceiver setup! It's exactly the same, down to the 17 retries. I still don't know the root cause, but at least I can experiment for myself now. I haven't followed all the details of this, but could there be an output that's supposed to be open-drain and you're using push-pull outputs? That could cause problems in a two-transceiver setup where two sources could potentially drive the same signals. Shouldn't be... there aren't any open drain pins in the system. The TashTalk PIC has an active-high driver enable pin (always output) and a single pin that switches direction to do LocalTalk input and output; the transceivers have an active-high driver enable pin and an active-low receiver enable pin (both inputs), and the firmware changes direction on the LocalTalk I/O pin within one cycle (125 ns) of toggling the driver enable output pin.
Posted by: twelvetone12 on 2023-11-11 08:48:58 Super! I'm really curious if you find anything, I'm really out of ideas right now.
Posted by: Tashtari on 2023-11-11 09:42:21 I'm digging... First off, it looks like 17 isn't as much of a clue as I'd hoped. There's apparently an old off-by-one bug in the firmware that means it tries sending a frame 33 times instead of the expected 32. Divide 33 by 2 and round up and you get... 17. Fixed that bug and now it retries 16 times. Anyway, I think I have a root cause. Here's what's happening: TT sends its RTS frame Having finished, TT switches the LT pin into receive mode The LT pin (which is still cooling down from being driven) returns to idle (high), TT mistakenly thinks it's the beginning of a frame, and starts receiving it TT discovers that this non-frame is not the CTS frame that it's expecting, flags a collision, and starts to wait for the line to be idle so it can send another RTS frame The CTS frame comes in, TT starts receiving it, and echoes it to the UART TT isn't expecting a CTS frame because it's waiting for the line to be idle so it can send an RTS frame, so it flags a deferral and starts waiting for the line to be idle again The double-fault of a collision followed by a deferral is why there are only 16 apparent attempts to send the frame. Apparently, the two-transceiver arrangement has enough latency when returning to idle compared to the one-transceiver arrangement that it triggers the bug. This may be fixable by just inserting a delay, but I've got to be careful how and where I insert it... the TashTalk code is a bit delicate.
Posted by: twelvetone12 on 2023-11-11 09:47:27 If I understand correctly, the problem is that TT switches to input and then the pin goes high? What if we add a pullup?
Posted by: Tashtari on 2023-11-11 09:51:12 If I understand correctly, the problem is that TT switches to input and then the pin goes high? What if we add a pullup? I'm not sure if that would work, I think the transceiver is correctly interpreting the state of the LocalTalk bus, it's just that the bus itself takes a few microseconds to return to idle and TashTalk isn't waiting long enough. I can correct this in firmware, I just need to make sure I'm doing it in a way that doesn't break anything else in the process.
Posted by: twelvetone12 on 2023-11-11 10:03:08 Mmmmh ok I see (and I tried the pullup and did not work lol), but maybe a transistor could do the trick? Basically it removes one of the two tranceivers from the bus when the LTEN pin flips?
Posted by: Tashtari on 2023-11-11 10:11:01 Mmmmh ok I see (and I tried the pullup and did not work lol), but maybe a transistor could do the trick? Basically it removes one of the two tranceivers from the bus when the LTEN pin flips? You're welcome to try if you want to but I would think that the transceiver IC already does that - lowering the DE pin should stop it driving the LocalTalk bus at all. Anyway, I think I know how I'm going to fix this, I should have a build for you to test within the hour.
Posted by: twelvetone12 on 2023-11-11 10:16:07 Cool! Thank you very much! I will try to test it this night if I make it or tomorrow morning. The scary part is that I need to desolder the PIC and I need to be fully awake for that 🙂
Posted by: Tashtari on 2023-11-11 10:29:09 Here it is! Let me know if it fixes things for you.
Posted by: twelvetone12 on 2023-11-11 23:47:57 Ok, I reprogrammed the pic and it works perfectly! I'm transferring files and printing. Thank you very much for this! I want to run some more tests, like using a serial cable instead of the two phonenet adapters, but I think it is ok. Il will order new boards fixing the problems this one has, and if you want I can send you one. Then we should see if the USB2PhoneNet thing is doable 😉
Posted by: Tashtari on 2023-11-12 04:20:03 Ok, I reprogrammed the pic and it works perfectly! Oh, thank goodness. =) For future reference: The trouble was caused by that little delay between when DE went low and when LT went high at the end of the RTS frame and before the CTS frame - I measured it at about 2.46 us in my setup. If you get a minute, could you measure how long the delay is on the USB2LT? The firmware now tolerates a delay of up to 5.5 us, I'd like to check that that's a comfortable margin before I release this fix as v2.1.1.
Posted by: twelvetone12 on 2023-11-12 05:13:08 If I got my reading right, it is around 1.8uS: And here is the clean view:
Posted by: Tashtari on 2023-11-12 05:15:50 Okay, cool, thanks for checking that. 5.5 us seems like a good threshold. I'll update Github and release v2.1.1 shortly.
Posted by: twelvetone12 on 2023-11-12 05:19:15 Super! Thanks to you for looking into this. I fixed the other problems with the boards and I will order them this week.
Posted by: twelvetone12 on 2024-01-19 06:03:05 Finally had time to test the new boards, just to discover I made an error and the regulator releases the magic smoke. Who can spot the error? sigh Time to make a next batch of boards I guess.
Posted by: Tashtari on 2024-01-19 06:23:00 Happens to the best of us. =/ My condolences.
Posted by: twelvetone12 on 2024-01-20 01:03:44 Well as they say, it's not use crying over spilled milk! So a new batch is on it's way, I just hope it arrives before I have travel again.
Posted by: demik on 2024-01-20 04:37:18 Finally had time to test the new boards, just to discover I made an error and the regulator releases the magic smoke. Who can spot the error? sigh Didn't use ERC ? 🙂
< 4 >