Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Embedded Systems

Protocols for Niche Area Networks


Jul99: Protocols for Niche Area Networks

Jaromir is a senior staff engineer in Motorola's Roznov (Czech Republic) Systems Application Laboratory. He can be contacted at [email protected].


The electrical appliance industry is rapidly moving into the world of electronic controls that have enough intelligence to monitor and modify system behavior. But while the technology is readily available, the barrier to wide-spread implementation of intelligent controls is cost effectiveness, which adds to the price of household and other electrical appliances and devices.

One way of reducing costs is to combine electromechanical and software control. Once software and electronics are implemented in an appliance, you then need communication systems so that sensors can talk to controllers. Niche Area Networks (NAN), based on serial communication with embedded protocols, are starting to fill this need. In this article, I'll introduce "SimpleChat," one such NAN communication protocol that's designed for applications where cost efficiency is more important than very high data rates. The SimpleChat protocol can be supported by all types of low-end microcontrollers (with built-in UART) that support 9-bit transmission, such as Motorola's 68HC05/HC08 family. SimpleChat reference designs, for instance, have been created for AC inductance motor drives (using the MC68HC08MP16 or MR24), temperature sensors (using the MC68HC05JJ7), air conditioners, and the like.

SimpleChat Overview

As Figure 1 illustrates, SimpleChat systems consist of Master, Slave, and Peer nodes. Peer nodes can run in Master or Slave mode (the default for Peer node). Master and Peer nodes can access the network at any time to perform communication. Slave nodes do not own the right to initiate communication. Master nodes can request Slave nodes to send information back to the Master. Because of the software SCI implementation specification, Slaves can be implemented on microcontrollers without UART.

Communication between nodes is via Push/Pull -- the Master sends the Push field of the message and the addressed Slave responds with the Pull field. A half-duplex transmission performs this communication. The SimpleChat system allows Single Master or Multiple Master network configurations. Any node in a network can broadcast an emergency notification and any Master can simultaneously control a group of Slaves.

The SimpleChat protocol is based on the Open Systems Interconnect (OSI) seven-layer model; see Figure 2. SimpleChat addresses layers 1 (Physical) and 2 (Data Link). The Data Link layer is divided into three sublayers -- the Logical Link Control (LLC), Upper Media Access Control (UMAC), and Lower Media Access Control (LMAC). LLC and UMAC are typically implemented in software. The LMAC is usually based on an SCI (UART) and simple timer.

Devices connected to the SimpleChat bus use a single message format. Figure 3 illustrates the general composition of SimpleChat messages (as they appear on the bus). An IDLE symbol separates any message on the bus from other messages. Each message consists of two major fields -- Push and Pull. The Push field contains information sent from the Master to the Slave. The Pull field contains information sent from the Slave to the Master. A passive bus period that is shorter than an IDLE symbol is known as an Inter-Frame Separator (IFS) and separates Push/Pull fields.

The first frame of a Push/Pull field is always an Address frame. Following Address frame 0, one or more Data frames are present. The last frame of a Push/Pull field is always a Data frame containing a checksum of all of the previous frames in the field. The protocol uses a simple 8-bit arithmetic checksum. An IFS also separates frames within a Push/Pull field. The SimpleChat protocol supports different types of messages.

Application Messages

Application messages (Figure 4) are those in which Masters or Peers convey application information to Slaves (and vice versa). Since application information is being exchanged, and since the SimpleChat protocol does not define any of the application layer, the content and meaning of application messages are completely application dependent. The SimpleChat protocol merely provides a data link for connecting the applications.

Using Application messages, the Master controls the timing of all frames within the Push field and the Slave controls the timing of all frames within the Pull field. Another message may not be sent until an IDLE symbol appears on the bus.

Network Messages

Network messages (Figure 5) are one-way broadcasts in which Masters or Peers convey network information to all Slaves in the network. The SimpleChat Data Link generates all network messages. The application should never attempt to generate them because of unpredictable consequences.

