Larry, I am happy to hear that it worked for you.

I am in the process of preparing a new release of GCC4MBED. I will add your NUCLEO-F401RE-device.mk file into the mix. Please feel free to send me any more targets that you add. You can just point me to the -device.mk files or issue a pull request on github. I can only test that they build during my new release testing since I don't have the boards themselves but that's better than 0 support :)

Thanks,

Adam

Larry, I just committed your changes to the working branch of GCC4MBED and will merge into master once I finish my testing on the other platforms.

Thanks again,

Adam

Hi Adam, thanks for all the work you are putting into offline compiling!!!

I am an ARM noob, and have spent last 15+ years mainly with Microchip PIC related projects. Slowly learning about ARM. Currently we are developing 3 new ARM related boards, and want to add them to mbed (F401, F030 & L151). I am having trouble getting the L151 project to compile offline: http://developer.mbed.org/questions/5252/Errors-building-STM32L152RE-mbed-project/

This brings me to my question. Up till now, I have used the EmBlocks and CoIDE export functions to export the project, and than build them offline with GNU GCC (via EmBlocks & CoIDE). I am not sure where GCC4MBED comes in? Does it provide optimized code generation? How is using GCC4MBED different from how I am currently doing it? I realize the IDE is different, and you use Eclipse with GCC4MBED. But, is there any difference in the compilation process and result? Sorry for noob question!!!

Hello David,

That is a good question! If the export option works for you, then I recommend that you should continue to use it. GCC4MBED was created before there was any official offline support from the mbed team.

Why have I continued to maintain it after the mbed team has added offline export and fully open sourced the SDK? Mostly because I still find it useful for my own projects:

• Many of my projects start offline with GCC and never see the online compiler. I find the GCC4MBED makefiles easier to use for creating a new project. I just need to create a short makefile for my new project and then use an include directive to pull in the existing GCC4MBED makefiles containing all of my tweaks from the last couple of years.
• I want to build the mbed SDK as it is needed when I build my code. If I make a fix in the SDK and build my project, GCC4MBED takes care of rebuilding just what is necessary for me to test out those changes. I don't have to build some parts with Python and then others with make.
• I don't want to take Python as a dependency for building my C/C++ open source projects.
• I still primarily use the LPC1768 based mbed board in my projects and I prefer to use my MRI debug monitor rather than the CMSIS-DAP solution for debugging the 1768. GCC4MBED has MRI support tightly integrated.
• I am used to the GCC4MBED workflow and I don't want to change :)

I hope that helps,

Adam

Hi Adam

Thanks for detailed reply! Since I only started using mbed a short while ago, I never knew they didn't have export, or open source.

- When did they make it open source? Have you noticed mbed increase in popularity lately, maybe since they open sourced it? I want to use mbed for our new products, and will be nice if it doesn't fade away over the years! There are so many other APIs! But, seems to me like they are gaining popularity, and many manufacturers have just recently added hardware to the supported platforms.

- Also, do you know if your GCC4MBED will create smaller binary files? I think I read somewhere that there are also micro libraries or something like that you can use with the GNU compiler to create smaller executable?

- It seems like quite a process involved getting mbed to compile using eclipse. I am currently using EmBlocks and CoIDE. But, eclipse has many more features. I started installing "GNU ARM Eclipse Plug-ins" - not done yet, quite a bit involved. Do your GCC4MBED scrips take care of some of that, and reduce the work required to get Eclipse to compile exported mbed projects.

I think it was open sourced in February of 2013. I see lots of more people here on the mbed site and many more platforms have been added since. Back then there was just the LPC1768, LPC11U24, and KL25Z. It's open source so it's not like the code will just disappear, even if mbed itself did. BUT its blasphemous to even talk like that :)

They should be similar in size. We both use newib-nano to keep the size down. The Keil compiler output still seems to be smaller most of the time but the difference isn't anywhere as bad as it was when we started using GCC with mbed.

