Eugene Hutorny » VELOOS

MIHA675 – Multi Input Hall Automaton

Eugene — Thu, 07 Dec 2006 15:59:25 +0000

Previous examples illustrated VELOOS programming aspects. This post provides an example of using object oriented paradigm for designing VELOOS application. Unlike the previous examples which were purely programming exercises, this example is dedicated to a utilitarian home appliance application and provides a "reference design" for VELOOS applications.

Example3 – Designing MIHA – Multi Input Hall Automaton

Introduction

There are two common approaches for light switching in halls and staircases – off-timers and intermediate switching schemes (please excuse me if terminology is wrong). Off timers turn light on when user pushes a button and turn off when specified time elapsed. Intermediate switching schemes toggle lights when user toggles any switch (of two). Each approach has its own advantages and disadvantages, however, both approaches require special switches, which could be an undesired constraint for interior design. See, for example, Intermediate lighting switch, Stair case timer, Multifunction staircase timer

Requirements (user’s needs)

Implement a light-control appliance that:

combines off-timer and intermediate switchers
provides support for at least 3 switches
supports regular light switches as well as push-buttons
provides settable 0.5-10 min timer range with a simple user interface for entering value

MIHA Design Description

Key Design Decisions:

Implement the appliance (named MIHA) as a VELOOS application running on a PIC microcontroller
Store application configuration in EEPROM during device programming
Use potentiometer for specifying timeout

Architecture
MIHA consists of the following units (see architecture diagram on Figure 1):

Multi-input Switch Debouncer	Reads and debounces switches, sends a message on switch state changing. Featuring triple port read with majority logic and software implementation of RC-integration and Schmidt trigger.
Hall Light Automaton	Implements automaton logic, provides supports for switches/push-buttons, send ‘alt’ message to actuator and ‘off’ message to the delay block
Delay Time Input	Reads potentiometer value and sends the value read to the delay block Featuring support for multiple channels. ADC access is arbitrated via time quantization
Message Delay Block	Provides delay for the ‘off’ message.
Discrete Actuator	Turns on or off an output pin depending on the message received

Mapping Architecture to Implementation. Mapping from architectural units to implementation units is straightforward – all MIHA units are directly mapped to operating system objects, inter-unit communications are mapped to messaging. All MIHA objects are configurable with EEPROM data. To make design flexible, object configuration embeds acceptor handle. The latter two decisions establish a generality which is captured as two abstract classes: PDO – a configurable Process Data Object PDD – a dynamically bound PDO (See class diagram on Figure 2)		Figure 1.
		Figure 2.

Moduling

Major advantage provided by VELOOS is ability to design and implement loosely coupled objects. The following practice can be applied to get full advantage of loose coupling:

A unit should be made up of (at least) two files: (1) .inc containing interface and (2) .asm – implementation
Each unit should implement one class or a hierarchy of closely related classes.
A unit should not instantiate objects of reenterable or configurable classes. Instead it should publish class name in the interface.
A unit may instantiate object of a non-reenterable class. In this case it should publish object name and encapsulate class name.

Sharing RAM among objects

Decoupling objects via messaging mechanism provides a very explicit and straightforward watershed for scoping variables – everything that should survive between two messages is a part of object state and should be allocated in udata section, everything that may be discarded after handling the message is a temporary variable and can be allocated in udata_ovr section.

Using Timer for Resource Access Arbitration

Class Potentiometer Parameter Input (PPI) implements time-quantified approach for sharing ADC among several instances – time is sliced on N quants, each instance may access hardware only if TIME mod N equals to channel number. To simplify computing TIME mod N, N can be chosen as power of 2. In this example N = 16.

Multi-input Debouncer On timer event Debouncer polls the port three times in a row and applies majority logic to determine current switch state. This approach eliminates sporadic spikes than may be present in a noisy environment. For each assigned pin it maintains a counter. This counter is incremented whenever pin level is high and decremented if low. Counter is maintained in range 0..16, e.g. when it reaches the boundary it is not changed. When counter reaches upper threshold (12) logical output state is changed to 1 and to 0 when it reaches lower threshold. This is a software model of an RC-integration connected to a Schmidt trigger. Few samples of switch bouncing are shown on figures on right. The switches are regular light switches manufactured by VIKO. Hardware Schematic MIHA schematic is shown on Figure 6. Relay, loaded on PIC12, should have actuating current up to 25 mA. Resistors R1-R4 are used for pull-up and can be roughly 1 kOhm. In an environment with strong EMI their can be reduced to avoid pickup. Package Content The package includes three projects to build this application for three different devices – PIC12F675, PIC16F690, PIC18F248. It is licensed to public under the Open Software License Download MIHA Sources v.1.0		Figure 3.
		Figure 4.
		Figure 5.
		Figure 6.

