ATm128 - 2 Uarts !?

nobody wrote on Tuesday, July 26, 2005:

Hi All,

I’m new to RTOS but have been working with the AVR series for the last six years and I thourght that now would be about time to learn to use a RTOS.

I’ve ported the ATm323 example to my ATm128 (using IAR compiler) this works like a charm and I understand the basic priciples of it all but !

How can i get both uarts up and running with interrupt and buffers etc. ?

I have a GPS module on UART 0 and have written a decoding driver (not for RTOS though) but if any one has some code for FreeRTOS that can decode NMEA that would be great to look at too …

Best regards
Lasse Madsen

rtel wrote on Wednesday, July 27, 2005:

The serial port drivers in the demo are written to test ISR semaphore and queue mechanisms from within an ISR.  They work fine but are not written to be optimised solutions.  They can be tailored to provide optimised solutions for different applications.  For example, depending on the priorities within your system it might not be necessary to switch tasks immediately a character is received.

If you want an example of a more comprehensive and structured sample driver than supports multiple ports then take a look at Demo\Flshlite\serial\serial.c.

As a simple change, using more than one port requires the xComPortHandle to be used to identify which port any operation is to be performed on.  This is returned from xSerialPortInit(), and then used as a parameter to the send and receive functions.  The code as delivered for the AVR only supports one port so the xComPortHandle is not used.

As a minimal mod:

+ Change the queue definitions from one Rx queue and one Tx queue to an array of Rx queues and an array of Tx queues:

static xQueueHandle xRxedChars[2];
static xQueueHandle xCharsForTx[2];

+ Change xSerialPortInitMinimal() to take a parameter that indicates which port is being initialised - port 0 or port 1.  The xSerialPortInit() function prototype can be used if easier than modifying the minimal version.

xSerialPortInitMinimal() then has to of coarse initialise the correct port depending on the new parameters.  Also when the queues are initialised you have to initialise the correct queue within the array, eg.

xRxedChars[ PORT ] = xQueueCreate( uxQueueLength, sizeof( portCHAR ) );

Finally the init function returns a handle to the port - which can just be 0 or 1 as an index into the queue arrays.

+ xSerialGetChar() then needs to use the pxPort parameter which is currently ignored.  If this is 0 for port 0 and 1 for port 1 then all that needs doing is change xRxedChars to xRxedChars[ pxPort ].  pxPort expected to be a pointer to a struct (as per the flashlite serial driver referenced above) so will probably need casting to use it as an index.

+ xSerialPutChar() as per above, just change xCharsForTx to xCharsForTx[ pxPort ].

+ The interrupt routines have to also you the correct queue within the array.

This perhaps sounds complex but really is not. 


nobody wrote on Wednesday, July 27, 2005:

Hi again,

New question, but it concerns UARTs.  When trying to run the Demo program, I come up with the following warnings when I run Make ExtCoff -

Compiling: serial/serial.c
avr-gcc -c -mmcu=atmega128 -I. -D GCC_MEGA_AVR -I. -I…/…/Source/include -I…/Common/include -g -O0 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wextra -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align -Wsign-compare -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wunused -Wa,-adhlns=serial/serial.lst  -std=gnu99 serial/serial.c -o serial/serial.o

serial/serial.c:193: warning: `SIG_USART_RECV’ appears to be a misspelled signal handler

serial/serial.c:209: warning: `SIG_USART_DATA’ appears to be a misspelled signal handler

Should I concern myself with this?  The reason I ask is vAltStartComTestTasks is the only task I cannot get to run.  If the call to it in the main.c file along with the error check for it, everything works just as it should with no problems whatsoever. 

I have reviewed the above reply and plan to look at the Flshlite program and make the changes mentioned above if they make sense with my code.

Any help is much appreciated.  Thanks,

Josh Wittmier

nobody wrote on Wednesday, July 27, 2005:

Because the 128 has to ports the signal handlers are names slightly differently.

SIG_USART_RECV is the name for single port systems,  for a dual port system it is something like SIG_USART0_RECV for port 0 and SIG_USART1_RECV for port 1.

Can’t remember the exact signal names, but you should be able to find it in the header WinAVR header files.

I think there is another older thread on the same subject in this forum.  This might also give you the exact signal names.