I agree. I don't actually use Eclipse much myself. I also haven't found an easy way to set it up.

How do you like Em::Blocks? I plan to give it a try once I free up some time.

-Adam

A new version of GCC4MBED is available on github at https://github.com/adamgreen/gcc4mbed#quick-start

New features include:

• Upgraded mbed SDK from revision 88 to revision 91.
• Added https://github.com/adamgreen/gcc4mbed/blob/master/notes/new_devices.creole#adding-new-devices-to-gcc4mbed to document the process of hooking new devices, that are already supported by the mbed SDK, into GCC4MBED.
• Debug builds now use the new -Og optimization flag.
  • This is an experimental addition that I may remove in the future.
  • I see that it still occasionally optimizes away some local variables.
  • It has also failed to place a breakpoint where I expected.
• Added support for NRF51822 and NUCLEO_F401RE devices.
  • NUCLEO_F401RE support was added by Larry Littlefield
  • The NRF51822 support is still a work in progress:
    • Can't use the drag and drop programming feature with the resulting .hex file to program the device. There are some ihex records used by the GNU linker that aren't supported in the CMSIS-DAP firmware.
    • The linker displays Conflicting CPU architectures 12/0 errors but treats them as warnings and still produces the correct output.
    • Users that are already familiar with using pyOCD to program and debug their mbed devices can use the same method for NRF51822 targets using the .elf files generated by GCC4MBED.
    • The .elf files generated for the NRF51822 targets contain both the SoftDevice and the user's application.

Hi Adam, Thanks for giving me credit for the NUCLEO addition. It wasn't that much. I noticed you did not include the change to gcc4mbed.mk line 332:

deploy $(DEVICES)-deploy  

Was it over looked or not compatible with multiple devices?

I am forking and re-downloading the latest copy. I'll let you know if I find anything unusual. Then I should be able to give a pull request in the future, if any.

-Larry

Larry,

Thanks again for the contribution and testing.

Yes, the 'deploy' rule is meant to be equivalent to LPC1768-deploy to be backwards compatible with the original versions of GCC4MBED which only supported that single platform. If an application has multiple entries in $(DEVICES) then your change would map deploy to set of dependents that doesn't match what you want.

For your projects, you should be able to add a rule like the following to the end of your project's specific makefile, after the include for gcc4mbed.mk.

dep : NUCLEO_F401RE-deploy

-Adam

I am sorry Adam but I can't get this to work. I tried all the combinations I could think of in the project makefile, the NUCLEO-F401RE_device.mk and the gcc4mbed.mk. the only way it will actually deploy is if I comment out your rule or modify it in gcc4mbed.mk and then put a rule in the project makefile.

If it was a variable then it would be over written in the succeeding parsing process, but rules do not supersede that way, at least in GNUmake, which is what I have in ubuntu linux. The GNUmake manual says it is illegal to have more than one rule with the identical left side.

Any more suggestions?

And the build and deploy work fine with the release of gcc4mbed.

It is a shame that mbed decided to use such a long name for the NUCLEO boards. It makes the lines so long. Unix is of, and by and for the people who cannot type!

-Larry

Hello Larry,

1. The less typing the better.
2. Can't have multiple make rules with same output.

Those are the two reasons that in my example I called the custom project deploy rule dep instead of deploy :)

dep : NUCLEO_F401RE-deploy

-Adam

Thanks again! And here I thought it was your typo! Ha. Over thinking it. Works fine!

I will continue testing the F401 with more libs over time.

-Larry

Adam, others,

Has anyone looked at or used Visual gdb? I have and use Visual Studio, and this project integrates gcc compiler and debugger into that world.

thanks, Dave Smart

David, "Visual gdb" looks pretty cool but I don't use Windows as my primary development environment. If you or others do happen to try it, I would love to know how it works out for you.

-Adam

A new version of GCC4MBED is available on github at https://github.com/adamgreen/gcc4mbed#quick-start

