Such as it is, the “operating system” for the unofficial Dublin Maker badge is nearing completion. The latest work has focused on the inter-badge communication. This is a wired protocol (the lanyard is the cable that links the badges together).
Inter Badge communications (IBC)
The protocol makes use of the USART in the STM32F030. The USART supports a single wire half duplex protocol. The TX pin only is used and is configured as an open drain with an internal pull-up. When it is transmitting it becomes an output. When not transmitting it is in receiver mode. Given the probably poor cabling and connections the communications speed will be set as low as possible but not so low that it gets in the way of game play. The protocol should therefore have as little overhead as possible.
Addressing
Some applications will require sender and receiver to be identified so both addresses must be in each data packet. A single byte for device address – probably overkill to allow this but it is simpler to process and could have special addresses e.g. broadcast for certain situations.
Indicating start of packet
The hardware link as designed has two signal wires: One for half duplex data the other for indicating that the bus is busy. A sender pulls this line low just prior to starting a transmission. This is handy for a number of reasons:
* It allows us know when the bus is busy.
* It can be tied to an interrupt to put the chip into “packet receive mode”.
* When it goes high, packets are either processed or discarded.
* No special start or end of packet signals are necessary
* In some ways this is like the “carrier” in CSMA/CD
The packet format is as follows:
* tx/rx signal #########DST SRC FLG_LEN DATA0..DATAn CHK###########
* busy signal #######|__________________________________|#########
Flags/control byte
Following the address bytes a third byte will contain flags and length inforation. 4 bits for flags (such as : ACK, NAK, ANNOUNCE etc), 4 bits for length
Address assignment
How does each station get an address? It could be hard coded but that’s a separate firmware image for each badge – too much work. The user could be asked to enter it but this complicates the user interface. Automatic address assignment was chosen in the end and it works as follows.
On power up, send an ANNOUNCE broadcast packet (Broadcast address is 0xff):
0xff SRC 0x20 CHK
Where SRC is the address the station is attempting to use. If some other device has this address then a NAK will be sent and a new ANNOUNCE with the next address is sent.
NAKS may get lost but I’m not dealing with this – it’s not that critical a protocol
The image below shows the bus traffic when a station powers up and attempts to claim the address 0xfe. The current holder of this address sends a NAK to indicate that 0xfe is taken so a new announce packet is sent for the address 0xfd. This is successful.
Error detection
A simple 8 bit checksum byte will be used to provide some form of error detection – it’s not great but it’s better than nothing.
Difficulties encountered
The main problem was managing state (I’m still not sure it’s ok) and also one major gotcha. I tried using the Timer subsystem to manage delays in the communications code. The Timer uses the SysTick timer and interrupts to measure the passage of time. Unfortunately, some of the IBC code runs in interrupt context within which (nested) SysTick interrupts don’t happen. This might be possible but I decided not to get too adventurous with the NVIC and found another way to pace communications
What’s next?
Now that IBC works I have to come up with a game that requires it. This will require passing information from the badge communications layer up to an application layer – something I’m not quite clear on how to do yet.
Source code is as usual available over on github
ioprog 