View previous topic :: View next topic |
Author |
Message |
FoxtrotMike
Joined: 31 May 2007 Posts: 11
|
Help: How to receive packets of different length |
Posted: Wed Jun 06, 2007 2:00 pm |
|
|
Hi:
·I'm trying to interface with a device that sends packets of variable length via RS-232 at 1200 bps, with a delay of several seconds between two given packets. I'd like to know when a packet is ready to process. I'm thinking of a timeout flag; for example, if no byte arrives in one second, the flag changes, indicating it's time to process the data. The packets have a fixed header of 6 bytes, but no fixed tail sequence, so i can't tell when the packet it's complete just by examining it.
·My idea so far is to enable a timer interrupt whenever a int_rda ocurrs, count how many times the timer interrupts triggers, and if that number exceeds a certain value, set the flag. I'm afraid that enabling two interrupts may interfere each other.
·I haven't put this to code, and i'm not certain if it will work. Do you have any ideas on how to handle this issue?
Best regards,
Foxtrot Mike |
|
|
rnielsen
Joined: 23 Sep 2003 Posts: 852 Location: Utah
|
|
Posted: Wed Jun 06, 2007 3:09 pm |
|
|
If your device sends it's data, without pausing withing the packet, then a few miliseconds would be enough to determine if the packet is finished. Using a timer would be an excellent way to flag this. Simply have your rs232 routine reset the value of the counter that you use inside of the timer isr each time a character is received. When the data stops, the counter will increment and when it reaches a certain value have a flag set that is then handled in your main() so it doesn't keep the program inside of the isr.
Ronald |
|
|
FoxtrotMike
Joined: 31 May 2007 Posts: 11
|
|
Posted: Wed Jun 06, 2007 3:14 pm |
|
|
Thanks! I'll work on the code. When it's done i'll post it, so you can give me your opinion.
Best regards,
Foxtrot Mike |
|
|
inservi
Joined: 13 May 2007 Posts: 128
|
|
Posted: Thu Jun 07, 2007 1:47 am |
|
|
Hello Mike,
I completely agree with Ronald. The interrupt is probably the better way to mesure time between events. The interrupt can also be used for some seconds simply by counting more events.
dro. _________________ in médio virtus |
|
|
Ttelmah Guest
|
|
Posted: Thu Jun 07, 2007 3:54 am |
|
|
However I would look again at the 'packet'. i can't think of any device, that would be so 'silly', as to not have some way of knowing that the packet has finished.
Can you describe the data format?. Is there possibly something like a 'length' field just after the 'header'?...
A timeout, is quite a good idea anyway, but seems a 'messy' way of actually handling the data.
Best Wishes |
|
|
rnielsen
Joined: 23 Sep 2003 Posts: 852 Location: Utah
|
|
Posted: Thu Jun 07, 2007 8:17 am |
|
|
What device are you referring to? Could you post the manufacturer/model/part# of the device? Maybe even a link for the data sheet. I, too, believe there should be some sort of format that would indicate the length of each packet.
Ronald |
|
|
future
Joined: 14 May 2004 Posts: 330
|
|
Posted: Thu Jun 07, 2007 8:48 am |
|
|
I would start like this:
typedef one struct for each packet type you expect to receive.
setup a receive buffer big enough to receive a full message and a pointer to it.
declare and increment a timer variable at each.. 10mS.
if a byte is received, reset the timer, increment the pointer and add the data to the receive buffer.
if timer reaches 100 counts, reset the pointer to the buffer start address and cast it to the correct type (knowing how many bytes you received). Then process the packet.
Hope you get the idea. |
|
|
FoxtrotMike
Joined: 31 May 2007 Posts: 11
|
|
Posted: Fri Jun 08, 2007 8:44 am |
|
|
Hi:
·The device is a propietary design; I've been told the documentation is confidential, so i don't have much to work with, but i'm trying to get some info. Anyway, i found out that the device has RTS/CTS lines, so a better way to determine when a packet starts/ends may be to read the RTS line from the device.
Thank you all for your help.
Best regards,
Foxtrot Mike |
|
|
|