New features include:

• Upgraded mbed SDK from revision 91 to revision 92.
  • There are some timer related fixes in revision 92 that I wanted to pickup.
• Reverted Debug builds back to using the -O0 optimization flag.
  • The debug experience of -Og was very similar to -O2 so it was of little benefit.
• Temporarily disabled the NUCLEO_F401RE device support which was just added in the last update.
  • Something in this release of GCC4MBED has broken this STM platform. We hope to re-enable it in the near future.

Update : Some of my issues were answered a bit deeper in, as I was reviewing under "More Information".

Hi Adam - great work on the offline tools.

Some small suggestions that may help other users.

1. At the point in the instruction "Decompress and extract the contents of this archive", I would suggest that you insert another step or two. Many "installers" just need to unzip to a temporary place, so with my recent run at this, that's what I did. But at the end of the install, it was clear that I just placed them in a "final" location - (in a "temp" folder)
2. Add a note related to uninstalling, or upgrading. Are there any special concerns? For example, do I simply destroy this folder, or has it modified the system path (or registry in Windows)? Following the "BuildShell.cmd" file, it appears that the system path is configured through the buildenv.cmd file, yet a small confirmation that these tools are "self-contained" would be helpful.

Recommendation:

• Create a folder/directory where you want to host these tools for execution (e.g. Windows: c:\gcc4mbed, ...)
• Decompress and extract the contents of this archive to that folder, such that this folder has in its root the contents of "adamgreen-gcc4mbed-..." (build,external,mri,etc.).
• Run the install script appropriate for your platform ...
• You can then run the BuildShell script which will be created during the install to properly configure the PATH environment variable for this installation location.

Hello David,

Thanks for the feedback! I have updated some of the gcc4mbed notes to make the file placement clearer to the user.

https://github.com/adamgreen/gcc4mbed/tree/working#quick-start
https://github.com/adamgreen/gcc4mbed/blob/working/notes/install.creole#uninstall

I was working on other related projects and delayed making these updates until I was preparing to update to a newer build of the mbed SDK (revision 93).

Thanks,

Adam

Hello Adam,

Back to dev after many years...

I'm in the process to setup an Ubuntu 12.04 (Linux Fr-pr-DellE6510 3.2.0-77-generic-pae #112-Ubuntu SMP Tue Feb 10 15:41:09 UTC 2015 i686 i686 i386 GNU/Linux) machine. I just finished upgrading Eclipse after many browser tabs opened and I'm quiet done.

Following the Quick Start, I noticed that I might need ia32-libs library ! Honestly I'm not sure it's actually required for 32 bit arch... But if it is, then it doesn't sound like an easy task under this distro. Now few browser tabs later I coming back here to say, that's not going to be as simple as guessed in the Quick Start in the Ubuntu case.

Q1) Do we need ia32-libs for Ubuntu 12.04 (32 bits) ?

Also and this is even more scary to me, when creating the project under Eclipse. You mentioned "Even though we are using the GNU ARM toolchain, we will select the Sourcery G++ Lite one because it uses the tool names which most closely match what we desire." and for my precise case is supposed to be the ARM Linux GCC (Sourcery G++ Lite). I do not have this option available under my preferred IDE today... Few browser tabs later this all go to Mr. Mentor Graphic and I'm a strong believer to the open source, therefore here is my second question:

Q2) Do we need to install ARM Linux GCC (Sourcery G++ Lite) to get this working under Eclipse?

This is just for information. I do not plan using web hosted developments tools currently offered, this might explain why I'm posting here.

Many thanks in anticipation for your answers.

Regards,

JL

A new version of GCC4MBED is available on github at https://github.com/adamgreen/gcc4mbed#quick-start

New features include:

