[Boost-users] boost::asio asynchronous read problem

Subject: [Boost-users] boost::asio asynchronous read problem
From: Sebastian Götte (s_at_[hidden])
Date: 2011-06-05 11:38:17

Hello,
I have a problem when asynchronously reading from a serial port via
boost::asio. The application should exchange a few commands and status
bytes with the device, then the device starts sending data and the
application listens and parses this data. A diagram of the
initialization procedure is attached to this mail.
I implemented this process using the Qt framework, and it works (data is
being displayed as expected). Now I re-implemented the same procedure as
a gnuradio module using boost::asio (i.e. a shared library with a nice
python wrapper) -- and the initialization seems to work, but I did not
succeed in reading anything after that.
The constructor of the gnuradio module is being called on startup and
does the initialization. After that, the "work" method is called in an
infinite loop and should read and parse the data, and since this module
is a source module I think it is ok that this call is blocking.
The data that should come from the serial port after Initialization
looks like this (shown is one "burst", this is sent 125 times a second):
[\FX\FX\FX\FX\ X\FX\FX\FX\FX\ X\FX\FX\FX\FX\ X\FX\FX\FX\FX]
Where F is a hexadecimal digit, [, ] and \ are the respective ascii
characters, and X is any value of no interest (but should be 0x00).
From this "line" (not delimited by \n, but by [ and ]) the four hex
digit groups shall be extracted:
FFFF FFFF FFFF FFFF
...and then be converted to four signed words (It does not need to be
fast, and this format was pretty debugging-friendly).
My problem is that after the device has been initialized successfully
(all init methods have been executed) the read handler registered when
async_read is called in work is never executed (I verified async_read is
being called). The output of a test run (loading the module, thereby
initializing it, then calling work(...) repeatedly) looks like this:

-01--rt--02-bar-wh--03--04--01--wh--05--06--wh--07-foo-08--wh-gr_block_executor:
source <gr_block openmind_buspirate_source_s (2)> produced no output. 
We're marking it DONE.

I would expect this output followed by an output similar to the first
line described above ([\FX\FX...).

I use an aptosid linux, kernel 2.6.39-0 i686 and my gcc's answer to
--version is
gcc (Debian 4.6.0-10) 4.6.1 20110526 (prerelease)
My libtool's version is 2.4 and my gnuradio version 3.3.0. I use boost
1.46. My autoconf version is 2.68, my automake version 1.11.1, my make
version 3.81.

Since this is a lot of code I do not include it here. The code of the
important part of the working Qt-based app may be found here:
https://github.com/jaseg/openmind-viewer/blob/09db5ba834d8d2c49cb239b1933f2fdf81fad728/src/buspiratesource.h
https://github.com/jaseg/openmind-viewer/blob/09db5ba834d8d2c49cb239b1933f2fdf81fad728/src/buspiratesource.cpp
Whereas the boost::asio-based code is available here:
https://github.com/jaseg/openmind-viewer/blob/02fac3937fe625c85f0d05813ad9df81a3cbf51d/lib/openmind_buspirate_source.h
https://github.com/jaseg/openmind-viewer/blob/02fac3937fe625c85f0d05813ad9df81a3cbf51d/lib/openmind_buspirate_source.cc

I would be glad about any suggestions.
Sebastian