Bash – send data to serial (rs232) port and wait for response

Sending data to a serial port is quite easy in Bash, for example:

And you can read from a serial port using cat:

However cat must typically be run from a different shell instance as it blocks waiting for data. So is it possible to write and then read the response from a single shell instance?

Well, it is, but it requires a bit of sleight-of-hand. For example, if we start cat in the background and then send the command, cat will report the response as follows:

Which works but it a bit of a mouth-full! cat continues to run in the background, and will print more responses as they arrive.

But what if you want to just send one packet and then wait for a single response?

This is a bit harder, but if your response ends with an end of line character, or another known character then we can use read to help with this…

First we setup a read command in the background, unlike cat, this command will end when a response is received or when the timeout time arrives, then we can send our command:

This gets read to wait for up to 20 seconds (-t20) for a line of data (max size, 60 characters -n60) from /dev/ttyS0, which it reads into RESP, it then echos $RESP – all of this happens in the background. echo then sends the packet which will result in a response.

If your response packed ends with a character other than an EOL character then you can specify a delimiter to read using the -d command-line option.

Again it’s all a bit long winded, so we can wrap it all up in a bash script (send_tty.sh) as follows:

An example of using the script:

Github repo is here

Visual Studio Paho MQTT Error C2238 unexpected token(s) preceding ‘;’

If you’re receiving errors like the following when trying to build a project in Visual Studio 2017 using the Paho C client:

Then there is a quick fix, the problem seems to revolve around the following for DLLImport & DLLExport in the Paho header files:

The catch here is that neither WIN32 nor WIN64 will be defined as instead either _WIN32 or _WIN64 will be defined.

So a quick fix is to define either WIN32 or WIN64 in your project’s ‘Preprocessor Definitions’ depending on whether you are targeting x86 (32bit) or x64 (64bit).

Here are some of the other errors you might see when you have this problem:

PCL Octree Cheat Sheet

The point cloud library (PCL) is a fantastic resource for working with point clouds, however it is a large library and it can take a while to effectively find your way around it. The octree construct is very useful for working with point clouds, but again it can take a while to learn how to interact with octrees. To help me to remember how to interact with them I will include some examples here:

To iterate across the nodes of an octree (depth first):

To iterate across the leaf nodes:


Get a Voxel’s Bounding Region given node iterator:

Get point indices from leaf node iterator

Get point indices from leaf node pointer

PCL C2988 unrecognizable template declaration/definition Visual Studio 2017

If you get this compile error:

Error C2988 unrecognizable template declaration/definition

When you:

from the Point Cloud Library (PCL) in Visual Studio 2017, then either throw the following in before the #include, like this:

or upgrade your version of Visual Studio 2017 (I haven’t tested this yet myself!)

Not sure why, it’s something to do with workarounds for VS 2017 bugs or something…

An implementation of ntohf() with code

I am working on extracting data from some binary navigation messages today. Working with binary data can be difficult and quite confusing – especially when converting byte order from network (big endian) to host byte order (possibly little endian). The integer types are well covered by ntohs() and ntohl() et al. but when dealing with floats things can get a bit harder as ntohf() isn’t always available to the hard pressed programmer!

So I have included a simple implementation below, I have tested it during my own use, but it use at your own risk as this code may well be an example of a rather dubious use of unions!

This version is slightly adapted from an original implementation by Kevin Bowling (pls. see copyright notice).

ASCII ‘art’ for Camera Calibration Python Script

Working on a python script for a focus calibration (software based) routine for a computer vision camera, in order to spruce it up a bit I decide to add a nice ASCII introduction! #Friday

camera_cal

ExifTool truncates ASCII MakerNote data

ExifTool can be used to output a specific Exif MakerNote from your images’ metadata by using the following command:

This will output makernote Id 0x13, however if the makernote that you are interested is long, then ExifTool may truncate it and output only the start with […] at the end!

To have ExifTool output the full makernote, use the -b (binary) option like this:

Using a Virtual USB Serial Port from a Guest OS on VirtualBox

Here is a decent set of instructions on how to access normal COM ports as well as USB Virtual com ports from you Guest OS running on VirtualBox – Thankfully it worked for me but I had to install the FTDI drivers on the Guest for rs232, I got them from here.

Thanks jorgensen!
.

Have ExifTool Display Maker Notes

Phil Harvey’s ExifTool is a fantastic software tool for displaying and interacting with image Exif data, however by default it doesn’t display maker notes and I always forget the command line options to persuade it to list them, so here it is – the -u option gets exiftool to display ‘unknown’ tags and theses include maker notes!

The makernotes will be listed as unknown items by their hex ids.

Happy days – Thanks Phil!

exiftool display maker notes

.

I2C1_Wr / I2C1_Rd functions hang with MikroC for PIC – Need Timeout

In some cases both the MikroC i2c functions I2C1_Wr() and I2C1_Rd() can hang or lockup indefinitely until the PIC is reset. This can happen if the I2C bus isn’t properly terminated, for example if a connection breaks or similar (broken wire or solder joint etc). Having your PIC lockup during operation is generally not very desirable if your are trying to develop a stable software system – if for some reason an i2c device hasn’t been properly connected your system will just lockup for good!

Different posts discuss this problem and its various causes:

https://forum.mikroe.com/viewtopic.php?f=13&t=21270&sid=f45f0199695794c83516f89919183cbb&start=0

and

https://forum.mikroe.com/viewtopic.php?f=88&t=60224

MikroC provided the code to their functions so that software developers (us) could work around the problem, this library implements versions of I2C1_Wr() and I2C1_Rd() that timeout rather than hang, a timeout values is passed as a parameter:

https://libstock.mikroe.com/projects/view/1052/i2c-non-blocking

The library doesn’t implement a C version, so inspired by it (thanks Danny!) I have ported the functions into C, and added some comments – use at your own risk, it works well for me on PIC18F family chips but hasn’t been exhaustively tested!

I have declared the timeouts as constants rather than allowing the timeout to be passed in as a parameter – this is so that the functions can be used as drop-in replacements without having to modify client code.

And to Read:

This works for the first i2c device, it is left as an exercise for the reader to convert it for a second i2c device, i.e. I2C2_Wr() and I2C2_Rd()