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)

Capabilities

SISAM 88 – provides the same set of capabilities as SISAM 690 (differences are underlined/strikethrough):

• S – Sampling single logical channel – RB2 RB5 up to 500 ksps (kilo sample per sec)
• X – Sampling dual logical channels RB2, RB1 RB5, RB4 up to 200 ksps per each channel
• J – Limited buffered sampling sole channel @ 5 Msps (2560 1920 samples via internal buffer)
• M – Measuring pulse timing on RB3 RC5 up to 12 kHz average,
• o – drive (trigger) four five output pins right before (0.8us) sampling starts
• O – drive (trigger) four five output pins immediately and/or in a sequence (20 us per data byte)

In addition to mentioned above, SISAM can be used as a variable frequency generator (VFG). With the current firmware – as a side effect of S command (a separate command is planned for upcoming firmware updates)

System requirements

• High-speed serial port (such as SerialXP)
• Triple power supply (+5VDC, +12VDC, -12VDC)

Schematics

SISAM88 hardware schematic is given on Figure 1. It includes

• MCU PIC16F88 (U1)
• 20MHz crystal (X1)
• RS232 level converter, build up on SN75150 line driver (U2), current-limiting resistors R1-R3, R6, a Zener diode D1 that prevents RA5/VPP from being pulled up to +12V.
• Current-limiting resistors R4, R5 on input
• Four connectors J1-J4.

J2 is an angled 10 pin male IDC header identical to a COM2 connector on the motherboard. J1 is an angled female IDC header mating with the COM2 connector. J3 is an angled 4 pins header mating with Mini-Molex power connector (FDD power). J4 is a 6 pins header compatible with your ICSP programmer (for example PICkit2).

Actuator outputs are connected to RA0-RA3.
Wire RB4-RB5 delivers clock from EUSART to SSP. RB4 also serves as VFG output.

External connectors

Power – it is an altered FDD power connector. 12V ground header is pulled out of it and another header inserted instead. This header is wired to -12VDC.

Bracket DB9 – it is a standard COM2 bracket cable. In this design it is used as an input/output connector for connecting probes. Pin 5 on this connector is still used for ground to make it compatible with RS232 cables that may have it connected to the chassis. It make safe connecting a regular RS232 cable.

Firmware

SISAM v1.1/88 Firmware is available for download.

Revision 1.1 includes the following changes
1. Fixed defect with improper speed estimation for command r02;X0;

Board

Figure 2 shows the board layout (Scale 1:2). Discrete parts, which are not shown on this layout, are surface mount on the soldering side. PCB layout is not yet ready.

The board has some space reserved for the future upgrades.

ICSP

PIC can be programmed in circuit; however, the device should be disconnected from power supply.

Pictures

DB9 bracket	SISAM 88 board	Cables connected	SISAM in place
		Notice altered FDD power connector

See also: More about SISAM; Simplescope; Overclocking COM port; Downloads

Overview

Experiments were made with four RS232 Level Converter designs:

1. PNP Transistor, parasitic -12V
2. PNP Transistor + JFET current source, parasitic -12V
3. PNP Transistor, external -5V supply
4. SN75150 – Dual RS232 Line Driver

Test environment:

• TTL output generated by SISAM in diagnostic mode
• Converter loaded with 1.5m shielded cable (C?‰?100-300pF) + PC USART (Winbond)

Data verification methods:

• watching and reporting framing error condition and
• comparing received data to expected

Test tools:

• SITEST ??“ sends commands to SISAM and forwards data to stdout
• LOOFI ??“ reads data from stdin and verifies the stream against the master pattern, made of the first count characters.

Command lines for tests are the following

SITEST /port=COM1 /count=640000 U03; > c:\temp\U03.txt
LOOFI /count=224 /file=c:\temp\U03.txt

SITEST sends U03 command to SISAM. This command turns SISAM in diagnostic mode and SISAM sends sequences of characters 0×20 to 0xFF using baudrate, specified in the command (U00 ??“ 115.2K, U03 ??“ 921.6K). SITEST saves data to file and aborts execution if a framing error is detected. Then LOOFI is used to verify data.

1. Hardware loop test In this test RX and TX wires were connected on the free cable end and test data were send with a terminal application. Test has passed 460.8K and has failed on 921.6K ??“ wrong data received.
2. PNP parasitic -12V Test has passed 230.4K and has failed on 460.8K with farming error. Oscilloscope has shown that falling edge is too sloping. I have tried to lower R1 and R2 and test has failed. I also tried to shorten the cable from 1.5 m to 0.3m and it did not make results any better.
3. PNP+JFET parasitic -12V As a variation of previous design, I have replaced R2 with a 10mA current source made on BF245A. This did not make results any better. My explanation to this ??“ parasitic power is not a good power supply to drive even small capacitive load at that high speed.
4. PNP external -5V In this test the circuit was powered with??“5V external power supply. R1 and R2 were varied from 1K to 100 Ohm. The best results were achieved with speed R2=360 and R1=10K – Test has passed 460.8K and has failed on 921.6K with framing error. These resistor values cannot be used with parasitic power, because transistor’s collector current (Ic?‰?30 mA) is higher than can be derived from a single COM port line.
5. PNP+JFET external -5V This design I did not try because it needs another type of JFET with IDSS current 30mA and I did not have it handy.
6. SN75150 SN75150 is a dual supply dual RS232 line driver. Despite SN75150 datasheet states maximal baud rate 120K, it works on 921.6K and the test has passed 921.6K. I tried to power it with +5V and -12V parasitic power and it did not work at all.

