detection of end of data packet with arbitrary length

[AliBahar]

Hi every body, I'm working on AVR program (using Atmega128) that communicates with PC based on rs232. the communicated data stream has an arbitrary length. there is no any information about data length in content of data packets. how can I detect the data stream length?
as you know we can calculate the interval time between data packets and any longer time should be considered bus idle time and the previous packet is considered as the end of data stream. please help me to make the code of this algorithm or any other useful methods.
usart setting : boudrate:9600 - one stopbit - Databits=8 - no parity
USART0 Receiver interrupt service is activated,

 

[Easyrider83]

1. Detect the timeout of last byte received. RX interrupt clears the timer. If timer interrupt occurs, time is out and data is valid.
2. Detect 0x13 0x10 condition.
3. Detect 'stop' character condition
Last two valid only for text trasmition. No raw data allowed.

 

[betwixt]

Agreed - unless you can pass the length as part of the data, for example as the first bytes, or you can use a unique 'end' value, the only method is to detect when the transmission ceases. You need to maintain a timer that counts at fixed time intervals, for example 100 times a second, you reset it to zero when a byte is received and if it reaches a certain count value you deem the transmission has ended. You have to choose the count speed and maximum value according to how long the gap is likely to be between one data packet and subsequent ones.

Brian.

 

[AliBahar]

am I right?
baud rate is 9600 bps so the time equals 10.42 ms. the packet frame contains 10 bits so we should wait for 105 ms and after that we can say the end of packet is detected if there is no new packet in RX.

You need to maintain a timer that...

another question: can I use delay functions instead of timers?

 

[betwixt]

The bit rate is 1/Bauds (for simple serial data) rate so each bit lasts 1/9600 seconds = 104.4uS. Each byte is typically 10 bits, start bit, 8 data bits and a stop bit so the time per BYTE is 1.042mS. Be careful not to confuse the bytes with the packet frame which could be several bytes long.

You might be able to use a software delay function, it depends on how the assembler/compiler code works. The problem is that in many cases the delay function is a 'blocking' one, you can't get out of it until the delay period is finished, that can make it more difficult to monitor for incoming data at the same time.

Something to consider: The packet may consist of many bytes but just multiplying the number of bytes by the byte duration may give a wrong result. It assumes there is no gap between the bytes. Depending on your code it is possible there is an additional 'inter byte' delay you have to factor into the calculation. For example, 10 bytes sent "back to back" would take 10 * 1.042mS = 10.42mS but if there was any delay between one byte and the next, the total would be a longer period.

Brian.

 

[Easyrider83]

another question: can I use delay functions instead of timers?

If you using RTOS, yes, but it is a dirty way.
Best way is to use 0x13 0x10 combination.