VELOOS Example 3

Eugene — Wed, 06 Dec 2006 21:38:00 +0000

This example for PIC12F675 implements set of “actuators” and “generators” controlled via USART. Actuators produce one 300 ms pulse when it receives command ‘ON’ and three 100 ms pulses delimited with 100 ms spaces (pauses) on command ‘OFF’. Generators, when turned on, produce pulses and spaces of the specified duration (1..255).

Actuators and Generators are implemented as instances of Actuator and Generator classes. Yet another class in this example protocol driver parses the incoming via software USART commands and forwards it to a corresponding object. Command format is: command[data,[data]]; COM port settings: 2400, 8bit no parity, 1 stop bits.
USART is implemented in software and uses INT0 and TMR1 interrupts for timing bits.
Command language consist of 8 commands (H..O)

H,I,J control an actuator,
K,L control a generator,
N all actuators do OFF, susped all generators
O all actuators do ON, resume all generators.

H,I,J commands accepts ‘0′ and ‘1′ as a parameter to execute OFF or ON command respectively. K,L commands should be supplied with pulse and pause duration

For example:

H0 Actuator 1 do OFF
LUA Turn on generator 1 with 85 ms pulse and 65 ms space

Example 3 Sources

Hardware Scematics. Connect loads to GP0,GP1,GP4,GP5 (not shown on the schematic)

Simulation Results

VELOOS 1.0 released

Eugene — Mon, 20 Nov 2006 18:02:45 +0000

VELOOS is an object-oriented message-triggered cooperative operating system for 8-bit Microchip microcontrollers licensed to public under the Open Software License
Release 1.0 includes VELOOS kernel and two timer drivers (TMR0 and TMR2 based). It has been tested on the following devices: PIC12F675, PIC16F690, PIC18F248.

Download VELOOS v.1.0

Supporting other 14-bit core and 16-bit core devices

By design, VELOOS allocates its message at the end of available banked (e.g. not shared) memory. Unfortunately, standard .inc does not include constants defining memory limits, therefore pic.inc refines “device model” and this refinement block has to be provided for each device to be used for a VELOOS application.

ifdef __16F690 include "p16f690.inc" include "pic16.inc" _pic = _pic16F690 _pic_maxram = 016Fh ; with shared bank excluded _pic_maxrom = 0FFFh _pic_maxeeprom = 0FFh endif

With this refinement, VELOOS is expected to work for any 16-bit core devices (PIC18), and any 14-bit core (most of PIC14 and some of PIC12). Perhaps, it may also work on 12-bit core (PIC10 and some of PIC12). However, since there are no interrupts, timer drivers can not be used. Also, these devices have severe memory constraints, which make use of OS unreasonable.

VELOOS Example 2

Eugene — Wed, 15 Nov 2006 15:30:06 +0000

This post continues series of examples and describes how VELOOS can be used for implementing time-triggered applications.

Example2 – Heartbeat Driven PDO

Design idea:	Enhance previous example with a timer and two PDOs processing timer messages. Use EEPROM to keep instance-specific data.
Value:	Gives a simple example of implementing (1) time-triggered PDOs, (2) reenterable classes. Implements a class which may be used for debug purposes to watch system "heartbeat".

Design Description

This sample application implements two PDO each triggering port pin with a certain period: first PDO is on 1 sec period, second – on 1 ms. Since behavioral pattern of these PDO are the same, they were implemented as instances of the same class.

Deploying VELOOS Timer Driver

Timer Driver is a non-reenterable encapsulated PDO with an interrupt handler and internal counters for millisecond and seconds. To deploy a timer driver to VELOOS application, the project should include file vtm0.asm (Timer0 based) or vtm2.asm (Timer2 based). Timer constants are calculated automatically based on _osc_clock. Timer driver configures hardware timer for 1 ms interrupts. When a timer interrupts occurs, Interrupt Handler sends a broadcast message. Timer PDO counts 1ms messages and on every 1000-th broadcasts a 1s message. Both 1 ms and 1 s messages include current time value.

