Nucleo F401 branch on github sheepdoll

Since I need to access it on a remote computer, I pushed the current state of the work I am doing to a branch sheepdoll on github. The branch is called STM32F401_testing. This only has some of the initial monkey script copies based on the Information I gleaned from STMCubeMx and reading the existing Nucleo code.

This branch will not compile due to differences in the compiler includes. I started to change the includes in core, but it looks like restructuring core to the same paths that are in F1 is a better approach, that way I can diff and search the whole directory.

I chose to base the Nucleo port on the F1 directory tree, because that is a stable and working tree for me. This may make it easier in the future to whomever wants to merge the F1 and F4. At the moment I want to keep them in separate trees. While there are similarities, I also want to separate out the F2 stuff. I have some abstract thoughts on this that are more modeled on the AVR workflow. In AVR you start with a footprint. Nucleos always will have a 64 pin footprint. At the moment it looks like the F2 and F4 stuff is assuming large footprints and pincounts. I have boards I laid out to use AVR 15 or so years back, that I can pop a mega328 on and use without changing hardware. I think this is what the Nucleo is trying to catch up with. That one can replace the F103RB on an existing layout with a F401RE. There is a lot more I could post here, but this is turning into a wall of text, and I probably put most readers asleep, so to cut to the chase …

I am pretty rusty with git so I would not recommend others pulling from this branch, other than to read it. I am also not in the position to take push requests. This notice is just done as a courtesy FYI by one of the sheep in the flock.

The only question I would ask at this time is what is the path difference in behavior between library quotes like #include “libmaple/libmaple.h” compared to #include <libmaple/libmaple.h> To get the headers to compile I had to add ‘libmaple/’ to a lot of the library includes.

I think the paths are defined in platforms.txt and it looks like in the F1 tree these have been moved into system/, which is where the compiler as run is looking for includes. I am not sure where platforms.txt is inheriting the includes paths from.

I think that taking the F1 and then doing update to make it compatible with the F401 is the best option.

Although I thought that perhaps it would be possible to eventually merge the F1 and F4 folders, I now think in that structure that Libraries would be a big problem.

