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!

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. Commented Oct 7, 2011 at 13:01

1 Answer 1

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

Sign up to request clarification or add additional context in comments.

5 Comments

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: 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).
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: 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).
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.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.