Request for comments on 4 task application

Steven Grunza sgrunza at
Mon Feb 18 17:58:24 UTC 2013

  I'm about to start designing/writing code for a robot system.  Some of
the high level details of the system are:
	STM32F4Discovery (with custom IO board) motor/sensor controller
running real time executive

	Cortex-A8 powered Eval board running Linux 

The Cortex-A8 board decides what to do based on its sensors and reports
from the M4 board's sensors and then sends commands to the M4 over a
bi-directional RS-232 link.

This email is about the M4 board.

I originally started my design using FreeRTOS but I have some concerns
about continuing down this path.

It appears that the STM32F4Discovery board has a BSP in RTEMS already so
I'm going to try going down the RTEMS path and see how far I get.

My first problem is how to setup the initial project.  I've been looking
through the examples-v2 files and haven't found what I feel is (or
recognize as) a good starting point for this project.  The
classic_api/triple_period example seems to be closest to what I need but
doesn't really seem to be the ideal starting point.

The basics of my design involves several tasks of equal (for now)

Task1 - Console
	This task would handle the RS232 console port.  Its output would
be mingled with any serious messages about the M4 system's state
(kprintf() like messages) and would handle debug messages of the
peek/poke type.  This task would have a message queue to accept messages
from other tasks to display on the console and would be the only
"proper" way for any other tasks in the system to get text out to the

Task2 - 2nd RS232 port
	This task would handle RS232 I/O with the Cortex-A8 system.  The
message format would be defined so that messages from the Cortex-A8
board could be sent to other tasks in the M4's system.  For now I only
expect messages to the PWM and Sensor tasks but there may be more as the
project grows.

Task3 - PWM
	This task would accept commands on a message queue and control
the STM32F4's built-in timer's to setup the requested PWM.

Task4 - Sensors
	This task would accumulate sensor data from the on-board sensors
(quadrature shaft encoders, bump-sensors, ultra-sonic range finder, etc)
and provide data to the Cortex-A8 by sending a message to Task2.  This
task would also accept messages asking for sensor readings from Task1
for debug purposes.

The ideal example would show how to setup an application with 4 tasks:
	- each task able to send and receive messages on a message queue
	- each task coded in a different file (to keep things
	- at least one of the tasks having a timer-based callback
	- at least one of the tasks showing the recommended way to
access hardware that's not supported by the BSP
	- two tasks accessing hardware based on a semaphore without
resorting to busy-waiting

This seems so simple as written above yet I'm not sure of exactly what
RTEMS calls I need, what headers to include, etc.

Any suggestions/code examples/pointers welcome.  I'm hoping to keep my
code close-enough the RTEMS standards that my code can become an example
for other similar projects.


Steven Grunza

  I've been doing embedded work for years but this is the first time
I've been the system architect.  That's a big part of the reason I'm
doing this...

More information about the users mailing list