Preferred local PCB comms, UART or USB?

B

blazini36

Active member
I started thinking about making a PCB that will carry both a Teensy 4.1 and an Rpi CM4. I've had a couple of CM4s sitting in a drawer next to a bunch of Teensy 4.0s and 4.1s for a while now. I got the bug to build a PnP machine, and somehow a 3D printer as well which I haven't had as of yet. Probably doesn't really matter either way as something like klipper probably only sends small amounts of data but I've come to somewhat dislike USB for latency and general issues. So for local PCB communication I'm leaning towards UART.

USB is half duplex and differential from the silicon so there's some noise immunity but I'm rather confident I can handle single ended UART without noise being too much of a concern. I haven't even begun to route the board yet and it seems kind of silly but I'd almost be tempted to stick RS422 transceivers at both ends if it becomes more than a couple of inches. Sounds like over kill but who knows with a bunch of little stepper drivers buzzing away. I'll likely route SPI too but I don't think it's currently supported with anything I'd use software wise.

I'm curious what other people prefer to do for serial communication in situations like this.
 
For signals wired relatively short distance on a PCB, any of these should be fine. If you're more comfortable with 1 way over the others, probably best to go with whatever will be easiest for you to use.

Ordinary UART serial has a nice simplicity. But unless you also wire up RTS & CTS, it has no flow control which puts more timing requirements onto your code just to reliably receive data. You have to add code to parse the messages from a stream of bytes, because the protocol doesn't give any indication of message framing. Over and over on this forum we see poorly written serial receive code. It can be done well, but many people don't.

If you're good with those limitations, might as well go with serial.

For longer distance communication where high power motor control is involved, ethernet might make a lot of sense. The signals go through magnetic coupling on both ends, so you automatically get isolation from ground shift due to high currents. Signals are fully differential without DC bias (like USB). Cheap network cables are unshielded, but today shielded cable is readily available, even cables where each twisted pair is individually shielded. On the SBC or PC side, modern operating systems tend to have well optimized network drivers that (usually) give low latency.
 
I'm not much of a software guy so I pretty much have to rely on "what's there". I've done several things with Teensy's focused on special serial applications but in those cases I had the help of a programmer and I knew exactly what it was talking to and how it worked.

Wiring up the flow control isn't much of an issue as long as I can spare the GPIO pins. I don't know alot about the specifics of the serial implementation in say Marlin but it seems to be widely used even with higher baud rates.

As for Ethernet, I don't see it's use anywhere in the small machine world and I think tying up the Rpi's only Ethernet port for MCU communication is probably not a great idea. I tend to use small X86 PCs for larger machines, specifically ones with 2 ethernet ports because in those cases I use Mesa cards that run over 100mbit. The open source FPGA firmware Mesa designed has actually been ported to alot of things but they also used SPI in a couple of Rpi specific products. I tried to drum up some interest in Teensy 4.x ports a ways back but people tend to be stuck on what they know works. There's cases where I want a very tidy all in one type of install in that's where I'm going with this. Just trying to point it in the right direction.

One thing I just noticed is that Klipper tries to install firmware to the MCU itself. I don't know the specifics about that but I assume that the Teensy can only be flashed via it's micro USB port? Not sure if any of that is necessary but now I'm curious if the Teensy 4.x can be flashed via any other method?
 
For same-PCB communication, you can do SPI & UART, decide later. No need for UARTS XCVRs on the same board, unless you want multidrop.

No need for USB, as you will introduce a cable without locking connectors, which I'd avoid for your primary data link.
 
You must log in or register to reply here.
Back
Top