• Upgraded GNU tools to GCC ARM Embedded 4.9-2014-q4-major.
• Upgraded mbed SDK from revision 92 to revision 94.
• Re-enabled NUCLEO_F401RE device support.
• Added support for NUCLEO_F411RE, DISCO_F407VG, and LPC4330_M4.
  • NUCLEO_F411RE support was added by weyoui
  • DISCO_F407VG support was added by Larry Littlefield
  • The LPC4330_M4 support is still a work in progress:
    • Has been tested on Micromint's Bambino 210 board.
    • This platform also contains beta level support for the MRI debug monitor as well.

If you are running a 32-bit version of Ubuntu then you don't need to install ia32-libs.

No, the GCC4MBED install steps take care of installing the GNU Tools for ARM Embedded and don't require Mentor Graphic's Code Sourcery.

I don't use Eclipse so I am not certain how it should be configured to work with more recent builds.

Many thanks Adam for your prompt answers,

I figured out how I may deal with this after all and also tried an alternative method based on GNU ARM Eclipse plug-ins which also delivered has expected. But I'd rather pursue with the mbed off-line way.

I will continue to poll this thread ;-) which I'm definitely interested in.

BTW: Another thanks for this new release which actually coincide perfectly in time with my plug-in way with GCC ARM Embedded 4.9-2014-q4-major. I'm upgrading gcc4mbed right now !

Have a cool 1/2 weekend.

Rgds, JL

Hello everyone

Here is my attempt at a NUCLEO_F103RB-device.mk file:

#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

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


# Compiler flags which are specifc to this device.
TARGETS_FOR_DEVICE := TARGET_NUCLEO_F103RB TARGET_M3 TARGET_CORTEX_M TARGET_STM TARGET_STM32F1 TARGET_STM32F103RB
TARGETS_FOR_DEVICE += TARGET_FF_ARDUINO TARGET_FF_MORPHO
GCC_DEFINES := $(patsubst %,-D%,$(TARGETS_FOR_DEVICE))
GCC_DEFINES += -D__CORTEX_M3 -DARM_MATH_CM3 -D__FPU_PRESENT=0

C_FLAGS   := -mcpu=cortex-m3 -mthumb -mfpu=vfp -msoft-float -mthumb-interwork
ASM_FLAGS := -mcpu=cortex-m3 -mthumb -mfpu=vfp -msoft-float
LD_FLAGS  := -mcpu=cortex-m3 -mthumb -mfpu=vfp -msoft-float


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


# Version of MRI library to use for this device.
DEVICE_MRI_LIB :=


# 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_F103RB/TOOLCHAIN_GCC_ARM/STM32F10X.ld

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

I do not own such a board, but I decided to give it a go, since I wanted to use the mbed code on a generic (eBay) STM32F103 based board. I was able to get it to compile and upload the resulting .hex file to the board using stm32flash, and so far it is working

A new version of GCC4MBED is available on github at https://github.com/adamgreen/gcc4mbed#quick-start

New features include:

• Upgraded GNU tools to GCC ARM Embedded 4.9-2015-q1-update.
• Upgraded mbed SDK from revision 94 to revision 100.
• LPC11C24 support was added by merkur2k
• NUCLEO_F072RB support was added by Mathew Chasan Calmer
• Other patches from the community. Thanks!
  • Fixed name of linker script for STM32F407VG from zmoshansky
  • Makefile: remove trailing slash if provided by user to avoid breaking rules matching from Clément Léger
  • Makefile: add a way to exclude specific files with EXCLUDE from Clément Léger

Hi

I'm an mbed newbie, and I'm trying to get offline compilation going.

I've tried the SDK ( https://github.com/mbedmicro/mbed ), with all the python scripts, but that doesn't have a way of adding non-core libraries (does it?). I presume that's just for people developing mbed, not using it?

I've tried exporting from the online or the SDK, but that gives you just one target and one 'test' program - I want at least three targets and a dozen different test and real programs.

Plus the export of BLE_iBeacon from online doesn't actually work built locally - it once complained the stack and heap were fighting each other, but just now I tried it and it built, but it did nothing at all on the board. The compiled hex download works fine.

