HAL libraries... no C++ or heap

Development of new Cores using the STMCubeMX and HAL
stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

HAL libraries... no C++ or heap

Post by stevech » Sat May 14, 2016 9:50 pm

So far I"ve found no C++ or heap-using code in the HAL code; it's all standard C.
This includes the following
  • FATFS - ST's adaptation of ChanFS. Straight C. Stack is used for temporary 512 byte buffers (e.g., DIR and so on)
    SDIO driver for uSD cards and FATFS
    MCU PLL and clocking setup (auto-generated)
    USARTs - DMA, Interrupt, polling
    SPI, DMA, Interrupt, polling, multiple SPI ports
    GPIO in, out, edge change interrupts
    Timers including DMA in high speed pulse sample times
    Watchdog timers (IWD)
    FSMC intgerface - DMA, polling
I've not used but have read about the other peripherals (on chip) and they seem to also be generic C.

User avatar
Slammer
Posts: 243
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: HAL libraries... no C++ or heap

Post by Slammer » Sat May 14, 2016 10:40 pm

ST notes about HAL:
The drivers source code is developed in Strict ANSI-C which makes it independent from the
development tools. It is checked with CodeSonar static analysis tool. It is fully documented and is
MISRA-C 2004 compliant.
also
APIs are RTOS compliant:
- Fully reentrant APIs
- Systematic usage of timeouts in polling mode.
- Object locking mechanism: safe hardware access to prevent multiple spurious accesses to shared resources.

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

Re: HAL libraries... no C++ or heap

Post by RogerClark » Sun May 15, 2016 12:07 am

@stevech

What does your post relate to.

It doesnt seem to be a question.

We have at least 2 other threads about the HAL. So it would probably make more sense to post to them, rather than starting another

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: HAL libraries... no C++ or heap

Post by stevech » Sun May 15, 2016 5:13 am

This is in a forum section called HAL and CubeMX. So it seemed appropriate.
There has been discussion of the use of C++ in Arduino libraries.

A key point is that some ST supported high level libraries like FATFS from Chan are strictly C, whereas many Arduino libraries use C++ classes with constructors that use the heap, and other forms of dynamic memory allocation.

Feel free to nuke the whole thing.

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

Re: HAL libraries... no C++ or heap

Post by RogerClark » Sun May 15, 2016 6:09 am

Hi @stevech

It just seemed a to be a post as statement, which is unusual

I can move it to one of the other HAL threads

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: HAL libraries... no C++ or heap

Post by stevech » Sun May 15, 2016 5:35 pm

just an attempt to use thread title to answer a fairly often asked question area

Ollie
Posts: 188
Joined: Thu Feb 25, 2016 7:27 pm

Re: HAL libraries... no C++ or heap

Post by Ollie » Sun May 15, 2016 6:25 pm

Thanks Steve.

The start of this chain could be unusual, but the given statement had valuable information that is available only after some involved investigations. The location of this chain seems proper.

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

Re: HAL libraries... no C++ or heap

Post by sheepdoll » Sun May 15, 2016 9:31 pm

stevech wrote:just an attempt to use thread title to answer a fairly often asked question area
Made perfect sense to me. I ask this question in my head a lot.

Can not remember if it is here as well. On the AVR forums there are a lot of threads relating to C++ and the commercial compilers. The gist of it is that in "real" process control work C++ is not allowed due to dynamic memory allocations and no real garbage collection. C++ is security risks as well as reliability risk. You can not predict where the code, and or interpretable values, are stored for later execution. Do you really know the state of your state machine when the state variable is somewhere on a stack that could be overwritten by a rouge pointer or unbounded array?

User avatar
Slammer
Posts: 243
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: HAL libraries... no C++ or heap

Post by Slammer » Sun May 15, 2016 10:02 pm

I think that C++ without dynamic allocation is OK for critical systems.
I always do: a) set heap size to 0 at linker script, b) define an empty, custom new constructor c) no STL libraries.
Anyone can say that this is not C++, but a C with classes, which is partially true.

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: HAL libraries... no C++ or heap

Post by stevech » Mon May 16, 2016 12:11 am

Slammer wrote:I think that C++ without dynamic allocation is OK for critical systems.
I always do: a) set heap size to 0 at linker script, b) define an empty, custom new constructor c) no STL libraries.
Anyone can say that this is not C++, but a C with classes, which is partially true.
(emphasis is mine)

I agree. But many/most casual coders don't know about the affect of code in constructors, coalescing time penalties, and so on.

Post Reply