-
Software
01/18/2016 at 06:33 • 0 commentsSoftware is coming along. The major building blocks have been written:
- Tiered menu system
- Common UI
- 40 character input (multi-line)
- Software de-bounced buttons
- Interactive "shell"
- User configuration
- Animation
- LEDs
- A couple easter eggs
Still need to move the RFM69 code out of its test harness and into the main code. Of course to start testing this we will need to assemble another breadboarded badge to pass data back and forth.
One of my complaints with electronic badges has been management of firmware. It's inevitable that bugs will be discovered when your userbase goes from 1 to 5 to 500. It seems that every group is re-flashing badges with fixed software at the con and I have yet to see one with an indicator of the software version inside. We've added this to the badge. As of today we're tagging the software as v0.5.0. Hopefully this will reduce confusion should any firmware pushes be necessary at DEFCON.
-
Prototype coming along
01/14/2016 at 06:30 • 0 commentsProbably a bit ahead of the power curve but we want to get the prototypes in hand to really nail down the software. So far the badge only exists on several breadboards in a garage and schematics/layouts in Kicad. The goal is to send the design to fab this weekend or next. You can see the a quick and dirty rendering of what we have so far in the gallery.
-
Busy Weekend
01/11/2016 at 07:18 • 0 commentsThis weekend we made some progress on the prototyping. Pin assignments have been set and we're starting to build the prototype in Kicad. Several previous mockups have been done, but now it's time to design something to fab.
RFM69 has been moved to SPI2 to free up SPI1 for the user. Arduino maps the SPI global variable to SPI1 and most libraries simply use it when connecting to peripherals. We're maintaining full user control over SPI1 a.k.a. SPI to help with software portability.
Here's a breakdown of what we expect the user to have access to:
- As many as 20 GPIO (may be 18 depending on USB goes)
- 8 of which will be ADC
- 14 with interrupts
- 1 Hardware SPI
- 1 Hardware I2C
In addition to the hardware work, we re-factored the user input code into its own library for ease of use. This will help as multiple planned functions require it (multi-line and single line).
That's it for now.
-
340 FPS!
01/08/2016 at 22:29 • 0 commentsFinal badge may not have quite this performance, but we fixed hardware acceleration on the I2C bus for the OLED and measured 340 FPS animating a stick figure. The animation is simply flipping through 20 or so monochrome bitmaps so there's nothing special or particularly computational complex. Nonetheless, it is ridiculously fast!
The plan is still move the OLED to the SPI bus and share with RFM69 and flash storage, the cheapo Ebay screen we got off Ebay came I2C. SPI OLEDs are in the mail.
-
Libraries libraries libraries
01/06/2016 at 17:45 • 0 commentsAs our code base has grown so have the dependencies on various Arduino libraries. Adafruit GFX, SSD1306, RFM69, etc etc. Each has its quirks and we've had to make tweaks here and there to make them work together. Example, to preserve analog IO, we need to move the NeoMaple library off its default pin of PA0 to something else.
This, of course, makes configuration management a nightmare. Not only do we have to deviate from the libraries but we now must maintain our changes independently and keep them synchronized in our git repo between our various computers.
To date, we've used the Arduino IDE for development. Managing libraries and their various versions has proven to be difficult. Arduino supports multiple library folders but the source folder with the .ino file doesn't support folders. Each source file becomes a tab across the top and unmanageable at scale.
Our next goal is to move the development over to Eclipse using the Arduino plugin. This still requires the Arduino IDE to compile and configure the boards. But Eclipse is much easier to manage large code bases than Arduino is. Hopefully it will have better library management too!
Maybe something like cmake or platform.io is a better alternative.
-
An initial update
01/05/2016 at 15:57 • 0 commentsNow that our badge has it's own hackaday.io page, it's time to use this to publish our status. The three of us have been working on the badge quietly for several months. As early as October we started throwing ideas against the wall to see what would stick. We looked at accelerometers to FPGAs and settled on the design we have now which is based on the Maple Mini by Leaf Labs.
Why the Maple Mini?
For one, the design is mature enough for clones on Ebay and two, the BOM was straightforward and easy to implement. However, it did come with drawbacks: a unique IDE and drivers that don't work well on Windows 10.
This is where STM32Duino comes in. Roger Clark has done a fantastic job modernizing the toolchain, bootloader, and libraries for STM32-based designs like the Maple. In fact, the schematic we have right now is more of a generic STM32 device than a Maple.
So what do we have today?
After several fits and starts, we have a cheap Maple clone, a bare STM32F103CBT6 on a breadboard with major components, and a barebone breakout of the STM32 with supporting components (crystal, caps, LED, and buttons) to support further software development.
On the software side, we have about 1500 lines of code pushing animations across the WS2812B LEDS & OLED, basic UI supporting text and button input, several easter eggs, and a modified RFM69 driver from LowPowerLab.
More to come...