FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [February 2010 Threads] LPC17xx Serial examplePosted by Ron B on February 25, 2010 Hello, I am trying to make a serial driver for the LCP1768, which I tried to derive from the serial driver that was included with STM32 examples. My example is close, but crashes "after some time." Does anyone have a good example that works with the LPC17xx series?
Thanks
RE: LPC17xx Serial examplePosted by Ron B on February 27, 2010 Well I haven't seen a follow up yet, so let me expand my issue. The main problem that I am having with the LPC1768 is that you cannot have a fully interrupt driven serial driver because the Transmit ISR only triggers on a FIFO transition to empty instead of generating interrupts while empty. So while IDEALLY I would like to do this: My code would call this function to place characters into the serial buffer: signed portBASE_TYPE serial_putChar(signed portCHAR ch, portTickType xBlockTime )){ signed portBASE_TYPE xReturn = pdFAIL; xReturn = xQueueSend( TxQueue, &ch, xBlockTime ); UART1->IER |= UART_IER_THREINT_EN; return xReturn; }
And this would be the serial interrupt handler: void serialISR(){ portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE; portCHAR cChar;
if(UART1->IIR & UART_IIR_INTID_THRE){ if( xQueueReceiveFromISR( TxQueue, &cChar, &xHigherPriorityTaskWoken ) == pdTRUE ){ UART1->THR = cChar; } else{ UART1->IER &= ~UART_IER_THREINT_EN; } } portEND_SWITCHING_ISR( xHigherPriorityTaskWoken ); }
This part doesn't work like that. So I am working to have a task load the THR transmit register for me. This is what I have so far (rough outline): My main function call would be signed portBASE_TYPE serial_putChar(signed portCHAR cOutChar, portTickType xBlockTime ) { signed portBASE_TYPE xReturn = pdFAIL; if( xQueueSend( xCharsForTx, &cOutChar, xBlockTime ) == pdPASS ){ xReturn = pdPASS; } return xReturn; }
The interrupt handler: void serialISR(void) { portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE; portCHAR cChar;
if(UART1->IIR & UART_IIR_INTID_THRE){ { xSemaphoreGiveFromISR(xSendSemaphore, &xHigherPriorityTaskWoken); } portEND_SWITCHING_ISR( xHigherPriorityTaskWoken ); }
And my task to load characters into the THR register would be void xUARTsendTask(void *pvParameter) { uint8_t sendChar; vSemaphoreCreateBinary(xSendSemaphore); xSemaphoreTake(xSendSemaphore, 0);
for( ;; ){ xQueueReceive(xCharsForTx, &sendChar, portMAX_DELAY); UART1->THR = sendChar; xSemaphoreTake(xSendSemaphore, portMAX_DELAY); } }
The problem I have with this is that it halts have transmitting 2 characters. So what I am looking for is some ideas on making this work.
RE: LPC17xx Serial examplePosted by Richard Damon on February 27, 2010 While I am not familiar with this processor, here is what I tend to use a the pseudo code for the transmit character routine:
Place character into software queue if that worked and serial transmit buffer is empty, force transmit buffer empty serial interrupt.
The key here is finding a way to force the interrupt. On many processors you can write to the interrupt request flag to set it, or have some other way to trigger the interrupt.
RE: LPC17xx Serial examplePosted by tgarner on February 27, 2010 What I usually do is use the Tx interrupt enable as a busy flag.
Putchar(c) { if( Tx IE flag ) put c in Queue else { Set Tx IE flag Write C directly to hardware } }
ISR if char in Queue transmit it else turn off Tx IE flag
RE: LPC17xx Serial examplePosted by Richard Damon on February 27, 2010 That has a race condition. If the interrupt for the last character going out occurs between the test of the IE flag and the insertion into the queue, then you end up with a character in the queue that will get output out of order, as the next character sent out will go directly to the transmit buffer, and then the queued character. One fix, if it is available, is to disable interrupts around the code.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|