In a pseudo language messages can be declared as the following (acceptor field is not shown):

struct VTMR_cMsgTimer1ms { byte msg_id; word millisec; } struct VTMR_cMsgTimer1s { byte msg_id; word seconds; }

Handling Timer Messages

Timer messages are regular VELOOS messages. To handle a timer message, PDO should first recognize the message and then, if necessary, examine time delivered with the message and take appropriate action:

MyHandler ; FSR points to message ID field movlw VTMR_cMsgIDTimer1ms xorwf INDF, W ; if message.msg_id <> VTMR_cMsgIDTimer1ms skpz return ; return incf FSR, F ; make FSR pointing to LSB of message data movf INDF, W andlw 0F0h xorlw 007h ; on 7-th msec of every 16 msec skpnz return ; do something

Targeting Reenterability

To make a class reenterable, it should not be build-time-bound to any resource. This sample class achieves reenterability by using This as a pointer to EEPROM data with configuration (message ID, port mask) assigned to a particular class instance. In run-time PDO reads data from EEPROM on per need basis (e.g. does not cache in in registers). Since message ID is also stored in EEPROM, message handler first reads message ID from EEPROM and then message is processed:

TmrHandler movf This, W call EE_read ; W = EEPROM[This]; //(== msgid) xorwf INDF, W skpz return

With this design, class should be properly instantiated, e.g. object data should point to the configuration location in EEPROM. This can be achieved with use of a label, placed in EEPROM section:

DEEPROM code On1mSecData ; Configuration name de VTMR_cMsgIDTimer1ms, .1 ; Configuration data VOS_Objects ; Object registry begins On1mSec ; Object name (not necessary for this example) VOS_mPersistentObject MyTimer, On1mSecData ; Instance on MyTimer constructed with ;object data pointing to configuration

Building the project

All classes and objects for this example (except Timer) are declared, implemented and instantiated in one file: main.asm. Although this is not a recommended practice, this example, for simplicity, gives it this way. Moduling aspects will be discussed in a subsequent example.

A package with sources for this example can be downloaded on this link. It includes the following files:

`Example2.mcp`	MP LAB project file
`main.asm`	Example2 application sources
`pic.inc`	Processor-specific primitives, macros and includes
`pic16.inc`	PIC16/PIC12 specific primitives
`vos.asm`	VELOOS kernel
`vos.inc`	VELOOS public interface
`vos_cfg.inc`	VELOOS configuration file
`vtm2.inc`	Timer public interface
`vtm2_m.inc`	Timer auxiliary macros
`vtm2.asm`	Timer implementation
`16f690.lkr`	VELOOS specific linker script

Download sources

Running the application

This application was loaded to PIC16F690 on "Low Pin Count Demo Board" supplied with PICkit™ 2. Activity of 1s driven object can be visually monitored with a led. Activities of other objects (1ms and self-triggering) can be monitored aurally, for example by connecting a headset, or with a scope. Signals from RC2 and RC3 were captured with Simplescope and their traces are shown on Figure 1 and Figure 2. As results show, in the first run 1 ms period was actually shorter – 970 us instead of 1000. Therefore, for the next run internal oscillator has been tuned with -4 value. Traces indicate that 1 ms period varies 1000-1080 ms – this is an expected effect of message queuing.

Figure 1

Figure 2

Application Source