i.e there would only be one library folder and quite often, libraries make low level access to the hardware (and very often don’t even use the pseudo HAL functions that are in lib maple e.g. gpio_write_bit()

So I think, realistically, the best approach is to have to maintain 2 code bases which are virtually identical, except for the differences in the libraries (e.g. I suspect the F4 would initially have less libraries than the F1)

I know this is not an ideal situation, as if changes that are in files that are exactly the same in both F1 and F4 needs to be changed, then both copies would need to be changed, but I think its the only practical solution for an open source community project.

I’m also wondering whether even now I should remove the F3 and F4 folders and put them into separate repo’s, i.e perhaps its best to do this now, before too many people start using the F4 (and no one is using F3 as far as I’m aware)

I got the F401 changes to compile the blink sketch. It is getting a bit late here for connecting hardware. I also want to do more checking on the build flags. I am also wanting to learn more about where the clock setups are.

The issue was the include paths in platforms,txt I had copied the one from the Nucleo 103 variant folder as I know the upload tools in that work. This plaforms.txt was including system/ folder and not the cores/ folder. On the F1 varient, there looks to be a lot of duplication inside both System and Cores. I am still unclear on the <library> compared to the “local” include methods.

Most of the issues I am having relate to small pin devices like the Nucleo . There were a references to things like PortE and SPI3 or 4 that I had to #idef out.

I have no opinion on the F3 stuff. The F4 does seem like a standalone unit. For the time being I would say to keep at least the F4 folder under the Arduino_STM if it is not broken then there is no real need to fix it. I can see the advantages of having separate Arduino_STMF1 and Arduino_STMF4. The other way to do it is by chip footprint size the way Atmel does it.

I suspect that most semi-advanced users will probably delete the variants they do not use. My tools menu is getting a bit long with all the variations of bits of hardware I have collected over the years.

Thanks @sheepdoll

I did tidy the System folder and removed all the C files that were in there, but its possible there are duplicates if header files in system and cores

This is probably something that needs to be sorted out in the F1 code, but as it wasn’t broken…

I know Victor is also looking at some duplications of C functions in cores. Well, they are not duplicates, but there is a .c and a _f1.c in some places, and this seems to be causing issues with the ISR vector table population

So Victor is investigating merging the some of the xxx_f1.c with the xxx.c

The reason, I didn’t spend more time cleaning it all up, was because we seemed to have more pressing problems on the F1 and I needed to just get stuff working

BTW. I think the original idea of separating System form Cores, is that (1) it could allow different processors in the same code base, e.g. if there was a separate System_f1 and System_f4 as this the include paths are set in platform.txt and could be switched easily and
(2) to isolate the core Arduino API from the patform specific stuff.

But in the end, I think both fell by the wayside. i.e I don’t think LeadLabs:libmaple has isolated the core arduino stuff from the platform stuff.

Anyway, Thanks for you efforts and let me know when you have pushed anything to your github repo (whatever its called) as I’m keen to test on F407 !

@sheepdoll

I took a look at tidying up the includes, but it looks like its not an easy job.

We can removed the stm32f2 folders from the STM32F1/system/libmaple tree, as they should not be used

However trying to combine includes into less folders would take a bit more time, as I’m slightly concerned that it may be possible to move an include that is not used unless a specific function is needed, and consequentially I’d not spot that I’d missed something.

I think I will take a look at this, but I think its something I’d need to tackle at the weekend, rather than at the end of a day of coding for work.

RogerClark wrote:@sheepdoll
…

I think I will take a look at this, but I think its something I’d need to tackle at the weekend, rather than at the end of a day of coding for work.

sheepdoll wrote:There is no real hurry on the cleanup. Getting the ISR vectors is much more important.

I pushed my latest changes to <https://github.com/sheepdoll/Arduino_STM32.git> branch STM32F401_testing for those who might want to play with the F401 code as a Nucleo board. The blink sketch will compile but it will not run. There are probably low level GPIO mapping differences between the F401 and the F407.

Rick,

I agree, moving the ISR vectors to C is a good idea.

I have a backlog of other issues I’m trying to clear first, but I intend to get back to this when I can

@sheepdoll

I cant seem any commits to your fork of the repo (It could be I’m looking at it incorrectly on github)

https://github.com/sheepdoll/Arduino_STM32

did you create a new branch your fork?

The most recent update GitHub shows me is

Added generic STM32F103RC support and started work on generic STM32F103R 13 days ago

Seems like it might be:

https://github.com/sheepdoll/Arduino_ST … 01_testing

umm
Yes. Looks like the changes are in that branch

I though that @sheeldoll was doing a different approach.

ie just modifying the F4 folder

I think a better option would be to attempt to convert the F1 folder to work with F4, as there are lots of changes and fixes in the F1 folder that are not in the F4 . Not just the changed I initially made to libmaple, but changes leaflabs made to libmaple after the AeroQuad people took their copy (2 or 3 years ago)

RogerClark wrote:umm

I think a better option would be to attempt to convert the F1 folder to work with F4, as there are lots of changes and fixes in the F1 folder that are not in the F4 . Not just the changed I initially made to libmaple, but changes leaflabs made to libmaple after the AeroQuad people took their copy (2 or 3 years ago)

@sheepdoll

Thanks for the update.

I see what you mean about there being no easy way to do this

I wasnt aware of openSTM32, (Looks interesting)

I did register on STM32 own community forum, but have not got an decent answers to my questions. Though they do have guy who calls himself “clive” that seems to know everything and posts thousands of replies. I suspect he is STM or a team of STM people

Re: Restrictive license on the LD file

Is it generated by the STM32 Cube ?

RogerClark wrote:

Re: Restrictive license on the LD file

Is it generated by the STM32 Cube ?

I’d not come across linker scripts until I looked at the STM32 stuff and it all looks like hieroglyphics to me

I suppose it would be possible to re-write the linker script to remove the licensing problems, but I suspect its not something that could be done without a reasonable understanding of the linker script language (whatever that’s called )

RogerClark wrote:I’d not come across linker scripts until I looked at the STM32 stuff and it all looks like hieroglyphics to me

@sheepdoll

Curious, I had always supposed that the Arduino/wiring really called make, like a lot of other IDEs do in a hidden way.

I think it was proposed that the Arduino IDE switch to using a makefile and just run make, but AFIK thats not what it does at the moment.

It seems to build a list of the files it needs to compile by just iterating the filesystem of the core in question.

It also seems to parse the sketch looking for library includes and then adds them at the start of the list of files it needs to compile

Currently I’m at a loss about how it actually links the files, because Victor has a proposed fix to a ISR Vector problem which involves merging code from 2 files into 1. The fix works, but makes no sense unless there is something strange going on with the order in which it links those two files.
But it compiles them one after the other and it doesnt matter which file the code is in, as long as all the code is on one file and the code is not split across 2 files. (I cant see any dependency in the code in the two files either)
very odd…

So let me know if you figure out how the IDE actually links all the object files together

More incremental success.

I made a new boardgroup and private branch to test the STM32CubeMX libraries in. https://github.com/sheepdoll/Arduino_ST … MX_testing Like my work with F4 to Nucleo F4 most of the changes were in board.txt and platform.txt. This time I changed some of the compiler define switches and include paths to compile the template as generated by STM32CubeMX. One file had to be moved/renamed due to case sensitivity ‘startup_stm32f401xe.S’

currently I have the arduino stuff stubbed out. I was curious as to how the files are included/built. It is as Roger stated, the IDE builds everything it sees.

I noticed that Koduino also uses the poison pill *.ld linker script. Since the same script appears in muliple places with different copyrights, I suspect that this is just cut and paste boilerplate that got stuck on it.

I did look at the *.map that was in the tmp directory. Actually there is a lot of useful reports saved in the tmp directory. These all get deleted when the Arduino IDE is closed. In theory one could point gdb at the elf file and see how the code is loaded. I noticed that since this code is mostly stubs that a lot of fields are zeroed out. This may explain why the vectors are disappearing under some combinations. The existing linker scripts use includes to handle common stuff. They also need to be fine tuned to the actual chip.

The next step is to see which Arduino library set maple or koduino would best float on top of the CSMIS code.

@sheeldoll

You may want to look at https://github.com/MakerLabMe/STM32_Arduino_Cores as well

As this may be another candidate for providing the Arduino API overlay

Edit.

Looking at MarkerLabMe’s Arduino files, they are a little out of date but they should be at least at Arduino 1.0 API level

More incremental success. Well actually the first milestone.

I started to port some of the Arduino.cc 1.6.4 sam F4 core over the CubeMX HAL framework. Ran into some conflicts as both Arduino and HAL were attempting to use some identical names in different ways. Spent much of the day writing wrappers for DigitalIO functions.

Abstractly HAL and arduino are similar. Providing basic access to the underlying hardware. My wrappers failed, at the same point I was having with moving F1 over to F4. The alternate function pin table. Then I realized that CubeMX sets these as part of the startup code in main(). So I scrapped the wrappers and tried a more direct approach.

I set the /* user code */ in main() to call setup() and loop(). It is evident that the HAL model has already provided what is pretty much an identical abstraction to the way Arduino does things. Similar to the way Marketing put some useless shield headers on the Nucleo board. Realizing that the sketch now has direct access to the high level HAL functions I put the same ones from the STM32 Nucleo into the sketch like such
void setup() {
// put your setup code here, to run once:
/* there is no setup code, STM32CubeMX sets the gpio as part of code generation */
}

void loop() {
// put your main code here, to run repeatedly:

HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);

/* Insert delay 100 ms */
HAL_Delay(100);

}

Wow

Thats amazing progress

I’m cloning your repo now.

I better download the STM cube again, as my version is somewhat dated.

Edit. Are you using the STM Cube or the Cube MX

Edit..

Perhaps the Cube is called CubeMX and I’d not realised

I’ll check whats on my other machine, as I’m sure I have something installed already ,….. Somewhere…..

@sheepdoll

How did you create your g_APinDescription ?

It doesn’t look like its being used, but it is getting compiled, so using your file on the F103 didn’t work for me (not surprising as its referencing things the 103 doesn’t have)

Apart from that, I’ve managed to get the F103 compiling.

