Clearing EUSART flags and registers in MIcrochip mid-range devices

[jpanhalt]

MCU= PIC16F1519 (enhanced mid-range)
Language=MPASM
EUSART configured to receive only

I enable and disable the EUSART interrupt at various points in my program. Before enabling the interrupt, I want to be sure the EUSART interrupt flag (RCIF), errors, and associated error flags are clear. This is my first experience with hardware USART or EUSART.

The datasheet for the 16F1519 states that reading FIFO of the RCREG is not a reliable way to clear the framing the error flag (FERR) (See: “Note,” page 243). Since CREN will clear the OERR error, but will not clear the FERR error, I have chosen to use SPEN, which clears both.

My sequence is, therefore, read RCREG X2, toggle SPEN, and enable interrupt.

1) Do you agree with that interpretation of the datasheet and use of SPEN in preference to CREN?

2) Since SPEN clears overrun, overrun error flag, and FERR flag, does it also clear the FIFO? That is, is the double read of RCREG still necessary? I searched the Microchip forum and with Google, and there seems to be a little uncertainty about exactly what resetting with SPEN clears in EUSART. I am assuming it does not clear FIFO or RCIF.

3) Would another sequence, such as clear SPEN, read RCREGX2, enable interrupt, and set SPEN be better? Or, perhaps, clear SPEN and RCREG on leaving the interrupt and not re-enable them until after re-enabling the interrupt. Right now, I am using GIE for interrupt enable, but may change to RCIE and leave other interrupt capability available.

Regards,

John

 

[betwixt]

1. it is ambiguous. I use CREN and it seems to work fine.
2. I don't think so, it is possible for a byte to remain in the FIFO if the serial system is suspended.
3. My way is to disable SPEN to prevent further reception, then read RCREG twice to clear the FIFO, disable CREN, re-enable CREN. RCIF is cleared by reading RCREG so there is no need to do it again.

Brian.

 

[jpanhalt]

Brian,

Thank you for the quick response.

That is quite similar to what I am doing. I appreciate your confirmation that I am not totally off in the woods. Reading RCREG twice only takes 2 tcy. I am working at 8 MHz and only 9600 baud, so what's a microsecond going to hurt? The weight of opinion seems to be that the FIFO buffer is not cleared, except by reading it, so I will just assume it is not.

As best I can tell with EUSART, there is nothing that toggling CREN will do that toggling SPEN won't do, so I skipped that step.

I dislike questions that are asked in a vacuum, but I didn't want to make my question too long and risk confusion. Now that the question has been answered, here is more on what I am doing. I am measuring the duty cycle of a 100 Hz signal from a remote accelerometer and sending that data (4, 8-bit bytes) wirelessly to the 16F1519. Right now, I am playing with sending it as two, 2-byte chunks (i.e., 16 bits each for high time and total period) versus waiting until the end and sending all four bytes. I may save a couple of mS, if I do the former, but then timing becomes a little more critical. In any event, I have lots of time for a few extra steps to ensure accurate communication.

Regards, John

 

[betwixt]

That sounds very reasonable. Regarding the FIFO, as far as I can tell, reading RCREG transfers the received data directly to it's destination (W) and at the same time pushes the next byte out of the FIFO into RCREG. It makes sense to do that so that it can be retrieved as quickly as possible before there is time for the FIFO to be overwritten. So your (and my) double read of the RCREG should be enough to flush it clean.

Just out of curiosity, are you encoding the data before sending it over the wireless link? I have something similar here in which a temperature reading is sent wirelessly and I use a pseudo-Manchester encoding done in software to ensure it's integrity. The link is FM using cheap 433MHz modules with a 12F1822 at each end. The 'send' end reads temperature down a 1-wire interface, encodes it and controls the transmitter, the 'receive' end decodes the data, verifies it's CRC then forwards it using an SPI lookalike interface to a network.

Brian.

 

[jpanhalt]

I am using a pair of XBee S1's. I believe they use a proprietary encoding system, but I am not sure. Early on, I was only dealing with the accelerometer and was using a 12F683 to capture the output and do all the math. I used a serial 2X16 display. To test the XBee's, I just inserted them between that MCU and the serial display. To my utter amazement, it worked and one could barely tell any difference in the display.

Since that experiment, I have put all of my attention on using a GLCD (64X128) and on improving the data capture. I am just assuming/hoping that when I get a one-wire link between the two MCU's and get the 16F1519 doing the math, then going wireless will be "easy."

Before getting the XBee's, I had tried some inexpensive RF links and realized I needed some form of encoding like Manchester, as bit width was highly variable, particularly for the start bit.

Regards, John

 

[betwixt]

I think you are right, the Xbee uses something like Manchester coding but probably buried in some other protocol wrapper. The issue with cheap FM modules isn't the bit width as such, it's the variability of transmit and receive frequencies from one module to the next. I use my own code to ensure the data slicer is optimized and it has excellent reliability while still allowing a normal UART to pluck the bytes from the data stream. The sending end in my system is in a box, mounted outdoors and powered from a small PV panel (2" x 3.5") so it has to cope with extremes of temperature and fluctuating supply voltage, both bad news for cheap RF modules!

Brian.