Serial Port Emulation

One great thing about "UART" connections, is that you don't even need a UART. If all you want is output for "printf" logging/debugging, a single port pin and a few dozen lines of carefully crafted assembly language can be suffice. On an MSP430 running at 921KHz (yes, that's a K), you can easily bit-bang a 57.6K baud output "UART" (if there are no interrupts running during output).

--
Grant Edwards               grant.b.edwards        Yow! They collapsed 
                                  at               ... like nuns in the 
                              gmail.com            street ... they had no 
                                                   teen appeal!

Looking at the past, it seems embedded interfaces fall out of use about a decade or two behind the consumer space (assuming they ever reached).

For instance, parallel ports died out on consumer hardware somewhere between

2000-2008. While a very few select motherboards still have them, and there are some quite niche PCIe cards. by-and-large they're dead in the embedded space too - you couldn't ship a product that expected a parallel port today without people complaining.

Similarly GPIB's heyday was the 80s, and about 10 years ago it was still popular to control test gear, but nowadays USB and ethernet are favoured. (The longevity of test gear means instruments are still shipping with GPIB, but I suspect most people aren't using it unless they have legacy setups)

So the trick is to pick something that's current in the consumer space, and hope that its decline will be slow and lingering.

One way to look at this is to think about the sunk costs. For example, RJ45 cabling isn't going anywhere because there's a vast investment in structured wiring. So your chances are good if you speak some form of ethernet. Similarly there's a huge amount of IP out there. It would be wise to support IPv4 and IPv6 (the legacy and the new standard). Where you go with protocols on top of that stack (HTTP, HTTPS, SSH?) is a much more variable question. And there are security implications that aren't present in standards like RS232, which cause more churn that you might want (eg in what current web browsers do).

I would be wary of extrapolating a current long-life standard (RS232) that it will live for the same lifetime again. What drove RS232 was serial ports, printers and modems. We don't have dialup modems and dot matrix printers any more. It's only the serial consoles on servers and embedded boards that are really keeping RS232 alive at this point. Although it's sufficiently simple and sufficiently useful for software bringup that I can't imagine a RS232 to adaptor is going to be very complicated.

Although a TTL serial header on your motherboard (see every wifi router ever) labelled with pinouts and voltage levels must be fairly cockroach-friendly I'd imagine. Maybe you can't buy a suitable cable in the supermarket post-armageddon but somebody will still make something to read it, even if it's extremely niche. It's just so simple.

I'd say a basic USB 1 isn't likely to go anywhere because every keyboard and mouse speaks it, and I can't see that changing. If USB HID is an option for you, might be worth considering. Similarly USB 2.0 Mass Storage is fairly ubiquitous.

USB serial is a bit messier - the protocol is less well specified, there's already a wide range of silicon that needs its own special driver.

The current mode seems to be convergence - a USB Type-C connector does 'everything', and if a new protocol comes along we just add an addiitonal mode for that. So I'd worry less about cabling, and more about UI (how do we indicate that somebody plugged in an HDMI-over-Type-C cable and we don't have a video output?)

I do worry that all this negotiation is going to go wrong later down the track.

I think the wider question is: where do you want to be on the simplicity/performance curve? RS232 is very simple, and so implementations are easy, but it's not performant. If you want more performance, you might have to go to ethernet or USB Mass Storage, but they depend on larger host software stacks.

The other option is to distribute your own software stack - ie a virtual machine image. You're still relying on the host machine having an ethernet/USB port, but you can pin down things like browser versions and drivers.

Theo

I don't really see the problem with USB. It's 4 wires: VCC, D-, D+, GND Route that to a pin header, you can bodge something on to that just like serial. If you're running at USB 1.1 speeds then wire length isn't really an issue (any more than it is with TTL UART anyway). Bonus points if you use the same pinout at PC motherboard headers so their standard cabling will work.

If you choose to put a port on the back of a machine then people will need a cable for that. They might not have the right one, and their local supermarket might not have the right one, but they can order one. It's no worse than TTL UART.

I agree that UART is so simple that any microcontroller ever should be able to bit bang it, which helps.

Theo

Isn't USB specified for even shorter distances than RS-232 ?

The nice feature with USB, when bus powering small devices are used, there are hardly going to be ground potential issues.

One thing to watch out for, is slow control signal responses on USB-to-serial port converters. These mostly appear to have been designed for devices with a decent amount of buffering built in. So if you keep it so that you depend little on the RS-232 control signals, or that you can tolerate that sensing or changing them is slow, you should be fine.

But I agree that RS-232, both in nominal and TTL voltages, will be around a for considerable time.

