Build Process for Firmware

If you have been following this from the beginning, I am going to talk about the build process for the firmware ROM images for the different platforms.  If you haven't been following you can find the first post here.

The build process overall should do some simple things:

1. Build the ROM images from source.
2. Clean old ROM images and build remnants out of the repository.
3. Run a static code analysis of the source that makes up the ROM images.

 I chose to start with the three most similar platforms to configure the build process.  I decided on using clicker 2 for PIC32, mikromedia for PIC32, and the chipkit Pro MX4 boards.  These three boards all utilize a PIC32MX460F512L processor and we can use the free xc32 compiler from Microchip.

I am using Linux as my development platform, specifically Linux Mint 17.1 Rebecca.  I created my project directory to isolate as much of the hardware specifics as possible from the main firmware application code.
My directory structure looks as so:

 

Build ROM images from source

The master makefile is contained in the firmware folder, and it utilizes platform specific makefiles contained in the makefiles directory.  The master makefile has targets to build a specific platform's ROM image, or all ROM images.

Here is an excerpt of the master makefile, it's quite simple.


###############################################################################
#    Target Definitions
###############################################################################
#
#    NOTE: Usage of @ prior to the command will quiet the output of the command.
#
###############################################################################

###############################################################################
#    Build the firmware image that runs on the chipKIT Pro MX4 Board
###############################################################################

mx4:
        @make -f makefiles/Make_Chipkit_Pro_Mx4.mk

           
Building the mx4 target results in output as follows.

cmartin@mega ~/source/AlphaBot/source/firmware $ make mx4
make[1]: Entering directory `/home/cmartin/source/AlphaBot/source/firmware'
[CC ] main
[CC ] board
[LNK] AlphaBot
[HEX] AlphaBot
   text     rodata       data        bss        dec        hex    filename
      0          0       1644          0       1644        66c    build/debug/chipkit_pro_mx4/AlphaBot.hex
make[1]: Leaving directory `/home/cmartin/source/AlphaBot/source/firmware'



The specifics of building code, generating ROM hex images and cleaning up the build directories are contained in each platform makefile.  This provides flexibility that will be needed in the future when the STM32 and Zynq boards are used as targets also.

The platform specific makefiles are very similar to each other since they use the same compiler and processor.  There are several issues that you can run into trying to use the xc32 compiler from the command line only.  The following makefile excerpts are used to build the object files for modules.


###############################################################################
#    Board Specific Definitions:
###############################################################################

BOARD=PRO_MX4
IMAGE_NAME=AlphaBot
PROCESSOR=32MX460F512L

###############################################################################
#    Tools:
###############################################################################

TOOL_PATH=/opt/microchip/xc32/v1.34/bin

CC=$(TOOL_PATH)/xc32-gcc
SIZE=$(TOOL_PATH)/xc32-size
HEX=$(TOOL_PATH)/xc32-bin2hex

###############################################################################
#    Compiler:
###############################################################################

PROCESSOR_FLAG=-mprocessor=$(PROCESSOR)
CC_OBJECT_CFLAGS=-g -c $(PROCESSOR_FLAG) -D$(BOARD) -MMD -MF
CC_IMAGE_CFLAGS= $(PROCESSOR_FLAG) -Wl, --defsym=__MPLAB_BUILD=1 

###############################################################################
#    Build all objects in the project.
###############################################################################

all:    main board
    @echo [LNK] $(IMAGE_NAME)
    @$(CC) $(CC_IMAGE_CFLAGS) $(BUILD_PATH)/main.o $(BUILD_PATH)/board.o -o $(BUILD_PATH)/$(IMAGE_NAME).elf
   
main:    $(SOURCE_MAIN)/main.c
    @echo [CC ] $@
    @$(CC) $(CC_OBJECT_CFLAGS) $(SOURCE_MAIN)/main.d $(SOURCE_MAIN)/main.c -o $(BUILD_PATH)/main.o

board: $(SOURCE_PATH)/board.c $(HEADER_PATH)/board.h
    @echo [CC ] $@
    @$(CC) $(CC_OBJECT_CFLAGS) $(SOURCE_PATH)/board.d $(SOURCE_PATH)/board.c -o $(BUILD_PATH)/board.o   

