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.

Bus Pirate Helps

I finally used my Bus Pirate to solve a real problem. Well solve may not be right, but it helped.

I have these nearly new solar panels and charge controllers I bought in Lankawi last winter. The remote displays quit working but the batteries are still getting charged. So the problem is minor and only involves the display.

A solar panel dealer here in Puerto Princesa sells the same controllers. I took in the displays and ask him to check them on his system. They work fine. So it is the actual controller that doesn't transmit out the data. He also had a PC cable to talk to the controllers. I borrowed it and checked it out. I found the pins that it uses in the cable and hooked the bus pirate in logic analyzer mode. His cable is fine. PC is fine. I hooked the Bus Pirate to the controller and nothing!

So I used it but the controller is still broke a little. I have another battery monitor that I use really. It watches any charging device and monitors the load. So I don't need the read outs from the solar controllers anyway.

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!

Venturing into ARM Territory

Still thinking about the autopilot, I decided the Arduino was not going to make it for computing the inertial measurement unit (IMU) direction and error.

So I ordered some new stuff: 
STM32F429I-DISCO, STM32F4DISCOVERY and NUCLEO-F401RE from element14. They were not the cheapest, but they pretend to be a Malaysian company, so no problem with Customs. And they ship from Singapore so next day delivery for $2.50 US.

These are all small 32 bit ARM Cortex-m4 processors. The NUCLEO is Arduino shield compatible and the slowest at 84Mhz. The Discovery ones are the older generation, but 168Mhz. The big one has an TFT touch disply, so it cost a little more. I am hoping the NUCLEO will be fast enough since it is cheap.

I also ordered a 10DOF(degrees of freedom) IMU from a local company MyDuino.com.  It is a compact and low cost IMU from DFRobot. It integrates the ADXL345 accelerometer, the HMC5883L magnetometer, the ITG-3205 gyro and the BMP085 barometric pressure sensor on one board. They are all I2C devices and 3 axises each. So with careful combination you get a true magnetic course and the speed of deviation from that course. Just what an autopilot needs.

NUCLEO-F401RE at about $11 each at least should fun for a few days.

They are all mbed enabled with stlink built in. This means they implement a USB memory stick when plugged into a computer with USB. Programming the flash is magic. Copy the binary to the drive and if it recognizes it, it flashes the processor and removes the program from the drive.

Because it is mbed enabled you can go to mbed.org, create an account and instntly compile, download and install a number of demos. It seems easy to write programs and a reaasonable number of libraries are there.

One big gotcha though. If you have poor Internet connectivity like me on the boat, it is all done on-line. The user interface is FireFox.

I have installed the ARM tool chain to cross compile under Linux. And downloaded the ARM hardware support files from ST.com, but it is not as simple as the mbed stuff. There are other IDEs, like Arduino, but I havent fornd an open source one small enough to down load here yet.

I also have not found the mered of example and hardware driver libraries like the Arduino yet. Hopping that I just haven't looked in the right place yet.

Finished the Copy of the Sparkfun LCD Backpack Kit

Hand drilling the through holes was not too big of a problem. I did break my last bit and had to bicycle across Penang to the electronics store for more .8mm bits. It is Tonsin Components on Agile street just up from the end of Chulia. Only a couple miles.

My good pliers as a spacer to give clearance not to drill the desktop.

The screws sticking out the sides of the chuck should have been set screws, but this was less than $10 for motor, chuck and a few bits.

Looks pretty god at this stage.

I forgot to take any photos as I was soldering in the components. It was quite a challenge. I had not noticed that so many of the holes are used as vias! Most of the chip,and two of the headers have more than half their holes that way. Then I still had several shorts and non-connections to sort out. About 2 hours to solder it up and get the lights to work.

Not as pretty. It is "no clean" flux. Power, GND and Rx on the left. PGM header on right.

The top side

This is my previous incarnation of almost the same circuit. It is done up on a Radio Shack proto board. Just a little bigger and a little messyer.

