I went through the docs and this forum, and couldn’t find an answer. I would like to add support for the STM32F7 and some GPL3 hardware-abstraction libraries (a framework like CMSIS?).
Should I do this?
How, if so?
Standards to follow? Integration tips?
Thank you.
—Ian
So I think I may be able to use this compiler if it has cortex-m7 support…
platforms/ststm32.py
Then I think I would have to add build options for the F7 and the discovery board to this file?
ststm32.json
(Sorry, 2 links max for new users)
And to add the HAL libraries (which I think are distinct from mBed), I am utterly lost.
These are the ones I want to add. Perhaps these are better regarded as libraries?
http://stm32f4-discovery.com/hal_api/
—Ian
Ok…
So I will also need to add a linker script. But that’s easy. It looks like the arm-eabi compiler will also support the arm7 family. So that’s encouraging.
Also on my wishlist for libraries: Telehash, SerialIP (an arduino lib).
Hopefully, I will have a build working tonight. If I succeed, should I fork on github and submit a PR? Some of this work replies on changes to the repo.
—Ian
Hi @jspark311
I see here two problems:
cortex-m7 CPUs due to the old version of GCC toolchain for ARM in our packages.To overcome problem #1 you just need to replace our ARM toolchain with a newer one.
Problem #2 is not so easy. You will need to write a build script for HAL framework. Here is an implementation for similar to HAL SPL framework and then you will be able to use these libraries. 
Hi,
This is surely an interesting question as I have quite a few boards I would like to add. The problem is that every one of them seams to have its own requirements and uses other tools.
Switch Science has a small mbed platform using LPC1114FN28 (a lpc1114 in DIP form factor) that is supported in platformIO.
However, the LPC1114FN24 chips I have are just standalone chips and as a result uploading is done differently: lpc21isp uploading the hex-file over the serial port of the chip…
I like these chips as they are in a “DIP” package, and therefor very breadboard / perfboard friendly.
2/ STM32F103-family
ST has the Nuclea-F103RB (mbed) board but there are certain other platforms out there that also uses that chip. One of them is the maple.
The original maple was designed by leaflabs (however not supported anymore since march 2015), but you can find clones of these boards from other vendors:
On that board, code is uploaded over USB (using the DFU-protocol), using a tool like dfu-utils
For me, fhe big advantage of these devices is that it is a complete board stacked on a DIP “breadboard friendly” socket and that they are very cheap (less then 4 euro)
The STM32F103C8 has half of the memory of the STM32F103RB, so this probably needs some tuning of the linking process.
The maple originally used the maple hardware library (which is a arduino/wiring compatible library for STM32F103) but -just like the hardware- that isn’t supported anymore neither, so the other STM32 libraries that also already in platformIO are probably a better option now.
BTW. There also is a project called “stm32duino” which creates a arduino/wiring compatible library for the STM32F103 chips.
These boards have a jtag socket so I used openocd to upload code.
(But I do guess openocd does require some tuning as its configuration-file depends on the jtag hardware you use).
Now, I may have missed it but sofar I have not really found a document what are the different options to create a new platform and how to do this in a generic way.
Certain elements (like the configuration-file for openocd, or linker-map files that describe the amount of memory in a chip) are quite hardware dependant, so I wonder how one can crate a platform for these devices in a as-generic as possible way.
Also, my developement platform at home is linux. I have no idea how to implement this for windows or mac.
So what would you propose?
Does it make sence to work on this?
Cheerio! Kr. Bonne.
valeros, thanks for the reply. To your point (1)…
I have a working STM32F7 toolchain elsewhere. gcc -v reports:
Using built-in specs.
COLLECT_GCC=./compiler/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/ian/working-copies/Digitabulum-RTOS/compiler/bin/…/lib/gcc/arm-none-eabi/5.2.1/lto-wrapper
Target: arm-none-eabi
Configured with: /src/gcc/configure --target=arm-none-eabi --prefix= --libexecdir=/lib --infodir=/share/doc/gcc-arm-none-eabi/info --mandir=/share/doc/gcc-arm-none-eabi/man --htmldir=/share/doc/gcc-arm-none-eabi/html --pdfdir=/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/arm-none-eabi --build=i686-linux-gnu --host=i686-linux-gnu --with-gmp=/build-native/host-libs/usr --with-mpfr=/build-native/host-libs/usr --with-mpc=/build-native/host-libs/usr --with-isl=/build-native/host-libs/usr --with-cloog=/build-native/host-libs/usr --with-libelf=/build-native/host-libs/usr --with-host-libstdcxx=‘-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm’ --with-pkgversion=‘GNU Tools for ARM Embedded Processors’ –with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r,armv8-m.base,armv8-m.main
Thread model: single
gcc version 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848] (GNU Tools for ARM Embedded Processors)
And the compiler that ARM compiler that came with platformio (IDE 1.1.1 CLI 2.8.6)…
Using built-in specs.
COLLECT_GCC=/home/ian/.platformio/packages/toolchain-gccarmnoneeabi/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/ian/.platformio/packages/toolchain-gccarmnoneeabi/bin/…/lib/gcc/arm-none-eabi/4.8.4/lto-wrapper
Target: arm-none-eabi
Configured with: /src/gcc/configure --target=arm-none-eabi --prefix= --libexecdir=/lib --infodir=/share/doc/gcc-arm-none-eabi/info --mandir=/share/doc/gcc-arm-none-eabi/man --htmldir=/share/doc/gcc-arm-none-eabi/html --pdfdir=/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/build-native/host-libs/usr --with-mpfr=/build-native/host-libs/usr --with-mpc=/build-native/host-libs/usr --with-isl=/build-native/host-libs/usr --with-cloog=/build-native/host-libs/usr --with-libelf=/build-native/host-libs/usr --with-host-libstdcxx=‘-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm’ --with-pkgversion=‘GNU Tools for ARM Embedded Processors’ –with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 4.8.4 20140725 (release) [ARM/embedded-4_8-branch revision 213147] (GNU Tools for ARM Embedded Processors)
So unless you actually removed stuff from gcc’s support directories, you have all the support I need. You just don’t have a tag for it. 
But your point (2)… That is something I’d possibly be willing to do. The SPL libraries won’t fly on the F7. I gather that ST discontinued them. The HAL libraries support the whole F-series (which includes many of krbonne’s parts, also).
You will need to write a build script for HAL framework.
Yeah… I figured. I don’t know scons yet, but I did indeed comb the SPL scons scripts and I think I can manage it.
If I fork on github, do the work, and submit a PR, will you merge if it doesn’t suck?
I might also direct my efforts at openCM3. They are clearly thinking about the F7, but have practically no support yet. Anyone have an opinion on this? I haven’t used OpenCM3. Just SPL directly on F1, F3, F4.
krbonne,
My stuff also uses DFU. I’d use that feature as well.
LeafLabs was good ware… The F4 was plush.
isn’t supported anymore
Made any choices about new libs yet?
Now, I may have missed it
I did too. This was the best doc I found, and it led me to the right places, I think:
http://docs.platformio.org/en/latest/platforms/creating_platform.html
Also, my developement platform at home is linux. I have no idea how to implement this for windows or mac.
Likewise. I wouldn’t be able to test any of those “alternative” development platforms. Someone else would need to do that, if anyone cared.
Does it make sence to work on this?
It does to me. Autoconf, scons, and the like are my biggest intellectual weakness here. I’ve been trying like mad to adopt better coding standards and write careful pre-processor logic to support it. But I have a hard time justifying learning autoconf when I can spend the time improving tools like this, and then never have to worry about it again.
My github user is jspark311. If they’ll take a PR, ping me and I’ll colab with you there?
—J. Ian
Hi,
First let me add links links of the devices I talked about:
Olimex Olimexino-stm32 this is a clone of the original maple board, but with the advantage of certain more “industrial” extensions (larger input voltage range, lipo battery charger, …)
Chinese STM32F103RC board
The “RC” chip has a hardware DAC which interests me as I want to use this for ham-radio use (digital signal processing and generationà
Chinese mapple mini clone breadboard friendly
The olimex board is probably functionally equivalent to the nucleo-F103 board so it can use the mbed library, except that you need either USB/DFU or jtag/openocd to flash the device.
For the other two STM32 devices, they have less or more flash and RAM. I don’t know if there would be a way to use mbed for these board.
In essence, I have been thinking about using platformIO to create a mbed enviroment for devices that officialy not supported by mbed.
I’ll reply to your message:
Made any choices about new libs yet?
Not yet. For me, this is just a bit of fun learning about microcontrollers, datacom and about signal-processing. I do not have a “fixed” library.
Sofar, on the stm32, I played around with the original ST-libraries, mbed and stm32duino.
I currently focus on mbed as I am playing with a couple of ISM-band radio modules based on a TI CC1101 (link here ) and sofar I have only found mbed libraries for this device.
However, I am not fixed on one particular library.
I also have a couple of RF devices based on the si4463 laying around I want to try out. For that, I will use the “radiohead” library with mainly is for arduino.
Custom Development Platforms — PlatformIO latest documentation
Yep, looks like the correct place to start. I’ll start from here and see how far I can go.
Also, my developement platform at home is linux. I have no idea how to implement this for windows or mac.Likewise. I wouldn’t be able to test any of those “alternative” development platforms. Someone else would need to do that, if anyone cared.
I do not know what the platformIO people think about this. PlatformIO is platform-independent, so when people start making linux-only extensions, that does break their goal.
Does it make sence to work on this?
It does to me. Autoconf, scons, and the like are my biggest intellectual weakness here. I’ve been trying like mad to adopt better coding standards and write careful pre-processor logic to support it.
Same thing here. Usually no issue to create a couple of scripts to do the things I want to do, but writing “generic” code is a lot more work and by then I usually have found something else more interesting to play around with.
Cheerio!
Kristoff
The mbed platform supports a NUCLEO-F746ZG board.
sstaub
Thanks! I didn’t know that. 
Hi all,
A small update on this:
I tried to get mbed to work on the STM32F103CB and RC boards (using gcc4mbed) but both failed:
BTW. In contrast to what I mentioned above; the maple mini uses a STM32F103CB (not C8), so it actually has the same amount of memory as the RB chips (not half as mentioned above).
So I am kind-of stuck. 
Cheerio! Kr. Bonne.
I am now awaiting delivery of cheap Chinese stm32f103c8t6 boards (so-called “blue pill”, or “yellow header”) and once they arrive I will try to make it supported with PlatformIO. I found people claim the mbed framework supports it already to some extent - they’re almost identical to ST’ NUCLEO-F103RB boards, with the difference in RAM amount and some pins missing.
EDIT: RAM is the same 20KB, it’s the flash memory that’s halved, 64KB instead of 128KB. I have required mod in ststm32.json but it has to wait for the boards to arrive to be tested. I will do PR on github once ready.
I recommend using PlatformIO 3.0 for the new development platforms. See example how to integrate new framework
Stay tuned, this is just a beginning.
My PR finally got merged and support for BluePill STM32F103C8 will be offcially included in next release of mbed framework (this will be 122). Looking at a pace of previous development this should land rather sooner than later.
These libraries, you provided, are based on ST HAL framework and its support is not implemented yet.
Hi @valeros,
how is going with a ST HAL support? Is it somewhere on the PlatfromIO roadmap?
Best regards,
Konrad