Re: [SLUG] Serial write problem
On 25/05/10 12:00 Brett Coady wrote: SNIP Before I try a different linux (cut-down debian Potato is available) Wouldn't a 'cut-down Debian potato' be called a 'Chip'. :) Patrick -- Linux - you use it everyday -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Serial write problem
#yiv1721350468 #yiv915510959 p, #yiv1721350468 #yiv915510959 li
{white-space:pre-wrap;}
On Saturday 22 May 2010 20:46:49 Jim Donovan wrote:
I have been working with a single-board computer (TS-7250, using the
built-in linux) which, about three times per second, sends 8-byte messages
out through COM2 to another device. Very occasionally (it can go 20 hours
without failing) a message doesn't all get transmitted. Only 7 of the
eight bytes get sent. On these occasions, the status returned by write(2)
is Resource temporarily unavailable.
It seems reasonable to try another write(2) to transmit the eighth byte.
However, it crashes without returning. We tried with COM1 and the same
thing happened. This is illogical - we are not using handshaking and the
UART has no way of knowing what is going on at the other end of the line
This may be quite logical if the UART's FIFO or Buffer get flooded and it is
returning a message back to the CPU.
You don't tell us what Baud rate your running at either ?
or even whether there is anything there. I have dumped termios and the
control registers immediately before the crash; no corruption or other
abnormality is evident.
Before I try a different linux (cut-down debian Potato is available), does
anyone have any simpler suggestions?
Tried changing Baud rates ?
Thanks,
Jim Donovan
regards
Brett Coady
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Serial write problem
I have been working with a single-board computer (TS-7250, using the built-in linux) which, about three times per second, sends 8-byte messages out through COM2 to another device. Very occasionally (it can go 20 hours without failing) a message doesn't all get transmitted. Only 7 of the eight bytes get sent. On these occasions, the status returned by write(2) is Resource temporarily unavailable. It seems reasonable to try another write(2) to transmit the eighth byte. However, it crashes without returning. We tried with COM1 and the same thing happened. This is illogical - we are not using handshaking and the UART has no way of knowing what is going on at the other end of the line or even whether there is anything there. I have dumped termios and the control registers immediately before the crash; no corruption or other abnormality is evident. Before I try a different linux (cut-down debian Potato is available), does anyone have any simpler suggestions? Thanks, Jim Donovan -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Serial write problem
On 22 May 2010 20:46, Jim Donovan j...@aptnsw.org.au wrote: I have been working with a single-board computer (TS-7250, using the built-in linux) which, about three times per second, sends 8-byte messages out through COM2 to another device. Very occasionally (it can go 20 hours without failing) a message doesn't all get transmitted. Only 7 of the eight bytes get sent. On these occasions, the status returned by write(2) is Resource temporarily unavailable. What line discipline is the tty driver in? raw? cooked? What do you see on the other side? Looking at tty(4) now I see that things progressed hugely since I last programmed serial terminals, so I'm not up to date with all the API's but I assume the principles of serial communications are still similar - there could be (usually should be) some flow-control and checksum mechanism going on between the two sides which might interfere with the flow (flow control could be either using STOP and START bytes (^Q/^S) or lowering the signal on one of the lines). It seems reasonable to try another write(2) to transmit the eighth byte. However, it crashes without returning. We tried with COM1 and the same thing happened. This is illogical - we are not using handshaking and the UART has no way of knowing what is going on at the other end of the line or even whether there is anything there. I have dumped termios and the control registers immediately before the crash; no corruption or other abnormality is evident. How do you define a crash? The program explodes? The UART stops responding? The entire single board kernel crashes? what? Can you give more details from the control registers and the other data you gathered? Before I try a different linux (cut-down debian Potato is available), does anyone have any simpler suggestions? Thanks, Jim Donovan -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Serial write problem
Jim Donovan wrote: I have been working with a single-board computer (TS-7250, using the built-in linux) which, about three times per second, sends 8-byte messages out through COM2 to another device. Very occasionally (it can go 20 hours without failing) a message doesn't all get transmitted. Only 7 of the eight bytes get sent. On these occasions, the status returned by write(2) is Resource temporarily unavailable. It seems reasonable to try another write(2) to transmit the eighth byte. However, it crashes without returning. We tried with COM1 and the same thing happened. This is illogical - we are not using handshaking and the UART has no way of knowing what is going on at the other end of the line or even whether there is anything there. I have dumped termios and the control registers immediately before the crash; no corruption or other abnormality is evident. Before I try a different linux (cut-down debian Potato is available), does anyone have any simpler suggestions? Thanks, Jim Donovan I'd be trying to see if its happening after a set time or set number of bytes. I'd also try and blast data out and see if you can cause the failure in a short enough time frame to debug it. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