7. Summary on tests

Table 1

N/T – Not tested

6. Notes on driver selection

In this chapter I provide my motivation for driver selection.

I have looked for drivers in TI Interface Selection Guide. None of 1000 kbps drivers were available from local dealers (besides those drivers are not cheap). Therefore I decided to take a 120K driver and ‘overclock’ it. Considering that the current level is important for driving capacitive load, I limited my selection to dual supply chips. With these constraints I picked the smallest PDIP chip available locally and it happens to be SN75150. Its advantages: small footprint, very little overhead, level compatibility with PNP-based design, low price. Disadvantages ??“ necessity of dual power supply.

If dual power supply is not acceptable, you may try other drivers (such as SN75C3232, MAX3232, MAX232). I would appreciate if you share your results with me.

Overview

For developing applications with a long life cycle it is very important to ensure that a new release contributes no regression comparing to the previous release. This may become a challenge when an application provides number of capabilities, operates in number of modes or implements number of states. A common approach for addressing this challenge is to establish an automated test environment.

Figure 1 shows a typical automated test environment. It consists of

Batch Controller – a (software) component for running tests in a batch and aggregating overall batch result Test Tool – a component that executes single tests and produce test outputs Comparator – a component that compares test outputs against masters and reports discrepancies Test Cases Repository – a storage of test batches, test cases, test input data and masters Test Log Repository – a storage of test output data and test discrepancies

Figure 1

Typical sequence of events for automated testing:

• Actor uses Batch Controller to start a specific test batch
• Batch Controller reads test cases that constitutes the batch
• Batch Controller calls Test Tool for executing a test case from the batch
• Test Tool reads input test data for the specified test case, applies stimuli to the Testable Application, captures, preprocesses and records application responses
• Batch Controller, upon completion of a test case (all test cases), calls Comparator to compare a test output to a corresponding test master.
• Comparator compares test output and master, writes discrepancies (if any) and signals success/failure
• Batch Controller, upon completion of all test cases, aggregates test results and signals a batch result (success/failure) to the Actor.

A simple test environment

A simple environment for automated testing can be implemented as the following

Test Tool

To use this simplest automated test environment for testing embedded applications, the Test Tool should be a command-line utility, capable to apply stimuli to the testable application and capture the application response to a file.

SISAM & SITEST

SISAM is PIC-based application capable to accept commands via RS232, actuate pins according to the command, acquire data from one or two channels and send acquired data via RS232. SITEST is a command line interface to SISAM. It accepts a sequence of characters from the command line, sends these commands to SISAM and writes data to standard output. These features make SISAM a good candidate for simple testing environment. Figure 2 shows architecture diagram for a test tool build on SISAM and SITEST.

Figure 2

Filters

Due to nature of embedded applications acquired data may vary from run to run even for valid runs. This variability is very application specific; it may make impossible output-to-master comparison, and thus may easily bury the idea of automated testing. To address this issue, acquired data should be filtered and coarsened to the level at which all valid runs would produce identical outputs while invalid runs would still have some difference in the output data. Such a filter should be a command line utility that reads from standard input and writes to standard output. Of course, writing a filter requires additional efforts, however, from authors’ experience, implementing a simple filter does not require any significant efforts.

Function Generators

SISAM is only capable to provide static stimuli for a period of data acquisition. Therefore, if the test conditions require some alternating stimuli applied in parallel with data acquisition, a "function generator" can be used in conjunction with SISAM. A "function generator" is an embedded application that accepts a static input (function ID) and generates a variable function on output.

SISAM uses RTS/CTS flow control for reading command and DTR flow control for sending acquired data. This means that PC should set RTS before sending commands and watch for CTS (e.g. use CTS sensitivity option). When PIC goes into data acquisition mode, it sends an ASCII string starting with Y4-MODE: followed with new mode description. This description can be directly used with mode command or with BuildCommDCB function.

PC should change the COM port mode as directed. Since the mode description contains rts=off dtr=on, DTR will be set SPACE signaling that PC is ready to receive acquired data.

PC stops Data acquisition by setting DTR to MARK and restoring 115200 baud rate.

If during data acquisition PIC encounters an error, it signals a BREAK, e.g. holds RX in SPACE until PC sets DTR to MARK. PIC does not leave error state until PC holds RTS MARK, therefore, to recover from error state, PC should restore baud rate 115200, set RTS to SPACE and read error message.

When data acquisition is performed with sync flag and PC needs to break waiting, it should alter TX line. If CTS sensitivity option is applied to COM port, WriteFile to the port will not succeed, SetCommBreak should be used instead. After this PIC will enter a error sate which should be cleared as stated above.

Initial state

PC opens port for normal operation: baud=115200 parity=N data=8 stop=1 octs=on dtr=off rts=of

Sending a command to SISAM

PIC is in IDLE state 1. PC sets RTS=SPACE 2. PIC confirms by setting CTS=SPACE 3. PC sends commnd(s) 4. PIC sets CTS=MARK 5. PC continues transmission 6. PC completes transmission 7. PC sets RTS=MARK 8. 2 ms timeout 9. On either of (7) or (8) PIC accepts command 10. PIC sends new COM port mode 11. PC changes COM port mode 12. PC signals START by setting DTR=SPACE PIC is in WAIT state 13. PIC sends data PIC is in ACQUIRE state 14. PC signals STOP by setting DTR=MARK 15. PIC stops transmission 16. PC restores COM port mode PIC is in IDLE state

Output stream format

PIC sends acquired data as described below