Beaglebone Analog Input read() results in 4 bytes

After writing some C code to read the analog inputs, it became clear that reading analog inputs via the file system (.../ain1, etc.), the system returns 4 bytes for each read. The bytes are the ASCII characters for the digits 0-9 (values got from 0-4095), and if the reading is less than 4 digits, the byte = \x00 is placed in trailing locations. The \x00 byte is the string terminator for C, and is not present for readings that are 4 digits long. This could explain why channels shift when reading the analog values via Tcl reads: the area the 4-byte value is read into might not have a string terminator.

So, the technique is to read into a buffer of 5 or more bytes, then make sure the 5th byte is a \x00 by either setting the whole area to \x00 first or storing \x00 there after the read, then the C string will be properly terminated.

Recoding Analog and GSM Modem drivers in C

I have referred to problems with the analog inputs shifting channels and GSM modem hangups often in the blog. Since I've been coding in Tcl, I thought that it might be hiding some behavior or data behind its own layer of software. To investigate this I recoded the analog input and GSM modem interface in C language. Since I've done so I've not seen any problems, but then I've only written test programs. I still need to rewrite the bulk of the monitor in C.

I've been off doing other stuff here in New Hampshire and will not be back to this for a week or so. More then hopefully.