USART C18 Issued(RFID)

[0xFF]

A fifo buffer is required when you need to do some processing on the previous data. Writing it to an LCD may take longer than to receive 2 bytes and cause an overrun error.

If I showed you the processing I do on my packets (without a FIFO), and what I do in between receiving packets, you'd change your position. Basically, I rip apart the first 5 bytes into status bits (I only use 7 of each, so 35 status bits) and act upon most of them.

 

[AtomSoft]

the issue is i dont see why a fifo would be used here if i collect all the data then only after all data is in i work with it. Its not like im writing to LCD while getting the data.

1. GET DATA
2. Work on data
3. Write to lcd

A Fifo would work when im collecting large amounts of data while doing something else like a multitasking type area.

 

[Pommie]

If I showed you the processing I do on my packets (without a FIFO), and what I do in between receiving packets, you'd change your position. Basically, I rip apart the first 5 bytes into status bits (I only use 7 of each, so 35 status bits) and act upon most of them.

You are doing something 3 times per second so of course you don't need a fifo.

I don't have a position on this, it is not a competition. I just try to help people.

Mike.

 

[Pommie]

the issue is i dont see why a fifo would be used here if i collect all the data then only after all data is in i work with it. Its not like im writing to LCD while getting the data.

1. GET DATA
2. Work on data
3. Write to lcd

A Fifo would work when im collecting large amounts of data while doing something else like a multitasking type area.

How do you tell the RFid module to send data?

Mike.

 

[0xFF]

Sorry, I'll keep my mouth shut.

 

[AtomSoft]

hey both of you relax you both are helping alot.

Mike the RFID sends me data when i swipe a card over. It doesnt wait for me to ask for it. It sends when its available.

0xFF i have my setup somewhat like that. As noted before it works now. I think it was a timing issue. Every since i placed that delay between CREN OFF/ON its been working. I like the IDEA of a FIFO and will surely use it when getting large amounts of data into little places.

Like a 10Byte var and have it scroll out 100bytes you understand?

 

[Pommie]

Sorry, I'll keep my mouth shut.

Please don't (keep your mouth shut). I wasn't trying to belittle you, just trying to point out that there are situations when a fifo is required. In your case it wasn't.

Mike.

 

[Pommie]

Mike the RFID sends me data when i swipe a card over. It doesnt wait for me to ask for it. It sends when its available.

With this particular case you shouldn't get overrun errors occurring. Makes me wonder why you did? Maybe the module sends each ID twice? Or, does it send it continuous whilst the tag is present?

However, if you setup a production line with a new ID tag coming 20 times a second then I think the fifo will save your bacon.

Mike.

 

[binzer]

Please don't (keep your mouth shut). I wasn't trying to belittle you, just trying to point out that there are situations when a fifo is required. In your case it wasn't.

Mike.

I see it as multiple suggestions, one or both may work, or a combination of the two may be better. Some people have more ideas because they have 'been there done that', it's more fun to discuss and share than to pee on the corn flakes.

 

[Pommie]

I see it as multiple suggestions, one or both may work, or a combination of the two may be better. Some people have more ideas because they have 'been there done that', it's more fun to discuss and share than to pee on the corn flakes.

Would you mind translating that into English?

Mike.

 

[AtomSoft]

lol you guys are hilarious...

It sends the ID(12 bytes) as soon as i swipe the card and will keep sending it until i remove the card. So it might send it many times a second.. @ 2400bps. The max it can send is about 25 IDs in 1 second. So maybe thats why i get the error. Hence i would have to disable and re-enable the usart unless i delay for 1 second after the first 12 bytes have been recieved.

 

[AtomSoft]

i added the 1 second delay before reading and no errors!

void GetRFID(char *buffer){
  char i;                           // Length counter
  unsigned char data;

    delay_s(1);                     // [b]I added this and no more OERR errors![/b]
    for(i=0;i<12;i++)               // Only retrieve len characters
    {
        while(!PIR1bits.RCIF);      // Wait for data to be received
        data = RCREG;    
        
        *buffer = data;
        buffer++;                   // Increment the string pointer

        if (RCSTAbits.OERR)
        {
        // overrun error  (this sequence clears the error)
            RCSTA = 0;     // disable the reciever
            delay_ms(100);
            RCSTA = 0b10010000;     // reenable the reciever
            break;
        }
    
        if (RCSTAbits.FERR)
        {
        // framing error (read the byte to clear the error, but throw it away)
            data = RCREG;           //Skip read to clear
        }
    }
   
}

