Page 3 of 3

Re: Some updates to F4

Posted: Wed Aug 19, 2015 10:07 pm
by madmalkav
I was not looking for what tool shall I use to code as much as helping with the stm32duino port. But if I can help with your branch in any way, I'll be glad.

Re: Some updates to F4

Posted: Wed Aug 19, 2015 11:18 pm
by sheepdoll
Rick Kimball wrote:
sheepdoll wrote:Understanding the STM32CubeMx tool should be a good first step for an IT/Coder. It is graphical, runs on all platforms.
Runs and being useful are two different things. On linux it runs, but much of the the GUI doesn't work, so it is not really a viable tool.
I was thinking that the CFQ might be more interested in using this with windows. On OS X there is only one part that does not work, the pin configurator, should one want to override the default suggestions. I figured it was the same on Linux.

Re: Some updates to F4

Posted: Thu Aug 20, 2015 12:06 am
by sheepdoll
madmalkav wrote:I was not looking for what tool shall I use to code as much as helping with the stm32duino port. But if I can help with your branch in any way, I'll be glad.
If you were working with a F1xxx it makes sense to continue with the stm32duino F4 port. I guess the other question would be do you want to use the F4 as an Arduino, connect shields, devices etc. or do you want to get your hands dirty writing the low level library code? If it is a matter of using things like SPI and I2C, then F4 is not the right platform. Core library coders on the other hand are few and far between ...

On the "maple" F4 core I found there was simply too much low level hardware device specific fixed coding. Basically I was having to rewrite sections from the ground up. The F1 and F4 cores are not in sync. F1 is much more mature. F4 came from an earlier maple branch and was targeted to a specific F4 and a specific quad copter drone controller board.

I did a lot of work a few months back getting the F4 Nucleo stuff to work based on the F1 Nucleo stuff. The lack of serial streams in the F4, became too much work , so I came up with using the CubeMx code directly. Why I now have a separate branch.

Nucleo does help as these boards always use an 'R' series chip with a fixed number of pins. Where things get complex is that something simple like a serial port is on one group of pins on one chip and another on a different chip. There are options that do map things is a consistent sort of way. These are known as alternate pin functions. The F4 core has different names and orders in the tables. To complicate things, these tables point directly at hardware register addresses, so there is not a 1 to one map. CubeMx solves this and I get other cores like the F0 I have been playing with for free.

Re: Some updates to F4

Posted: Thu Aug 20, 2015 2:04 am
by RogerClark
I think unless you are a hardened coder that trying to modify the core is going to be a steep learning curve.

If you want to get the F4 Nucleo working, its hard choice, because from what I recall the Nucleo F103RB board has a load of specific config stuff which Matthias had to write to get it to work with the F1 Maple core.

You'd be best off PM'ing @madias and asking him the quirks of the Nucleo

So, I have a feeling that working with @sheepdoll's latest core may be worth looking at, rather than trying to hack the Maple F4 (aka AeroQuad) core to work with the Nucleo F4

But of course there are no libraries yet for @sheepdoll's core. So perhaps writing the SPI library for that core would be a good use of time ?

Re: Some updates to F4

Posted: Thu Aug 20, 2015 2:53 am
by sheepdoll
RogerClark wrote:
But of course there are no libraries yet for @sheepdoll's core. So perhaps writing the SPI library for that core would be a good use of time ?
Could not think of a better suggestion myself. Even having a second person working through the blink and serial stuff would be a help.

I did get some of the wiring (digital i/o) and serial print stream libraries working. I made an examples folder for this. Even having a second person working through the blink and serial stuff would be a help.

Writing a SPI library would probably be fairly easy using the HALMX branch, and It would probably work across most of the cores.

Since the CubeMx enables the SPI hardware, when setup() is called SPI is all set to go. All one has to do is write a wrapper for the SPI code to read and write using the HAL callbacks. Most of this is fairly high level c++. in the setup there is an attach typically a spi.begin() class. the loop would call the read and write stream class for something like spi.read() and spi.write(). The fiddly part is making this simulate the AVR clock rates and hardware pin placements.

Re: Some updates to F4

Posted: Thu Aug 20, 2015 3:05 pm
by madmalkav
Will try to look at it in the next days. I'm currently busy with some unexpected home improvement works :/

By the way, I still need to understand how all that sea of stuff interrelate between. I thought CubeMX was just a GUI for making the MCU initialization code easier, and the HAL are some ST provided libraries to use against standard GCC-ARM?

