HAL libraries… no C++ or heap

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.


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.


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


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
Sun May 15, 2016 5:35 pm
just an attempt to use thread title to answer a fairly often asked question area

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.


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

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

wallaceowen
Mon Jul 17, 2017 8:55 pm
No arduino C++ code uses the heap, AFAIK.

The ATMega328 has only 2k of RAM, and there’s no malloc() let alone new(). All ram not allocated to named vars is used for the stack.

The ATMega2560 only has 8k, but can use up to 64K of external RAM for data (Harvard arch. means all code lives in the Flash)

So, all those C++ libs are written with the expectation that create objects are declared as static file-scope vars.


ChrisMicro
Tue Jul 18, 2017 7:48 am
The ATMega328 has only 2k of RAM, and there’s no malloc() let alone new(). All ram not allocated to named vars is used for the stack.

You can add your own new and delete:

#include <stdlib.h>

__extension__ typedef int __guard __attribute__((mode (__DI__)));

extern "C" int __cxa_guard_acquire(__guard *);
extern "C" void __cxa_guard_release (__guard *);
extern "C" void __cxa_guard_abort (__guard *);

int __cxa_guard_acquire(__guard *g) {return !*(char *)(g);};
void __cxa_guard_release (__guard *g) {*(char *)g = 1;};
void __cxa_guard_abort (__guard *) {};

void * operator new(size_t size)
{
return malloc(size);
}

void operator delete(void * ptr)
{
free(ptr);
}


Leave a Reply

Your email address will not be published. Required fields are marked *