With network messages, Masters control the timing of all frames within the Push field. Another message may not be sent until an IDLE symbol appears on the bus.

Addresses 254 (%11111110) and 253 (%11111101) are reserved for network messages and must never be used for Slave devices. In addition, the protocol specifies addresses 0 (%00000000) and 255 (%11111111) as illegal. These addresses have higher probability of appearing accidentally under faulty conditions, so these addresses must never be used for Slave devices either. This still leaves enough combinations for uniquely addressing Slaves. Reserved network messages (Table 1) include:

ILLEGAL0 (ILLEGAL0 - %00000000). An illegal 0 (ILLEGAL0) network message is any message that has all logic 0s within the Push/Pull Header frame.

ILLEGAL1 (ILLEGAL1 - %11111111). An illegal 1 (ILLEGAL1) network message is any message that has all logic 1s within the Push/Pull Header frame. This is illegal because many SCIs and UARTs can mistake a Header frame like this for an IDLE symbol. It also prevents a single noise pulse (1-bit time during an idle bus condition) from being mistaken as a single header frame of value %11111111.

BROADCAST (BROAD - %11111110). Broadcast messages are those simultaneously sent to all Slaves in the network. The Master sends a common Push field to all Slaves. Depending on the broadcast message type, zero or one Slaves (but never more than one) may reply with a Pull field.

  • Sleep (SLEEP), used for the network to enter into SLEEP mode.
  • Wake (WAKE), used for the network to wake-up from SLEEP mode.

  • Synchronization (SYNC), used for many purposes. SimpleChat networks that contain devices with timebases of wide tolerance require periodic resynchronization. This is achieved by ensuring that the Master periodically sends a special message that performs no data transfer and is only used by the Slaves for deriving timing information. This is the primary purpose of the SYNC message. The periodic action occurs totally within the SimpleChat Data Link, and no application intervention is required.

MULTICAST MESSAGES (MULTI - %11111101). Multicast messages (Figure 6) are those in which the SimpleChat Master conveys network information to all Slaves within the specified group and is a one-way broadcast communication. All Slave nodes must specify which group they belong to. With multicast messages, Masters control the timing of all frames within the Push field. Another message may not be sent until an IDLE symbol appears on the bus.

Network Access Control

Since the network is a shared communication channel, the network protocol must define how the channel is shared. Recall that the same SimpleChat node can serve as a Master, Slave, or Peer. Most networks are comprised of one Master and several Slaves. In such a configuration, the Master polls each Slave periodically. When polled, a Slave can transmit a message. No potential conflict can occur on the bus because of the communication timing by the Master. However, also recall that the SimpleChat protocol allows for multiple Masters.

When the bus is free, any Master or Peer node can start to transmit a message. A node that is ready to transmit a message must first sense if another node is currently transmitting. If not, the first node can begin transmitting immediately. Prioritized messages are transmitted. If two or more nodes start transmitting messages at the same time with the same priority, the bus access conflict is resolved by byte-wise arbitration. The Master or Peer node with the message of highest priority to be transmitted gains bus access. SimpleChat network access control is based on the method used by SAE J1708, "Serial Data Communications Between Microcomputer Systems in Heavy Duty Vehicle Applications" (1990).

Collision Avoidance

Masters can begin transmitting messages only after an IDLE state on the bus, and if the bus is still free in the specific time window after that. The specific time window for the collision avoidance (TCA) is defined as a time window of a time duration equal to the following equation:

TCA=Tb·MP

where Tb is the bit time and MP is the message priority (0 to 7). The bus activity detection is performed inside this TCA window at a bit-wise level, using start-bit detection, looking for the falling edge of a start bit. This start-bit detection is serviced by the IRQ interrupt service routine. If a Master node detects bus activity within the TCA window, arbitration is lost.

Arbitration Algorithm

