-
The New Status Light: Getting to blinky
07/06/2019 at 10:48 • 0 commentsAt 10pm on a Thursday evening in early April, it suddenly seemed like a great time to make another version of the status light I've been using for the last few years. Something small, simple and fun. Why not chuck together a schematic and a start a layout before calling it a night!
I'd been eyeing the STM32F070 for another project needing a basic, low-cost controller with a USB peripheral built in, and that seemed to fit the build here too. Sure, an ATTiny85 with V-USB is a little cheaper, but the options the STM32 brings to the table are worth the premium:
- 6KB of SRAM, plus a dedicated 1KB buffer for the USB peripheral
- 32KB of flash
- More capable timers (five of them)
- More I/O in a similar footprint thanks to a smaller pitch package
- SWD interface for debugging, making debugging a simple experience vs debugWIRE on an AVR. With AVRs lacking a PDI or JTAG interface I usually avoid using the debugger unless I absolutely can't solve an issue by code analysis.
Most of these are overkill for a device that controls a handful of addressable LEDs, but the smooth remote debugging experience is probably worth the cost alone. The STM32 does need 3.3V regulation, but the part count is reduced overall compared to the V-USB approach.
Schematic
There's not a whole lot to this piece of hardware. All of the spare pins on the micro are broken out so this can be used as a mini dev board for other devices that need USB control.
A few notes for next time:
- I somehow managed to slip a pull-up resistor onto the reset line of the STM32 and sent that to the fab, even though I'd read the datasheet that states there's a built-in pull-up and only suggests adding a capacitor to ground. This is not needed.
- My 11pm-brain failed to put much thought into which pins might be better than others and just picked the first available pin (
PA0
). This is fine for bit-banging the LED data signal, but on this MCU model (C6
),PA0
has no useful special function! An SPI or UART peripheral could've been used to encode the SK6812's time-based signal as bytes and sent via DMA instead of blocking for 115uS, but it's not a big deal for this project. - Using the USB peripheral on this chip requires the pins for both of the onboard I2C peripherals, so no hardware I2C is available on the broken-out pins. This isn't needed for the lights and can always be implemented in software if needed, but it's worth noting as a limitation of this chip when using USB.
- Putting a jumper or button footprint on the BOOT0 pin as a default would be helpful. I tied this to ground as I wasn't planning to use the built-in USB firmware upgrade mode myself, but as I'm planning to share these devices with people at my workplace that might've come in handy for letting someone upgrade their own firmware easily without requiring a J-Link/ST-Link.
PCB layout
Again not much to see here. The pictured layout is slightly improved over the design that went to the fab - "2.0a" fixes an unnecessarily long ground return path for the crystal, though this hasn't caused any issues in the boards I had made so far...
I'd previously bought all of the components needed for this build, so I sent the board off and moved onto other projects while waiting. The PCB manufacture only took a couple of days, but the standard-post shipping I chose took significantly longer.
Board bring-up
Three weeks later, the PCBs arrived and I spent an evening at the bench soldering. Assembly went fairly smoothly, with the regulator installed and tested first, then the STM32 installed and confirmed accessible over SWD:
The SK6812-mini LEDs went on, and toggling their data pin as fast as possible confirmed they were all working at full brightness. A little NOP wrangling later, the correct time-based data signal could be sent and the LEDs were ready to work. The encoding has slightly different timing than the WS2812(B), but it's the same concept.
The first issue arose when the board wouldn't communicate over USB, with dmesg reporting something along the lines of "device not accepting address". While trying to confirm the crystal was operating at the expected frequency I somehow managed to destroy the oscillator circuit in the chip I was using (just by probing it?), and from then on that chip would hang waiting for the external oscillator to start, even when the STM32 was completely removed from the circuit.
After replacing the crystal and MCU, everything worked correctly and a basic USB HID device was registering correctly with the host:
Basic USB device firmware
A simple USB device is fairly straight forward conceptually - configure a bunch of endpoints that can be polled by the host to read data, or interrupted by the host to write data. Combined with the semi-documented STM32 USB device library + HAL though, I was in for a fun time.
I won't bore you with the gory details, but after three long evenings of reading, digging through the example code and complaining about ST's code quality, and almost bailing to use libopencm3 I had an endpoint that I could send colour data:
Two status lights assembled and running. I haven't settled on a design for the 3D-printed case yet. Continuously piping new colours to the device to animate works as a demo, but it's not ideal. The next step is to offload most of the work to the device and provide an interface for programming changes and animations:
- Immediately set the colour of all or some LEDs
- Transition to a colour
- Hue-shift to a colour
- Program a series of frames/commands
- Play a configured series of frames/commands (once, N times, forever)
- Program the USB disconnect and connect behaviour (eg. host going to standby)
The host side of this will be implemented in a Python library, since libusb1 makes the host side super easy:
with usb1.USBContext() as context: handle = context.openByVendorIDAndProductID(VENDOR_ID, PRODUCT_ID) if handle is None: print("Failed to find a device") with handle.claimInterface(0): handle.interruptWrite(1, bytearray(...))
-
USB Status Light: Prologue
05/12/2019 at 10:04 • 0 commentsWriting firmware for the v1 USB status light in 2016 A couple of years ago I was part of the site-reliability team at Xero - a squad of in-flight cyber mechanics outnumbered 100 to 1 by a fleet of production servers. To cut through the daily noise of alerts, logging and system metrics, I figured a simple light on my desk to say "something's not right" would be a useful novelty. The catch? This was my second electronics projects, and I had no idea what I was doing.
Searching for "usb controllable led" in 2019 lists a bunch of devices you can outright buy, but back when I started this project in 2016 there didn't seem to be much around. At the time I referenced a single article about a "USB status cube" someone had built, but searching for that article now turned up numerous projects doing exactly the same thing as I ended up with: an AVR chip, V-USB and a bunch of programmable LEDs. I have no idea how I missed all of these at the time, but we can chock it up to blissful ignorance.
In any case, this is the story of my first PCB and how it's still a useful tool almost three years later. This isn't a build guide, but if you're building something similar you can use this as an example of what not to do.
How not to draw a schematic
In my first electronics project I'd skipped a schematic and PCB and simply used point-to-point wiring and some strip-board to hack it together. For the status light, a PCB was needed to arrange 9 surface-mount LEDs in a fixed pattern, along with the SMD WS2811 chips and microcontroller.
Now keep in mind at this point I had never laid my hands on any EDA software. I grabbed a copy of Eagle (because that's what I'd seen other people using - I recommend KiCAD now) and set to work bashing my fists on the keyboard until this monstrosity came out:
Among the overlapping, diagonal wires, lack of decoupling capacitors, lack of meaningful labels (what are those USB pins!!?) and haphazard organisation, I'd give this an F for "functional but utterly terrible". It definitely captures the "I have no idea what I'm doing, but I have a goal to achieve" spirit that comes with being a total newbie.
The crisscrossing wires were introduced during layout to make it possible to route the board single-sided, but it's a gross schematic regardless. Also note that the LEDs were desoldered/borrowed from a 12V WS2811 strip that used groups of generic RGB LEDs with separate driver ICs, so even though this design has 9 LEDs it's only three addressable columns.
For reference, here's the USB part of the schematic recreated to be actually meaningful:
PCB layout
Choosing to create a single-sided board with 50+ connections for my first PCB layout experience taught me two things:
- PCB layout is a really fun puzzle.
- People who do PCB layout professionally are the unsung heroes of this era.
This layout also graded F for "technically functions". It follows no rules other than "pads on a net must be connected". You might notice that the layout pictured is version 1.2. The first attempt (picture) ended up a complete mess of bodges as I'd missed a reset pull-up for the AVR, had multiple unconnected ground pours, and had mirrored the ISP header. The original version also had one less LED in the centre column, which gave uneven brightness so a third was added.
I won't go into detail about making the PCB at home other than saying it taught me to avoid making PCBs at home unless absolutely necessary. Sure, do it once as a learning experience, but then you'll understand why it's usually better to pay someone else to do it.
The application of solder to the entire board was 50% mess from soldering, 50% trying to hide said mess by covering the whole board in solder. Firmware
The firmware for this original version of the project isn't particularly interesting or good, but you can download the code if you're curious. A few points of interest:
- Uses a CIE1931 luminance look-up table to achieve linear perceived brightness
- Has a breathing effect that slowly fades the brightness up and down around the selected colour.
- Transitions smoothly between colours when changed by the host.
I've had no problems using the V-USB device other than occasional packet failing to send if you spam it with control messages to change the colour.
Making an enclosure
The case for this only had a few constraints:
- It needs to sit on a desk;
- It should have space for a logo to be embossed on its face;
- It needs to be made of a material that diffuses light from the board inside.
To cover these I chucked a cylinder into Fusion360, cut a 13° plane into its side to make desk-friendly base, then shelled and split the solid into a lid and base. A separate riser piece (green below) gives clearance for an IDC socket on the back of the PCB:
The interface between the base and lid has no tolerance in the design, but the layer ridges from 3D printing combined with flexible ABS plastic result in an excellent friction fit that holds firmly but can still be taken apart by hand:
The riser is glued into place as it was an afterthought, but a lip could be easily integrated into the base half to replace this.
3D printing this in semi-transparent ABS, sanding it smooth and putting the board inside gives a decent diffusion and a nice smooth finish. There aren't many decent photos of this build, so here's a frame from a video:
Fast-forward to 2019
Although this device is slightly crusty and questionable, it's actually been incredibly useful for the last two years at my job working on large compiled software projects. Not long after starting, I configured the light to glow green when a local build succeeds, and red when one fails. The colour blasts full-brightness for a few seconds to get my attention, then dims to show the last state.
When I know a build is going to take a while, this light-based notification lets me switch task completely - even something not on the computer - and get a visual indication when the build is done. It sounds like a bit of a novelty, but it's actually been a very useful tool.
For posterity, here's some photos I grabbed when I had the light back at home recently to update its firmware with some new modes.
Front cover on in 2019 The PCB inside the enclosure The back of the PCB with a few through-hole components and the attachment of the USB lead. Also note this is affixed with double-sided tape! Downloads
I won't provide the original Eagle files as they're not fit for reuse, but the rest of the project files can be downloaded below for the curious.