Multi-Module Communication Example

Related
Products

Product image for BrainStem Moto 1.0 Module

Introduction
Source Code - Networked Scratchpad Access
Source Code - Initating a Task on a Networked Module
Source Code - Using TEA to Communicate Scratchpad Data
Source Code - Using a Relfex to Communicate Scratchpad Data
Executing the Network Task

Introduction

This example shows how multiple BrainStem modules can share data. It also demonstrates how one module can initiate a task in another module.

BrainStem modules may be networked via an I2C bus. In a network a host device can send commands to any module in a network. Individual modules can also send commands to each other.

Diagram of a networked topology of multiple BrainStems and a Host.

Network topology for communication between BrainStem modules and a Host computer.

The latest GP and Moto Modules have enhanced I2C features for scratchpad access. They support multiple-byte scratchpad writes via the cmdPAD_IO command. They also support direct I2C reads from other modules' scratchpads via the cmdPAD_SETPTR and cmdIIC_RD commands or aPortIICRead VM port.

Note

GP 1.0 Modules of Build 12 or later, GP 2.0 Modules in the Garcia robot, and Moto 1.0 Modules of Build 6 or later have these enhanced features. Build number and version may be checked with the cmdVAL_GET command.

Older modules support single-byte scratchpad writes and do not support direct I2C reads of the scratchpad. If a module (the caller) must request an action in one of these older modules (the target), it must send a command to the target that launches a reflex or TEA program. The target must then respond accordingly. It can write to the caller's scratchpad or write to the caller's semaphore if it is waiting for data. Using a reflex is more efficient, but it limits the amount of data that can be transferred. Using a TEA program requires extra processing overhead and a free process slot in the target, but it provides more flexibility.

Contents

Source Code - Networked Scratchpad Access

The simplest technique for transferring data between modules is for one module to write to another module's scratchpad. With this technique, a module can write to another module at any time or check its own Scratchpad at any time to get the latest data supplied by another module. No synchronization is required.

The following example is written for a network of two BrainStem modules, one a GP with address 2, and the other a Moto with address 4. The Moto module is configured as the router and the Moto writes and reads the Scratchpad in the GP module.

Network topology of BrainStems with Host.

Example network of BrainStems across the I2C bus.

Note

Networking routines for communication among BrainStem controllers was included in the "aBus.tea" library as of the Software download version 60325.

The network subroutines could be used in any module with the enhanced I2C features. Try reconfiguring your network so that the GP is the router and change the defined TARGET value to 4. The GP module will write and read the scratchpad in the Moto module.

#include <aCore.tea> #include <aPrint.tea> #include <aBus.tea> #define TARGET 2 void main() { char i; int m; // test int routines // (write and read back 1,3,5,...,31) for (i = 0; i < 32; i = i+2) { aBus_WritePadInt(TARGET, i, i + 1); } for (i = 0; i < 32; i = i+2) { m = aBus_ReadPadInt(TARGET, i); aPrint_IntDec(m); aPrint_Char('\n'); aCore_Sleep(100); } // test char routines // (write and read back 1,2,3,...,32) for (i = 0; i < 32; i++) { aBus_WritePadChar(TARGET, i, i + 1); } for (i = 0; i < 32; i++) { m = aBus_ReadPadChar(TARGET, i); aPrint_IntDec(m); aPrint_Char('\n'); aCore_Sleep(100); } }

Contents

Source Code - Initating a Task on a Networked Module

This example is written for a network of two BrainStem modules, one with address 2 and the other with address 4. Either module may be set as the router.

Then two different methods will be explored to read back the Scratchpad data on the slave controllers. The first method is executed on the master controller by launching a TEA program that reads and writes the value to a semaphore. The second method uses a reflex to read the Scratchpad data and write to a semaphore. Greater detail for each method is explained in the following sections of this example.

The "nmaster.tea" program uses a routine from the "aBus.tea" library called aBus_WritePad that can write a byte to another module's Scratchpad. Two additional routines are also created to demonstrate methods to trigger slave module actions. One routine, called aNetwork_ReadPadTEA, is with using a subordinate TEA process and the other is handled by executing a reflex routine, called aNetwork_ReadPadReflex.

