Serial data problem with upgrade 4.099 to 4.124

[cassioriguela]

Dear friends,

I have a problem with upgrade 4.099 to 4.124. I have a firmware that receives some data from serial interface and put it into a buffer, like EX_SISR.C. After updated, I have some data lost, i can see it because i'm sniffing serials pins. In sniffer, I receive complete packets, but when I look my buffer it's possible to see that i lost some data, generally, the last bytes.

See interrupt code:

[asmboy]

i'm surprised it EVER worked

in the #use rs232 - SPECIFY RX TX pins and add ERRORS

read your manual !!!
then one messed up routine at a time:

[Ttelmah]

UART1, works instead of needing to specify the TX/RX pins, so this one wouldn't cause a problem, but ERRORS, is absolutely essential. It should _only_ be omitted if you are handling errors yourself. So agree 100% about this bit.

The point about removing kbhit, is that it is extra work not needed. The interrupt _only_ triggers, when there _is_ a byte to read. Testing if a byte is available, is pointless. However Asmboy has forgotten to remove the corresponding close bracket. This needs correcting.

Add the comment that using the % operator is really to be avoided in the interrupt. It is not 'too bad' with a binary buffer size, and 8bit addresses, but with 16bit addresses here it makes many times more work than is needed. AsmBoy has fixed this, but not explained 'why'.

Agree about the buffer full handling. Much slower than ideal. However 't' needs to be an int16, not a byte, since the indexes (configuration not shown), need to be int16, for a 512 buffer size. Hopefully they _are_ int16?....

However the 'else' is not needed in the buffer handling, the earlier return means you only reach this if you haven't returned before, so gives the 'else' behaviour.

Best Wishes

[cassioriguela]

Thanks for response asmboy.

I forgot but I define pins tx e rx. See code:

[cassioriguela]

[asmboy]

First I would - if possible - USE A SMALLER buffer
and then poll Zkbhit more often.

[cassioriguela]

[asmboy]

[cassioriguela]

Thanks for response, asmboy.
I'm doing exactly it.

Thanks

[cassioriguela]

I don't know what is happening. Somebody has more any idea ? I'll contact CCS support.

Thanks

[cassioriguela]

Just for helping somebody helping me.

My code gives me some warnings:
>>> Warning 216 "main.c" Line 5396(0,1): Interrupts disabled during call to prevent re-entrancy: (@PUTCHAR_3_)
>>> Warning 216 "main.c" Line 5396(0,1): Interrupts disabled during call to prevent re-entrancy: (@DIVS3232A)

I think that my interrupt is going down and i'm losing some data.
Somebody has some idea why i'm getting this warnings ?

Thanks!

[Douglas Kennedy]

Interrupts aren't parallel processes. In the main code the compiler expects that an interrupt can occur at any point in the code. Now suppose you use a function in the main code that takes a few instructions to execute then it could get interrupted. Now lets further assume that very same function is inside an ISR. To the compiler that means the function could be interrupted in main and at the same time be asked to execute in the ISR. That's what the compiler doesn't like so it protects the function in main by making it interrupt proof. The way to look at interrupts have the code as small as possible and remember that some arithmetic functions and others built into CCS are accomplished by internal function calls to keep the code size down so if they are used in an ISR they will be protected by the compiler in main.
Division exponentiation trig functions aren't good to have inside an ISR if used also in the main code due to the lockout of the interrupt while they execute in main

[Douglas Kennedy]

Zigbee will involve interfacing to a RF transceiver. The transceiver's receiver is asynchronous. Further the whole system is half duplex. Next timing is very critical. Generally this means that the transceiver's receiver probably needs a priority interrupt and that the transceiver's transmitter needs to be managed so as not to intentionally walk over any incoming packets. Zigbee has the further disadvantage that it expects a master controller aka PAN coordinator to be powered at all times ( probably tethered to a mains supply with battery backup). Anyway the interrupt logic will be very time dependent and the PIC will probably need its timers synched to the transceiver which in turn is synched to the master controller.
Even with this I'd still assume asynchronous reception due to drift in the transmitting devices clocks. Anyway with all this going on I'd want the ISR's to be very lean and mean and I'd choose a PIC with several timers plus a good Xtal to get precise timing intervals and reduced drift overtime. Probably a 24 series to get the interrupt priority.

[cassioriguela]

[cassioriguela]