05945818

8/13/2019 05945818

http://slidepdf.com/reader/full/05945818 1/4

Small operating system for Freescale HCS08 microcontrollers

Jan Dolinay, Petr Dostálek, Vladimír Vašek

Faculty of Applied Informatics

Tomas Bata University in Zlin

Zlin, Czech Republic

e-mail: [email protected]

Abstract —This contribution deals with small real-time

operating system RTMON developed at our institute as a

teaching aid for microcontroller programming lessons. This

new system is based on previous versions of RTMON for HC11

microcontroller and for PC. It should make it possible for

students to understand the basic concepts of creating

applications with use of operating system and easily write their

own applications with several concurrently running processes

in C language. The operating system currently works on

Freescale HCS08 GB60 and QE128 microcontrollers and also

on Atmel AVR Mega8 microcontroller.

Keywords-Microcontroller, HC08, real-time, operating

system

I. I NTRODUCTION

In microcontroller (MCU) programming, real timeoperating system (RTOS) can be used to help solve the usual problems related with this task, for example, the requirementof executing multiple tasks concurrently, quick response tohigh priority events, managing hardware resources of theMCU, etc. In our lessons of microcontroller programmingwe include RTOS based programming as well.

On 16-bit or 32-bit MCUs, RTOS are used quite often;on smaller 8-bit systems it is not usual, because these

systems have limited memory and CPU power and it is moreefficient to write the required program without RTOS. Nevertheless, if the RTOS is small enough to “fit“ into suchMCU, it can still bring the same advantages as on a biggerMCUs. In our lessons we use Freescale Semiconductor 8-bitMCU with HCS08 core. As we wanted to include a RTOS programming techniques into our lessons we needed a RTOScapable of running on this MCU. The other options would beto add to our portfolio another MCU, e.g. 32-bit, but then thestudents would have to learn 2 different MCUs in the samelimited time, which would probably lead to confusion.Moving to 32 MCU completely, abandoning 8-bit wouldseems as better option, maybe, but this would have thedisadvantage that such an MCU is typically very complex

(many peripherals with advanced functionality resulting inmany control registers). For programming such an MCU onetypically uses software drivers (either stand-alone orincluded in a RTOS) because programming some peripheralat the level of setting up the register values is very long andtedious task. This would not fit the purpose of our course,which is to give the students understanding of the basic principles.

If we look at the available RTOS there are quite many ofthem. As mentioned above, most of them are focused on bigger 16-bit and 32-bit MCUs, but there are some whichsupport also small 8 bit MCUs. FreeRTOS [2] can bementioned, which is distributed under GPL license andcurrently officially ported to 23 architectures. Anotherexample is MicroC/OS-II [3] which is also free foreducational, non-commercial use. It is suitable for use insafety critical embedded systems such as aviation or medicalsystems and is ported to great number of architecturesincluding Freescale HC08 and Atmel AVR.

One disadvantage of using such a professional system isthat it is often quite complex due to the wide options itoffers; typical RTOS for 32 bit MCU contains drivers forUSB, Ethernet etc. and even though it is configurable towork in simple arrangements, the user can still have toomany things to worry about.

Moreover, there was already an RTOS system developedat our institute for PC based systems and also for HC11, andthe students are familiar with its interface. So even if itwould not be impossible to choose from existing systems, itwas decided to implement a light-weight version of theRTMON system for our lessons. Once the system was upand running for our HCS08 derivative (GB60) it becameuseful to port it to other derivatives also. As a result,

RTMON currently supports two members of HCS08 MCUfamily: GB60 and QE128 [4], and also Atmel AVR MCUsATmega8 and ATMega168. Adding new derivative is quitesimple so the list will possibly grow in the future. In thefollowing text we describe the properties of the RTMON forHC08 (and AVR) microcontrollers, the original system forPC and HC11 has wider options

II. RTMON DESCRIPTION

The RTMON system is used as a precompiled libraryaccompanied by a header file. This simplifies theorganization of the project and the build process. Userenables RTMON usage in his program by including theheader file (rtmon.h) in his source and by adding the library

to his project. Currently the library and sample projects areavailable for two development tools: Freescale CodeWarriorand Atmel AVR Studio with WinAVR suite.

If needed, user can also rebuild the RTMON library.Typically this is useful to change the configuration such asmaximum number of tasks, length of the OS time period(tick), etc. There is documentation which describes the

70978-1-61284-361-2/11/$26.00 c2011 IEEE