The situation with USB connectors is unfortunate, of course, but you're rather seriously understating the mess that was parallel SCSI. At least with USB, if you manage to get both ends of the cable plugged in, it'll likely work. With SCSI you might have 8 and 16-bit wide devices, with both single-ended and differential signaling, as well as incompatible pinouts and genders all using the same (or different) connectors, meaning not only that identical looking cables could be incompatible, but devices with identical connectors could be, and devices sometimes required certainly orderings on the bus (mixing 8 and 16-bit devices, for example). And let's not forget termination (and god help you if you had mixed 8 and 16-bit devices).

or

r.

,

nt,

d a y

use

Low speed USB was designed for very simple implementations and is 1.5 Mbps raw data rate which is about as fast as UARTs are typically run. However t here are timing issues that limit cable length, at least for the higher spe eds. I think low speed is length limited to If you choose to put a port on the back of a machine then people will nee d a

o

Most USB stuff these days is micro-USB. Type-C is gaining ground with phon es and tablets, mostly because of the charging capabilities.

Serial ports, either TTL or RS-232, have a plethora of connectors used. I' ve seen, DB-25, DB-9, RJ-11, RJ-45 in multiple pinouts, 0.1" spaced 0.025" square posts in sum(n!) configurations where n ranges from 3 to 9.

le

That's why every design I do determines the interface by the requirements, not by a predefined choice of one size fits all.

I'm currently looking at rolling a design that will use an FTDI chip for it 's JTAG capabilities as well as providing a UART. But the package is large r than the device I want to control.

Rick C.

Agreed. I've done software UARTs on various devices, for several purposes. The first one I made was for use in an RS-485 bus system where the installers regularly mixed up the A and B lines. The solution was a software UART that detected the level of the idle line, and adjusted its polarity accordingly. I've also used a software UART on an AVR because I wanted a baud rate of 150 Hz (without a K), and that was too slow for the microcontroller's baud rate divisor.

I had a 57.6Kbaud software UART on an AVR once, running at 9.6 MHz. But that UART was full duplex, interrupt-driven and with 4 times oversampling on the receiver.

On more modern microcontrollers, you can do a bit-banged UART transmitter easily enough in C with a timer interrupt for the timing.

Yes, the low speed USB is not too bad - at those speeds you don't have to worry about connectors, impedances, length matching, etc. And it is possible to bit-bang it if you have to. But it is still more effort than handling a UART at that speed, especially on the software side.

5m USB cables are not uncommon, but beyond that you tend to have active cables (with a USB hub in the middle).

Yes, I agree.

(But one of the requirements I put on most new designs is a 3-pin or

6-pin header for an FTDI TTL UART to USB cable for debugging output.)

If you make sure your pinning on the FTDI chip matches those supported by OpenOCD (which can support a great variety of choices here), then your board has a built-in debugger. I did done something similar with a Coldfire board many years ago - it was a great convenience in test and programming.

The RS-422 is much worse. The local installers not only mixed A with B but possibly also A' with B' or mixing A with A' and B with B'.

The A, B, A' and B' notation is unambiguous but the meaning of the Tx+, Tx-, Rx+ and Rx- notation varies from manufacturer to manufacturer.

Some installers have managed to mix the signal ground (if present) with A, B, A' or B :-).

That's why I always use FTDI - when you only have one type of silicon, you only need drivers from one place. They are good at keeping their Windows drivers up to date, which is nice when every version of Windows changes things. And there has been solid support in Linux forever, as well as useful libraries (like pyftdi) for controlling them.

But HID is another possibility, especially if you have to connect to Windows systems.

USB mass storage has some advantages. Hosts already have the software stack - you just need it on the device. But it can be a handy way of doing software updates (copy the file onto the device), and makes it easy to distribute relevant software, PC applications, documentation, etc., with the hardware.

Ethernet is always nice, flexible and fast - but you again need software on the device. And there is always the question of how you identify the device - it is no longer "the thing plugged into your computer".

That sounds a good deal more effort, especially as it depends highly on the virtual machine software on the computer.

Anything you can do with RS323 you can do with Ethernet. There are pathological size/weight/power cases where Ethernet doesn't fit but if it does...

--
Les Cargill

Ethernet does have a couple of annoying configuration issues, and requires either a custom client on an attached PC, or requires enough software to implement TCP and a TELNET or HTTP server (and TCP/IP brings a couple of annoying configuration issues as well).

And, of course, as soon as you do have an Ethernet connection, anything non-TCP/IP is ruled out because the customer and marketing will immediately want to be able to do (whatever) from across the campus, and then inevitably further than that. And then you have security issues.

Definitely the way to go if you can, but there are enough hurdles that you can find yourself longing for async RS-232 and a terminal emulator.

Not sure I would consider it pathological to not have Ethernet as a likely option. Almost every small processor today has serial ports built in, and most of the ones that don't can fake it with bit banging pretty easy. You need a processor with much more significant resources before you get an Ethernet port on the processor, and then you need the resources for the Ethernet stack.

