led_clock-old/README.md

6.7 KiB

The LED clock is an add-on for round wall clocks. LEDs need to be attached to the border of the clock. The micro-controller will then show how much time of the day passed using light.

project

summary

The time will be shown as arc progress bars, instead of hands pointing at the current time. The hours passed since the beginning of the midday are shown using blue LEDs. The minutes passed sine the beginning of the hour are shown using green LEDs. The (gamma corrected) brightness of the last LED shows how much of the hours or minutes has passed. Whichever progress is higher will be shown on top of the other. For example if it's 6:45, the first half of the circle will be blue, and an additional quarter will be green. The seconds passed since the beginning of the minute are shown using a running red LED, similar to the seconds hand. The red color might be added on top of the blue, or green color, then showing as violet or orange.

technology

The LEDs are controlled using a STM32 F1 series micro-controller (based on an ARM Cortex-M3 32-bit processor). The board needs to include a 32.768 kHz oscillator for the Real-Time-Clock (RTC). Preferably use a blue pill board. The board needs to be powered by an external 5 V power supply (e.g. using the USB port). To set the time connect using serial over the USB port (providing the CDC ACM profile) or USART1 port (TX and RX are on pin PA9 and PA10) and enter "time HH:MM:SS". Optionally connect a 3 V coin battery on the VBAT pin for the RTC to keep the correct time in case the main power supply gets disconnected. To know the charge of the coin cell connect its positive terminal to ADC channel 1 on pin PA1. The level of the battery will be shown on the LEDs just after a restart, and the voltage will be shown over serial. To avoid the micro-controller to drain the battery trough the GPIO when un-powered use an NPN transistor, with the collector on the battery, the emitter on the pin, and the base to Vcc.

For the LEDs use a 1 meter LED strip with 60 red-green-blue WS2812b LEDs. Tape the LED strip along the border/edge of the clock. Ideally the wall clock has a diameter of 32 cm for the 1 m LED strip to completely fit. Otherwise change the number of actually used LEDs in the source files. Connect the 5 V power rail of the LED strip to the 5 V pin of the board. Connect the DIN signal line of the LED strip to the MISO pin of the micro-controller on PA6. SPI is used to efficiently shift out the LED color values to the WS2812b LEDs. A custom clock is provided for this operation using channel 3 of timer 3 on pin PB0. Simply connect this clock to the SPI CLK input on pin PA5.

The brightness of LEDs is dependant on the ambient luminosity. To measure the ambient luminosity a 5528 photo-resistor is used. Connect one leg of the photo-resistor to ADC channel 0 on pin PA0 and the other to ground. Connect one leg of a 1 kOhm resistor to ADC channel 0 on pin PA0 and the other to a 3.3 V pin.

If the board does not provide a 32.768 kHz oscillator for the internal RTC it is also possible to use an external RTC such as the Maxim DS1307. The time is then read over I2C and incremented using the square wave output. Working example code is under the DS1307_4096Hz_timer tag.

board

The current implementation uses a blue pill.

The underlying template also supports following board:

Which board is used is defined in the Makefile. This is required:

  • for the linker script to know the memory layout (flash and RAM)
  • to flash the corresponding bootloader
  • map the user LEDs and buttons provided on the board

code

dependencies

The source code uses the libopencm3 library. It also uses the STM32duino-bootloader for easier DFU flashing.

Both projects are already git submodules. To initialize and get them you just need to run once: git submodule init and git submodule update.

firmware

To compile the firmware run make.

documentation

To generate doxygen documentation run make doc.

flash

The Makefile offers two ways of flashing the firmware on the board:

  • over the SWD port (Serial Wire Debug)
  • using the USB DFU interface (Device Firmware Upgrade)

The default mechanism make flash uses DFU.

SWD

To flash over SWD you need an SWD adapter. The Makefile uses a ST-Link V2, along with the OpenOCD software.

The main firmware will be placed after the bootloader. Thus you first need to flash the bootloader, else the main firmware will not be started. To flash the bootloader run make bootloader.

SWD is nice because it will always works, even if USB is buggy or the code on the board is stuck. It also does not require to press on any reset button.

To flash using SWD run make flash-swd

SWD also allows to debug the code running on the micro-controller using GDB. To start the debugging session run make debug.

DFU

To flash using DFU you just need to connect the USB port. When booting the micro-controller will start the STM32duino-bootloader bootloader. This configures the USB to accept firmware updates. After a short timeout (<1s) it will start the main firmware.

The main firmware will not be started if the bootloader is missing. You only have to flash the bootloader once, using the SWD method. To flash the bootloader run make bootloader.

To then flash using DFU run make flash-dfu or simply make flash. This will try to reset the board to start the bootloader. Else you will need to reset the board manually using the reset button.

The firmware also offer serial communication over USB using the CDC ACM device class. Since the micro-controller first starts the bootloader, it is recognised a DFU device. To provide the CDC ACM interface the host needs to re-enumerate the USB device. For this a USB disconnect is simulated by pulling USB D+ low for a short time (in software or using a dedicated circuit). Then the host will re-enumerate the USB device and see the CDC ACM interface.

You can also reset the board by setting the serial width to 5 bits. This allows to restart the bootloader and flash new firmware using DFU. To reset the board run make reset. This only works if the USB CDC ACM is running correctly and the micro-controller isn't stuck.