Today I was writing an application under Ubuntu Linux where I wanted the user to be able to click on a shell script to start running the main C++ application as a daemon in the background. I found a few example scripts using the nohup and disown commands but none of them seemed to work and my application would terminate as soon as the shell window closed. I found that it was necessary to include a sleep command between spawning the process and using the $! result for the disown command.
A few of the example scripts I found didn’t include a sleep and seemed to be parts of well tested and documented packages so maybe this requirement varies by Linux distros. The following is the latter segment of the bash shell script I wrote:
Today I was changing my TomTom datalogger to use threads for GPS reception and initially had some linking problems despite including pthread.h in the C++ source code and adding -lpthread to the linker options. The thing that threw me at first was pthread_create linked fine but I was getting linker undefined reference errors to other common POSIX threading calls such as pthread_exit and pthread_join.
At first I was worried that arm-linux-g++ didn’t support POSIX threads and was only providing an unimplemented stub routine for pthread_create that satisified the linker but didn’t work. It turned out however that POSIX threading is supported by GCC for the ARM but it doesn’t sit well with static linking of the libraries. I’d only used static linking for initial convenience when I wasn’t sure what libraries would be required, once the project was converted to dynamic linking of the LGPL libraries required by the project everything worked fine.
After believing I had the problem solved with the TomTom GPS feed after some quick bench testing I was looking forward to gathering some good test data during a business trip to Victoria that involved quite a bit of driving around. Unfortunately the problem cropped back up during mobile testing and I didn’t have time to troubleshoot before leaving. Presumably the extra processing the TomTom navigator application was doing while moving and calculating routes caused the timing of everything to alter a little and rendered the data I collected uselesss.
After further investigation today despite trying a few different techniques the C++ stream failbits and eof bit I was relying on don’t seem to get set correctly for the GPS feed. I’m not sure yet if this by design, a bug in the GCC ARM C++ standard libraries or a problem with the TomTom GPS driver. Once I knew the underlying problem it was easy to change the application logic to cope with the blocking that not having the eof indicator caused. I’ve now confirmed during further driving tests I can collect 100% of data to progress the KML and HTML data generation. Soon I will change my GPS C++ library to use threads rather than relying on the eof bit, a side-effect of my current workaround is that the signals I use to shut down the application gracefully won’t be received in a timely manner.
Recently the serial communications ports on a VMWare machine I had setup for embedded development stopped working. I believe what triggered the problem was booting the VM while another VM had the same physical serial ports locked and it appeared to get the XP device stack into an odd state. I found that by deleting the serial ports under hardware manager and performing a reboot it cleared the problem.
Today I was creating a new VMWare virtual machine to install some embedded development tools I need for an upcoming project but don’t use often enough to have cluterring my main machine. The first login after adding the machine to the Windows domain took approximately 20 minutes. It reminded me I’d had the same problem a few years ago and the problem can occur when the machine is set to use an Internet DNS server rather than the DNS server for the local domain. Adding the local domain DNS server as the first priority DNS server for the network adapter corrected the problem.
After being side-tracked onto another project I got back to the TomTom datalogger application and believe I’ve solved the problem with intermittent pauses in the GPS output from /var/run/gpsfeed. The problem ended up being easy to repeat on the bench and in fact I could see the same pauses doing a cat /var/run/gpsfeed from the serial console but only when my application was running in the background. It only occured when my main loop was set to check for new input every 200mS, when I put it up to one second everything started working smoothly.
The TomTom is set to output a GPS fix approximately every 800mS so 200mS seemed like a fairly appropriate value to keep the buffers flushed and everything running along smoothly, but instead it appears the driver may have a problem if the buffer gets emptied too often. I’m using C++ streams so just have a fairly typical while stream.good style loop to process any new data received on a character basis and go ahead and process the data when a new $GPRMC / $GPGGA pair has been received. It will need some field testing but fingers crossed problem is now solved.
Doing some testing on a TomTom datalogger application I’m writing I’m finding some data gaps in the NMEA GPS output both from /var/run/gpsfeed and /var/run/gpspipe. At first I suspected the feed may not be sending out NMEA data during a loss of coverage, however recently observed the TomTom tracking OK during a period the problem was occuring. It is possibly because I’m attempting to log all data so that I can post-process the data for reporting and KML generation. To assist hearing when the data feed stops without taking my eyes of the road I’ve attached a piezo buzzer and diode to a DB-9 connector that seems to give an audible but not too annoying sound at 115200 bps.
By default the TomTom One doesn’t give console access over ttySAC0, instead it looks like a plug & play daemon periodically polls the port possibly for a GPRS modem. A few attempts at allowing access to the shell with TomTom Navigator running concurrently failed so rather than modifying the ttpnpd file that I use to launch my main application I created a file called SerialTTY.cap in the SDKRegistry directory:
And in the bin directory created a small shell script called SerialTTY to perform the redirection between the shell and the /dev/ttySAC0 port:
stty -F /dev/ttySAC0 115200
sh < /dev/ttySAC0 > /dev/ttySAC0 2>&1
All works well and after the initial period I didn’t see any more interference from the plug & play daemon. I noticed in the /bin directory (on the internal filesystem) that the lrz binary is provided and successfully used it to perform a zmodem file transfer. In conjunction with a few scripts this may be a more convenient way to transfer new binary images to the device rather than going through the reboot required when using the USB mass storage interface.
The RS232 cable was attached to the TomTom and all works fine with the serial interface. I also attached the suspected audio line out to pin 1 on the cable and the line input to pin 2 in case they prove useful in the future. They are normally RTS/CTS on the PmodRS232 board but it has removable jumpers that will provide convenient access to the lines.
The TomTom data connector uses a non-standard 2.5mm audio style jack that has four poles on the inside and two around the outer sheath. I have been unable to find a convenient source for the connectors so will remove and replace with a cable to mate with a Digilent PmodRS232 adapter to perform 3.3V TTL to RS232 conversion during debugging. I’ve done some work with a scope and resistors to determine the pin functions for at least the pins I require. The connector viewed from the top of the PCB looks like this:
Pin functions were determined as:
1 = RX data in for UART ttySAC0, default rate = 115200, 3.3V TTL.
2 = Power output for accessory, I tested sourcing 100mA will no ill effects on unit.
3 = TX data out for UART ttySAC0, default rate = 115200, 3.3V TTL.
4 = Measured 1.4V output, most probably an audio line output.
5 = When connected to ground via a 1K resistor the unit reports an external line input, so presuably that’s what it is.
6 = Ground.
7 = Function unknown but when connected to ground via a 10K resistor it caused an immediate shutdown of unit.