8/13/2019 05945818


procedure and also projects for the two supported IDEs,which can be simply opened and rebuild.

RTMON is preemptive multitasking OS which issimplified to a great extend to allow easy use for students. Itis written in C language with the exception of small platform-specific code written in assembler. The schedulerassigns time slices to processes based on their priority. The priority is integer in the range 1 to 254. Priority 0 is thehighest and is reserved for the RTMON initialization process

and priority 255 is the lowest and is reserved for the idle process (called dummy in RTMON).

RTMON allows execution of two different types of processes (taks): normal processes which execute only once(such process typically contain infinite loop) and periodical process which is started automatically by RTMON withgiven period. These periodical processes are useful for manyapplications, typically for example in discrete controllerswhich need to periodically sample the input signal andupdate the outputs.

For the sake of simplicity of both the implementation andusage, several restrictions are applied. First, the RAMmemory for processes and their stacks is statically allocatedfor the maximal number of processes as defined in

configuration file. In the user program, it is not possible touse this memory even if there are fewer processes defined. Incase more RAM is needed for the user program, themaximum number of tasks and/or stack-pool size can bechanged in configuration file and the RTMON library must be rebuild.

The priority of each task must be unique, so that in eachmoment one task (the one with highest priority) can beselected and executed on the CPU. The scheduler does notsupport cyclical switching of several processes with the same priority on the CPU in round-robin fashion; it simplychooses the task with highest priority from the list of taskswhich are ready to run. Processes can be created on the fly, but it is not possible to free and reuse memory of a process.

No more than the maximal number of processes can becreated, even if some processes were previously deleted.These restrictions however do not present any big

problem for most applications and allow for small kernelcode size and ease of use.

There are only two objects (data structures) in theRTMON system: process (task) and queue. The queues are buffers for transferring data between processes. It wouldmore properly be called mailboxes in our implementation aseach queue can contain only 1 message. Several queues can be created, each containing a “message” (data buffer) ofcertain size. The size can be specified when creating thequeue and is limited by the total size of RAM reserved for all buffers of all the queues (queue pool size). Processes can

read and write data to the queue and wait for the queue to become empty or to become full. This allows for use of thequeue also as a synchronization object (semaphore).

III. RTMON SERVICES

The following basic operations can be performed with a process in RTMON. Each operation corresponds to a

function in the RTMON library which user program can call.These functions are described in more details below.

• create process

• start process

• stop process

• delay process

• continue process execution

• abort (delete) process

For queues there are the following functions:• create queue (specify size)

• write to queue with/without waiting

• read from queue with/without waiting

There are also two functions for controlling the RTMONitself:

• initialize RTMON

• end RTMON operation

First service called by the user program should bertm_init, which has the following prototype:

char rtm_init(IDPROC** init_id);This function will initialize RTMON data structures andcreate 2 built-in processes: init and dummy. The dummy isthe idle process which runs when no other process is ready torun. It has priority 255, which is the lowest. The init processin RTMON is a special process with highest priority (0) andit is the process which controls creation and end of all other processes. By calling rtm_init the user program obtains ID ofthis init process. In fact, the C function which calls rtm_init(typically it is the main() function) becomes the body of theinit process. So from the call to rtm_init on from theRTMON’s point of view the code of function main is nowthe code of the init process and it is executed until it delaysitself by call to rtm_delay_p. The init process will createother processes and then start them, but no other process willactually execute until init process puts itself into sleep because the init process has the highest priority.

The returned value is either RTMON_OK of one of theerror codes defined in RTMON.h. This is the convention forall RTMON functions that they returns this code.

Function rtm_end is used to end RTMON operation.

char rtm_end(IDPROC* init_id);It stops the init and dummy processes and stops the

periodical timer interrupt which provides ticks for the OS.This service can be called at the end of user program (end ofmain function). However, since typical embeddedapplication runs infinitely and never ends, it is often notneeded to call this service at all.

Services for working with processes start with thefunction which creates a new process – rtm_create_p, whichhas the following prototype:

char rtm_create_p(const char* pname, unsigned char prio, void(*pfunc)( ), int stack_size, IDPROC** proc_id );

2011 12th International Carpathian Control Conference (ICCC) 71

8/13/2019 05945818


This service creates a new process in RTMON andreturns the caller (via the proc_id parameter) the identificatorof this process which is then used for all further operationswith this process (e.g. to start or stop it).