BTW.
There is something strange with .S files. I had to make the startup_stm32f103xe.s into startup_stm32f103xe.S i.e upper case S, and Windows isnt supposed to be case sensitive.

I’m not sure if I was imagining things, but the Blink sketch you posted seemed to work, but the LED was blinking really slowly.

But when I uploaded again, it stopped working.

But… There is no code to init the pin, so I can’t see how it could have been working, unless it was some sort of hang over as initially I had the bootloader installed which sets my LED pin to push pull.

Anyway, if it was working… I have an issue with HAL_Delay as its a lot slower than 100ms, more like 2 or 3 seconds per loop.

RogerClark wrote:… There is something strange with .S files. I had to make the startup_stm32f103xe.s into startup_stm32f103xe.S i.e upper case S, and Windows isnt supposed to be case sensitive.

I tried changing the large S in platforrms.txt recipe to a small s. Did not work, so I changed the filename itself.

I would not expect my testing branch to work for a F103 Nucleo directly. The MxNucleoF401.ioc is configured for the F104, with most of the alternate functions enabled. I have not checked if the HAL code generated by a 103 ioc has the same API. The clock configuration is done in CubeMX so using the HAL code from one processor setup, would not be expected to work without change on the other one. I would think a second variant would be needed for the F103 and plan to make one … eventually …

For the time being the existent STM32duino maple lib works well on the F103 board. I want something that would work with the F401 Nucleo and eventually the F429I Discovery.

This experiment is still much of work in progress g_APinDescription was giving me some issue. I was first attempting to use it as flags without modifying Arduino.h from the 1.6.4 sam folders. Too much Atmel Sam specific registers were invoked. So I temporally abandoned that part and put the HAL code into the sketch to see if it was working. It did and I was happy.

