Actually, I think my shortest path to joy at this point is to just live with the errors, and only pick up this particular baton again if the embedded system shows the same behavior (in which case I'll know it's not Linux, or me+Linux, but just me).
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Personally, I never, ever, ignore the dropping of bytes. In a robustly designed system that simply should not happen (unless you are experiencing interference or other hardware problems).
I'm surprised no one has asked you what your flow control settings are and if you are sure they are working as expected.
What flow control are you using and are you using the same flow control method in the final product ?
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
And normally I'd chase down the dropped bytes, too -- except the Linux part of this is most definitely throw-away, and I'm starting to feel like I'm wasting time that my customer is paying for.
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
would be simple to stuff the recieved bytes in file as you get them so you can go back and check if you got the byte after you see it missing at the higher level
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
I understand, but the behaviour under Linux could be exposing a design flaw.
I wasn't expecting you to be running without flow control, but given that you are, one question comes to mind:
What version of Linux are you running ? At one time, the amount of unread serial port data was limited to one page, but while looking around to double check I saw reports that the driver got changed a few years ago to buffer all incoming data (which I must admit I didn't realise until now).
I have not checked the Linux serial port driver source to see if that's still the case or if this change got reverted.
Other questions:
Are you losing random single characters or contiguous blocks of characters ?
Are you losing characters regardless of the character's ASCII value (including losing printable characters), or are you only losing non-printable/control characters ?
If you are running a packet type protocol with distinct pauses between packets instead of a continuous stream of bytes, what part of the packet are you losing ?
Are you keeping the channel open the whole time or are you closing it between read operations ?
Have you done a "stty -a" on both sides of the link _while your program is running_ to make sure that your serial ports are actually setup the way that you are expecting them to be ?
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
[For some reason, I thought you were developing the device based software on a Linux box and using a second Linux box in it's intended final role as a control/data receiving platform.
That's why I referred to stty -a on both sides of the link. From your description, I now see the setup to be a Linux box in place of the final MCU based device talking to a third party device you have no internal access to.]
I find the loss of the start character (and only the start character) to be very suspicious. However, before assuming a problem in your reception logic, can you check something else ?
When you open the serial port in the Linux abstraction layer, are you opening it just once at the start of the program and passing the file descriptor from the open to the following read and write calls or are you opening and closing the serial port before and after each read and write (maybe in order to try and isolate the Linux specific code) ?
If you are opening and closing the serial port during every I/O operation you may introduce a race condition which could cause the exact problem you are seeing.
BTW, what is the actual value of the start character and are you running the serial port in raw mode ?
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Could you modify the ISR and store every received character into a shared memory? This could help in locating the source of error, hardware, ISR, other tasks.
Actually I'm running the low-level protocol in a Linux box to replicate a MCU-based command head, talking to the old MCU-based board which I'm going to replace the new MCU-based board.
But, that doesn't change much.
I'm opening the serial port once in -- I hope! -- raw mode (I'll have to double-check that), and only closing it when the program closes.
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
Yes, I could, and yes, that makes sense. I think I'll just shove it into a little circular buffer, actually -- I already have error-recovery code in the main body of the program, I can break on that then go look at what the ISR thought it was receiving.
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.