; License: Licensed to public under the Open Software License ; http://www.opensource.org/licenses/osl-3.0.php include "pic.inc" include "vos.inc" ;------------------------------------------------------------------------------ __CONFIG _WDT_ON & _INTRC_OSC_NOCLKOUT & _CP_OFF & _PWRTE_ON & _MCLRE_ON & _FCMEN_OFF & _BOR_OFF & _IESO_OFF ;------------------------------------------------------------------------------ constant mask = 02h ; mask to be used for driving port (RA1) constant msgid = 040h ; message ID constant mask1ms = 04h ; mask to be used for driving port on 1 msec event (RC2) constant mask1s = 08h ; mask to be used for driving led (RC3) VOS_Classes ; Class definitions begin MyClass VOS_mClass MyHandler, MyInit ; MyClass implementes MyHandler and MyInit methods MyTimer VOS_mClass TmrHandler, TmrInit ; MyTimer implementes TmrHandler, TmrInit ; Class definitions end with beginning of the next code section VOS_Objects ; Object registry begins MyObject VOS_mPersistentObject MyClass, mask ; Instance of MyClass constructed with object data == mask On1mSec VOS_mPersistentObject MyTimer,On1mSecData; Instance on MyTimer constructed with object data pointing ; to EERPOM location On1Sec VOS_mPersistentObject MyTimer,On1SecData ; Another instance on MyTimer ; Object registry ends with beginning of the code next section ;------------------------------------------------------------------------------ DEEPROM code On1mSecData de VTMR_cMsgIDTimer1ms, mask1ms On1SecData de VTMR_cMsgIDTimer1s, mask1s ;------------------------------------------------------------------------------ code MyInit ; This was loaded with object data comf This, W ; W := ~mask banksel TRISA movwf TRISA ; Prepare port for output VOS_mPostMessage MyObject, msgid ; post message to itself return ;------------------------------------------------------------------------------ MyHandler ; FSR points to message ID field, This is loaded with object data movlw msgid xorwf INDF, W ; if message.msg_id <> msgid skpz return ; return movf This, W banksel PORTA xorwf PORTA, F ; Toggle port VOS_mPostMessage MyObject, msgid ; post message to itself return ;------------------------------------------------------------------------------


EE_read

    banksel      EEADR

    movwf        EEADR                      ; EEADDR = This

    banksel      EECON1

    bsf          EECON1, RD                 ; EE Read

    banksel      EEDATA

    movfw        EEDATA 

    return

;------------------------------------------------------------------------------

 

TmrHandler

    movf         This, W

    call         EE_read                     ; W = EEPROM[This] == msgid

    xorwf        INDF, W

    skpz

    return

    incf         This, W

    call         EE_read                     ; W = EEPROM[This+1] == mask

    banksel      PORTC

    xorwf        PORTC, F                    ; Toggle   PORT

    return        

 

;------------------------------------------------------------------------------

TmrInit incf This, W call EE_read ; W = EEPROM[This+1] == mask xorlw 0FFh ; W = ~mask banksel TRISC andwf TRISC, F ; Prepare port for output according to mask return ;------------------------------------------------------------------------------ VOS_BootHandlers code ; starts a section for the application boot handler banksel ANSEL clrf ANSEL ; Turn all pints to digital clrf ANSELH banksel OSCCON ; Set Fosc = 8Mhz movlw (.7 << IRCF0) movwf OSCCON banksel OSCTUNE movlw -.4 movwf OSCTUNE ; !!! NO RETURN ALLOWED !!! ;------------------------------------------------------------------------------ end

VELOOS Example 1

Eugene — Fri, 10 Nov 2006 14:17:15 +0000

The previous post gave a brief introduction to VELOOS design idea. VELOOS assumes that an application is decomposed on PDOs (Process Data Objects). This post describes by example features provided by VELOOS for implementing PDO.

Self-triggering PDO

Design idea:	Implement a PDO sending a message to itself. On every message received toggle a pin.
Value:	Provides a simple example of PDO implementation. Implements a metric for measuring/estimating system throughput.

Implementing a PDO for VELOOS requires three steps:

Declaring a class
Implementing message handler and initializer
Instantiating an object

Declaring a class

Class declaration sections starts with VOS_Classes macro and ends with beginning of any other section. As with regular MP ASM sections, there is no explicit ’section end’ therefore it is important to properly delimit class declaration sections. A source file may have only one class declaration sections (MP ASM constraints).

Within class declaration section, a class is declared VOS_mClass macro. The macro should be preceded with a class name – a valid MP ASM label. This macro generates the class’s dispatch table. It accepts two labels as parameters: message handler and initialization handler. These labels should be known in this module (e.g. defined in the same module or imported with extern directive).

VOS_Classes ; Class definitions begin MyClass VOS_mClass MyHandler, MyInit ; MyClass implementes MyHandler and MyInit methods code MyInit ... return MyHandler ... return

Instantiating an object

Object instantiation section begins with VOS_Objects macro and ends with beginning of any other section. It accepts two parameters – class name and object data. Object data can be any 8-bit value. System does not make any assumption on it, it just loads this value to system variable This. Class name must be a label of a previously declared class. It should be known in this module.

