USB2LT TashTalk Usb to LocalTalk

[twelvetone12]

ATmega328's UART can run faster with very low error rate, I use it at 500k. TashTalk on the PIC does 1M. I can't say anything on the EtherWave unfortunately, I never even saw one...

 

[Mk.558]

Well I'm curious what the benefit of using the uC's internal UART versus a dedicated "real" UART can do. AFAIK most of them aren't really designed for stuff above 115200bps.

 

[Phipli]

Well I'm curious what the benefit of using the uC's internal UART versus a dedicated "real" UART can do. AFAIK most of them aren't really designed for stuff above 115200bps.

How do you mean? The internal UART is a real UART, it is just integrated?

 

[twelvetone12]

Well I'm curious what the benefit of using the uC's internal UART versus a dedicated "real" UART can do. AFAIK most of them aren't really designed for stuff above 115200bps.

I guess it depends on the application? The atmega328 datasheet gives the usart settings for up to 1M when running @ 16mhz.

 

[Mk.558]

Well, a UART is a UART, but the built-in one of the PIC or Atmel uCs aren't as capable as dedicated UARTs, but I reckon everybody here already knows that. I believe our PIC expert here went with PIC because he's familiar with it, and that's a valid reason. I don't want to pretend I know any more than he does, or than anybody else here does. I'm just presenting a different option, doesn't mean it's the answer.

I went to Mouser and just searched for a UART that is RS485 compliant. Here's one:

https://www.ti.com/lit/ds/symlink/tl16c752c.pdf