The arguments of this function must provide enoughinformation to configure the process.

• pname – this is descriptive name of the process. It iscurrently not supported by RTMON to savememory, so it is ignored and need not be set.

• prio – the priority of the process. This is integer between 1 and 254, the values 0 and 255 arereserved for RTMON. The higher is the number thelower is the priority.

• pfunc – pointer to the function which represents the process. This is the code of the process.

• stack_size – size of the stack for this process.Each process has its own stack which must be bigenough to hold all CPU registers (saved on interrupt), alllocal variables (defined within the function whichrepresents the process) and all return addresses forfunction calls made from the process including systemcalls. RTMON keeps an array in RAM (stack pool) fromwhich it allocates stacks as specified in call to

rtm_create_p. The maximal size of stack of all processescannot exceed the size of this stack pool. The pool size isdefined in header file and can be changed, but theRTMON library must be then rebuilt. Required size ofstack depends on architecture and also on the number ofvariables and function calls in the process, typicalminimum value is about 32 bytes if the process usesvirtually no stack and about 64 for normal processes. Ifsome stack-consuming function is used, the stack sizemust be extended accordingly. For example, on HC08GB60 we found out that when using sprintf functionwithin the process, the stack should be at least 100 bytes big, or even more.

char rtm_start_p(IDPROC* proc_id, int time_to_start,int time_period);

Starts a process. After using rtm_create_p the processexists in RTMON but is not scheduled, not executed on theCPU. For the process to actually start executing, it must bestarted by rtm_start_p service.

• proc_id - is the ID of the process to start. It isobtained by previous call to rtm_create_p.

• time_to_start – is the delay for the start, so that the process is not started immediately but only afterspecified number of ticks. Typically this argumenthas value 0 which means the process is startedimmediately.

• time_period – this argument allows specifying the

period with which the process is automaticallyrestarted. If it is 0 the process is started only once(typical for processes which then run in infiniteloop). If it is nonzero then is the period in ticks withwhich the process is started repeatedly. It isimportant to ensure that the process ends in shortertime than is the period of start in this case. This is

useful for high priority processes which need to periodically perform some short action, e.g. measureinput and save the result.

char rtm_delay_p(IDPROC* proc_id, inttime_to_delay);

This service allows pausing execution of given processfor specified period of time (given in ticks). Value of 0means infinite delay, which puts the process into sleep until

it is waken up by other process.

char rtm_continue_p(IDPROC * proc_id);This service continues execution of a process previously

delayed by rtm_delay_p call.

char rtm_ch_period_p(IDPROC * proc_id, inttime_period);

This service changes the period of a process. Theargument time_period specifies the new period of start of the process. Typical use of this function is to cancel the periodical start of a process by calling this function withtime_period equal to 0. This is necessary when periodical process is to be stopped because without changing the period

to 0 (canceling periodical start) the process wouldautomatically start in the next period.

char rtm_stop_p(IDPROC * proc_id );Stops execution of a process. Most common use is to call

this function at the end of the process in periodical processes.Such process must end by this call to return control toRTMON. Another use is to stop all processes when RTMONis ended if such situation is needed.

char rtm_abort_p(IDPROC * proc_id );Removes process from the list of existing processes in

RTMON. This function has currently no use becauseRTMON does not allow reclaiming memory occupied by a

process when the process is aborted, so even if process isaborted, it does not allow creating a new process instead ifthe maximum number of processes is reached.

Besides the services for working with processes,RTMON also contains services for working with queues.Queues are optional component which can be excluded fromthe system if not needed, to save memory. In such case theseservices are not available.

There are three basic operations supported on a queue:create, write and read. Deleting a queue is not supported. It isassumed that the developer defines all required queues aheadand does not need to dynamically create and delete queues inthe run time.Before use, queue must be created using rtm_create_q

service which has the following prototype:

char rtm_create_q(const char* pname, char l_msg, charn_buff, IDQUEUE** pid_queue);

• pname is the name of the queue, it is not usedsimilarly as in process name in rtm_create_p.

• l_msg is the size of the buffer (message) which thisqueue can hold. The size is limited by size of queue

72 2011 12th International Carpathian Control Conference (ICCC)

8/13/2019 05945818


pool defined in RTMON for all queues. Typicallythis operand is given as sizeof of the type passed bythis queue. For example, if processes will exchangean integer value through this queue, then the l_msgargument would be given as sizeof(int).