Ill try to shorten the delay to compensate for getting 3 times the info. so if i can read 25 in 1 second then 1 gets read in .04 seconds aka 40 mS. So if i want to delay for 4 ids then i multiply by 4 to make it .16 aka 160mS. Ill make it delay 160-200mS instead of 1 second to see if its faster yet with no errors.

 

[AtomSoft]

ok to make this work well i think i need to buzzer when the id is entered so one knows to remove the card from view then delay about 300-600mS before reading a new ID.

Ill add a tiny buzzer in a minute to try it. but around 300mS works well . 2 of 10 reads where errors but where automatically fixed with that overrun error code. so it works pretty good i would say.

 

[Pommie]

Why not just do it right in the first place. You have overrun and framing errors because you can't process the data quick enough. Add a fifo and all your errors will disappear.

Mike.

 

[AtomSoft]

pommie as you may know im am not the best with interrups. I think i should study it more before i even try adding the FIFO. But since is the beginning of me learning this anyway i think its the perfect time to study interrupts more and to implement in any designs.

off the top of your head do you know of a good way to practice using interrupts. (especially USART) interrupts.

 

[futz]

Found this at Microchip. It's nice clear, simple demo code with a FIFO buffer. Might help.

Interrupt Driven Serial Routines with Circular FIFO for PIC16x Micro

This is another routine that I want to share. This is the interrupt driven serial routine with circular FIFO for any PIC16x micro with a hardware UART. Compiled with Hi-Tech C. Since this is unbuffered, so I added a software FIFO. The FIFO management is quite lean and fast but required the size of the buffer to be power of 2 (2^x). This is because FIFO roll-over uses bit-wise AND of (buffer_size - 1). This reduces code size due to that no more conditionals to test pointers overflowing the buffer.

 

[futz]

pommie as you may know im am not the best with interrups. I think i should study it more before i even try adding the FIFO. But since is the beginning of me learning this anyway i think its the perfect time to study interrupts more and to implement in any designs.

off the top of your head do you know of a good way to practice using interrupts. (especially USART) interrupts.

I still have a tendency to avoid using them, but once you dig in interrupts are really not so difficult. Start out writing just an ISR that detects when you press a button or something. That's so simple that it'll get ya over your fear a bit. Then do interrupt driven RS232 receive. Again, very simple. Tinker with some easy ones like that, work your way up to more complex ones (multiplex a row of 7-seg displays - still very easy - it's just a timer interrupt) and you'll soon be writing ISRs for everything.

 

[AtomSoft]

heh dont laugh but that code confused me more lol i think im getting it tho. I can read your FIFO code more than the other one.

If i am right what it should do is on interrupt add to the buffer and when full it starts at the beginning again.
So if i have a buffer size of 4 bytes it goes


BUFFER [0] [1] [2] [3]
DATA A B C D

So if i have 1 more byte come in it looks like:

BUFFER [0] [1] [2] [3]
DATA E B C D

or if i have 4 more bytes come in it looks like

BUFFER [0] [1] [2] [3]
DATA E F G H

correct?

If so then i would have to read the first one 1st then the rest of the 12 i need. and just clear the buffer when im done as so i wont get invalid data or double data.

I see how this would save space. But i doubt it would help in getting data correctly.
I think the interrupt alone could solve the issue of the overrun error and would eliminate the delays in place.

Since i would capture all data in interrups and only keep the first 12 anyway. Then after the 12 are in a variable i can compare it with new incoming data and if the same just skip them.

Then when back to running normal non-interrupt code i can clear the buffer.

 

[AtomSoft]

I still have a tendency to avoid using them, but once you dig in interrupts are really not so difficult. Start out writing just an ISR that detects when you press a button or something. That's so simple that it'll get ya over your fear a bit. Then do interrupt driven RS232 receive. Again, very simple. Tinker with some easy ones like that, work your way up to more complex ones (multiplex a row of 7-seg displays) and you'll soon be writing ISRs for everything.

Heh i think ill try the baby steps like buttons first. Then ill try a receive (USART) and hopefully will have hair left on my head

 

[futz]

Heh i think ill try the baby steps like buttons first. Then ill try a receive (USART) and hopefully will have hair left on my head

Do not worry. They're both ultra simple. Dive in and you'll see what I mean.