Problem reading data from an RFID module

[PrinceNai]

For parsing anything serial I always use the same approach: find something distinct in incoming message in ISR_RDA that indicates that useful data will come next. Disregard that part of the message (in your case OK and whatever special character comes next) and fill the working buffer only with the data I'll work with. From address 0 of the buffer, to make it really easy to display or compare later. Unlike the old hands out there, I do use a debugger, otherwise my first LED would never blink till now. That is why I have a second, much bigger circular buffer where I store everything I get from a serial, not stopping when it's full, just overwriting old stuff. To see in a debug window everything I've received. And if it doesn't work as expected, why my breakpoint wasn't reached.

[vas57]

[PrinceNai]

To clear a buffer:

[vas57]

[Ttelmah]

You should never have to clear a circular buffer. When you read a character,
using the bgetc, the space this used immediately becomes available for a
new character.
The way to clear the buffer if you need to, is simply to set next_out=next_in.
This says the buffer is empty.
PrinceNai's routine would not work, he needs to set next_out to zero as well.

[vas57]

[Ttelmah]

Your approach is fundamentally flawed.
Using a linear buffer, and clearing like this risks losing data if you receive
a character before you finish processing the received message.
You are missing the 'point' about using the circular buffer. This is not
used instead of your linear store for the assembled string, but as well as.
You use this to handle the interrupt, and then have as many character
times as you give space for in this to do the message handling.
You then assemble your message into a linear buffer from this. Ideally
parsing the message, so you know it is complete when you see the 'OK'.
At this point you output or parse the assembled message, and then
start again.

[temtronic]

I got into the habit of clearing all buffers back in the Assembler dayze, to be 100% SURE the 'new' data really, really was NEW data...
kinda like wiping chalkboards clean, before writing on them....

[vas57]

@PrinceNai's
You didn't have to delete the last post, I'll use your idea in a reader for an access system.
Ever since I corrected the software with this idea, my reader, with a tag on it, has never made a mistake reading UID. I am 100% satisfied, even if the theory says otherwise. Thank you all.

[Ttelmah]

You have to understand that while a design works perfectly on the bench,
when it goes out into the real world, you will at some point have an
occasion where a character gets corrupted. To be really reliable, your
code needs to be able to handle and recover this sort of event. It may
only happen once every few years, but at some point it will happen.
Designing code to actually be 'rugged' is much harder than simply
writing something that works......

[PrinceNai]

I agree that bench and real world are two completely different beasts. Only the end users and working environment can test your system beyond anything you ever imagined could happen when it was designed. I also agree that a code should be able to recover from the unexpected, not just sucking a thumb when (not if) it happens. Regarding reading RFID cards. They are used for what? Opening doors, registering presence, confirming something (opening doors and confirming money transactions is what we use them for where I work). Nothing life threatening, so elaborate escape sequences in code are not really needed. From my perspective the procedure is simple: read a card, compare ID that was read with stored ID's and do something if they match. If not, remove the card and try again or use another, registered card. With some delays between readings it works 100%, with a linear buffer. I made this one because my then 6 year old kid was stating he must use a card just like me. OK, order readers from China, solder something, add a beeper and bring home some cards. Write some code. He tested it like 10.000 times on the first day. I seldom heard a short beep indicating something went wrong and always a long one shortly after. But I did hear from my wife that she'll bash my head in if I ever again construct something with a beeper.

[vas57]

Here I agree with PrinceNai, because the software is for access systems in residential buildings. If a code is read incorrectly, nothing happens, the next one comes correct and the reader will open the door.

[temtronic]

One thing to add to the 'reader' section is a 'timed out escape'. In EVERY serial communication it's possible to 'stall', get 'hung up'(can happen when cat pulls out the com cable...sigh). CCS saw this and in the FAQ section show how to 'escape'.

[Ttelmah]

Yes. This also handles the 'part message' situation for you.