• n_buff – the number of messages (buffers) this queuecan hold. This argument must be 1, this version ofRTMON does not support more than one message.

• pid_queue - this receives the id of the newly created

queue. User program then uses this ID for all furtheroperations with the queue.

For writing and reading messages to queues there are twoversions of functions – one with suffix _w which stands for“wait”. Such function waits for the queue to becomefull/empty if it is not in the proper state. These wait functionscan be used to synchronize process execution.

The queue functions have the following prototypes:

char rtm_write_q(IDQUEUE* pid_queue, void* pdata);char rtm_write_q_w(IDQUEUE* pid_queue, void*

pdata);char rtm_read_q(IDQUEUE* pid_queue, void* pdata);char rtm_read_q_w(IDQUEUE* pid_queue, void*

pdata);

pid_queue is the ID of the queues obtained by previouscall to rtm_create_q and pdata is pointer to memory bufferwhich received or contains the data to be read from orwritten to the queue. RTMON always reads/writes thenumber of bytes defined by queue size into this buffer; theuser must ensure that this buffer has the proper size (is a pointer to proper data type).

IV. CONFIGURING RTMON

There are several macros defined RTMON configurationfile which allow customizing the system to user’s needs. It is

important to note however, that after changing any of thesedefines the RTMON library must be rebuild, otherwise thechanges have no effect. Examples of configuration constantsare:

• RTMON_SMALL – allows using 8-bit instead of16-bit variables in process data structure.

• USE_QUEUES – allows removing the queues fromthe RTMON library, so that if queues are notneeded, the respective functions can be removed andthus memory space is saved.

V. REBUILDING RTMON

As mentioned, RTMON can be customized by either the

configuration defines described earlier or by modifying thecode itself. In either case the system library must be rebuild.Rebuilding the system is not different from building anyother program in the development IDE. In case of HCS08microcontrollers, this IDE is CodeWarrior, in case of AVRMCUs, this is AVR Studio with WinAVR tools installed.

There are projects prepared for these IDEs, so rebuilding theRTMON library is just a matter of opening the project,changing defines in the header file as required and rebuildingthe project.

VI. CONCLUSION

Simple real-time operating system for Freescale HCS08microcontrollers has been created. This system is intended as

a teaching aid for lessons of microcontroller programming.The interface is based on already existing version of thesystem for PC and HC11 microcontroller, but the internalshave been written completely for the scratch to allow it towork with limited data and code memory of small 8-bitmicrocontrollers. RTMON is pre-emptive multitaskingsystem which allows defining processes up to certain number(typically 10) and running these processes either in infiniteloops or periodically with given period. Available functionsare very simple due to the limited memory of the targetmicrocontrollers and intended use of the system, but still thesystem provides the advantage of easy implementation ofembedded system as a set of independent, concurrentlyrunning tasks. The main limitation of current implementation

can be seen in the inefficient use of RAM memory for process stacks and queues which are allocated at build-timeof the RTMON library and must be therefore defined inclose relation with intended application, number of processesand their contents. This implementation is advantageous forschool exercises because it allows easier implementation inuser application, but for practical use in the industry it is notcomfortable as it requires rebuilding the library for eachapplication. However, this rebuild is not a difficult task, soeven in this implementation the system is usable.

Currently, RTMON is ported to Freescale HCS08 GB60and QE128 derivatives and to Atmel AVR Mega8 MCU.The source code is structured for easy modification and porting to other platforms. In the future it would be desirable

to port RTMON to more MCUs, but also to extend thefunctionality by some I/O drivers, such us driver for general purpose inputs and outputs, serial communication etc.

ACKNOWLEDGMENT

This work was supported by the Ministry of Education,Youth and Sports of the Czech Republic under the ResearchPlan No. MSM 7088352102 and by the European RegionalDevelopment Fund under the project CEBIA-Tech No.CZ.1.05/2.1.00/03.0089.

R EFERENCES

[1] T. D. Morton, “Embedded Microcontrollers,” Prentice Hall, Upper

Saddle River, 2001.[2] The FreeRTOS Project. Available from: <http://www.freertos.org>

[3] Micrium RTOS and Tools. Available from:<http://micrium.com/page/products/rtos/os-ii>

[4] Freescale 8-bit microcontrollers. Available from:<http://www.freescale.com/webapp/sps/site/homepage.jsp?code=8BITMCU>

2011 12th International Carpathian Control Conference (ICCC) 73

05945818

Documents