There are lots of little fiddly things. I was setting up g_APinDescription by hand to match the startup code (see the code generated in gpio.c and uart.c under the CubeMX created folders. Each has its own HAL_Initxxx code which is called by main() before I call the Arduino api setup(). Shadowing the peripheral setup with the g_APinDescription breaks the Arduino model when CubeMX is used for the configuration. I am also not quite sure of making a strut of two struts one a pointer and the other direct fills the array correctly. One reason I wanted to try gdb so I can dump the symbol tables. g_APinDescription is also defined as a constant so would make it Nonvolatile for filling in from the HAL setup code.

Eventually the Arduino/Processing API will need to map from the pin back to the port. The array seems like a good way to do this. The HAL code seems use static to hold the structure data for the pin config. I suspect the designers considered that there was no need to keep the pin configurations around once it was set. Reading the HAL documentation, there should be accessors for reading the current configuration state.

@sheepdoll

Ok about the Pin map array. It looked machine generated but I could not find it in the CubeMX output.

BTW
I didn’t use your Nucleo variant.

I got the Cube to generate code for the F103C8 and made a new variant.
Then I changed some things to get it to compile for both variants, by adding a build.hal parameter in board.txt to set the HAL folder names in the include path.
I had to put ifdef’s in Arduino.h because of the difference in the top level HAL include file, and I changed the master clock in variant.h to use the CPU value that is defined indirectly in boards.txt

I had to delete some example files that the Cube generated, as they hung the compiler and are not needed, and of course I had to change the .s to .S otherwise the startup code didn’t get compiled in.

Oh. And of course I had to grab the correct linker file and move it to the ld folder, though actually this could just be specified by changing the linker file parameter in boards.txt

I wonder if its worth putting this stuff in a separate repo for people to play with ? I.e there are several other people with F4 boards, and also another group (on gibhub ) who were interested in using the HAL with libmaple (albeit this is not quite what you are doing)

What I need up doing was cloning your repo to my hardware folder to a different folder name “sheepdoll” so I could keep my original Arduino_stm32 folder, then delete the F1,F3 and F4 folders from your repo.

Then both will co exist.

However I don’t want to step on any toes by reposting a modified version of your work on GitHub under another repo name.

Btw. I don’t think I can fork you repo, back to my GitHub account to send you pull requests, as it would have a name clash with the original repo.

RogerClark wrote:

What I need up doing was cloning your repo to my hardware folder to a different folder name “sheepdoll” so I could keep my original Arduino_stm32 folder, then delete the F1,F3 and F4 folders from your repo.

Then both will co exist.

However I don’t want to step on any toes by reposting a modified version of your work on GitHub under another repo name.

Btw. I don’t think I can fork you repo, back to my GitHub account to send you pull requests, as it would have a name clash with the original repo.

On the git command line if you do

git add -A

after deleting the other folders…

Then do git commit -am “Your message here”

then

git push

However, I won’t be able to pull from your repo if those files are deleted, as it would delete them from my repo

Probably best to just make a new repo for this stuff

I can do this if you want, or I’m happy to fork from a new repo you create.

BTW. I find the easiest way to start a new repo, is just to create a blank one (a just a readme and a possibly a license), on git hub.

Then clone that repo to your local machine.

Then copy all the files you already have, into that repo (note don’t copy the hidden .git folders)

Then add those files

git add -A

git commit -am “Initial commit”
git push

BTW.
I just tried not needing to move the linker script, and it works even with spaces in the path

In boards.txt

STM32F103CB.build.ldscript=SW4STM32/STM32F103CB Configuration/STM32F103CBTx_FLASH.ld

Update.

I seem to be missing some top level headers for gpio.h etc.

They look like they were machine generated by the Cube, but I don’t seem to have them in my export

I’ll try opening your 401 project and see if I can figure out any differences in the settings

Edit.

OK.
It looks like you have to go into the graphical UI and define some pins in order for it to generate any the gpio.h etc

Annoying, it seems to always output the examples, and DSP lib stuff, even if I select “Copy only the necessary library files” . Both of which cause the compiler to hang for some reason.

BTW.

If I want to put the code in a different start address e.g. 0x8002000 so I can use the bootloader, do you think the only thing I’d need to change is the linker script, or did you notice anything else in the HAL files that specifies the code base address ??

Thanks

Not sure I would want to be responsible for maintaining a repo. My websites are several years without an update. Happy to contribute what and when I can. This current phase has my interest, as I have been wanting to use this hardware for about as long. I have enough projects to keep me busy for about 500 years. This is just one of them.

I did a bunch of diffs on the Xp machine using windiff to compare directories. The high level HAL stuff that goes int the src and hdr folders is pretty much the same other than the includes and some device specific stuff.

“Copy only the necessary library files” and “Generate peripheral initializations as a pair of ‘.c/.h’ files per IP” need to be selected. Not sure where the DSP lib stuff is coming from. I do not have that. When the SDK Libraries are downloaded from the Help menu they install a mass of stuff in the user directory in the folder STM32Cube/Repository including lots of demos and templates along with the downloaded zips. Some of these seem older than the auto generated SDKs. I suspect this is as much of a work in progress on the ST side as it is on ours. Especially on the Mac OS X side. Some options under windows, like changing the push pull and pull-up states of pins under the Configuration tab, do not work on the OS X version. Even though the release version 4.8.0 is the same.

No worries

I’ll make a new repo and copy my F103 and your NucleoF401 stuff in there, but at the moment my F103 stuff isn’t even blinking the LED any more.

BTW.
I recall @WestW (github) saying the Cube seems to be a work in progress but that was a few months ago.

I noticed when I initially tried to export the F103 HAL files that the Cube has to download a zip, which I presume has the F103 boilerplate in it.
And I see now there is a update menu until the Help menu. So I guess they may update the libs from time to time.

The F103 export seems to contain a DSPLib which I had to delete entirely, otherwise the IDE tries to build it all, including examples – which seem to hang the gcc compiler.

Anyway, I’ll see if I can at least get an LED to blink on the F103 using the HAL

@sheepdoll

OK.

I have at least got your basic blinky sketch working !

For some reason, the SWD (STlink) pins are currently miss-configured.

I’d have thought that if the Clock and Data lines PA14 and PA15 were not configured, they’d default to be SWD but this doesnt seem to be the case for me at the moment

RogerClark wrote:@sheepdoll

OK.

I have at least got your basic blinky sketch working !

For some reason, the SWD (STlink) pins are currently miss-configured.

I’d have thought that if the Clock and Data lines PA14 and PA15 were not configured, they’d default to be SWD but this doesnt seem to be the case for me at the moment

Thanks for the tip about “Sys”

Thats fixed my SWD issue

Sorry to keep asking questions, but did you take the core files from the Arduino SAM and convert the functions into stubs by removing the code inside the functions ?

I notice not all files are present. I presume this is because its a work in progress.

BTW. I thought I’d look at what Avik did, and for some reason he chose not to use the SAM core as the base, and instead has written his own files e.g. gpio.c , I’m not sure the logic in doing this – I’ll see if I can contact him

Also, I know I’m interested in getting the F103 going as well as the F4, but I wonder if the HAL API for the F103 and the F4 are identical.

i.e if we write functions for pinMode in the core, making calls to the HAL, I wonder if it would be fine for everything, or just things like GPIO

I looked at the basic stuff like pinMode and it seems like it is the same, but I wonder if SPI etc would be subtly different. i.e Ideally they would be the same

Anyway.

I think I may start a new repo and let all the F103 users play with at least blinking an LED using the Cube and the HAL

PS. I really need to write a script to delete some files after the cube does its export as I cant stop it outputting the examples and there is also a template c file that needs to be removed,

BTW. I did try enabling the USB device stuff, but it didnt compile as it seems to be missing something. This could just be a fault in the Arduino build, but I’d not be surprised if it was an issue in the Cube exported files.

RogerClark wrote:Thanks for the tip about “Sys”

Thats fixed my SWD issue

Sorry to keep asking questions, but did you take the core files from the Arduino SAM and convert the functions into stubs by removing the code inside the functions ?

Thanks for all the information.

I tracked down the F1 HAL doc to here

http://www.st.com/st-web-ui/static/acti … 154093.pdf

However its not practical to try to read both docs, even in two windows side by side and attempt to spot differences in the HAL.

BTW.
I see where you got the pin map from… Its from the SAM.

I think we may be better off just taking the PIN_MAP stuff from libmaple. The only thing that needs to be right from the start is that we must make sure the PIN_MAP gets compiled into Flash, otherwise we’d have the issue that libmaple has at the moment, where the PIN_MAP is not initialised when global vars (and hence class constructors) are initialized, and we end up with some libraries that don’t work

But I’m pretty sure we have a fix for this in libmaple, but I’ve been wresting with code that Victor wrote to fix this, and I’ve not managed to get it to work for me.

Anyway. I think the best thing I can do is add the HALMX folder at the same level in my repo as the STM32F1, F3 and F4 folders, so that the HALMX folder can then share the tools etc.

I’m not quite sure about a plan of attach (I’m sure other people would pitch in), but GPIO is going to be by far the easiest, then probably get the USARTS working.

Then SPI, then I2C (we can always use the bit banged implementation that libmaple uses for I2C as it just uses GPIO)

I’d also like to get it to work with the bootloader, but that should just need a small change, to move it to 0x8002000 – however using Maple’s usb is going to be a bit more work.
I’m not sure if its worth using the Cube’s USB stuff or not. I can’t currently get it to compile, and even if I did, I’m not sure what driver would be needed.
But the plus point with the CubeUSB is that there are options to run as HID, Audio or Mass Storage rather than Virtual serial.
However it doesnt seem to have the option to be able to do more than on usb type at once. (unlike the Leonardo / pro micro which can operate as virtual serial and HID at the same time – I think)
(Actually, no one has mentioned HID so far at all, which is a bit surprising, since the device has native USB)

Anyway, I’m not sure I’ll get much more done today.

I may have a go at moving it to 0x8002000 and use the bootloader (only for uploads) – just to see how hard it is to modify thing

Cheers

Roger

Edit.

I just remembered the (arrggghhhh) linker script license.

I’m someone clever, e.g. Rick.. Could re-write the script.

It really doesn’t look like anything special. I wonder if the libmaple linker script could be modified to do the same job.

In facts its such a small file, I doubt in reality even if it was written from scratch by someone else, whether it would end up looking very much different from the current file.

The other option is to post to ST’s community forum to request clarification. i.e how come they are redistributing this file outside of System Workbench.

ummm. Annoying but not insurmountable

Edit.

The libmaple linker script is no good without modification, it has external references that are not in the HAL or code e.g. __start__
However if you google some parts of the Cube generated linker script, there are loads of existing scripts that seem to look virtually identical e.g

http://sourceforge.net/p/stm32/code-0/9 … 2f407vg.ld

which could be “adapted” to work, and which don’t seem to have any license stipulations.

In fact. I took the one from sourceforge, and just had to change the FLASH and RAM size, and it worked for me
(see blow)

There are some differences, link min heap size and also it doesn’t have ” .ARM.attributes 0 : { *(.ARM.attributes) }”

But I’m afraid I’ve no idea what most of this stuff does. (again, perhaps Rick can help)

I think, I’ll put this stuff into a new repo and make it a sub module on the main repo, so people can have a play

ENTRY(Reset_Handler)

MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 128K
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
}

