I frequently find myself navigating ’round on my bike, juggling Google Maps precariously in one hand. I don’t appreciate the bulky handlebar phone mounts about so thought I’d make something to neatly integrate with the Garmin Quarter Turn mount…
Following on from adding support to wiringPi for the MCP4725 DAC, I wanted to add driver blocks to Simulink such that one could use them to create graphical models for the Raspberry Pi that could interface with the real-world – a workable alternative to expensive real-time targets.
My laser cut binary clock, Wooden Bits, originally had no means to set the clock, other than at compile time. I later added a tactile button and ISR to provide this function (increment the time until the correct time is shown) but I wanted a way to tap into the extra features of the DS3231 (alarm, temperature) and also to experiment in wireless control.
The Raspberry Pi lacks a DAC but using the I2C bus, one can easily add a device like the 12bit MCP4725. The GPIO library wiringPi provides support for I2C devices, however, getting the MCP4725 working with it isn’t a simple as one might hope. The device is 12bit but the I2C protocol works on bytes (8bits). To send 12bit data, the Microchip designed the message transfer like this:
Continuing on from my Ambient Noise Level Indicator, I wanted to create an enclosure and make it stand-alone – not requiring a computer to do the processing. I ended up with a little device that converts noise amplitude to the light spectrum: Noise Crayon.
The Ambient Noise Level Indicator used the MCU serial host Processing to perform a FFT and various averaging routines to create an indicator for ambient noise. The idea being that it would change colour when background levels rise above a threshold. Moving to an ATMEGA328, performing this processing – especially the FFT – is asking a little too much of it. There are libraries but I’ve heard of limited successes.
Simulink Embedded Coder offers an ARM Cortex-M support toolbox, which includes code optimisation for the MCU and QEMU emulation but lacks any S-Block drivers for the device. The lack of drivers limits the Simulink development to merely number crunching. You can create
cevel blocks that execute external C functions but this requires separate source files with a shared header and pre-defined initialisation, leaving the model without full control of the hardware. In this post, I go over the process of creating hardware driver S-Blocks.
The Atmel Studio IDE is a useful tool thanks to the comprehensive debugging support and management of project drivers via the Atmel Software Framework (ASF) – coming from a hardcore Vim advocate. One thing I dislike about IDEs is the fact they hide the make process from the user making it difficult to break a project away from the software. On wishing to develop code on different operating systems (being Visual Studio based, Atmel Studio is limited to Windows), and outside the IDE, I set about creating a Makefile for an Atmel Studio project built around the ASF.
I’ve been meaning to make a binary wall clock for a while and to also try out kerf bending with the laser cutter. What put me off creating kerf bends before I found OpenSCAD, was the manual creation of all the lines in the right places. It’s the kind of repetitive, uniform task computers were made to do.