/* nmaster.tea */ #include <aCore.tea> #include <aCmd.tea> #include <aBus.tea> #define SCRATCH_PAD_SIZE 32 #define SCRATCH_PAD_REFLEX 100 #define SCRATCH_PAD_PROGRAM 7 char aNetwork_ReadPadReflex(char cModule, char index) { char value=0; asm { /* trigger response reflex in other stem */ pushsb 5 pushlb 3 pushlb cmdRAW_INPUT pushlb SCRATCH_PAD_REFLEX pushsb 8 pushlb 5 popcmd /* read semaphore immediately */ pushms aPortProcID pushls aPortSemaphore adds pushmbx popbs 1 } return value; } char aNetwork_ReadPadTEA(char cModule, char index) { char value=0; asm { /* run response program in other stem */ pushsb 5 pushlb 6 pushlb cmdVM_RUN pushlb 3 pushlb SCRATCH_PAD_PROGRAM pushmb aPortAddress pushmb aPortProcID pushsb 11 pushlb 8 popcmd /* read semaphore immediately */ pushms aPortProcID pushls aPortSemaphore adds pushmbx popbs 1 } return value; } int main() { char i; int sum=0; /* scribble into other Stem's pad */ for (i=0; i<SCRATCH_PAD_SIZE; i++) { aBus_WritePad(4,i,40+i); } /* retrieve data from other Stem's pad */ for (i=0; i<SCRATCH_PAD_SIZE; i++) { sum=sum+aNetwork_ReadPadTEA(4,i); } /* retrieve data from other Stem's pad */ for (i=0; i<SCRATCH_PAD_SIZE; i++) { sum=sum+aNetwork_ReadPadReflex(4,i); } return sum; }

Contents

Source Code - Using TEA to Communicate Scratchpad Data

TEA can be used to send information back to a calling process via a semaphore. The parameter passing makes the routine very flexible. It could be copied on all modules in the network. This routine uses up a file slot and will require a free process on the slave module.

The "nslave.tea" program contains a routine that looks up a Scratchpad byte and sends it to the particular module and process that requested the byte. All a calling program, such as "nmaster.tea", needs to know is which file slot contains the "nslave.tea" program. The slave program is stored in file slot 7 for this example.

/* nslave.tea */ #include <aCmd.tea> #include <aPad.tea> void reply(char cModule, char cProcess, char data) { asm { pushsb 5 pushlb 3 pushlb cmdDEV_VAL pushsb 7 pushlb 53 addb pushsb 7 pushlb 5 popcmd } } void main(char cModule, char cProcess, char index) { char cData; cData=aPad_ReadChar(index); reply(cModule,cProcess,cData); }

Contents

Source Code - Using a Relfex to Communicate Scratchpad Data

A reflex can be used to transfer information across a network with the use of the Scratchpad and semaphores. Semaphores can be used to synchronize the communication between processes. When a process is waiting for a semaphore, that process does not use any RAM and pauses the process execution and frees RAM for other processes to use.

The reflex used in this example requires only two commands and can run independently of any TEA programs. As a side note, it does not use up a file slot reserved for TEA programs. The first step in the reflex routine uses the cmdPAD_INPUT command that reads a byte from a Scratchpad location. The byte read from the Scratchpad is then propagated as the raw input to the cmdDEV_VAL command, which writes the Scratchpad byte to the calling routine's semaphore. Once the semaphore is written, the calling process will resume execution.

Reflexes are limited in their parameter passing that typically results in hardcoding reflexes. Hardcoding is one drawback when writing reflexes. Every module and process that may request a byte will need a separate reflex.

The following "pad.bag" file contains commands for storing this reflex in module 4 (Moto) EEPROM. This reflex makes module 4 (Moto) write one of its Scratchpad bytes to the semaphore for process 0 in module 2 (GP).

/* pad.bag */ 4 11 128 100 128 148 4 11 128 101 129 148 4 12 128 0 4 3 52 101 0 4 12 128 1 2 3 4 53 0

Contents

Executing the Network Task

To try out the sample code, it is necessary to have two BrainStem modules. Configure them in a network as described above. Compile and load the example code by entering the following commands in the Console:

batch "pad.bag" steep "nmaster" steep "nslave" load "nmaster" 2 0 load "nslave" 4 7

Each time a TEA program starts or terminates, it sends a message to the host. Since this example involves launching lots of TEA processes in Module 4, you may wish to disable these messages. To do so, enter the following commands which will make Module 4 run in Quiet Mode .

4 18 20 1 /* Set to quiet mode */ 4 19 /* Save parameters */

Now run the master program:

launch 2 0

The master program in Module 2, slot 0 writes bytes into the scratchpad of Module 4. Then the master program reads back the bytes and adds them up, first using the reflex technique then using the TEA technique.

Revision History:

2006-10-31: Updated example with the "aBus.tea" routines and added diagrams to help explain the network topology.
2004-03-18: Example Created.