VOS_Objects ; Object registry begins MyObject VOS_mPersistentObject MyClass, 0 ; Instance of MyClass constructed with object data == 0

Objects can be instantiated in the same unit where class implemented or in a different unit. In latter case, class name should be exported with globaldirective.

Note on Class Reenterability

A reenterable class allows instantiating several objects. From the system point of view all classes are reenterable. Whether a particular class is reenterable or no depends on its design and implementation and it is up to developer to make such decision. To make a class reenterable, all resources it uses must be allocated by means of object data. PDO implemented in this example is not
reenterable.

Implementing a message handler

Message handler is a subroutine, called by the OS when it finds a message addressed to this object or a broadcast message. On handler entrance This is loaded with object data and FSR is pointing to the message ID, so that the handler may compare INDF to a (set of) message ID(s) known to PDO. A PDO should process only know messages and ignore all others. Once the message is recognized, PDO may increment FSR and access message data (if necessary). In this example message has no custom data.

Implementing an initializer

Initializer is a subroutine, called by the OS on start-up (power up and reset events). On its entrance This is loaded with object data. Initializer is called for every instantiated object, therefore Initializer should prepare all registers or periphery used by this particular instance. If there is a need of some initialization code executed for all instances PDO should implement a boot handler.

Sending a message

VELOOS provides few macros for sending messages. Each of those macro “allocates” space for a new message, places acceptor handle, message ID, sender handle (in the last location). When it completes, FSR is pointing to custom data location,
so that PDO may put message data if necessary.

Macro	Parameters	Description
`VOS_mPostMessage`	`obj_to` - accepter handle `msg_id` - message ID	Posts a message to a statically defined object. Both message ID and acceptor are defined at build time
`VOS_mBroadcastMsg`	`msg_id` - message ID	Posts a broadcast message. Message ID defined at build time
`VOS_mPostMsgIndir`	`obj_ptr` file containing accepter handle `msg_id` message ID	Posts a message to an object using handle stored in a file, e.g. Acceptor is defined at run time while message ID at build time
`VOS_mPostMsgDyn`	`obj_ptr` file containing accepter handle `msg_file` file containing message ID	Posts a message to an object using handle stored in a file and message ID stored in another file. Both acceptor and message ID are defined at run time

In this example only one form is used:

VOS_mPostMessage MyObject, 2 ; post message to MyObject

Implementing a boot handler

Boot handler is a fragment of code executed by the system on start-up. It is not related with any class or object. A boot handler is implemented by placing code to VOS_BootHandlers section. Since an asm file may have only one occurrence of a section name there could be only one boot handler in a source asm file. However, application that consists of many files may have many boot handlers. Order of execution is not known and not fixed, therefore the code should not relay on any particular order. When boot handler is executed objects are not initialized

VOS_BootHandlers code ; starts a section for the application boot handler banksel ANSEL clrf ANSEL ; Turn all pints to digital clrf ANSELH banksel OSCCON ; Set Fosc = 8Mhz movlw (.7 << IRCF0) movwf OSCCON ; !!! NO RETURN ALLOWED !!!

Building the project

A VELOOS project, to be properly built, should include VELOOS kernel (vos.asm) and VELOOS specific instructions in the linker script for the target device. Unfortunately, MP LAB does not support multiple lkr files (it just takes the first one) therefore changes have to be made in a copy of a standard .lkr file distributed with MP LAB.

VELOOS can be configured (fine tuned) at build time. All configurable parameters are given in a separate inc file.

A package with sources for this example can be downloaded on this link. It includes the following files:

`Example1.mcp`	MP LAP project file
`main.asm`	Example1 application sources
`pic.inc`	Processor-specific primitives, macros and includes
`pic16.inc`	PIC16/PIC12 specific primitives
`vos.asm`	VELOOS kernel
`vos.inc`	VELOOS public interface
`vos_cfg.inc`	VELOOS configuration file
`16f690.lkr`	VELOOS specific linker script

Download Example1 Sources

Simulation results

Figure 1 shows Logic Analyzer trace (20000 IC = 10 ms). As it can be easily counted, this example processes 13 messages per millisecond with turnaround in about 150 IC. Any load on CPU will decrease this number (which will be illustrated in the next example). 150 IC per message can be considered as messaging overhead and should be accounted when designing time-critical applications.