There's no doubt that we won't get 3Mbps over the serial port. However given the 1.25MHz clock of the EtherWave Printer Adapter (or Mac/PB adapter, they're the same thing), surely a 16MHz clock could get you 1Mbps, which is still 5 times faster than standard LocalTalk at 230.4Kbps.

I guess my argument comes down to, besides familiarity with the PIC platform, which is way more than I know, what does the PIC uC offer over a dedicated UART? If all you're using the PIC uC for is the built-in UART, which admittedly is very nice, then besides the fact that a ATtiny85 or PIC "equivalent" is cheaper than a dedicated chip, isn't that kind of a waste? I'd argue that bumping the speed up is a better investment for the future for sure -- how we get to that part I don't know.

 

[robin-fo]

I personally consider PICs and Atmel stuff as obsolete. Why not consider to use something decent like a STM32? And yes, they have really fast UART peripherals. And how would you attach an external UART to a Microcontroller anyway? SPI? Or bitbang parallel?

 

[twelvetone12]

At my company we wanted to switch from Atmegas to STM32s (there is an almost pin-compatibile one with the 328p), we did a round of prototyping, I ported the firmware, we made the production boards, then the pandemic arrived, the STMs started to have a lead time of 90 weeks, then 100, then 110... so we had to revert back to Atmegas I'm still salty because while the 328p is a great platform, the STM32 was fantastic!
But for an application like this one (TashTalk and "slow" localtalk), a PIC is really enough

EDIT: IMHO the main difference is development tool and community support. Programming PICs and AVRs is very easy and there is a huge community, STMs on the other hand have a much more complex setup (unless you use one of the arduino boards) and documentation in my opinion is not so great, so probably that's why they tend to be used more for professional projects.

 

[robin-fo]

We had a similar problem with STM32 shortage, so we switched to Nucleo boards for prototypes..

Do you know STM32Cube IDE and CubeMX? It allows you to set up your project within minutes. This includes FreeRTOS and Networking! You would never want to go back to Arduino if you are a Pro

 

[twelvetone12]

Aaannddd I reversed the USB connector on the board! sigh

 

[twelvetone12]

We had a similar problem with STM32 shortage, so we switched to Nucleo boards for prototypes..

Do you know STM32Cube IDE and CubeMX? It allows you to set up your project within minutes. This includes FreeRTOS and Networking! You would never want to go back to Arduino if you are a Pro

I use both of them, but I find them extremely clunky

 

[Phipli]

I went to Mouser and just searched for a UART that is RS485 compliant. Here's one:

https://www.ti.com/lit/ds/symlink/tl16c752c.pdf

That is a parallel part. The MCU integrated UART will be faster because it will automatically shift out, while you'll have to use 8 pins for data, plus more for control for an external one. Code wise, you'll have to set the output and strobe it...

Pins wise... It uses a lot more pins to drive a parallel UART chip from an MCU, and renders small 8 pin ATTiny85 or similar chips unusable. It would need an external shift register? Which would be much, much much slower than the ATTiny's built in serial.

There is also the issue that a single 8 pin chip has become a two chip solution about 5 or 6 times the board space.

everybody here already knows that

Hum. Not sure I agree. I've never reached for an external UART when the MCU has an internal one. I'd reach for a better MCU if I needed more from my UART.

The spec of the UART won't be the limiting factor in your example. The built-in one will be faster.

 

[Phipli]

Aaannddd I reversed the USB connector on the board! sigh

Solder it on the underside?

We've all been there.

 

[cheesestraws]

I reckon everybody here already knows that

I don't actually think that's universally true at all.

I went to Mouser and just searched for a UART that is RS485 compliant. Here's one:

That's a parallel UART and is generally unsuitable for use with microcontrollers. Also, I don't know what being RS485 compliant has to do with this. You can't drive LocalTalk from a UART, and TashTalk doesn't. So this whole discussion is completely moot, because it isn't the UART that's the limiting factor, because LocalTalk is SDLC.

If you want to discuss this all further, might I suggest you start a new thread rather than derailing this one?

 

[twelvetone12]

Solder it on the underside?

We've all been there.

Oooh this is a good idea, I was already drawing ad adapter

 

[tashtari]

So I started this thread to discuss the question of LocalTalk-but-faster so we don't derail this one.

 

[twelvetone12]

boards are finally here!

 

[robin-fo]

Nice! I‘d be happy to test one if you have any surplus

 

[twelvetone12]

Yes très volontiers! If it works, I have 5 of the first run.

 

[twelvetone12]

Some bodges later, the inevitable reversed power ic that went off in smoke... I can receive data but not transmit @tashtari I'm using version 2.0, is there anything special I need to do in software for this version? Or is it just a drop in for 1.0?

This is the relevant part of the schematic:



I tied together the LocalTalk I/O pin and the DE. If I write I get data in the bus but it is completely mangled. I thought I could have inverted A and B but they seem ok? I also tried bypassing all the filtering in case something was wrong there.

I'm testing this with a second TashTalk/USB known to work (WTT from now). If I write from WTT -> USB2LT I see my data in the terminal, but if I do USB2LT -> WTT I only see garbage. It also does not work with my PowerBook. The WTT is based on the RPi hat with only one transceiver, but I would imagine it makes no difference? I'm using two PhoneNet connectors and they work with WTT and my PowerBook.
Does anybody see something obviously wrong in my schematic? Any idea is welcome

 

[tashtari]

I'm using version 2.0, is there anything special I need to do in software for this version? Or is it just a drop in for 1.0?

The UART protocol is the same between both versions, the only difference is that the !MCLR pin is available in 2.0.

I don't see anything obviously wrong on the signal side. What kind of garbage are you getting from LT_IN_OUT when you send data from the USB2LT, and what are you using for a test case?

I'd start testing by just writing a single ENQ frame to the UART (0x01 followed by 0x01 0x01 0x81 0x01 0x01 - the CRC doesn't have to be correct) and seeing if TashTalk sends out the correct data on LT_IN_OUT. If it does, then check whether it's something on the level-shifting side. If it doesn't, especially if you're running tashtalkd for testing, one thing I'm tempted to suggest is that flow control isn't working properly, maybe your USB-serial chip isn't reading CTS correctly, or the driver isn't using RTS/CTS flow control, or something like that?