token bus design, Autotel

Autotel

token bus design

First prototype:

Git and documentation

The first prototype of the tokenbus is documented here: https://github.com/autotel/TokenBusHomogeneousNetwork

Media

Testing the speed of the prototyped network

Integrated prototype 1

The integrated prototype is developed in the branch COM_common_bus on the js-virtualModular git repository. It is based on the previous work, with some modifications

To reduce the amount of bytes to be transmitted, I decided to tweak the communication protocol from the one used in the JavaScript based prototype here

Bus communication syntax

the messages for the bus will be defined as follows: (each byte is separated by a comma)

msg mode | length , origin | destination [, payload]

the name of each byte is:

header byte,  routing byte, payload …

In any given module, the first two bytes will define whether this message must be ignored or taken. It is also possible that the first byte indicates whether the message should be ignored.

Header byte:

modes:

length:

the header is shifted a nibble, and or’ed with the length (0-16).  The length is inclusive of header and routing bytes. The message length format has not been defined, it can be:

Also, there is the option of using the F length as undefined length, in which case some number should be defined as terminator bytes, most likely an ASCII CR character. In such case, an escaping protocol should be deviced.

[https://en.wikipedia.org/wiki/ASCII]

Routing byte

Routing byte is only used for payload messages, since the com messages will have a different syntax. This byte results from (emitter_id)<<4 | (destination_id). Emitter id is the emitting module’s id within the current network. The destination and source bytes define whether to ignore the incoming payload, according to the indicated mode of message.

The bus network used in other network configurations

it is possible that in the future, with access to more complete micro-controllers or development tools, the connections between modules become physical (using mechanical connectors between modules) instead of virtual (where modules chose their targeted messages according to id’s in a bus). It is also possible that these modules may form more than one bus, to allow faster communications in a network that has many modules. There are reasons, however untested, that may lead to think that this protocol can be applied to such cases.

 

[The Complete MIDI 1.0 Detailed Specification]

 

Leave a Reply