There exist things like RasPi boards which can have FTDI USB RS232 ports attached. So really? You should be able to use DynDNS and DHCP and that's about all the config you need. With the RasPi's I have seen, it's even 802.11 - just carry an AP and you're in.

You can do all the fiddly bits once, and offsite.

Generally, I'll have a custom TCP server running on the Pi, which provides the option of encoding any twiddly parts about the device on the other end of the FTDI device, within the Pi.

Almost everything has Ethernet now.

Oh, not so much :) Well, sometimes :)

--
Les Cargill

Dunno; there are Arduino-class devices that fake having an Ethernet port pretty well...

So that's when you use a RasPi as a serial port server.

--
Les Cargill

I don't know what kind of systems you work with, but to me a Pi is convenient for testing and developing, but is out of the question for most delivered systems. The same goes for jumbled mixups with dynamic DNS - fine for test setups, not for deployment.

Almost every microcontroller does /not/ have Ethernet. Almost every electronics board made does /not/ have Ethernet.

It's nice to say you don't like using pis for delivered systems, but that's not useful to anyone else unless you explain why.

The rPi foundation even makes boards specifically for embedded systems and I believe they have some level of assurance these units will continue to be available.

I think both statements are exaggerations. Plenty of MCUs are Ethernet capable. If you want Ethernet it is easy to select a version with a network interface.

Rick C.

Fair enough.

Normally when talking about a Pi without being specific, it is reasonable to assume standard Pi boards. These have no guaranteed availability lifetime, no thoughts of MTBF or environmental limits, are full of connectors without any locking or stability, are impractical for any kind of solid mounting, and are not practically designed for production, testing and integration with industrial systems that need to be produced consistently, solidly, reliably, and cheaply.

These devices are made for the desktop - for education, experiments, fun, prototypes, for cheap computers. They are excellent for that. But not for later stages in most kinds of delivered embedded systems. (Of course there are some kinds of system where they are fine, but those are in the minority.) You buy you Pi boards one at a time, not in deliveries of hundreds or thousands.

The embedded Pi cards /are/ more suited for production of finished systems. But they still suffer from the same disadvantage any embedded Linux system has in comparison to using small microcontrollers - long and complicated production programming, finer and more delicate electronics, security, software auditing and control, software licensing, timing jitter, boot times, large and complex updates, unstable software, support, developer requirements, power requirements, environmental limits.

Now, embedded Linux systems can give you enormous flexibility, and you get a vast amount of software features and power for very little cost. In many systems, this is what you want, and a Pi compute module (not a normal Pi) may be a reasonable way to get that. But in many more systems, you don't need that - and the cost of having a much more complex system is far too high.

I did a quick and unscientific test. On Digikey, there are 78,510 microcontrollers. 4,498 have Ethernet. (Yes, I know you get multiple lines for essentially the same devices.) I will admit that is a higher proportion than I had expected. But still, the great majority of available types of microcontroller do not have Ethernet. And while I have no statistics here, I would expect the non-Ethernet microcontrollers here to ship in several orders of magnitude higher quantities than the the ones with Ethernet. At what point can we say that almost every microcontroller shipped does not have Ethernet? 99%

99.9%? 99.99%?

Certainly Ethernet is getting more common - there are more devices available, and there are quality network stacks available freely. There is a much lower entry cost to using Ethernet now than there was 5 years ago. But still I stand by my statement that almost every board made does not have Ethernet.

That is true, when you are at a certain size of microcontroller. If you are talking about a 32-bit device with 64 or more pins, 256K flash and

64K ram, running at 60+ MHz - yes, there is a high chance that you can find a device in the same family that has Ethernet. If you are using 8-bit or 16-bit microcontrollers, small or cheap devices (which may be 32-bit), low-power devices, high temperature devices, tiny package devices - no, you probably won't find Ethernet alternatives without changing family.

In my own designs, I am quite fond of Ethernet. It gives a lot of flexibility and convenience. (I have a board plan which would have Ethernet merely for development and debugging.) But it is not for every use.

I asked the grisp.org guy that same question, and he replied that:

1) most of the effort in developing an embedded dev environment was in writing device drivers that are very hardware-specific, and in the case of the pi, the hardware changes so fast that the drivers have to be rewritten all the time. So he wanted hardware with a longer lifecycle. 2) the rpi foundation doesn't allow changing the hardware design: you can plop their boards into their product and that's it. Note that the Beaglebone doesn't have that restriction, and there are various Beaglebone-derived boards available from seeedstudio and elsewhere.

The Grisp board is very nice but expensive enough that I can't imagine using one in a hobby project. Erlang on Grisp (basically Erlang runs on the bare metal without an intermediary OS) may have some slight latency advantages vs Erlang under Linux on an rpi, but if something is really hard-real-time I'd like to hope it can be offloaded to a simpler mcu (like the realtime coprocessors on the beaglebone) or to an FPGA.