Figure 1

Application Source

; License: Licensed to public under the Open Software License ; http://www.opensource.org/licenses/osl-3.0.php include "pic.inc" include "vos.inc" ;------------------------------------------------------------------------------ __CONFIG _WDT_ON & _INTRC_OSC_NOCLKOUT & _CP_OFF & _PWRTE_ON & _MCLRE_ON & _FCMEN_OFF & _BOR_OFF & _IESO_OFF ;------------------------------------------------------------------------------ constant mask = .2 ; mask to be used for driving port (RA1) constant msgid = 040h ; message ID VOS_Classes ; Class definitions begin MyClass VOS_mClass MyHandler, MyInit ; MyClass implementes MyHandler and MyInit methods ; Class definitions end with beginning of the next code section VOS_Objects ; Object registry begins MyObject VOS_mPersistentObject MyClass, mask ; Instance of MyClass constructed with object data == mask ; Object registry ends with beginning of the code next section ;------------------------------------------------------------------------------ code MyInit ; This was loaded with object data comf This, W ; W := ~mask banksel TRISA movwf TRISA ; Prepare port for output VOS_mPostMessage MyObject, msgid ; post message to itself return ;------------------------------------------------------------------------------ MyHandler ; FSR points to message ID field, This is loaded with object data movlw msgid xorwf INDF, W ; if message.msg_id <> msgid skpz return ; return movf This, W banksel PORTA xorwf PORTA, F ; Toggle port VOS_mPostMessageMyObject, msgid ; post message to itself return ;------------------------------------------------------------------------------ VOS_BootHandlers code ; starts a section for the application boot handler banksel ANSEL clrf ANSEL ; Turn all pints to digital clrf ANSELH banksel OSCCON ; Set Fosc = 8Mhz movlw (.7 << IRCF0) movwf OSCCON ; !!! NO RETURN ALLOWED !!! ;------------------------------------------------------------------------------ end

Very Low Overhead Operating System

Eugene — Mon, 30 Oct 2006 00:47:14 +0000

VELOOS - Very Low Overhead Operating System

VELOOS is a message-triggered cooperative operating system designed to run in places were a large vehicles can not run. Its implementation for PIC12F takes less than 200 instructions and 20 data registers¹. With addition of a timer driver, it becomes a time-triggered RTOS.

Preface

What is a real-time operating system in context of an MCU? First, it is an abstraction intended to share MCU resources among application components. Whatever abstraction is used in RTOS, it drives the application design – e.g. if a RTOS operates in terms of tasks, an application developer is obeyed to program application as a set of tasks.
Secondly – it is a set of services which an application developer may/should use to make application operable and achieve the application goals. Most common abstraction for RTOS is a multitasking. Multitasking has several advantages, which make it very appealing, however it also has disadvantages which are even more noticeable in context of an MCU applications.

Disadvantages of multitasking

1. It is costly (high resource consuming)

Task switching requires saving and restoring task context, which includes stack, some system registers and some hardware SFR’s (such as status).

2. Inter-task communications even more costly

Tasks abstractions were designed for executing rather isolated and limited in time routines. Task communication and synchronization requires use of other abstractions, such as semaphores, pipes, etc. These
communications/synchronizations features are usually accessible as functions and they are not trivial in implementation and use.

3. It is not well suitable for event driven applications

Many of MCU applications are event-driven – a particular application routine is executed on e response of an external event. When implementing such application with a multitasking, developer should map application requirements to available abstractions – e.g. decompose the application onto tasks. For an event-driven application this mapping is not trivial and creates unnecessary complications.

4. It is redundant

Multitasking assumes decomposing application on isolated or loosely coupled set of tasks which, due to nature of MCU applications, are implemented as infinite loops – every task implements an infinite loop. Memory allocated to a task usually is not used in other tasks, even if the task is in idle mode.

Alternate RTOS abstraction

Messaging is an alternate abstraction, which fits better for event-driven applications. With this abstraction an application is decomposed to set of process data objects (PDO) which receive and send messages in a response to other messages or external events, such as port change, periphery interrupts or timer.

Messaging provides a simple mechanism for both sharing CPU time and communicating among PDO’s. Despite messaging is also not a perfect abstraction, it requires fewer resources and needs implementation of very few and very simple abstractions – message, message queue, send message, and message handlers. All other abstractions and mechanism can be built with (on top of) these four and this is how VELOOS is designed and implemented.

