Using GitHub with GCC4MBED

I too have had a learning curve with git. It is the "hot new revision manager of the day". Mbed.com uses a version of it. The gcc4mbed is at GitHub.com so it seems the thing to do.

To start you git clone the software of interest. This makes a directory named after the repository in the current directory and downloads all the code from the repo there. Now you have  local copy to use/modify/enhance or whatever. So it is sort of sub-directory based.

gcc4mbed is written such that you use one of its sub-directories, gcc4mbed/samples/<proj-name>/ as the source of your project. If you want to contribute your enhancements back to the original author, there are commands to do that. However, they take the entire repo directory and process it. It is possible to configure your way around this, but then using the versioning system for your code gets cumbersome.

Therefore; I made a project directory tree for my stuff that separates it out of GCC4MBED's tree structure. This should make it easy to manage individual subsets of projects for revision management. This makes it much easier to use minute by minute during development, so less time is wasted trying to remember recent changes. It also allows a  complete removal and re-write of the GCC4MBED without affecting my projects.

gcc4mbed/
├── build/
├── external/
├── mri/
├── samples/
├── src/
Projects/
├── App_test
│   ├── ADXL345
│   └── IMU_cal
├── build -> ../gcc4mbed/build/
├── DISCO_F407VG-device.mk
├── external -> ../gcc4mbed/external/
├── Funct_test
│   ├── ADXL345 -> ../../FreeIMU/ADXL345
│   ├── FPU_mathTest
│   ├── I2C_NVIC
│   ├── MB_i2c_IT
│   ├── rtos_basic
│   ├── rtos_mutex
│   ├── rtos_signals
│   └── Ticker
├── mri -> ../gcc4mbed/mri
├── Project
│   └── IMU10DOF
└── src -> ../gcc4mbed/src/

The symbolic links line up with the directories that the makefiles expect so they compile OK, but keep my stuff separate. I use the Project, App_test and Funct_test directories to further divide the namespace.

More STM32 MBED Development Environment

For 2 months I have been switching back and forth between using mbed.com online, eclipse with gcc4mbed, gcc4mbed with geany and just gcc4mbed in a terminal with the makefile and vi.

Mbed on-line is expensive and very slow. I have had access as long as the cell company keeps the towers working, but not always. Also, mbed.com does not support the DISCOVERY boards on-line. The code is there, but I can't select a non-'mbed platform' for the compiler when i start a new program. When the internet access is fast, it is easy to exercise demo code there.

I really should give the eclipse CDT another shot. While I was trying simple programs in single files, it seemed OK. But when I got a little more comlplex it seemed to get unstable and not repeatable. Everything would be fine one day,then the next it could no longer find the libraries to compile the last copy of the file from the day before. I was having a lot of issues then and some may have been self induced.

Anyway I learned how to get the gcc4mbed setup to work directly. It did not support any of the STM32 boards at first though. I managed to modify the main makefile for the NUCLEOF401RE board (as in this post). Then every thing was fine for a while.

Until I decided to try the RTOS real-time extensions. Then it became obvious that I missed something in the special board-device-mk makefile. About the same time, the author of gcc4mbed decided to update it to the newer rev. 92 of the mbed source. He asked me to rerun some of the tests on my boards to verify his changes.

Everything stopped working. A coupe weeks of reading forums and Google searches, I made some changes, verified lots of code and thought it was ready again. After submitting them, It turns out I missed one more, but I think we have it fixed now.

# Vendor/device for which the library should be built.
MBED_DEVICE        := NUCLEO_F401RE
MBED_TARGET        := STM_NUCLEO_F401RE
MBED_CLEAN         := $(MBED_DEVICE)-MBED-clean

# Compiler flags which are specifc to this device.
TARGETS_FOR_DEVICE := TARGET_NUCLEO_F401RE TARGET_M4 TARGET_CORTEX_M TARGET_STM 
TARGET_STM32F4 TARGET_STM32F401RE
TARGETS_FOR_DEVICE += TARGET_FF_ARDUINO TARGET_FF_MORPHO
GCC_DEFINES := $(patsubst %,-D%,$(TARGETS_FOR_DEVICE))
GCC_DEFINES += -D__CORTEX_M4 -DARM_MATH_CM4 -D__FPU_PRESENT=1

C_FLAGS   := -mcpu=cortex-m4 -mthumb -mthumb-interwork -mfpu=fpv4-sp-d16 -mfloat
-abi=softfp
ASM_FLAGS := -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
LD_FLAGS  := -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp


# Extra platform specific object files to link into file binary.
DEVICE_OBJECTS :=


# Linker script to be used.  Indicates what code should be placed where in memor
y.
LSCRIPT=$(GCC4MBED_DIR)/external/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TA
RGET_STM32F4/TARGET_NUCLEO_F401RE/TOOLCHAIN_GCC_ARM/NUCLEO_F401RE.ld


include $(GCC4MBED_DIR)/build/device-common.mk

Turns out the options for the floating point hardware, needed by the RTOS, needed to be applied constantly to each of the _FLAGS lines. If not, the linker would link a mixed set of libraries and the resulting code would hang in various places.

 So I now have a setup that at least is reliable.  I am using geany, a text editor using the GTK2 toolkit with basic features of an integrated development environment, with the special makefiles from gcc4mbed.

Saga of Off-Line compiling with the STM32 NUCLEO-F401RE

Of the 3 boards, I decided to attempt the NUCLEO-F401RE first. For a program I chose to try to implement a smart autopilot control head using the 10DOF inertial sensor.

Of course nothing is ever simple. First I used the online compiler at mbed.org It would be fine if not for paying for internet access by the byte! Not to mention that it goes off completely for a while several times a week. Usually when I am in the middle of something.

