Using Interrupt driven serial Port on 8051

thou shallt never disable the interrupt on a recv serial port.

"Makhan" schreef in bericht news: snipped-for-privacy@posting.google.com...

Where is the gain? Sit and wait until all those other 15 bytes arrive in the serial port? It seems that such approach is only a waste of time.

Keep a 256 byte ringbuffer, and let your serial interrupt fill it. Your main loop compares a pointer/index with the one you use to fill the buffer, to check if new characters have arrived. Process those characters, and update the main pointer/index.

don't disable the IRQ function. when receiving a character have the IRQ service simply put it in a recircular buffer. using 2 pointer regs to keep track of the next one to reed from the buffer and the next one to write to the buffer. when the two pointers match this means there is no characters in the buffer. when ever they don't match you read the character from the buffer of the current next-to-pointer then increment that pointer, when storing new characters you simply store it using the next-to-write pointer and then increment that pointer for the next.. now, before storing the new incremental results of the Next-To-write pointer you should first make sure that it does not equal the current Next-To-Read pointer! other wise this indicates an over flow and some form of error should be set .. your buff could be a simple 16 bytes or more depending on how much traffic your processor will take. lets assume its a 16 byte buffer, you do this in math Next-to-read = (Next-to-read+1) and H0F; ( $0F, 0x0f etc. take your pic); that will create a nice wrap around buffer.. etc..

Makhan wrote:

Please don't toppost. Your answer goes after, or possibly interleaved with, appropriately snipped quoted material. i.e. remove anything not germane to your answer.

You also need to resolve how to handle buffer overflow on input. For interactive use I recommend discarding the oldest char, rather than the new char. This allows a manual interrupt such as CTL-C to be noticed.

You also need to serialize access to the buffer pointers, unless there's an atomic read-modify-write on an 8051 (which I don't know, being a PIC guy). Otherwise once in awhile your mainline code will be interrupted after reading the buffer pointer and before updating it--and when the ISR returns, the pointer will be overwritten. This sort of thing is a real headache to debug, so just follow the rule about not sharing resources between ISRs and mainline routines, and serialize the circular buffers used for the interface. That will make your programs much less flaky.

Cheers,

Phil Hobbs

You can avoid the need for a critical region in which you lock out interrupts by proper access rules for the buffer indexes. While both the reader (main loop) and writer (ISR) can read both indexes, only the reader should modify the read index, and only the writer should modify the write index. It's also important to never write an invalid value to an index, since the other guy (really only the ISR here) can interrupt and use it. For a power of two buffer size, you can either let a byte index freely increment through all 256 values and AND it with the proper mask before using it, or you can do a wraparound test before incrementing, and set it to zero if equal to the wrap value. It isn't a good idea to increment the index and then mask it, since prior to writing back the masked value the index will be invalid.

"Neil Kurzman" schreef in bericht news: snipped-for-privacy@mail.asb.com...

I assumed plenty of XDATA ;)

Thank you all for the discussion, I am afraid there is more to it than I first wrote.

Actually, there is an array of microcontrollers each doing identical job, that is lighting up a multiplexed LED array (of variable characters) and the characters to display are configurable ofcourse, i.e. user can choose to display any information onto the array(s). Each micro corresponds to one row.

So there we go. I thought of giving an identity (any character 0xA0 and so on) each, to the microcontrollers for the rows and initially the idea was on identity match, update the allocated IDATA space with the charcters, else just ignore.

But can you please comment on the fact that if I go for filing the buffers on each serial port interrupt I will end up writing and rewriting all the micros with same data?

Thanks

Makhan

"Makhan" schreef in bericht news: snipped-for-privacy@posting.google.com...

Each and every uC in your setup will receive and generate an interrupt for each character. Of course you only want one uC to actually display the message, if the first character matches.

But who cares if each uC stores the entire message in a ringbuffer? Your main loop will just ignore messages that don't have that first character match. When it sees a character 0x0A or higher, it has received a full previous message, and it can check if that is is a matching one that needs to be copied to your led display.

So yes, you end up writing each uC with the same data, but who cares?

Why not use 9 bit mode with an "address" as your identity ?