VELOOS description

VELOOS design is based on few rather simple design decisions for establishing message processing.

Terminology

(It also reflects major design decisions)

Message	A fixed-size set of sequential general-purpose registers. Message embeds accepter address, message ID and applications data. By default, message is 4 bytes long with 2 bytes available for custom data.
Message Queue	A circular buffer of fixed configurable size.
Send Message, Post Message	A routine that accepts object handle and message ID, places them into the message area and returns indirect access register pointing to custom data locations. Messages are sent in asynchronous mode – sender does not wait until accepter processes the message.
Message Handler	A routine provided by application developer for processing messages. This routine is invoked by the system when it encounters a message addressed to the object.

Addressing Modes	Messages can be addressed to a specific object (direct addressing) or to all registered objects (broadcast addressing). The latter one is indicated by use of a reserved object address – FF
Broadcast Message	Message sent to all instantiated objects
Object Address, Handle	An 8-bit value uniquely identifying an object. In VELOOS, handle is a synonym of Object Address. VELOOS makes up handle values from lower octet of object entry address.
Object Entry	Pair {class pointer, object data} placed in the object registration section.
Object Instantiation	Predefined and required way of registering objects in the OS. It creates registration entry in the system and provides value for the object handle. Currently VELOOS implements only build-time object instantiation.
Object Initializer	An application routine provided by the application developer for initialization of registers and periphery used by a particular PDO instance. It is called on system startup.
Object Data	Any 8-bit value provided by the application developer and suitable for distinguishing among object instances. The system makes no assumption on object data value, it just loads it to system variable This.
Class	Set of entries/routines required for instantiating and operating an object – e.g. handler and initializer.
Class Entry	Pair of jumpers {goto handler, goto initializer} used for dispatching the system calls to an object
Class Pointer	Lower octet of class entry address
Class Definition	Predefined and required way of registering classes in the OS. It creates class entry in the system and provides value for the class pointer
VELOOS driver	Software that provides access to a shared resource and/or handles interrupts. A driver may consist of an object and an interrupt handler (IH)- a fragment of interrupt service routine.
Boot Handler	Fragment of application startup routine, provided by a PDO or driver for initializing of resources not associated with a particular PDO.
Interrupt Handler	Fragment of ISR provided by the application or a driver for handling concrete interrupt. Custom ISR are ordered and linked accordingly to (logical) priority assigned to it. VELOOS provides the prolog and epilog handlers, which provide context saving and restoring.

Principle of Operations

System Startup	On reset, system executes internal startup routines, and application boot handler. Then system enumerates trough object registry and for each entry calls object initializer.
Interrupt Handling	On an interrupt, the prolog handler saves all critical SFRs in temporary registers. Then control is transferred to a next interrupt handler. IH check the interrupt source and if the source is proper, handles the interrupt. As a result of handling an interrupt, IH may post a message. If the source improper, IH skips its body. After all IH were executed, control is transferred to the epilog handler, which restores the context and exits the interrupt.

Operating Mode	VELOOS points to the next message in the queue, retrieves accepter address from the message. If it is a broadcast message, system enters broadcast state. Otherwise, it enters Call Handler State.
Call Handler State	System loads the accepter’s class pointer to system variable This_class and object data to system variable This and calls the message handler. The message handler is expected to complete execution in a predefined timeframe. If it does not, system enters into timeout state. During processing a message, PDO may post message(s) to other objects, including message(s) to itself and broadcast messages. When the message queue is empty, system enters Idle state.
Broadcast State	VELOOS enumerates trough object registry and for each entry it calls corresponding handler.
Idle State (optional)	VELOOS maintains posts Idle message and calls handler for the next object. If the message queue is not empty after this call, system leaves idle state. VELOOS maintains a dedicated ‘next idle object’ pointer, which is incremented after each handler is call for the idle message. This ensures that every PDO gets idle message.
Timeout State	If a PDO fails to handle message in the given timeframe, VELOOS will abort handler routine and proceed with the next message in the queue. VELOOS provides two optional mechanisms for controlling execution time – the hardware watchdog timer (WDT) and software WDT based on a timer driver. Both mechanisms may work simultaneously.
Message Queue Overflow	When the message queue is overflowed, system sets Queue Overflow flag and overwrites an existing message – the first in the queue.

