We had a 2 hour Dublin Maker badge building session in Tog on Monday the 27th. 10 people showed up to (partially) assemble 13 badges. The firmware will need to be finalized before the final build which should hopefully happen in the next couple of weeks. Hoping to get a total of 15 built.
Author: fduignan
DM 5 Euro badge : first build
The first build of the unofficial €5 badge is more or less done. The image above shows a front view. Two 3.5mm audio sockets act as communications ports and allow a stereo audio cable be used as a lanyard. A game-pad style interface is provided for the bundled games. Also provided is a 4 pin header for uploading and debugging new firmware. The badge is powered off a 1.5V AA battery which is stepped up to 3.3V using a boost converter (just below the left audio socket).
I attempted a previous version of this by soldering all components in place but quickly realized that was so difficult that there would be few successful builds. I’ve since switched to a mixed wire-wrap and soldered build as shown below (I know it’s a bit rough :). This approach is much easier and errors are easily corrected.
Remaining tasks:
Tidy up the back of the badge
Develop a multiplayer game
Get ready for the badge “make-a-thon” in Tog later in May
Code and docs are available over on github
Dublin Maker Badge (unofficial) OS nearing completion
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
Breadboard games 2019 : Dublin
We had a great morning today with the children and teachers of St. Brigid’s primary school. We had 22 participants who all left with working BBG’s. Pictures and some more details over at St. Brigid’s blog.
This year’s code was more or less the same as last year’s however support for additional screens was added. Source code is over on github.
The event took place in the recently refurbished and fantastic Kevin St. public library. Thanks to all concerned especially Gillian, Ciaran and Esmé, Sam, Oran, Shannon and Shane.
The STM32F030 driving an ST7789 display
The ST7789 display used in this example is a 1.3 inch 240×240 colour LCD display. It interfaces to the STM32F030 at the pretty fast speed of 24MHz. The display is connected as follows:
My intention with this circuit is to create a low cost conference badge (actually for Dublin Maker 2019). The target bill-of-materials cost is €5 – most of which is attributed to the display.
Full size image
Connecting the hardware is only part of the story however and a software library is also required. This was based on the Breadboard Games code from last August in Wexford. The main changes that had to be addressed were the new initialization code and the openAperture code. These were based on the Adafruit library code and the manufacturer’s datasheet. This library includes some graphic drawing primitives as well as other functions to support game play (e.g. timing and random number generation). Additional functions will be added as the badge develops.
Code is available on github
A video of the library in operation is available on YouTube.
The STM32F334 from the ground up
The STM32F334 MCU has an ARM Cortex M4F core along with ADC’s, DAC’s and motor control timers – all of which are useful to me for DSP and motor control. My final intention is to design a couple of PCB’s around this chip so rather than buy a ready made board like the STM32F334 Discovery I decided to work directly with the bare chip.
First task is to mount the chip on a breakout board so that I can use it with a breadboard.
Full size image
Some tips when doing this:
Have a good soldering iron that does not get too hot (I have an Antek 25W iron)
Have lots of liquid flux available and apply liberally
Have solder wick to hand to sort out the (inevitable for me) solder bridges
The circuit was wired as shown in the diagram above and is shown here:
I used an ST-Link clone from Aliexpress which costs 2 or 3 Euro.
In the past I have manually written header files for the various internal peripherals. ST Microelectronics provide a System Volume Description file which can be used with SVDConv to create a header file. This header file relies on other components from the ARM CMSIS libraries spread across various folders. I don’t like this so I added various dummy files (some with zero content) to the same directory as the generated header file. This allows me confine all header files to one directory and is completely standalone.
Having done all of this various examples were written and the code repository is over at github. This will grow over time but for now there are examples of blinky, systick interrupts, UART i/o and the ADC.
Using the TLS2561 to wake the STM32L031 from sleep
In some ways this example is a bit illogical. The TLS2561 consumes a few hundred micro amps while operating so using it to wake the STM32L031 from sleep doesn’t make a lot of sense. This example may be relevant to those who want to use an external I/O pin to wake the an STM32L031 generally or maybe as part of a larger circuit.
The TLS2561 can generate an interrupt signal when the light received on Channel 0 goes outside a user specified certain range. In this example, the range was arbitrarily set to go from 0 0x100. If the received light is equal to or greater than 0x100 then the interrupt signal is driven low which wakes the MCU. If the light is less than or equal to 0 an interrupt is also generated. This isn’t exactly what I wanted (I only wanted an interrupt if the light was bright) so if the circuit is plunged into complete darkness an interrupt will also be generated. This unintended waking could be dealt with by checking the value on Channel 0 and, if zero, going back to sleep again.
Code is available as usual over on github.
