> > I would be delighted to chat with you on a separate thread. I tried > starting a new thread called "Serial Port complexity." It didn't seem to > get posted so maybe it's too off topic or had a link to a web page. > Perhaps there was an issue with your connection from the boonies! I do not see how the list-server would not just push your post to the list. Regarding serial port programming, there is quite a bit of info out there. And the only real issue I see is the popularity of USB on physical devices, i.e. you cannot find most tinker-toys or components with a serial port, while USB devices are widespread. For that there is the "FTDi chip" which does this kind of translation of USB to serial -- I know of it from automotve hardware and software applications. Regardless, the internet is vast with info on programming the serial port, but you may want to consider components with more modern and "wrapped" protocols, like I2C compatible components. If you have a project that needs to use modern consumer electronics components, you are more likely to run into an I2C compatible component than a serial port one. There is an I2C stack on the linux kernel and it works really well. We (a friend and I) programmed a tilt-sensor and display with an accelerometer over I2C driven by Python on a Ras Pi, and it included a graphical display on the X11 screen fo the Ras Pi. (And I hate Python!) We also recently struggled at an IoT hack-day to connect a soil-moisture sensor to the Ras Pi via I2C... > I don't know how Unix+SerialPorts+Terminals got irrelevant in these days > of industrial automation. > See my comments above. Most people coming out of college and into the market as engineers and technicians do Python and use stacks that are already there. The days of very raw serial protocol programming are for one (or two) generations behind. Yup, we are old -- you older than me -- and we can still learn, and should learn, a new thing or two.