The arbitration algorithm provides a method for reaccessing the bus if a collision is detected. The mechanism of arbitration guarantees that information is not lost. If two or more Master (Peer) nodes transmit messages at the same time, the bus access conflict is recognized by the bus monitoring feature of the UMAC layer. When the first bus conflict occurs, all Master (Peer) nodes should stop their transmission and wait for the predefined collision bus access time (TCBA), before starting transmission again. The collision bus access time TCBA is a time duration equal to the equation:

TCBA=TI+(2·Tb)·MP

where TCBA is the collision bus access time, TI the IDLE time duration, Tb the bit time, and MP the message priority (0 to 7).

The arbitration algorithm implements a sequence of events:

1. First collision detected.

2. Each Master (Peer) node on the bus stops its transmission and then waits for its predefined TCBA.

3. After timeout, TCBA, the Master (Peer), tries to start its transmission again.

4. Second collision detected.

5. Each Master (Peer) node on the bus stops transmission and waits for a newly defined TCBA. The new TCBA is calculated accordingly:

TCBA= TI+(2·Tb)·R

where TCBA is the collision bus access time, TI the IDLE time duration, Tb the bit time, and R the random number (0 to 7). The random number is the value of the last three bits in the core timer of the MCU. If any further collision is detected, the procedure is repeated.

The Master Data Link Interface

The Data Link interface has two main elements -- the Data Link command/control registers (which let the application program control the overall operational modes of the Data Link) and the data structures (which contain the Push fields to be sent and the Pull fields which are received).

Figure 7 illustrates the Data Link command register (DL_command), a RAM variable shared between the application and the Data Link software. Using it like a register greatly simplifies the programmer's tasks. The contents of this register are reset by issuing the Data Link reset command DL_CMD_RESET.

Whenever a command is written to the Data Link command register, the Data Link Busy (DL_BUSY) bit (0 = not busy, 1 = busy) is simultaneously set by the application program. The DL_BUSY bit remains set until the Data Link has completed the requested command, at which point it will automatically clear the DL_BUSY bit to indicate completion. The application program monitors the DL_BUSY bit to determine the progress of the requested command. In general, another command should not be issued by an application to the Data Link until the DL_BUSY bit has become clear. However, the Data Link may be reset at any time, without waiting for the DL_BUSY bit to become clear, by issuing a DL_CMD_RESET command.

The CMD5-0 Data Link commands determine the command to be executed by the Data Link. Whenever the Data Link is working on a command, the application program is free to continue and does not have to wait for the command to be completed. The Data Link works automatically in the background performing the requested command, thus no further application intervention is necessary. The currently defined CMD5-0 commands are:

  • DL_CMD_RESET, which causes the Data Link to stop sending further messages (but not SYNC messages), clears all internal error flags, and resets the DL_command and DL_control registers.
  • DL_CMD_SLEEP, which causes the Data Link to stop sending further messages (but not SYNC messages) and then a SLEEP message is broadcast to the network. This command does not place the Master node MCU into any power saving mode; these are responsibilities of the application program.

  • DL_CMD_WAKE, which causes the Data Link to stop sending further messages (but not SYNC messages), and then a WAKE message is broadcast to the network.

  • DL_CMD_NEXT, which causes the Data Link to send the next application message and stop sending further messages (but not SYNC messages).

  • DL_CMD_MULTI, which causes the Data Link to send a multicast message and stop sending further messages (but not SYNC messages).

The Data Link control register, DL_control (Figure 8), is a variable that is shared between the application and the Data Link software. Using it like a register greatly simplifies the programmer's tasks. The contents of this register are reset by issuing the Data Link reset command DL_CMD_RESET.

The SYNC Message Enable flag (DL_SYNC) controls the sending of SYNC messages (0 = disabled, 1 = enabled) and lets the application control the role of the Master. To avoid collisions, only one Master in the network can be configured to send SYNC messages.