More Homemade PCBs

Fail! Fail! Fail!
After numerous failures I think I may have a board I can use.I thought I had made good enough notes when I made the LEDTester board a while back, but???

This time I am trying to make the Sparkfun's Serial Enabled LCD Kit. They have posted the eagle files so I can change them if necessary. I didn't notice the trace width until after the first PCB failure.

The target, used w/o permission from Sparkfun.

I am using the presensitized positive photo resist boards with inkjet on transparencies for artwork still. And exposing in the direct sunshine which is just fine here near the equator. Kinda limits me to daytime PCB work though.

A weeks worth of failure from right to left. The left may be good.

The one on the right looked good, but I had forgotten what they looked like when finished etching. I took it out too soon and cleaned the resist off. The traces were too thin and were being eaten away anyway. After a lot of googling, I found how to increase the trace width, fix the errors this caused and get ready to try again.

The second board from right I noticed wasn't exposed enough, so I trird to re-expose it and develop it some more. Bad idea! I also got it out of the etch too quick. For each of these I had printed black grayscale from the default colors of eagle. this did not turn out to be opaque enough in the UV range to work but I blamed it on the other steps.

The second board from the left also failed. I printed it as color photo on photo paper. I also found a reference to a script(drill-aid.ulp) to run in eagle that makes all the holes smaller so it is easier to start the drill when hand drilling the holes for the parts. It draws a small circle with crosshatch in the middle of the hole to be drilled. Between it and the light color of the pads, when I printed the transparency, the pads pretty much disappeared. I etched it anyway to see for sure I could.

Top and bottom artwork taped like a hinge with tiny registration marks.

So the right answer seems to be, check the boxes for black and solid in the eagle print dialog, print photo color to photo paper even though it is a transparency. Then expose to sun 2 minutes per side covering the back side. Develop about 3 minutes in warm (not too hot, board 2) caustic soda until the extra resist washes off. Then etch in warm muriatic/peroxide till you see the board. You can take it out, rinse and check along the way.

Another view of the art and the board.

It looks better in person, I guess it is not very photogenic! HA.

Next to try to drill the holes by hand without destroying it.

Bench Variable Power Supply

I have been wishing for a bench power supply for quite some time. Part of the problem is you need one to be able to make one. So I decided to cheat and make one the easy way. It is also the proper size for my limited work area.

I still intend to make a proper one with current limiting and a few more amps, but this will  help in  the mean time.

Variable 1.5 to 30V 3 amp supply, No current limiting. Driving a drill spindle.

The local electronics parts house stocks a few of the popular Chinese modules. So I bought a box and some modules:

The layout. Amp meter requires separate supply.

The modules from top to bottom:
Digital DC Voltmeter 2.5-30V red
DC AMP METER DC 0-10A 2.5-30V
DPDT switch for input and battery on/off
LM317 based variable supply 
  Voltage Regulator AC/DC 1.25-37V max 2.2A
  overload and short protected
Banana plugs and 9v battery
not shown 19V DC old laptop supply

Links to similar:
http://www.tinydeal.com/yb27-dc-33-30v-led-digital-voltmeter-led-car-voltmeter-p-105975.html

http://www.tinydeal.com/yb27va-2-in-1-dc-0-100v-10a-led-digital-voltmeter-ammeter-p-107011.html

http://www.aliexpress.com/item/1pc-new-AC-DC-to-DC-LM317-power-Continuous-adjustable-Voltage-regulator-With-protection-free-shipping/1121236182.html

http://www.aliexpress.com/item/electric-tools12V-24V-Mini-PCB-Drill-Press-mini-saws-burnishing-chuck-Electric-drill-bits-0-6/1115717842.html

While looking for the sample link for the mini drill I saw many like I wish I had found! This one will drill holes in PCB but the runout is to big for milling and the collet is real trash. A 0.8mm drill bit fits with considerable force.