_estack = ORIGIN(RAM) + LENGTH(RAM);

MIN_HEAP_SIZE = 0;
MIN_STACK_SIZE = 256;

SECTIONS
{
/* Interrupt vector table */
.isr_vector :
{
. = ALIGN(4);
KEEP(*(.isr_vector))
. = ALIGN(4);
} >FLASH

/* The program code and other data goes into FLASH */
.text :
{
. = ALIGN(4);
/* Code */
*(.text)
*(.text*)
/* Constants */
*(.rodata)
*(.rodata*)
/* ARM->Thumb and Thumb->ARM glue code */
*(.glue_7)
*(.glue_7t)
KEEP (*(.init))
KEEP (*(.fini))
. = ALIGN(4);
_etext = .;
} >FLASH

.ARM.extab :
{
*(.ARM.extab* .gnu.linkonce.armextab.*)
} >FLASH

.ARM :
{
__exidx_start = .;
*(.ARM.exidx*)
__exidx_end = .;
} >FLASH

.ARM.attributes :
{
*(.ARM.attributes)
} > FLASH

.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array*))
PROVIDE_HIDDEN (__preinit_array_end = .);
} >FLASH

.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array*))
PROVIDE_HIDDEN (__init_array_end = .);
} >FLASH

.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array*))
KEEP (*(SORT(.fini_array.*)))
PROVIDE_HIDDEN (__fini_array_end = .);
} >FLASH

_sidata = .;

/* Initialized data */
.data : AT ( _sidata )
{
. = ALIGN(4);
_sdata = .; /* create a global symbol at data start */
*(.data)
*(.data*)

. = ALIGN(4);
_edata = .; /* define a global symbol at data end */
} >RAM

/* Uninitialized data */
. = ALIGN(4);
.bss :
{
/* This is used by the startup in order to initialize the .bss secion */
_sbss = .; /* define a global symbol at bss start */
__bss_start__ = _sbss;
*(.bss)
*(.bss*)
*(COMMON)

. = ALIGN(4);
_ebss = .; /* define a global symbol at bss end */
__bss_end__ = _ebss;
} >RAM

PROVIDE(end = _ebss);
PROVIDE(_end = _ebss);

/* User_heap_stack section, used to check that there is enough RAM left */
._user_heap_stack :
{
. = ALIGN(4);
. = . + MIN_HEAP_SIZE;
. = . + MIN_STACK_SIZE;
. = ALIGN(4);
} >RAM

/DISCARD/ :
{
libc.a(*)
libm.a(*)
libgcc.a(*)
}
}


Update

I’ve pushed all my files to a new repo

https://github.com/rogerclarkmelbourne/ … uino_STM32

This doesn’t contain the tools, its just the files for the HALMX folder that needs to go inside the Arduino_STM32 folder

