Re: [Boost-users] Asio problems with async_read
Allan Nielsen wrote on Mon, 8 Aug 2011 14:13:08 +0200
Hi
I have a funciton where we I am using boost::asio to read from the serial port of my computer.
I have started out with an implementation which uses read, and I am now trying to convert it to async_read because I want a time out.
When I am trying to use the async_read version, I get timeouts after I have read one or two charterers, even though I know there are more charterers to be read on the wire.
Not sure that this is much help since I've never really used boost.asio and reading further down the thread it may be a problem with how you are calling it. However having done a lot of serial comms in the past seeing a couple of characters only whilst more data is on the wire I'd guess that the timeout is as a result of the low level serial hardware interrupt. The UART is probably signalling that its internal FIFO buffer is full and you need to read this promptly - quite how that all pans out and what daemon / service has the responsibility of reading this these days I haven't got the faintest - I was writing TSR's when I knew the gory technical details of this so life was much simpler. I'm actually impressed that you've found a computer that still has a serial port on it! Most seem to have gone over to the ubiquitous USB these days - though that may be the easiest solution - use USB and a usb/serial converter which would avoid having to rediscover the lost art of programming UART latch timings etc and give you a decent amount of low level buffering so you could ignore low level stuff and just read the data. http://www.bb-europe.com/tech_articles/USB_converters.asp?gclid=CPvOgur5v6oC... or some such. HTH Alex
Hi
However having done a lot of serial comms in the past seeing a couple of characters only whilst more data is on the wire I'd guess that the timeout is as a result of the low level serial hardware interrupt. The UART is probably signalling that its internal FIFO buffer is full and you need to read this promptly - quite how that all pans out and what daemon / service has the responsibility of reading this these days I haven't got the faintest - I was writing TSR's when I knew the gory technical details of this so life was much simpler.
You might got a point... I have done some strace'ing: # This is the latest good read readv(6, [{"\362\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512}], 1) = 1 gettid() = 4712 write(2, "I0808 17:39:37.919446 4712 ccTa"..., 100) = 100 gettid() = 4712 write(2, "I0808 17:39:37.919489 4712 ccTa"..., 56) = 56 # What happens here? rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdc6c5b3000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdc6c5b2000 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 open("/usr/local/lib/libunwind.so.7", O_RDONLY) = 7 fstat(7, {st_mode=S_IFREG|0755, st_size=86957, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdc6c5b1000 read(7, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\"\0\0\0\0\0\0"..., 4096) = 4096 lseek(7, 69632, SEEK_SET) = 69632 read(7, "\306\37\0\0\0\0\0\0\326\37\0\0\0\0\0\0\346\37\0\0\0\0\0\0\366\37\0\0\0\0\0\0"..., 4096) = 4096 lseek(7, 73728, SEEK_SET) = 73728 close(7) = 0 munmap(0x7fdc6c5b1000, 4096) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, ~[RTMIN RT_1], [], 8) = 0 How should I catch such an event from my c++ code? And do you know what it means?
I'm actually impressed that you've found a computer that still has a serial port on it! Most seem to have gone over to the ubiquitous USB these days - though that may be the easiest solution - use USB and a usb/serial converter which would avoid having to rediscover the lost art of programming UART latch timings etc and give you a decent amount of low level buffering so you could ignore low level stuff and just read the data.
I'm using a USB to serial converter. But the case might be that the firmware for the converter is buggy! -- Allan W. Nielsen
participants (2)
-
Alex Perry -
Allan Nielsen