Dreaming of a CNC Something...

I decided I needed these stepper motors... It started when I saw the instructables page for
Easy-to-Build-Desk-Top-3-Axis-CNC-Milling-Machine nbsp;. I started dreaming of ways to make my own PCBs with SMD components. I am not a very patient guy when it come to hobbies and experiments, so mailing off eagle files and expecting the boards to find me on the boat just doesn't sound plausible.

I started the search for a CNC mill with a resolution for SMD parts, then I discovered the inkjet transparencies and photo-resist so there was no need for a mill.... but I keep forgetting that part.

I found the steppers in an electronics place accross on the mainland from Penang, in Butterworth, Destiny Electronics. Prices are not that good, but he has lots of stuff in stock! When I went for the photo sensitive board stock (booth single sided and double sided Kinsten- from Tiawan) I picked up a couple stepper motors too.
So this is the test setup.

Clockwise:
Stepper is a 17PM-J319 fairly popular in the surplus market but very little in the way of documentation. I believe it is a 1.8 degree, 8 volt, 6 wire bi-polar (could wire it as uni-polar I think too)
Ardunio UNO clone, davilino from Seeed Studios
L298 motor driver fresh from China
And last a LM317 based 3 amp variable power supply also fresh from China surplus
These I picked up at the parts store here in Penang so no great price there either. Places like tinydeal.com and e-bay have lots of these making me wish Paypal would ship to Malaysia. But then I'd be broke.

Inkjet and Positive Resist Photo Artwork

I just discovered that it is possible to print on transparency film with an inkjet and use photo-sensitive pre-sensitized boards for custom PCBs. This is my first try.

I begged a few scraps from the local parts store here in Penang, Malaysia. I searched all over for inkjet transparencies then discovered I have a pack (20 sheets) that are at least 5 years old already on the boat! So the only thing left is the developer. It should be about 6% sodium hydroxide, or caustic soda. After a few failed attempts to purchase it in grocery stores and pharmacies, I headed for "The Chemical Man". Sure enough he had it by the kilo. since I only wanted enough for a few trial boards he finally sold me 15 grams for RM1, about $0.32 USD!

 

The board is much better than the focus of my phone camera

A better photo with the artwork

Now to the process. I wasn't sure my new HP inkjet printed dark enough, so I printed two copied of the board. This LEDTester was the quickest board to get ready that I had. I was in a hurry to find out if it really worked. I pulled one of the glass plates from the oil lamp in the fore-peak and taped the printout down. Then taped the second copy directly over it. Next came the pre-sensitized PCB trimmed to fit so as not to waste much if it did work. I exposed it in the sun, 5:00PM a little cloudy. As a test I covered thirds at a time and exposed 1 minute each so the result was one end got 3 minutes, the middle 2 and the other end only 1 minute exposure. I could hardly tell the difference, but maybe the 2 minute was the best.

Next to the developer. I forgot to mix it ahead, so I covered the exposed board and got to mixing. Since I bought 15 grams and the suggested ratio is 6 grams in a litre of water (6% solution) I estimated a little less than one 6th of what I had and put in an old pickle jar about 700ml. I stirred and stirred! There must be NO particles or crystals of caustic soda floating around or it will disolve everything off the board they say.

OK in goes the board. 2 minutes and it was done. Looked great. I had a little muriatic acid (HCL from the grocery store in the Philippines) and hydrogen peroxide left from last year so I went for it as before. 2 parts peroxide (3%) and add one part HCL(23%). into a zip-lock baggie with the board and another 3 minutes or so I had a board!!

I re-exposed the whole board to the sun for 2 more minutes and back in the caustic soda to remove the layer protecting the traces. One wonders if it would work to print a solder mask and only remove the stuff from the pads and leave the rest of the photo resist to protect the traces?

Oh, by the way the board is a replacement for the earlier post my-first-etched-pcb-for-smd