Finally, the MP2-0 Message Priority bits determine the priority of the message to be sent out by the Data Link. The message priority value is tied with each message issued by the Data Link. A range from 0 to 7 of the message priority value is defined, then just the lower three bits of the DL_control register are used. The message priority 0 is the highest priority.

Data Structures

Data Link control software can use simple (optimized for minimal RAM usage) or complex data structures. In either case, the two fundamental elements of Data Link data structures are a single Push and single Pull buffer, both of which reside in RAM. These buffers are a few bytes of RAM that are shared between the application and the Data Link software. The Push buffer (Figure 9) contains the information that is to be sent in the Push field of message from the Master to the Slave. The Pull buffer (Figure 10) contains the information that is received from the Pull field of the message from the Slave to the Master.

The first byte of the Push/Pull buffers contains the Header frame information. The Header frame of the Push buffer contains the address of the destined Slave and the Header frame of the Pull buffer contains the address from the remote Slave. The application can use this address information for communication checking to increase the communication reliability.

Subsequent bytes of the Push buffer contain the Data frames information if it is required by the Slave, and subsequent bytes of the Pull buffer contain the Data frame information if it is sent by the remote Slave.

Data Link Command Example

The Data Link is driven by commands. The application has to take care of the contents of the Push buffer and message priority value in the DL_control register when application and multicast commands are applied. The content and meaning of the Data frames in the Push buffer is completely application dependent and in this example the following message composition will be used.

The Push field of the application message contains a Header frame with the destination Slave address. The first Data frame is an application command and the following Data frames are data corresponding to this command. The application program must fill in the Push buffer by the Header and the Data frames, and the message priority must be written into the DL_control register.

In this example, I'll focus on the DL_CMD_NEXT command, showing it handles application messages, basing my example on Motorola 68HC08 assembly code and presenting only the code needed for this Data Link command.

An application message is issued by the DL_CMD_NEXT command. The message priority constant (M_PRIOR) that is tied with this application message is ORed into the DL_control variable. Next, the Data Link Push buffer is filled. The Slave node address (switch node in this example) is written as a Header frame into the DL_push_buffer base address and the application command ("switch on" in the example) is written as the first Data frame into the DL_push_buffer+1 storage location. No data is required with this command, so the next Data frame might be a random value from the DL_push_buffer+2 storage location, but a better way is to clear this memory location. When the Data Link Push buffer is filled, the Data Link DL_CMD_NEXT command is issued. The program in Listing One tests the DL_BUSY flag and waits until the command is completed.

Slave Data Link Interface Example

Listing Two shows a single Push field buffer (DL_push_buffer), single Pull field buffer (DL_pull_buffer), and command register (DL_command) for the Data Link interface. The Push field of the application message contains a header frame with the Slave address, two data frames, and a checksum frame. The first data frame is an application command and the second data frame is data corresponding to this command.

In Listing Two, the example Slave is controlled by a simple remote Master. The Slave is capable of turning on and off some kind of load. The Master sends "switch on" and "switch off" commands to control the Slave. The example can be easily extended to execute multiple functions.

After initialization, the application code starts at the label app_loop. The application in the app_loop fetches the latest Push field that has been received by the Data Link. All accesses to the Push buffer are interlocked using the MCU's interrupt mechanism. Before accessing the Push buffer, the application code must set the interrupt mask (to lock out the Data Link) and then must clear the interrupt mask after the buffer has been accessed (to allow access by the Data Link again). This guarantees coherent information exchange.

Because the Slave already knows its own address, the first byte of the DL_push_buffer is not used by the application. The MSB of the DL_command location is a DL_BUSY flag. Whenever the Data Link has completed the command (received the message), it clears the DL_BUSY flag to indicate completion. The application program monitors the DL_BUSY in the app_loop and, if it is zero, performs an application command. The application command value is read from the DL_push_buffer+1 storage location and is scaled by 4. This value is used as an index into a jump table (app_table). The index value is checked for the length of the jump table, to prevent jumps over the table. The SWI instruction is inserted into the app_table to get entries scaled by 4.

