0

I declared these global variables:

volatile unsigned char BUFFER[7]={0,0,0,0,0,0,0};//to get all data
volatile unsigned char *PTR=&BUFFER[0];//points to start address

Inside the Microchip PIC interrupt function, the pointer reads the UART register and deference it to BUFFER[] array according to my code: 

*PTR=rcreg;
PTR++;

I then check the data in function main():

for(i=0;i<3;i++){
    if(BUFFER[i]==DATA[i]){
        k++;
        if(k==2){LED_On();}
    }
}

and set ptr to point at the start address of BUFFER[]

ptr=BUFFER;

Question: Is this the best way and correct way to read data in the register? How can I use pointer in interrupt function?

Thank you for your kind attention and help in advance!

Marcelo Cantos
  • 181,030
  • 38
  • 327
  • 365
AlanWong
  • 1
  • Please make some effort to format code properly. Dumping a single-line `for...if...if...` on people is no way to ask for help. – Marcelo Cantos Oct 07 '11 at 13:01

1 Answers1

0

You may want to consider implementing a lock-free circular buffer to transfer data between the ISR and main():
Circular lock-free buffer
Non-blocking algorithm

Community
  • 1
  • 1
Alexey Frunze
  • 61,140
  • 12
  • 83
  • 180
  • But it probably has to have a "lock" (semaphore/mutex) since it is shared by an ISR and main(). You will get problems if the ISR is writing to the buffer while main is reading it at the same time. – Lundin Oct 07 '11 at 13:37
  • @Lundin: If done properly and there are no odd cache effects to workaround, no locks are needed (atomic r/w/increment are sufficient) as long as there's only one reader and one writer for each such buffer. I've done it on a few platforms (x86 and TMS32054xx). – Alexey Frunze Oct 07 '11 at 14:02
  • The problem isn't really whether the access instructions are atomic or not, but rather that the UART may get an interrupt at any given time and overwrite the data stored. You will have some sort of lock and perhaps also double buffers to avoid that. And have in mind that this is a PIC, which is about as far from x86 as you get. The PIC is so painfully slow at executing code, that it may even be too slow to catch up with common RS-232 baudrates. – Lundin Oct 07 '11 at 14:20
  • @Lundin: if your code can't keep up with your data rates and the buffer overflows (7 bytes are probably too few to accommodate latencies), something's seriously wrong. Btw, control flow can help here (when you're close to filling the buffer completely, drop DTR/DSR/whatever to signal to the transmitter that the receiver isn't ready). – Alexey Frunze Oct 07 '11 at 14:33
  • 115200bps is a common baudrate which means you'll be getting a new byte every 87us (1/115200 * 10 bits). I think that's going to be tough to handle for most 8-bitters, PIC in particular. A large hardware input buffer in the UART peripheral on the MCU will help a lot - I don't know if PIC has this or not. – Lundin Oct 10 '11 at 09:39