Cleaning the Build remnants

 

The master makefile also contains targets to clean out the build remnants.  Here is the excerpt that accomplishes that goal.
 
###############################################################################
#    Clean all firmware image trees
###############################################################################

.PHONY: clean
clean:
        @make -f makefiles/Make_Chipkit_Pro_Mx4.mk clean
        @make -f makefiles/Make_Clicker2_Pic32mx.mk clean
        @make -f makefiles/Make_Mikromedia_Pic32.mk clean
       
###############################################################################

As before, each platform specific makefile is responsible for cleaning it's build remnants up after a build.  The platform files are all very similar as I said before, so I will include an excerpt from the mx4 file. 

###############################################################################
#    Clean the firmware image tree
###############################################################################

.PHONY: clean
clean:
    @rm -rf $(BUILD_PATH)/*.o
    @rm -rf $(BUILD_PATH)/*.hex
    @rm -rf $(BUILD_PATH)/*.elf
    @rm -rf $(SOURCE_MAIN)/*.d
    @rm -rf $(SOURCE_MAIN)/*.o
    @rm -rf $(SOURCE_PATH)/*.d   
           
###############################################################################

Static code Analysis 

 

I chose to use two utilities to do static code analysis on the firmware code base.
The first utility is called splint, it is a free version similar to the lint that was included in Unix installations.  I was able to use apt-get to install this and use the documentation to configure this to work for my project.

The second utility I chose is cppcheck, which I had some difficulties getting to work.  I tried to specify some include directories during the check of the code and cppcheck couldn't find the xc32 includes. The problem that I ran into had been fixed in newer version of the utility, however Linux Mint installed 1.61 by default.  I was able to fix my issues by retrieving the latest code for cppcheck ( version 1.68 ) and building it from the source.  After that I had no issues running the utility.

The makefile excerpts for this are shown below.

###############################################################################
#    Static Code Analysis of all source trees
###############################################################################
.PHONY: check
check:   
    @echo
    @echo [SPLINT  ]
    @splint -strict -noparams -exporttype -typeuse -nolib \
        -I/opt/microchip/xc32/v1.34/pic32mx/include/ -Iinclude/ source/*.c
    @echo
    @echo [CPPCHECK]
    @../tools/cppcheck-1.68/cppcheck --template '{file}:{line}, {severity}, {id}, {message}' \
                --force --enable=all -q -I/opt/microchip/xc32/v1.34/pic32mx/include/ -Iinclude/ .

I am sure there will be adjustments as I find issues and continue to build upon this code base.  I hope this was helpful in some way or another.

Start of AlphaBot project.

I have started a new project, one that involves working with robot platforms.

I have acquired a few neat little robot platforms from some really great companies.  I chose these robot platforms because they allow me to work with modular designs that can share some  hardware and firmware.

First, I ordered the Buggy from MikroElectronika.  I haven't really talked about this company or their products, however I love their stuff.  Their products are very well built, documented and they provide examples.  I actually have quite a few of their products, and I can use almost all of the devices I purchased from them with this robot platform.  Eventually I hope use all of the following with this project:

• clicker 2 for PIC32MX
• clicker 2 for STM32
• mikromedia for PIC24
• mikromedia for dsPIC33EP
• mikromedia for PIC32

MikroElectronika also has a very interesting plug and play system called mikroBUS.
This allows me to use various sub modules called Click Boards, 
these boards are great. I can write firmware code and prototype my system without designing and building the hardware first.  I have a few of the click boards, specifically the BLE P click and the nRF C Click that I wish to use with this project.
 
Second, I ordered the MRK Basic and MRK+Line robot kits from DIGILENT.  These robot platforms can't reuse the devices from MikroElectronika without building custom hardware adapters.  However, they have sub modules called pmods I can use with their chipKIT board as well as their ZYBO board.

This project will be quite challenging and enjoyable.  I plan to keep this blog updated as I work on it.

Research and Notes

I have found a great way to keep hierarchical notes and sync them between machines ( even with different operating systems ).
I have recently started using KeepNote, the note taking and organization application to record my notes.  I am using mercurial and BitBucket to keep my notes versioned and synced between multiple computers.
There is only one issue that I have had so far, and that is the indexing database.  If you want to use a source control to version and sync your notes, make sure you add the index database to the ignore file.
And as always a screenshot of KeepNote with some notes.

UltraEdit, UltraCompare, Tortoisehg and Linux

I recently purchased the UltraEdit / UltraCompare bundle from IDM Computer Solutions, Inc.  After some difficulty getting mercurial & tortoisehg  to play nice with UltraEdit and UltraCompare, I decided to make a post on how to accomplish this.

I created a bin directory under my home directory and extracted the UltraEdit and UltraCompare tarballs there.

mkdir /home/cmartin/bin

tar zxvf UltraEdit.tar.gz

tar zxvf UltraCompare.tar.gz

Next, I made soft links to the actual executables in the ~/bin directory as shown below:

ln -s /home/cmartin/bin/ucx/bin/ucx /home/cmartin/bin/ucx.app

ln -s /home/cmartin/bin/uex/bin/uex /home/cmartin/bin/uex.app

Once these tasks were completed, I edited my .hgrc file to match the contents below:

[ui]
editor = /home/cmartin/bin/uex.app
merge = UltraCompare

[extdiff]
cmd.UltraCompare = /home/cmartin/bin/ucx.app
cmd.args = -i -B -b -lt -t $local $other

[tortoisehg]
vdiff = UltraCompare
ui.language = en

[merge-tools]
UltraCompare.executable = /home/cmartin/bin/ucx.app
UltraCompare.args = -i -B -b -lt -t $local $other
UltraCompare.priority = 1
UltraCompare.gui = True
UltraCompare.binary = True
UltraCompare.checkconflicts = True
UltraCompare.checkchanged = True

Now tortoisehg is integrated and working with UltraEdit and UltraCompare.

Logic Analyzer and Oscilloscope software

I ordered a Logic Port from PC Test Instruments and it arrived today.  Here is a screenshot of a PWM signal on both my Rigol Oscilloscope and the Logic Port.  

MSP430 Debugging with open source tools

I recently switched to using open source tools to work on the msp430 micro controller architecture.  The previous post included a few pictures of the in-circuit programming / debugging adapter I constructed.  In this post I will talk a little bit about using Data Display Debugger on Linux to debug micro controller code.  The screen shot below is an active debug session using the data display debugger.

Data Display Debugger debugging firmware code.

If you aren't quite familiar with the tool set, please investigate the following links.

• msp430-gcc
• mspdebug
• ddd

 During the normal process of working with this micro controller one will use their favorite editor and either the msp430-gcc distribution tools directly or through a makefile to build the elf binary which is loaded to the micro controller.
A typical session looks as such:

mspdebug session connected to fet debugger

In order to debug using the msp430-gdb debugger from the command line, you need to start the gdb client within the mspdebug application.  The below screen shot shows this.

mspdebug hosting gdb client

Once the gdb client has been started, we can connect with the msp430-gdb debugger instance by using msp430-gdb binary-name.elf, as you see in the screen shot my application is Potentiometer.elf.  After the gdb console session starts up, you must type into the command session target remote localhost:2000 as that is the port that mspdebug's gdb client is running on . A console based session is shown below.

msp430-gdb being used in console mode

This is usable and quite fast, however it isn't very intuitive.  Many developers would prefer to use a GUI debugger interface.  The way to do that with these tools is to start the data display debugger from the command line in the following manner: ddd --debugger msp430-gdb binary-name.elf.

Aside from these steps, there is a way to just start the gdb client from the command line in one command as well: mspdebug rf2500 gdb 2000 .

Hopefully, this helps to make working with the debugger for msp430 micro controllers a little easier.

I started working with micro-controllers recently and needed an easy way to debug code in-circuit.

So I built an in-circuit adapter that allows me to use the Launch Pad's MSP430 fet Debugger while the micro-controller is setup in a breadboard.