And you are writing a layer to use that stuff with standard Arduino stuff, but libraries needs to be ported, right? So we must look for STM32 libraries like this and adapt them to the Arduino standard?

As you can see there is some stuff I still need to glue in the correct order in my head...

PS: I confess I have been playing a little with the mBed stuff, but don't take me for a traitor :D

Re: Some updates to F4

Posted: Thu Aug 20, 2015 5:38 pm
by sheepdoll
madmalkav wrote:Will try to look at it in the next days. I'm currently busy with some unexpected home improvement works :/

By the way, I still need to understand how all that sea of stuff interrelate between. I thought CubeMX was just a GUI for making the MCU initialization code easier, and the HAL are some ST provided libraries to use against standard GCC-ARM?
That is a way of looking at it. CubeMX evolved from a device specific platform such as CubeF4. This was sort of a marketing tool. A way for non technicals to search for which product was best for an application, then download the docs and manufactured supplied setup codes. The older stuff used device specific libraries called Standard Peripheral Libraries.

More recently (I think about 6 months ago) CubeMX was released which was built so it would generate the Hardware Abstraction Libraries (HAL) rather than the Standard Peripheral libraries. This added the feature to export the boilerplate C code as well as the project folders for a number of GCC IDEs. Specifically System Workbench for STM32 which is found on the openstm32.org website.
And you are writing a layer to use that stuff with standard Arduino stuff, but libraries needs to be ported, right? So we must look for STM32 libraries like this and adapt them to the Arduino standard?
Yes, the need is for transparent Arduino stuff. stm32f4-discovery.com is more for Coocox CoIDE or the propretary IDEs like Kiel. One of the reasons I was asking in my initial response as to your preferred IDE and tool chain.
As you can see there is some stuff I still need to glue in the correct order in my head...
There is a lot to wrap one's head around. The following is a sort of basic outline of what exists and what is is needed when working with Bare Metal Hardware (BMH).

CMSIS -- Cortex® Microcontroller Software Interface Standard -- this is common across multiple vendors so STM provide's a version, Atmel provide's a version (Like for the Arduino-Due,) etc. In the case of STM, This is generated by CubeMx, or can be downloaded as part of the developer package. Users probably never will modify this. (Or should not modify it) In theory one could take the Atmel due and wrap the "Arduino Core" on top of this. There are several examples online of abandoned efforts at this.

HAL -- Hardware Abstraction Layer -- provided by STM through CubeMx replaces the Standard Peripheral Library. Handles the initialization of the CMSIS. Parts of this are and need to be user modified. http://www.st.com/st-web-ui/static/acti ... 105879.pdf Is a good place to start to see what features are available.

MAPLE -- Arduino Core -- this is the "glue" you are looking for. Currently I use the Maple headers, structures and where I can C++ constructors to call or define Arduino/processing callbacks. Most of this needs to emulate AVR hardware and timings.

SYSTEM -- System Libraries -- mid level glue that supports specific devices. This is where things get gray. Is SPI (which exist on AVR core or system?) To confund things, is that on AVR SPI is used for ISP. To make SPI even more confusing Arduino puts the user LED on the same pin as the SPI clock. So many Arduino devs, create a bit banged SPI library to use different GPIO pins.

USER -- User generated Library-- An example of this, as it is easiest to implement, would be a MMC/SD card interface socket. This calls back through the above chain. Where it gets fuzzy is does it use bit banged SPI or Hardware SPI? What happens when using something like cortex and there are more than one hardware SPI ports to choose from? Then there are speed issues. MMC/SD initializes at one speed, then when it is ready, the speed is increased to maximize the data rates. Ideally we want the Arduino Core and system libraries to be transparent so that when one uses a nifty device from sparkfun or adafruit, the user supplied libraries work just like the tutorial.


PS: I confess I have been playing a little with the mBed stuff, but don't take me for a traitor :D
I could never get mBed to work, It always comes back with the compiler offline error message.

Re: Some updates to F4

Posted: Thu Aug 20, 2015 10:32 pm
by madmalkav
Well, just with that HAL pdf I have reading for some days ;)

(By the way, I didn't had problems with mbed online or exported, perhaps a macosx thing?)

Re: Some updates to F4

Posted: Fri Aug 21, 2015 1:05 am
by martinayotte
madmalkav wrote:(By the way, I didn't had problems with mbed online or exported, perhaps a macosx thing?)
Me neither, although I've used mBed with LCP1768, not STM ...
But also, many libraries are buggy, and their authors are not responding posts about it, even for bug fixes submits ... :(