No, seriously, if you played with serial communications you know that using an ISR helps a lot because you never know when the other device decides to send a few bytes on the line.
Asynchronous communication in full duplex baby!
So it is good to have an Interrupt Service Routine that gets the data for you from the line while you are busy doing other things.
Typically you are going to have a buffer with two pointers: one knows where to find the first location in the buffer where to write data and the other knows the first location where you did not get data out of the buffer yet.
If the two pointers point to the same lcoation, then there is no data to be extracted from the buffer.
In general this is a convenient way to buy some time and check every now and then if we received some data.
In the image above you can see an example where 3 bytes were received, so the write pointer points to the 4th location and 1 byte was read from the buffer, so the Read Ptr points to the 2nd location.
The two pointers have different values, so there is still data to be read in the buffer.
Obviously while you read and write you increment the relevant pointer, resetting it to zero when it reaches the end of the buffer.
This is one way to manage asynchronous communications, of course you could add some logic in your Interrupt handler routine to make your application react immediately i.e. when a specific character is received.
It is in genreral good practice, tho, to have as little logic as possible in the ISR routines, they should complete in the shortest amount of time possible.
Now, the funny thing is that the buffer we described is also called a FIFO (First In-First Out) buffer... which is already supported via hardware in the Cortex M3.
That's right, if you needed just a few bytes in your buffer, no need to set up an ISR, you could simply enable the internal FIFO and you can still do it even if you decide to use interrupts.
void SER_fifo(int uart,uint32_t enable,uint32_t dma,uint32_t trigger)
{
LPC_UART_TypeDef *pUart;
pUart = __get_uart_base(uart);
pUart->FCR |= (enable&0x1)|((dma&1)<<3)|((trigger&0x3)<<6);
}
The Fifo Control Register (FCR) can be used to enable the Fifo, define how many bytes should be received by it before triggering an IRQ and if it should use a dma channel to automatically copy the data to a specific memory location.
Neat eh?
@NXP
You can also reset the fifos (both the output fifo and the input fifo)... wait.. output fifo?
Yes, serial communication might be a bit slow for MCUs and imagine you need to send a few bytes out: the output fifo will be happy to store some of those bytes for you so you can go have fun doing other interesting tasks while it handles the communication.
You can do the same thing with an ISR routine or even use both at the same time.
Notice that you can activate both (RX and TX) fifos or none of them, but you cannot activate just RX and not TX or the other way round.
Now, let's see the interrupts.
The UARTxIER are the Interrupt Enable Registers for the various UARTS.
There are two interrupts we want to consider there :- The one generated when a new byte is received (or when the number of bytes in the fifo reaches the trigger threshold, if enabled) and this is the RBR one.
- The other, generated when the line is ready to send out some new data, meet the THRE (Transmit Hold Register Empty) interrupt.
The third one is triggered when the status of the receive line changes.
#define IER_RBR 0x01
#define IER_THRE 0x02
#define IER_RXLS 0x04
pUart->IER = IER_RBR | IER_THRE | IER_RXLS;
That line enables the uart interrupts... almost.
Actually we also need to enable the Uartx IRQ in the Nested Vector Interrupt Controller (NVIC) which has a cool name because it does cool stuff.
switch (uart)
{
case 0: NVIC_EnableIRQ(UART0_IRQn); break;
case 2: NVIC_EnableIRQ(UART2_IRQn); break;
case 3: NVIC_EnableIRQ(UART3_IRQn); break;
}
Now interrupts will be fired upon events and we should really do something with them.
To capture them we just need to define a function (one per each uart we use) with a specific name, I am using uart2 so :
void UART2_IRQHandler(void) __irq
{
...
}
Now we need to fill it with some good code, because I never had luck in succesfully compiling a statement like "...", so I guess it's not going to work for you either.
First thing, let's just say we want to have an input buffer which will be filled by the IRQHandler procedure.
#define UART_RX_BUFSIZE 32
uint8_t UART_RxBuf[UART_RX_BUFSIZE];
uint8_t bufWptr =0;
uint8_t bufRptr = 0;
Then we need to consider that the IRQHandler will be called for every kind of uart (uart2 in my case) related interrupt.
By "every" we actually mean as many as you can count with two fingers (or two bits), in other words : four.
This is the Interrupt Identification Register (IIR) which can be used to get the IntID, a 2 bit number that identifies which interrupt we are dealing with.
void UART2_IRQHandler(void) __irq
{
uint8_t intId;
intId = ((LPC_UART2->IIR)>>1)& 0x7;
switch (intId)
{
case INTID_RXLS : break;// whatever
case INTID_RDA :
while((LPC_UART2->LSR) & 0x1)
{
UART_RxBuf[bufWptr++] = LPC_UART2->RBR;
if (bufWptr >= UART_RX_BUFSIZE)
bufWptr = 0;
}
break;
case INTID_CTI : break; // whatever
case INTID_THRE : break; // whatever
}
}
This is a simple implementation that should provide RX interrupt handling, notice it does not check if our software buffer is overran.
Let's just add a couple of functions to get the data out of the buffer and check if we should do it.
int SER_hasBufData()
{
return (bufWptr!=bufRptr);
}
uint8_t SER_getBufData()
{
if (bufRptr>=UART_RX_BUFSIZE) bufRptr=0;
return UART_RxBuf[bufRptr++];
}
And finally we can update the test program
int main(void)
{
SystemInit();
setpll0(25,2,3);
SystemCoreClockUpdate();
SER_init(2,115200);
SER_fifo(2,1,0,0);
while (1)
{
delay(10000000);
SER_putString (2, ".");
while (SER_hasBufData())
{
SER_putString (2, "Received : ");
SER_putChar(2,SER_getBufData());
SER_putString (2, "\r\n");
}
}
return 0;
}
As usual, you can get my full code here.
