This month I have been spending some time putting together a simple development set-up for 32bit ARM devices. Whilst not yet fully complete I am making steady progress and have begun to document the process. This is easier said than done. I set out to do the simple task of making an LED blink to test my set-up. There is a lot more to learn than what I had originally expected. The 8bit Atmega 328P was simple by comparison.
What I have discovered is a lack of resources based around my set-up & understanding. Hence why I feel the need to document it where I can. My documentation is taking shape HERE. It is likely to evolve over time but it is better to make it available as I write it in the hope it proves useful to others.
This month I have started a couple of new projects. It began as one but soon split. The primary project was to make use of a 128x64 I2C OLED display. It has been sitting on the side for a few months after an impulse purchase. It soon became apparent that I needed a way to generate static images for the screen. Although there were programs out there that would convert a bitmap image into the hex code I needed, many were for Windows. So I decided to have a go at converting it myself.
So new to my GitHub repo are: DN2015-001 – An interface for the SSD1306 OLED Display Driver DN2015-002 – A bitmap to hex converter for use wwith DN2015-001
Both projects are under development at the moment. How much they develop will depend on how my experimentation with the OLED display goes.
I ran across a case when needed to check the number of instructions/clock cycles that my C/C++ code was generating. To do this I needed to have a look at the assembly listing that was created. Reading just the assembly is tricky so adding in the C/C++ that creates it makes following it a little easier.
The instructions contained here detail the commands required to generate the debugging information and the flags for avr-objdump which allow the C++/ASM listing to be generated. Typing in all these commands takes time, hence why I am using a Makefile in the first place. What I needed was to add them to the existing ed.am Makefile.
It turns out that the easiest way to do this is not to modify the original Makefile. Instead I created a blank Makefile for my project and include the ed.am Makefile. Having done this I can overload and add to its contents.
This is what I came up with, using “make list” will generate a program listing interspersed with the source code.
# Include Arduino Makefile
# Arduino Makefile downloaded from:
# Override some of the included Makefile settings
# Add '-g' to compiler flag to embed debug info (doesn't end up in .hex)
CPPFLAGS += -g
# Locate avr-objdump on system
OBJDUMP := $(call findsoftware,avr-objdump)
# Create a listing of asm and C source code
@echo "Generating Listing"
$(OBJDUMP) -h -S $(TARGET).elf > $(TARGET).lst
# Override clean target to remove additonal files
rm -f $(OBJECTS)
rm -f $(TARGET).elf $(TARGET).hex $(ARDUINOLIB) *~
rm -rf .lib .dep
rm -f $(TARGET).map $(TARGET).lst
This image is the result of a week of pulling my hair out. It is a simple read of a register on a device connected to a micro controller over an SPI bus. The protocol was simple, the code driving it was simple, but until today it refused to work. I had checked the connections, the component values, changed some of the hardware but wasn't having much luck.
The time came to get it onto the oscilloscope. I treated myself to a Rigol DS1054Z a few months ago and it has proved its worth already. Having access to a 4 channel scope with protocol decoding has allowed me monitor the bus and find my fault. The scope revealed that the SPI MISO line was signalling the same as the SPI Clock. It turned out I had a tiny solder bridge between some header pins on a break out board, never would have thought to look there. After removing the solder bridge I now have a working SPI bus. Now time to do something with it.