So how do command-liners like myself do this in mbed?

Cheers! Duncan

I just want to make sure that GCC is the toolchain that you are attempting to use offline from the command line.

They are useful to build the mbed libraries yourself using an offline compiler. You can however get pre-built versions by exporting a project for your offline compiler of choice from the online compiler. If you don't want to create a custom build of the mbed SDK then the exported libraries should be good enough. GCC4MBED builds the mbed libraries as needed using its set of custom makefiles and not via the Python build scripts.

The current version of GCC4MBED supports multiple targets when building with GCC. You can find more information about that here and see an example in the HelloWorld sample makefile. The current version doesn't support the building of libraries that are then shared across multiple projects but that support will come with the next release. An example of the use of that new USER_LIBS feature can be seen here. That feature should make it into the master branch soon.

I have built and used that sample in the past but not recently. I will give it a try during my next test pass to see if I can reproduce your problem.

-Adam

As Adam advertised his makefile, I'll do mine :-D There's a simple makefile for mbed - https://github.com/0xc0170/mbed_gcc_makefile , you can customize it for your needs, add more folders, libraries.

There's also cmake , compatible with BLE, you can find it here on mbed.

And one more, project generator which enables you exporting to various tools, use modules, find an example here https://github.com/project-generator/project_generator_mbed_examples

Here's an elided compile sample:

arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -c -g -fno-common -fmessage-length=0 -Wall -Wextra -fno-exceptions -ffunction-sections -fdata-sections -fomit-frame-pointer -MMD -MP -DNDEBUG -Os -DCORTEX_M0 -DNRF51 -DTARGET_FF_ARDUINO -DTARGET_MCU_NRF51_16K -DTOOLCHAIN_GCC -DTARGET_MCU_NRF51822 -DMBED_BUILD_TIMESTAMP=1443646133.16 -DTARGET_CORTEX_M -DTARGET_ARCH_BLE -DTARGET_NRF51822 -DARM_MATH_CM0 -DMBED=1 -DTOOLCHAIN_GCC_ARM -DTARGET_NORDIC -DTARGET_MCU_NRF51 -DTARGET_MCU_NORDIC_16K -DTARGET_M0 -DTARGET_MCU_NRF51_16K_S130 -std=gnu99 -I. -I./nRF51822 -I./nRF51822/bootloader -I./nRF51822/source -I./nRF51822/source/common -I./nRF51822/source/nordic-sdk .. -I./nRF51822/source/nordic-sdk/components/ble/device_manager/config -I./nRF51822/source/btle -I./nRF51822/source/btle/custom -I./mbed -I./mbed/TARGET_ARCH_BLE -I./mbed/TARGET_ARCH_BLE/TOOLCHAIN_GCC_ARM -I./mbed/TARGET_ARCH_BLE/TARGET_NORDIC -I./mbed/TARGET_ARCH_BLE/TARGET_NORDIC/TARGET_MCU_NRF51822 -I./mbed/TARGET_ARCH_BLE/TARGET_NORDIC/TARGET_MCU_NRF51822/TARGET_ARCH_BLE -I./mbed/TARGET_ARCH_BLE/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib -I./mbed/TARGET_ARCH_BLE/TARGET_NORDIC/TARGET_MCU_NRF51822/Lib/nordic_sdk/components/libraries/crc16 -I./BLE_API -I./BLE_API/ble -I./BLE_API/ble/services -I./BLE_API/source -I./BLE_API/source/services -o nRF51822/source/nordic-sdk/components/softdevice/common/softdevice_handler/softdevice_handler_appsh.o nRF51822/source/nordic-sdk/components/softdevice/common/softdevice_handler/softdevice_handler_appsh.c

And a link sample:

