AT91SAM7S and RS232: FreeRTOS Example?

sjlongland wrote on Tuesday, April 22, 2008:

Hi All,

I’m trying to develop a simple “hello world” application to familiarise myself with FreeRTOS.  This is part of a final-year university electrical engineering project.  The development environment:

o IAR Embedded Workbench v5.11 for ARM (Kickstart edition) on Windows 2000 Pro
o FreeRTOS 5.0.0
o ATMEL AT91SAM7S-EK development board

Looking at the Demo ports, I’ve managed to get the IAR example for the AT91SAM7S64 working… building and clicking the Go button yields an immediate “New Hardware Found” dialogue, stating it has found a “ Joystick”, and the LEDs on the board start flashing furiously.  So I know the board works, and that FreeRTOS executes on it.

What I can’t seem to put my finger on, is either:
(1) Documentation on how to interface with the UART on the board
(2) Example code that interfaces with the on-board UART

Ultimately I’ll be switching to using an AT91SAM7X board – the project is to investigate controller area networks.  As part of this project, I’d like to use RS-232 to act as a human-machine interface.

The demos seem to include a comtest.c example that would appear to do this – it is included in the AT91SAM7S64 IAR example, but the code doesn’t appear to have a visible effect on the serial port.  I’ve got the UART port hooked up to one of my desktop’s serial ports via a null-modem cable, with HyperTerminal configured at 115200 baud, 8n1, no flow control.

Has anyone seen any well-documented examples on how to drive the serial ports on these things, or know of some documentation describing how to go about it?  I’ve looked at the PDFs supplied on the DVD that came with the board, as well as the documentation on ATMEL’s site.  If anyone has any tips on how to go about this, I’d be very interested.  If I have to write one from scratch, I’m also happy to make a bare bones version that can be included in the FreeRTOS distribution.

Stuart Longland

davedoors wrote on Tuesday, April 22, 2008:

The comtest.c file is a generic test file used in all the demos that calls an MCU specific UART driver. The UART driver itself is normally simply called serial.c and included in a directory also called serial off of the project directory, Demo\ARM7_AT91SAM7S64_IAR\serial in this case. Note that there is also a serialisr.s file in the same directory.  The serialisr.s file contains the entry code for the interrupt handler. Are you including both the serial and serialisr files in your build?

The comtest.c file sends characters out of the serial port from one task and attempts to read them back in again from another task, so you need to connect Rx to Tx on the COM port for this to work. If you were instead to connect the COM port to Hyperterminal you should see the characters being transmitted (just the alphabet).

The serial.c file for the SAM7 just uses the driver functions provided by Atmel. You will see functions like AT91F_PMC_EnablePeriphClock being used. It might be that you need to include a different header file to get the right driver functions if the MCU you are using is different to that on which the demo was created.

sjlongland wrote on Wednesday, April 23, 2008:

Ahh… so it does… I’m not sure why I didn’t see this last time I tried it… It didn’t appear to be working last time I tried using it, but it certainly is working now.

Thanks. :slight_smile:

sjlongland wrote on Wednesday, April 23, 2008:

Ahh… got it working now.  I’m not sure why it didn’t work the first time, but I’m seeing data written to the serial port now.

That code seems to break, if I use the heap_3.c memory manager.  heap_1.c and heap_2.c work fine, but heap_3.c breaks the code.

But it seems I’ve got some life now… I’ve just got to look out for memory fragmentation.