Wireless network between microcontroller and PC

Not sure where to ask this, but I have reached a dilemma and I'm looking for a way to manage errors without bloated code.

Currently I have an 8051 based microcontroller (AT89S52) connected to my computer wirelessly through UART at 38K speed. I'm using HM-TRP uart modules. I have optimized my code on the 8051 well enough to make such speed not an issue for data processing.

The data thats always in transmission is 7 bytes long which consist of:

Byte 1: Receiver address with sync bits
Byte 2: Sender address with sync bits
Bytes 3 through 6: Raw data that the receipient takes as commands and parameters
Byte 7: CRC checksum value for previous bytes

Now my problem is being able to receive correct data and the best approach to take when incorrect data is received.

What I have done so far to try to minimize problems is:

1. Check every incoming byte as it arrives (except bytes 3 through 6) to see if data is valid at that time, and if any one byte is invalid, then discard entire packet fragment and start again. If the 7th byte arrives, then check for valid checksum and discard entire packet if checksum is incorrect.

2. Implement a stiff timeout equal to 1/3840 * 1.5 (enough time for 1 byte to come in but not 2 bytes) so that if the sender is too slow or disconnected, the entire packet fragment is discarded even if the next incoming byte (that arrives way late) is correct.


Since I'm in an environment where things need to be semi-fast (like where three valid packets need to be processed a second), I'm trying to figure out the best approach to take when a packet isn't valid or properly received.

Do I:

1. Cause a lockup in the microcontroller until the correct data is received? If so then the data may likely arrive fast but at the same time the user experience will be bad since the microcontroller controls other things such as user buttons and the LCD screen.

OR

2. Throw away packets and keep ignoring them until a valid one arrives? If I do this then even though the user controls might be fast, the networking will still be slow even though it needs to be fast.

OR

3. Have the sender send many duplicate packets all at once and pray the receiver receives at least one? If I do this then the sender will experience little lockup. while its not a major issue, how should the receiver deal with this efficiently?


or is there a better idea?

Also, because of the hardware which is an HM-TRP chip, the network is forced to run in half-duplex mode.

You could use a simple flow-control stop and wait protocol.

Additionally to ack/nack/etc responses (it helps to add in extra info with nacks), with binary protocols I like to frame my packet personally.

You could have a known start byte, or start byte sequence. It helps when you get out of sync and reduce the time to get back to normal. Downside is that it increases your data packet.

Just a suggestion.

Async com is always difficult. If the 232 part allows, send a start ID byte with check bit error, check for that (interrupt) error and valid ID byte. then fill the buffer(s). Clear that start ID bye vs the entire buffer will run faster. Chose a good Csum algo, Your start byte can look like data and you have to csum to validate. If possible, send ack after PROCESS is done, ak after data doesn't tell the sender anything but transission complete. Don't know why anybody uses '51 anymore.