arm-none-eabi-gcc -mcpu=cortex-m0 -mthumb -Wl,gc-sections specs=nano.specs -Wl,wrap,main -Wl,-Map=BLE_iBeacon.map,cref -T./mbed/TARGET_ARCH_BLE/TOOLCHAIN_GCC_ARM/NRF51822.ld -L./mbed/TARGET_ARCH_BLE/TOOLCHAIN_GCC_ARM -o BLE_iBeacon.elf nRF51822/source/nordic-sdk/components/drivers_nrf/ble_flash/ble_flash.o nRF51822/source/nordic-sdk/components/drivers_nrf/pstorage/pstorage.o nRF51822/source/nordic-sdk/components/drivers_nrf/hal/nrf_nvmc.o .. nRF51822/source/btle/custom/custom_helper.o BLE_API/source/BLE.o BLE_API/source/DiscoveredCharacteristic.o BLE_API/source/GapScanningParams.o BLE_API/source/services/UARTService.o BLE_API/source/services/DFUService.o BLE_API/source/services/URIBeaconConfigService.o mbed/TARGET_ARCH_BLE/TOOLCHAIN_GCC_ARM/startup_NRF51822.o mbed/TARGET_ARCH_BLE/TOOLCHAIN_GCC_ARM/board.o mbed/TARGET_ARCH_BLE/TOOLCHAIN_GCC_ARM/retarget.o -lmbed -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys -lmbed -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys arm-none-eabi-objcopy -O binary BLE_iBeacon.elf BLE_iBeacon.bin arm-none-eabi-size BLE_iBeacon.elf text data bss dec hex filename 22660 128 1604 24392 5f48 BLE_iBeacon.elf

Cool. I'll have a look!

Thanks! It's an Arch BLE if you have one to hand.

You/I didn't mention "yotta" - I tried that but it didn't have targets for the Arch or the Teensy which I'm using (although it did have currently useless targets for the microbit..).

Cheers! Thanks for replying so quick. I'm ever hopeful.. I just moved from cosy Arduino to mbed! :-)

Duncan

Thanks! I'll check 'em all out.

Duncan

Actually - there's something worse wrong - I tried a blinky export locally on the Arch and it didn't go either!

The .hex file is five times smaller than the online compiled one - is that a hint?

I spotted a 'merge' target which merges in a s110 softdevice and ran that on the iBeacon test, which gave a .hex file five times bigger .. but that didn't work either. It had the wrong s110 path on it, so obviously hasn't been tested recently.

Blink doesn't need s110, I presume, but I tried that anyway, and it still didn't blink. :-)

I tried your gcc in the BuildShell, but the same result. The gcc versions are practically the same, yours and mine, BTW. Here's mine:

$ arm-none-eabi-gcc - -version

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977]

And locally,

./workspace_tools/make.py -m ARCH_BLE -t GCC_ARM -d . -n MBED_BLINKY

works OK, full-sized hex file (316204). Export using project.py:

python ./workspace_tools/project.py -m ARCH_BLE -i gcc_arm -n MBED_BLINKY

build it .. gives a tiny .hex file (13053)

Conclusion: online and local core mbed SDK good, exported to Makefile version, bad. The .hex files are tiny.

Cheers!

Duncan

Well turns out I was right about the softdevice and needing to (fix and) use the merge target in the exported Makefile: you need the s130 one (which you do have in gcc4mbed), and, yes, even blinky needs the entire Nordic BLE stack to run!! OK..

So now I'd like to try gcc4mbed. :-) It's apparently the only way I can have many targets, varying libraries and many different device programs. Cool. Your .hex files are full size and looks like you use s130, so promising.

But it didn't work for me.. I did a clean git clone, linux_install and uploaded the (ready-built) .hex to the Arch BLE. Nothing.. :-(

I see you've not committed to master since 7th July? That doesn't have the USER_LIBS thing. Perhaps I should try your 'working' branch? Or is that unstable?

Finally .. any chance of a Teensy target? Or should I port that over myself from the main codebase?

Cheers! :-)

Duncan