Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Fri Nov 24, 2017 6:16 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Mon Oct 06, 2008 7:16 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
This was originally posted by arka saha as part of another thread. However the discussion is worthy of its own thread, so here it is:

Quote:
Thanks Jeremy for the reply.

I have one more question about serial recieve. Suppose serial buffer size is defined as 32, and when within a MSG_COM_RECIEVE execution another packet of 32 byte data has been recieved. My question is, as already one MSG_COM_RECIEVE is running will it insert a new MSG_COM_RECIEVE in message queu at the very moment the data recieved (and serial buufer size is 32) or will it wait for the current execution to get over (comm resource is same).


Technically, it will immediately enqueue the new serial data.

However, from a Qlarity standpoint, there is no way to tell whether it immediately enqueues the MSG_COMM_RECEIVE, or if it wait for the current message to finish executing -- either way a message ends up at the end of the message queue.

For a more detailed discussion of the Serial port, see this forum post: viewtopic.php?f=4&t=128.

One word of caution: Whenever I see anyone use terms such as "serial buffer size is defined as 32" and "packet of 32 byte data has been received" I get VERY concerned. This starts setting off alarm bells in my head that someone may be using SetSerialRecvSize and SetSerialTimeout to try and implement their serial parsing function. These functions are intended as optimization functions and NOT as parsing functions. In over eight years of supporting Qlarity, I have yet to see anyone use those functions in a manner that works 100% of the time. Invariably a dropped serial byte, or two closely spaced messages or some other communication glitch will cause problems -- often you can get the code very close to working, but once you leave it up for days or weeks a serial byte gets dropped and problems start happening.

The last paragraph may not apply to you, so you may be able to ignore it. I have just seen too many people spend weeks and months trying to glitchy serial algorithm -- spending far more time than it would have taken just to write a full parsing algorithm in Qlarity.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Mon Aug 02, 2010 11:23 am 
Offline

Joined: Fri May 28, 2010 6:35 am
Posts: 22
Just to confirm what I think I am seeing:

The timeout only occurs *between* characters and not for the time before the first character. Is that correct?

If I unplug the cable the terminal sends a request I do not get a MSG_COMM_RECEIVE with an empty buffer. I needed to set an external watchdog timer to detect a protocol timeout.


Top
 Profile  
 
PostPosted: Mon Aug 02, 2010 11:53 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Correct, that is an inter-byte timeout. If you want to detect if the remote device has stopped communicating (possibly mid-packet), use a Qlarity timer. Generally what I will do is set the timer when I transmit a message and turn off the timer when I receive the response. If the timer ever fires, I know something went wrong.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group