Even tough RS232 is from the 60’s it is still something that should be available on every device (a TTL version is acceptable too). Most embedded CPU’s, even big ones like the iMX8 have one or more serial ports that are useable without the need of complex software stacks.
Especially that serial ports can be used without a complex software stack, on some CPU’s it can be as simple as writing a byte to a register, makes them a very powerful tool. USB and even PCI based devices already need a lot software before they can output anything, which makes them more error prone and more resource intensive.
For a project with Aurum Engineering GmbH, where we needed to control hoists in a TV studio, we had two types of controllers.
One controller type, at the end of every rail, that received data via Ethernet and converted it to RS485 to transfer it to the (movable) hoist.
The second controller type, at every hoist, to receive the RS485 data and control the hoist motors. Both controllers were based on the same STM32 micro controller. To not depend on Ethernet we used the RS232 (via a temporally connected bluetooth to RS232 dongle for the moving hoists) to report all needed debugging data.
To not just have an endless list of scrolling text messages, something most ppl will think of when hearing “RS232 debug output”, we made a small TUI system that uses VT100 command codes to draw on the “screen”. (The GUI program in front was used to send test data over Ethernet.)
The screen was simply split in several sections (from top to bottom)
- The title bar with version info and up-time.
- A selectable (with functions keys) “applet” that shows detailed system state information.
- The bar splitting the screen, that shows which applet is selected and which applets are available. What applets are available depends on the hardware configuration, in the photo one can see Art-Net support that isn’t available in the screenshot from another studio.
- The list with log messages.
- The status bar at the bottom with infos like the address, DIP-switch settings, RS485 baud rate, and number of found hoists.
In case the screen is not big enough an error message is displayed. That same logic is used to detect if there is a terminal program connected at all, in both cases the CPU will not update the screen as much saving CPU power when nobody can see the TUI anyway.
So without web server, TCP stack, USB hardware, it is possible to create a very useful TUI that hardly needs any resources. The only thing you need to do is make sure your hardware has a good old serial port.
Feedback
Feel free to give feedback on Linkedin