I’m starting to get accustomed to using an ARM chip and wanted to do a small project. I’ve always enjoyed playing the game of Snake, but never programmed it myself. I present to you Snake on an ARM Cortex-M0 microcontroller.
I’m using the STM32 F0 Discovery board along with a Nokia 3595 cellphone screen. The hardware SPI on the ARM chip makes it pretty easy to address the display. But I’ve written the program to be display agnostic. Keep reading for more details on the programming choices I made.
Earlier in the summer I was talking to Bob Baddeley at a Sector67 meeting about my clock problems with the Binary Burst clock. I’m a little bummed out that I didn’t dig down and find the recommended application circuit for the RTC before I sent the board off for production. Bob suggested that it wasn’t a deal-breaker that I didn’t use a clock crystal with the same load capacitance, but that adding capacitors might fix the problem.
I’ve been trying off and on for years to get into ARM development. But my insistence on using FOSS for development has proven a difficult hurdle to overcome. But recently I acquire an STM32F0-Discovery board when they were offering samples. I’m proud to say I managed to get to a point where prototyping for the hardware on a Linux box is easy. I’ve written a bit about it here, and have posted a basic template (including Makefiles) in a github repository.
Above you can see my first working project. I ported it over from an AVR project, it’s the discovery board driving a Nokia 3595 LCD screen. It’s nice to have a microcontroller which is already at the 3V levels this display expects. Right now I’m addressing it via software, but I plan to migrate to hardware SPI and look into generating video. We’ll see.
One of my other near-term plans is to put up a quick post about how to use my template to compile the STM example code. I found that the image shipping on the boards is just a bit different from the source they provided in the firmware package.
I’ve been investigating the calibration register of the RTC chip I used in the Binary Burst clock. While doing so, I discovered some design considerations that I didn’t manage to consider while laying out the board.
I pulled out the Binary Burst Clock and did some more work on the firmware. The big change is that I’m using a different library for the i2c communications. The one I started with had some issues and I didn’t want to work them out myself. Instead I grabbed Peter Fleury’s i2c library. He has two in the package, one is for chips with full TWI hardware (which is not the case with the ATtiny84 I’m using). The other is a software implementation written in assembly. It’s meant to be included in C projects and is super easy to work with.
I also implemented a test to see if the RTC oscillator is running. If not, a ‘first run’ function will start the oscillator and enable the backup battery. The buttons now work for setting the time, and I’ve migrated from a delay-based time keeping tick to one that uses TIMER1 (also used for debouncing the buttons).
At this point I would say the clock is fully functional. I still want to look into some things like how best to calibrate the oscillator for the RTC. Also of interest to me is a deeper menu system that would allow for things like intensity settings and alternate time displays.
The most up to date code is on the master branch of the repository.