It seems to work fine for me with using an STM32F103C8 (even though I have exported the Cube as a F103CB (as its only the size of Flash that is different)

I compiled for NucleoF401 and it was OK, but I can’t test it (as I don’t have one of those.

(umm. Thinking… I have a F3 Nucleo, so it may be worth seeing if it works, and I also have a F407, so its worth exporting the cube for that as well)

Anyway, its something to play with.

Note to anyone reading this rather than the whole thread.

None of the Arduino API is present yet. I’m just using this blink test sketch (which does work) – uploading via STLink (though Serial upload could easiy be made to work)

void setup() {
// put your setup code here, to run once:
}

void loop() {
HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);
HAL_Delay(100);/* Insert delay 200 ms */
}

Re: variations between tha F1 and F4 HAL etc.

I took a look at the MakerLabMe wiring_digital.c

https://github.com/MakerLabMe/STM32_Ard … _digital.c

And it seems to need a lot of ifdef’s to support the different processors.

This seems to be mainly due to pinMode needing to setup the GPIO clocks, which are different on the F1 and the F4.

I will need to read the HAL docs, as it seems odd that the HAL would not abstract this. But I suspect perhaps it doesn’t. Or perhaps when Andy of MakerMabMe started his stuff the HAL was older and didn’t do this.

To early to tell the the moment

Edit

Makerlabme doesn’t use the HAL, as far as I can tell.

And it doesn’t look like Koduino uses the HAL (as far as I can see)

I finally got the standard blinkey sketch to run on https://github.com/sheepdoll/Arduino_ST … ting/HALMX. This uses macros to define millis() as HAL_GetTick() and delay() as HAL_Delay(). Not sure what do do with micros() as HAL sets up a millisecond timer. A lot of my AVR code uses microsecond timing. Will eventually want that as I use a resolution of between 24 and 25 uSeconds in the main loop for the frame rate. There is a lot of stuff to read on timer setup which is probably way down the path here… I really want to get some of the serial backchannel setup.

One has to love the C++ preprocessor. I forgot and left a stub for mills(){} so the LED would turn on and not blink. gdb showed me that the code was jumping into the stub. So when you make two functions identical through #define. They really are identical. Probably all the instances of mills were replaced with HAL_GetTick.

Surprisingly in the pushed code is not all that much is needed to glue digital IO onto HAL. At the moment there are not a lot of checks for setting up pins wrong. Arduino sam code checks the pin mapping array for peripherals that are blocking. As this array is static in flash, enabling a built in peripheral as part of the Arduino setup could behave unpredictably if the user arbitrarily decides to change the pinMode.

I will either need to shadow the peripheral maps with something that can be placed into a switch or compare, or make and find accessors into the upper levels if the abstraction layer. Mostly this does affect the pin mode clocks. On the F4xxx these are set in the gpio.c init() section called from main(). This works if the pin is defined in CubeMX and the header included. If a raw chip is setup in CubeMX and there is no gpio startup in main, then the pinMode() will fail as there is no clock. More likely the pinMode() will fail at compile as the gpio.h headers are not included and symbols left undefined.

Catching up on some of the other issues. At this point I really do not care about the linker script license. This project is “Educational” As the same code appears in multiple places, with and without license, I suspect this is an over aggressive use of cut and paste.

For the time being I am going to stay with the HALMX sandbox I setup. This may make it difficult to automatically update the https://github.com/rogerclarkmelbourne/ … uino_STM32 branch other than to option copy the changes over.

Re: delay();

I’m not sure why we cant use the HAL_Delay() for delay() ? They are both in milliseconds.

I did a bit of background reading around microsecond timing using Sys Tick, but the basic HAL code wont be enough to do this, some specific timer callbacks will be needed.

BTW. I also found some code that looks like it would handle the serial comms

http://stackoverflow.com/questions/2487 … hal-driver

Re: GPIO Clock enable.

As its on a port by port basis, all I did in the bootloader is enabled all GPIO clock for all possible ports, A to E in the case of the F103, this didn’t seem to cause any problems, so I suspect the same thing is possible in gpio.c (the Cube already wrote code enabling all the GPIO clocks even though I don’t think in the pin GIO thing I was using all ports.

RogerClark wrote:Re: delay();

I’m not sure why we cant use the HAL_Delay() for delay() ? They are both in milliseconds.

I hadn’t really dug into the details of the HAL implementation vs Standard Peripheral Library. I thought I had read that the HAL codes used the standard peripheral library .. but now I realize that the HAL code has its own version of the StdPeripheral stuff called HAL Standard Peripheral. Oh and it is incompatible with the older Standard Peripheral code.

bleh and bleh bleh

I am actually liking the new code that CubeMx spits out. Probably as I do not have to deal with the baggage of the older legacy stuff.

None of this really matters, The most important concept in programming is “Not invented here.” So old code from prior teems has really short shelf life as the prior team never could be a good as the current one

My take is that this new HAL stuff seems the same but different. I thought the older version was bloated and I don’t see anything changing. The one advantage it had was there was a bunch of code written for it you could use as samples. I guess if the goal is to provide an Arduino API layer to a ST HAL layer then what does it really matter : ) bloat on bloat.

The one thing I’m surprised not to see is some effort on ST’s part to take advantage of the bit banding features. I’m not really fond of the Texas Instruments HAL API layer however at least they have used bit banding where ever they can. The other advantage the TI TivaWare has over this stuff is that they burn it in the ROM so it is doesn’t have any wait state issues. The ROM code is zero wait state.

sheepdoll wrote: … The most important concept in programming is “Not invented here.” So old code from prior teams has really short shelf life as the prior team never could be a good as the current one

sheepdoll wrote:I am actually liking the new code that CubeMx spits out. Probably as I do not have to deal with the baggage of the older legacy stuff.

http://www.eevblog.com/forum/microcontr … #msg571671

That post / thread talks about some of the baggage .. and how they really didn’t fix it. So something that used to be obvious, say setting the pin to deal with GPIO_Speed_50MHz is now obtuse GPIO_SPEED_HIGH.

The CMSIS code is supposed to abstract all this stuff .. but instead ST puts a layer on that mimics the CMSIS stuff ( for the NVIC stuff for example ) and it is really the same but different and provides no value.

What irks me about these ARM vendors like ST and TI and NXP is they all have some layer of crap with the real goal of locking you into their way of doing stuff so you can’t easily switch to another vendor. What they fail to see is that the minute I start using their chip I’m already locked into whatever peripherals they have developed. It isn’t like my code for dealing with TI’s gpio registers is going to work on another vendors GPIO peripheral. The idea that they are adding value by providing some layer abstraction and that it is a useful thing is just a load of crap. They are just obscuring what I need to know.

-rick

Rick Kimball wrote:<…>
What irks me about these ARM vendors like ST and TI and NXP is they all have some layer of crap with the real goal of locking you into their way of doing stuff so you can’t easily switch to another vendor. What they fail to see is that the minute I start using their chip I’m already locked into whatever peripherals they have developed. It isn’t like my code for dealing with TI’s gpio registers is going to work on another vendors GPIO peripheral. The idea that they are adding value by providing some layer abstraction and that it is a useful thing is just a load of crap. They are just obscuring what I need to know.

-rick

Heh and with all that ranting . : ) .. I’m looking forward to see how this turns out. It might, at least in our small little world, provide enough abstraction that the same code can be used with the f103. f303 and f4xx

Keep up the effort, @sheepdoll !

-rick

Rick,

Thanks for the eevblog link.

The way I read it, that someone started to develop their product when using the STD peripheral lib, and when ST released the HAL version, they renamed some stuff, so that you can’t just use the HAL version as a drop in replacement.

IMHO,This sort of change is quite common in all branches of the software industry.

The OP on eevblog had the option to say with the old version of the Cube.
I can’t imagine any company maintaining the old and the new version at the same time.

Re:HAL locking you in to one manufacturer

They are all in competition with each other, I don’t see any commercial benefit for them to agree a API.
I also doubt that it would be possible to write an HAL API that would be work a work across the wide differences between Microcontrollers.

For example. I can’t imagine Cypress trying to design the PSoC around a HAL that works for STM boards.

The benefits of using STMs HAL would be

Support for the various generations of STM32 devices, and easier access to new devices e.g the F7
Not needing to write code from scratch for peripherals like CAN, I2S, SDIO etc
Easier to get support via the ST support community forum, as the majority of people either use the STD peripheral lib

All that being said…

I’ve no idea how portable the HAL is a across the whole family of STM processors, or the quality and efficiency of the HAL code etc, etc

But, I don’t think it does any harm for people to investigate the HAL as an option

