HAL libraries… no C++ or heap

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.

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.

@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

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.

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

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

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.

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

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.

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.

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.

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