Time Triggering	Time triggering is implemented with a heartbeat broadcast message sent by a timer driver with fixed periodicity (1 ms by default). VELOOS timer drivers also have option for additional 1 sec heartbeat.
Time Intervals	VELOOS does not provide an explicit mechanism for controlling time intervals between object activations. PDOs are expected to watch for proper time interval via heartbeat, using either time value provided with the heartbeat message or using countdown approach.

VELOOS drivers	Currently VELOOS provides two drivers: TMR0 based timer driver and TMR2/CCP based timer driver.
Persistent Storage	VELOOS provides two options for storing object registry – ROM and EEPROM. Class registry is stored in ROM.
Call Back	Callback is a message sent back from the accepter to the sender. System places sender’s handle as the last byte in the message and if the PDO does not override it, the accepter may use this handle to send a message back.

VELOOS implementation

VELOOS is designed and implemented in MP ASM language. Its primitives are implemented as ASM routines or macro.

VELOOS requirements

PIC family Feature	PIC12F675 program/data	PIC16F690 program/data	PIC18F program/data
Bare operating system	195/20	220/20	210/20
Heartbeat Timer (1ms, 1s)	75/7	85/7	70/7
A definition of class (per class)	2/0	2/0	2/0
An object instance (per object)	2/0	2/0	2/0

Possible extensions

Simple Networking with VELOOS

Messaging approach used by VELOOS allows implementing simple distributed computing in a simple and transparent way. First of all networking would need a network driver (a VELOOS class) that implements physical communication between MCU’s. This driver should be able to (1) filer incoming messages, (2) pack and send filtered messages via communication channel, (3) unpack messages coming from the communication channel and (4) post them to local message queue. Then, for every remote object application should instantiate a local proxy object (as an instance of network driver class). With this approach, an application can be easily distributed among several execution nodes (MCUs).

Various object lifetime

Currently the system implements only one lifetime scope for PDO. It is possible to extend this implementation for static objects (stored in ROM), persistent objects (stored in EEPROM), and dynamic objects (created in run-time and stored in RAM).

Exception handling

Currently the system has two exceptional situations (Handler Timed Out and Message Queue Overflowed) and provides no ability for changing behavior on these exceptions. VELOOS can be extended with exception handler support, by, for example, providing third jumper to the class entries, which would be called by the system when an exception occurs.

Class and Object Directory

Currently the system does not provide a mechanism for retrieving a list of classes and objects registered in the system. This feature can be implemented by class entry with additional jumper, which would return
class/object identification data in for, for example, human-readable class/object names.

VELOOS Example1 – Self-triggering PDO

VELOOS Example2 – Heartbeat Driven PDO

VELOOS Example3 – USART Controlled actuators and Generators

MIHA675 – a sample VELOOS application

All VELOOS related

Download VELOOS v.1.0

Future Posts

VELOOS sample application (planned)

VELOOS reference (planned)

^[1] Minimal configuration with broadcasting and message queue for 2 messages

Eugene Hutorny » VELOOS

MIHA675 – Multi Input Hall Automaton

Example3 – Designing MIHA – Multi Input Hall Automaton

Introduction

Requirements (user’s needs)

MIHA Design Description

Moduling

Sharing RAM among objects

Using Timer for Resource Access Arbitration

Multi-input Debouncer

Hardware Schematic

Package Content

VELOOS Example 3

VELOOS 1.0 released

Supporting other 14-bit core and 16-bit core devices

VELOOS Example 2

Example2 – Heartbeat Driven PDO

Design Description

Deploying VELOOS Timer Driver

Handling Timer Messages

Targeting Reenterability

Building the project

Running the application

Application Source

VELOOS Example 1

Self-triggering PDO

Declaring a class

Instantiating an object

Note on Class Reenterability

Implementing a message handler

Implementing an initializer

Sending a message

Implementing a boot handler

Building the project

Simulation results

Application Source

Very Low Overhead Operating System

Preface

Disadvantages of multitasking

Alternate RTOS abstraction

VELOOS description

Terminology

Principle of Operations

VELOOS implementation

VELOOS requirements

Possible extensions

Simple Networking with VELOOS

Various object lifetime

Exception handling

Class and Object Directory

Related Posts

Future Posts