RogerClark wrote:<…>
But, I don’t think it does any harm for people to investigate the HAL as an option

Hi Ray,

mrburnette wrote:Already, sheepdoll has exceeded what I would have initially expected.

I got the USART stuff to compile. It was the order of the #includes. Still working on the hooks into the stream print libraries.

In the mean time I attempted this test to see if I have the HAL setup correctly. It simply calls the HAL serial direct from the sketch

void setup() {
// put your setup code here, to run once:
// Hardware setup done as part of HAL init code through STM32CubeMX.
}

void loop() {
// put your main code here, to run repeatedly:
uint8_t wakeywakey[8] = "wakeup.";

HAL_UART_Transmit(&huart6, wakeywakey, 7, 0xFFFF);
delay(100);

}

@sheepdoll

Thanks for the update

using the HAL to access the UART would probably help me debug stuff at the moment. So thanks for that tip !

BTW.

You’ve probably already written this yourself, but here is wiring_digital.c

Note. My pin map is only defined as

typedef struct _PinDescription
{
const GPIO_TypeDef *gpioPort;
const uint32_t pin;
}

e.g.

extern const PinDescription g_APinDescription[]=
{
{GPIOA,GPIO_PIN_0},
{GPIOA,GPIO_PIN_1},
{GPIOA,GPIO_PIN_2},
{GPIOA,GPIO_PIN_3},

...etc etc etc


Just when you thought it was safe to go walking after dark …

Serial stream write (Serial.print) is sort of implemented. I tried it with a modified sketch based on one @madias posted here. I also put in the syscall connections that in theory would enable printf(). Makes the sketch 3 times the size when printf() is called, but no data is output in the serial monitor. A quick search on line indicates this is a common problem. I don’t feel like tracing it. I put the same HAL call into the UART stream write and to my surprise it actually worked.

In theory Serial1 should work as is connected to USART2. I did not see any data when I connected the lines to that that port. USART1 has pins in two different parts of the board. It is enabled at the HAL level, but not in the variant code.

The interrupt callbacks are still stubbed out. This means the ring buffer is not used.

Also stubbed out is the UART class init and setup code. This is actually done by STM32CubeMX. I had to leave in the Serial.begin() call, so it would find the serial stream. The baud rate and other parameters are ignored. The sam code used Atmel register parameters for the fields. These need to be mapped to the HAL_UART abstractions.

No reads are implemented as of yet. It may be possible to adapt the Brinir code to do the reads through DMA interrupts. I was up all night last night making this much work, So may take a break for a bit. As most of the ring buffer code remains, reading should be a fairly straightforward proposition, but the compile issues of last night might suggest otherwise.

The updates have been posted to https://github.com/sheepdoll/Arduino_ST … ting/HALMX This is of course an educational proof of concept branch. Not warranted to work for anything. There is still a lot stubbed out and any real sketch will behave unpredictably.

I am actually amazed that it works at all.

/*
simple serial sketch based on one by @madias
*/
#define ledpin 13
boolean flip=0;
void setup() {

/*
currently setup is done by STM32CubeMX

*/

Serial.begin(9600);
Serial1.begin(9600);

pinMode(ledpin,OUTPUT);
}

void loop() {
flip=!flip;
digitalWrite(ledpin,flip);
Serial.println("Port: Serial0");
delay(100);

Serial1.println("Port: Serial1");
delay(100); // delay in between writes for stability

}

@sheepdoll

Take a break.

Its a work day tomorrow (well its already tomorrow here, and has been for ages, but that’s the fault of the international date line )

I’ll download your code this evening and take a look.

I must admit I was a bit surprised about how the UART stuff in the SAM corer is structured. I don’t know why, but I’d imagined the ring buffer to be above the UART in the class heirarchy, but its not really.

The DMA stuff would be ultra cool, i.e do something the SAM doesnt do. But I’m not sure how you keep track of where the DMA write pointer is (I guess you can read it from a reg)

Anyway…

Take a break , everything is still going to be there tomorrow, and the next day etc

Incompatibilities between the F4 and F1 HAL

Your wiring_digital.c didn’t compile for me

GPIO_SPEED_FAST is not defined for the F1 HAL

Can you change this for GPIO_SPEED_HIGH as both HAL’s have this

From what I can see HIGH is the fastest on both the F1 and F4.

Another very minor thing.
Can you change you chip.h, so it includes the F1 of F4 HAL depending on the define in boards.txt

#if defined(STM32F401xE)
#include "stm32f4xx_hal.h" /* Ideally this is defined in variant */
#elif defined(STM32F103xE )
#include "stm32f1xx_hal.h"
#else
#error "Device not supported"
#endif

Update.

I just thought I’d take a look to see if I could use the HAL version with the bootloader.

Well the answer is yes and no…

The main issue is that the HAL needs to be modified

Each of the top level include files (i.e one per processor variant) (e.g. stm32f103xe.h) contains a link like this.

#define FLASH_BASE ((uint32_t)0x08000000) /*!< FLASH base address in the alias region */

Update

Unfortunately

NVIC_SetVectorTable(NVIC_VectTab_FLASH, USER_PROG_OFFSET);

Doesn’t seem to be in the HAL API

Well, nothing with SetVectorTable appears to be in the HAL

the only NVIC command appear to be

9.1.3 HAL_NVIC_SetPriorityGrouping
9.1.4 HAL_NVIC_SetPriority
9.1.5 HAL_NVIC_EnableIRQ
9.1.6 HAL_NVIC_DisableIRQ
9.1.7 HAL_NVIC_SystemReset
9.1.9 HAL_NVIC_GetPriorityGrouping
9.1.10 HAL_NVIC_GetPriority
9.1.11 HAL_NVIC_SetPendingIRQ
9.1.12 HAL_NVIC_GetPendingIRQ
9.1.13 HAL_NVIC_ClearPendingIRQ
9.1.14 HAL_NVIC_GetActive

I’ve posted a question to ST’s own forum

https://my.st.com/public/STe2ecommuniti … entviews=0

I think the work around is setting

SCB->VTOR

in main before Hal_init() is called, but i’ve not had time to confirm this

I played about a bit more with the CubeMX and the platforms.txt/board.txt files. I was not going to do this but one thing left to another and I wanted to push the changes to my laptop.

A few notes. The include chip.h is probably more akin to board.h. I moved this to the variants folder. This way I do not need i#ifdefs for the board type. Such is already handled through HAL configuration files. As it is I have about half a dozen STM32 boards. It looks like this may also work with the L0 and F0 demo boards I have. I have not added these to the on line repo yet as I do not want to clutter it. The F429I discovery CubeMX folder is there as I was playing with the mapping setup. (There is a lot to the F429I discovery it it basically a cellphone kit without a GSM modem. but I digress…)

To get the serial stream to work on my F103RB Nucleo I had to change the include paths in platform.txt to not hard code the F4 paths. So I added some keys in boards.txt to do this.

Setting up the new board with cube was surprisingly simple. I practice it was much easier to do than to write down.
Run STM32CubeMX and
Choose the board selector tab from the CubeMX menu and click the options to set all IP to default.
Set up the settings menu
Point the setup path to variants. Create the *.ioc project in the folder (This will become the Variant name)
Set the toolchain to SWSTM32
Make sure peripheral initi is set to pair the .c .h files

I had to first do a copy all used libraries to get the gcc folder to appear
Generate the project which should populate the variants folder You can open the folder from the completion menu.
Delete any demo examples and rename the correct *.s file to *.S for safety I deleted the other ones.

Back in the pin map window change any port pin initializations. ( side note: I did not do this the first time and did not get the USART3 mapped to the morpho pins. I was able to regen the project, re- compile it and it ran without changing any code.)

check the setting s menu. Copy only necessary library files should be set. Re generate the project.

At this point the project tree should be in place in the variants folder.

Copy the STM32duino files from a working variant into the new variant. This will be chip.h and the variant.h variant.cpp files.

Use a differencing editor like TextWrangler (Or BBEdit) to compare the working main.c in the working variant to the main.c in the new variant folder. Look for the calls to setup() and loop, these should be inside the user code comments. I did note that simple changes through CubeMX do retain the code inside the user code comments.

At this point the cloned variant is ready to edit variant.cpp. The only real change I had to make between the F401RE and the F103RB was to change usart6 to usart3 (and remember to check the alternate function pin mapping.)

I also noticed an option in the mac version of STM32CubeMX which is not in the windows version. This is to generate a .csv file of all the pin references. Most likely users will only need to create a new STM to arduino pin table. This .csv could be most useful for such.

There are also issues with some of the non portable options to the gpio, like the GPIO_SPEED_FAST verses GPIO_SPEED_HIGH. I also had to move the __io_putchar() from the uart class into the variant as I was hard calling the serial write code. In theory this should let printf() connect to the serial port, but it is not working for me at present. I have not tried this again.

These updates have been posted to https://github.com/sheepdoll/Arduino_ST … ting/HALMX

PS: I personally am not much interested in boot loaders as almost all the boards I have contain some form of STLink. Changing the auto generated files breaks my model for this experiment, which is to see how compatible they are. Of course if this were a real project things might be different.
A real project would probably also create it’s own linker load files. I wonder how open the plug in for the the tool file generator inside cubeMC will be?

@sheepdoll

Thanks. I’ll take a look.

I think you’ve done basically the same thing I did for the CMSIS / Driver path thing, except I only had one param instead of your two.

I could get away with 1 param, but I can see that using 2 params allows more flexibility in case the folder naming doesn’t totally follow the same naming convention.

I think a lot of F103 users will want to use the bootloader. But its a very small change to one of the “Template” files in the HAL, or possibly just an additional line at the beginning of main() – though I’ve not tested changing the vector table base address in main() as yet.

I’ll need to look at patching the libmaple USB stuff into the source, by probably adding the code into a maple_usb folder inside the core (just to its obvious that this is maple stuff and not the HAL usb)
Of course I’ll need to make sure that the USB clocks have been setup.

I’ll also preferably need to use HAL calls for the USB rather than direct register access that the libmaple is no doubt using

Anyway

Thanks again for sharing

Re: bootloader, perhaps we should make a separate thread for that. This one is getting rather full.

My vision for this was more to support the kits that are given out with packs of breakfast cereal at trade shows and online marketing seminars. A sort of quickstart way of making these things useful.

OK

I’ll start a new thread

sheepdoll wrote: … A sort of quickstart way of making these things useful …

I created a new thread

viewtopic.php?f=42&t=328

The stuff in my HAL repo is now out of date, so I’ll need to do a pull from @sheeldoll’s repo and copy the files over, then update my F103CB files and push them all back to GitHub (not something I’ll be able to do until this evening)

Rick Kimball wrote:sheepdoll wrote: … A sort of quickstart way of making these things useful …

Someone will need to test the data logging speed of a $5 maple mini + SD reader.
Probably total cost $10 + cost of SD card.

However I suspect the bottleneck is the SPI interface to the SD.

The $15 F103VET and ZET boards, have SDIO which may be usable with your new HAL based core. But they are bigger and possibly heavier.

But i really depends on precisely why the AVR’s are considered too slow.

RogerClark wrote:
But i really depends on precisely why the AVR’s are considered too slow.

@sheepdoll

I guess you will use the STM midi stuff, but there is a port of lib maple, that just does midi. (I think Matthias ported/ updated a version of libmaple that does this)

Re: data storage

I know you don’t have these boards, but the $15 F103VE and F103ZE board from eBay mostly have I2C EEPROM and SRAM built onto the board.
I think it was something like 4Mbytes (dont quote me).

So it would depend on how much data you want store, whether that would be usable. I guess also, you’d need to determine , whether needing the data logging board to be functional on landing (so you can extract the data), is practical, or whether the likelihood of damage was high – hence using a the SD card which you can extract and put into the PC or Mac etc would be better.

RogerClark wrote:Someone will need to test the data logging speed of a $5 maple mini + SD reader.
Probably total cost $10 + cost of SD card.

However I suspect the bottleneck is the SPI interface to the SD.

The $15 F103VET and ZET boards, have SDIO which may be usable with your new HAL based core. But they are bigger and possibly heavier.

But i really depends on precisely why the AVR’s are considered too slow.