Nucleo F401 branch on github sheepdoll

Limited support for STM32F4 Discovery, Nucleo and custom F4 boards
User avatar
sheepdoll
Posts: 238
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by sheepdoll » Sun Jun 14, 2015 6:35 am

RogerClark wrote:Re: delay();

I'm not sure why we cant use the HAL_Delay() for delay() ? They are both in milliseconds.
I did. Seems to work.
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.
I sort of got that impression too. I do not know what or how many things use uSec timing. My existing code polls on AVR timers, so that is always an option. The sam code has two versions on wiring.c I scrubbed one that seemed Atmel specific. the other was commented out and I left it in.
To be honest I have not read a lot of Arduino/Processing code. So I do not really know what the advanced users do.

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

http://stackoverflow.com/questions/2487 ... hal-driver
I'll take a look at that. There is quite a bit of serial examples in the ST stuff downloaded by CubeMX. I found the syscall.c file which I think hooks printf into the serial stream. At least that is what the example does. When I included one of the Arduino functions it wanted '_sbrk' I stubbed it out, but with the actual STM file it compile fine (syscall.c looks like it is part of a GCC distro.)

I am quite rusty on C++ having most recently programmed postscript with some ObjectiveC (Was playing with swift before this project caught my attention. Actually I was working on making swift talk to one of my existing AVR boards. I probably should be working on the desktop UI, but this is so much more interesting at the moment. )

At the moment I am looking for where the Arduino sam code attaches the Hardware serial to the stream classes. This is done different to the way your changes to maple libs are coded.

Arduino sam does not seem to use HardwareSerial.c instead it creates it's own low level static library based on manufacture supplied code from Atmel. That looks to be pre compiled into a separate static library with make. I think Koduino does this also. If I search for serial1 it is part of USB. Serial_ seems to be defined in UART an inherited by USART. I noticed that the HAL documentation sometimes interchanges UART and USART.

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.
That is what the HAL code seems to be doing. I am probably over thinking what is necessary.

User avatar
Rick Kimball
Posts: 1071
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by Rick Kimball » Sun Jun 14, 2015 5:05 pm

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
-rick

User avatar
sheepdoll
Posts: 238
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by sheepdoll » Sun Jun 14, 2015 6:04 pm

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 ;)

User avatar
Rick Kimball
Posts: 1071
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by Rick Kimball » Sun Jun 14, 2015 6:19 pm

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 ;)
You make me chuckle

-rick
Last edited by Rick Kimball on Sun Jun 14, 2015 9:14 pm, edited 1 time in total.
-rick

User avatar
mrburnette
Posts: 2060
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by mrburnette » Sun Jun 14, 2015 7:35 pm

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.

Can you qualify "baggage"? Are the below items anti-baggage?

- Faster?
- Smaller?
- Less SRAM dependencies?
- More easily maintained?
- More easily understood?


Ray

User avatar
Rick Kimball
Posts: 1071
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by Rick Kimball » Sun Jun 14, 2015 8:00 pm

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

User avatar
mrburnette
Posts: 2060
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by mrburnette » Sun Jun 14, 2015 8:04 pm

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
Now, that's the truth!

Ray

User avatar
Rick Kimball
Posts: 1071
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by Rick Kimball » Sun Jun 14, 2015 8:12 pm

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

User avatar
RogerClark
Posts: 7552
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by RogerClark » Sun Jun 14, 2015 10:58 pm

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

User avatar
mrburnette
Posts: 2060
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Nucleo F401 branch on github sheepdoll

Post by mrburnette » Sun Jun 14, 2015 11:15 pm

RogerClark wrote:<...>
But, I don't think it does any harm for people to investigate the HAL as an option
Certainly not! If one cannot play with their toys... it would surely be a sad day. Already, sheepdoll has exceeded what I would have initially expected.

Ray

Post Reply