Request for comments on 4 task application

[Joel Sherrill]

On 2/18/2013 11:58 AM, Steven Grunza wrote:
> Hello,
>    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)
> priority.
>
> 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
> console.
>
>
> 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
> manageable)
> 	- 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
OAR ends up consulting to do the framework of applications and then
handing it off to customers to finish. Off the top of my head, there will
never be a perfect example of what you want. You need a mix of task
types.

Task 1 - Look at examples-v2/led/msg_server. That has a task
    whose sole function is to read a message queue and blink
    an led based on the message contents.  The Init task in this
    case creates and sends messages so that is an example of that.

Task 2 - No good example AFAIK. The serial IO is termios and
   http://en.wikibooks.org/wiki/Serial_Programming/termios
   would be good examples of some of the coding. The basic
   task looks like a loop with a read() call. Then parse the
   data received and act on it. Timeout as appropriate.

Task 3 - Similar to Task 1 but with a different message queue
   and message format.

Task 4 - Similar to Task 1 with different actions.

I would draw a picture with arrows showing message types
and I/O connections. :)

If everything is in response to messages, then all is simple.
If you want periodic with checking for messages on each period,
then you will want to look at examples-v2/led/ratemon1 and
on each period call message queue receive with a no_wait option
to see if any requests arrived.

Blocking mechanism of each task needs to be selected. Looks like
message queues from your description.
>
> 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
>
>
> PS
>    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...
:)
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985