Read more about SISAM – SImple SAMpler and SISAN – SImlpe Signal Analyse

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):

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.

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

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.

Example2 – Heartbeat Driven PDO

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):

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:

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
;------------------------------------------------------------------------------

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


Self-triggering PDO

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.

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:

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


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)

Principle of Operations

VELOOS implementation

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

VELOOS requirements

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.

Related Posts

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)

MCU Models

Despite it is not explicitly spelled out, assemblers and C-compilers do use one or the other kind of MCU model, defined in terms of the programming language (assembly, C or preprocessor). These models are ‘flat’ (set of constants or static variables). These models are often incomplete and can be easily misused without any compilation error.
Linkers and simulators use another way of defining the same model and doing it in other, different languages with no or very little documentation support.
e# will give ability to define a formal, self-descriptive MCU model once and open it for use everywhere ??“ in compiler, application, and simulator. This indeed does not negate the need to learn the hardware. Instead e# will provide a formalized addendum to the device datasheet.
Defining MCU model in the same language as the program is written will open up possibilities hardly achievable in the current tools.

Cost of abstractions

All proposed abstractions are abstractions of the tool language. They will be constructed and executed on the host computer. There will be no abstraction one would have to use on the device. One still will be able to program in terms of instructions, and on top of that, may define abstractions for the device in extents of available device resources. For example, one would be able to define (and implement) an interface method call using whatever calling convention is appropriate and use it as if it were a HLL language.

Generic MCU

Many parts in an embedded application (such as state machine, math, conversion, etc.) can be written for a ‘more generic MCU’ and these parts can be transferred to other MCU that fit under the same ‘generality umbrella’. This will give developers freedom to make such choice – either writing with very limited very generic MCU and have highly portable code or writing for a given MCU and have more efficient and, of course, less portable code.

I hope this way of expressing will help the reader to understand my idea and an approach on its implementation.

1. It will allow writing better quality code in shorter time
2. It will reduce maintenance cost by providing abilities for regression testing (on a simulator or in-circuit debugger)
3. It will reduce impact of migrating to another device/platform

e# will be more restrictive to human errors and misusages. It will generate errors at places where a regular assembler gives no warning, such as use of literal instead of address (movf myconst,F) use of improper address (goto myvar), using a flag on a wrong register (bsf OPTION,GIE) and so on.

e# will provide facilities for ‘in-place’ validation which can be performed in scope of a simulator run or under an in-circuit debugger. For example, each call to a square root routine can be validated against square root calculated by the e# builder upon actual parameters passed to the routine. Developer will be able to program such validations in e# and apply appropriate action if an invalid condition is detected (log a message, raise an exception, etc.). Another example ??“ a delay routine can be validated against expected delay.

e# will provide facilities for automated testing (unit, integration, etc). Once established, these tests can be used for regression testing, allowing early problem detection when a new firmware version is in work (application maintenance) or when application is being moved to another target device (migration). These facilities will provide great help for debugging code, although they will not replace a visualized interactive debugger.

e# will give ability to use essential level of abstractions when designing and implementing applications and still giving developers full control on costs and penalties contributed by those abstractions. For example, developer will be able to define a ‘function call abstraction’ and implement proper mechanism for passing parameters and returning the result. Once it is done, the function call can be used in a similar way it is used on HLL and compiler will control if it is used as designed at syntax level, while developer may program code to verify it at semantic level.

e# will provide ability to program for an ‘abstract MCU’. Yes, I know, MCUs are different, but nevertheless, I believe, it is possible to define a generic MCU model with a most common set of registers and instructions, such as load a literal, move, add, subtract, branch etc. This generic MCU model will not be generating any machine instructions leaving this responsibility to a model of a real-world MCU used in the application. A library routine (such as 16-bit wide addition), written for an abstract 8-bit MCU it terms of abstract MCU instructions, will be instantiated in the application with instructions, provided by the model of actually used MCU.

e# will provide another way of delivering device notices, cautions, silicon errata to the developer. Until explicitly suppressed each notice associated with the device will be printed to the compiler output. These notices may have complex logic for determining if the underlying issue affects the application. This will help identifying problems before they happen and will simplify the migration path.

e# MCU model will be yet another source to learn the target device either by inspecting the model source or by exploring the device in IDE. Since the model will be defined in a programming language and accessible to IDE as a set of objects, exposing the model to IDE will be a rather routine task.

e# will provide facilities to control object vs resource allocation, eliminating need of separate linkers with their own ‘kind-of-a-language’.

e# will be better suitable for modular and/or OO design providing essential facilities for modularity, encapsulation, and objectivity.

e# will provide ability to debug process of code generation

Besides features not yet available in other languages, e# will address several shortcomings of assembly and C languages.

Table 1.e# vs ASM and C

¹ e# will not solve efficiency vs. portability dilemma, however, it will shift this solution from the tool selection stage to the design and implementation stage.