So I began searching for ways to develop, compile and download the code locally on my own machine. There are several web pages describing various commercial and open source IDEs (Integrated Development Environments) all of which are either too limited, don't support the ST micros or only run on Windows! We all know I don't do Windows!

First I tried using the STM32CubeF4 and STM32F4-Discovery_FW_V1.1.0 from st.com according to http://regalis.com.pl/en/arm-cortex-stm32-gnulinux

I didn't have much luck with anything but the blinky Helloworld program. So on with more. I found https://github.com/mbedmicro/mbed a version of the mbed libraries to use locally. After several days I decided I missed something in the fine print.

So I tried gcc4mbed both stand alone and inside of eclipse, which I also downloaded. No luck for several weeks. I went back to th eonline and suffered  some more.

Decided to try off-line one more time when I ran across this instruction page  It worked! Well, almost. The compiler and linker can't find all the mbed libraries in Debug mode. But they can in Checked mode, which still includes the debug code! Great, I am now standalone!!!

So I have 4 different installed copies of gcc for ARM, 5 libraries of code for the STM32-arm micros,  2 manual/Makefile setups with no working makefile except delivered demos and 2 IDEs.

Also I have several utility programs that I'm not sure about, openocd to download and manage a debug session over USB to the micro, stlink to reinstall firmware in the STM32 micros and mri to actively debug the micro over the USB and single step the code. Also have a couple terminal emulators for monitoring output from the print statements in the micro. And 4 workspaces with various non-working pieces of code... I should clean them up.

Summary:

1. follow instructions at http://developer.mbed.org/cookbook/eclipse-for-building-and-debugging
2. Next: https://github.com/adamgreen/gcc4mbed/blob/master/notes/porting.creole#readme
3. then from mbed.org convert the mbed include to a library
4. export the project for Nucleo target and GCC (ARM embedded) as the IDE
5.  I had to make a ../build/NUCLEO_F401RE-device.mk
   and samples/NucIMU_test/makefile is more than just the name change
   the first make compiled all of mbed for NUCLEO.   I copied parts out of the exported Makefile to find the answers for both the device.mk and the project makefile.

Here is the device makefile
NUCLEO_F401RE-device.mk

# Vendor/device for which the library should be built.
MBED_DEVICE        := NUCLEO_F401RE
MBED_TARGET        := NUCLEO_F4XX
MBED_CLEAN         := $(MBED_DEVICE)-MBED-clean

# Some libraries (mbed and rtos) have device specific source folders.
HAL_TARGET_SRC   := $(MBED_SRC_ROOT)/targets/hal/TARGET_STM/TARGET_NUCLEO_F401RE
HAL_TARGET_SRC   += $(MBED_SRC_ROOT)/targets/hal/TARGET_STM/TARGET_NUCLEO_F401RE/TARGET_MBED_NUCLEO_F401RE
CMSIS_TARGET_SRC := $(MBED_SRC_ROOT)/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE
CMSIS_TARGET_SRC += $(MBED_SRC_ROOT)/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/TOOLCHAIN_GCC_ARM
RTX_TARGET_SRC   := $(GCC4MBED_DIR)/external/mbed/libraries/rtos/rtx/TARGET_M4/TOOLCHAIN_GCC
ETH_TARGET_SRC   := $(GCC4MBED_DIR)/external/mbed/libraries/net/eth/lwip-eth/arch/TARGET_STM


# Compiler flags which are specifc to this device.
GCC_DEFINES := -DTARGET_NUCLEO_F401RE -DTARGET_M4 -DTARGET_STM -DTARGET_NUCLEO_F401RE -DTARGET_MBED_NUCLEO_F401RE
GCC_DEFINES += -D__CORTEX_M4 -DARM_MATH_CM4 -D__FPU_PRESENT=1 -DTARGET_FF_ARDUINO -DTARGET_FF_MORPHO

C_FLAGS   := -mcpu=cortex-m4 -mthumb -mthumb-interwork
ASM_FLAGS := -mcpu=cortex-m4 -mthumb
LD_FLAGS  := -mcpu=cortex-m4 -mthumb


# Linker script to be used.  Indicates what code should be placed where in memory.
LSCRIPT=$(GCC4MBED_DIR)/external/mbed/libraries/mbed/targets/cmsis/TARGET_STM/TARGET_NUCLEO_F401RE/TOOLCHAIN_GCC_ARM/NUCLEO_F401RE.ld

include $(GCC4MBED_DIR)/build/device-common.mk

*** UPDATE * Jan 25, 2015 **** The above makefile has problems with the single precision floating point hardware. Correct the *_FLAGS to this:

C_FLAGS   := -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mthumb-interwork
ASM_FLAGS := -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
LD_FLAGS  := -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp

And the project
makefile:

PROJECT         := NucIMU_test
DEVICES         := NUCLEO_F401RE
GCC4MBED_DIR    := ../..

#NO_FLOAT_SCANF  := 0
#NO_FLOAT_PRINTF := 0

OBJECTS = ./main.o ./ADXL345/ADXL345.o ./HMC5883L/HMC5883L.o ./TextLCD/TextLCD.o ./ITG3200/ITG3200.o 
INCLUDE_PATHS = -I. -I./ADXL345 -I./HMC5883L -I./TextLCD -I./mbed -I./mbed/TARGET_NUCLEO_F401RE -I./mbed/TARGET_NUCLEO_F401RE/TARGET_STM -I./mbed/TARGET_NUCLEO_F401RE/TARGET_STM/TARGET_NUCLEO_F401RE -I./ITG3200 
include $(GCC4MBED_DIR)/build/gcc4mbed.mk

Now if only the code got the right answer!