This version of the software uses just two commands, switch_on and switch_off. Whenever the application has read data from the DL_push_buffer the DL_BUSY flag should be set by the application program.

Conclusion

Because of their small hardware requirements, UART-based networks represent an attractive alternative in embedded distributed control. They give system designers flexibility in optimizing cost-effective embedded systems.

Niche Area Networks can be constructed in a modular way. New nodes that communicate only among themselves can be attached to the network without knowledge of the preexisting nodes and without interfering with their use.

The length of the network is so small that the network propagation delay can be neglected. All nodes see the same bit simultaneously, when transmitted. This fact increases the reliability of the network, as the transmitter is able to check that the correct value is on the bus at the time that it is seen by the receiver. Data integrity is confirmed using checksum and acknowledge methods.

DDJ

Listing One

        LDA     #M_PRIOR                ;Get message priority
        ORA     DL_control              ;Combine DL_SYNC and message priority
        STA     DL_control              ;Store result
        LDA     #SWNODE                 ;Get Switch node address
        STA     DL_push_buffer          ;Store node address
        LDX     #SW_ON                  ;Get switch on command
        STX     DL_push_buffer+1        ;Store command
        CLR     DL_push_buffer+2        ;No data is needed
        LDA     #DL_CMD_NEXT            ;Get command send message 
        STA     DL_command              ;Issue command & start sending
        BRSET   DL_BUSY,DL_command,*    ;Wait here until command completed

Back to Article

Listing Two

app_loop:       
        SEI                             ;Prevent interrupts
        BRSET   DL_BUSY,DL_command,MAIN_continue ;Branch if no new
*                                                Push field arrived
        LDX     DL_push_buffer+1        ;Fetch application command value
        LSLX                            ;Scale jump vector
        LSLX                            ;Entries scaled by 4
        TXA                             ;Prepare vector for checking
        SUB     #START-app_table        ;Check if command is in the range
        BMI     command_ok              ;Branch if command is OK
        CLRX                            ;Clear vector if not
command_ok:
        LDA     DL_push_buffer+2        ;Fetch Push data
        BSET    DL_BUSY,DL_command      ;Set waiting flag
*                                        (cleared by new Push field arrival)
        CLI                             ;Allow interrupts
        JMP     app_table,X             ;Jump using received control
*                                                field as an index
*
app_table:
        JMP     service_000             ;Service control value %000
        SWI                             ;Dummy byte to align jump entry
        JMP     service_001             ;Service control value %001
        SWI                             ;Dummy byte to align jump entry
        JMP     service_010             ;Service control value %010
        SWI                             ;Dummy byte to align jump entry
*
START  EQU     *
                
********************************************************************
*                            No action (%000)                       *
*********************************************************************
service_000:    
        JMP     >app_loop               ;No action, resume looping...
*********************************************************************
*                        SWITCH ON (%001)                           *
*********************************************************************
service_001:
        LDX     #1                      ;Get command to be returned
        CLRA                            ;Get data to be returned
        BSET    LOAD_ON,PORTA           ;Load switch on
update_link:
        SEI                             ;Prevent interrupts    
        STX     DL_pull_buffer+1        ;Update Pull command field
        STA     DL_pull_buffer+2        ;Update Pull data field
        CLI                             ;Allow interrupts
        JMP     >app_loop               ;Resume looping...
*********************************************************************
*                       SWITCH OFF (%010)                           *
*********************************************************************
service_010:
        LDX     #2                      ;Get command to be returned
        CLRA                            ;Get data to be returned
        BCLR    LOAD_ON,PORTA           ;Load switch off
        BRA     update_link             ;Update date link 




Back to Article


Copyright © 1999, Dr. Dobb's Journal

Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.