Re: Hard fault in __free_r

[Trampas Stern <trampas at gmail dot com>]

Freddie,

Thanks for the information!

What I was trying to do using the smart pointers was to make a way to start
and stop peripherals for low power.   The basic idea is something along the
ideas of:

size_t print(char *str)
{
Uart *ptrUart = Board->getUart0();  // gets pointer to Uart0, if no one is
using Uart0 it powers on and initializes it.
// Use uart as needed .

} //at end of function the uart is released, in the board board class it
will power off uart0 if no other code is using it.


I found two problems:

1. was that smart pointers allocate memory from stack, which I did not want.
2. the __free_r problem.

I went back to doing the "C way" where I call an acquire() and release()
function.

Again I am an old school embedded guy, but like some of the C++ features.
One of the things I dislike about C++ is also its advantage, that is it
does things like the delete behind the scenes.  I have almost decided it is
better to use the acquire() and release() such that next guy reading code
(me in 6 months) knows what it is doing and then use the C++ delete feature
to be an error check that you called release().

I was getting ready to do a project using an RTOS (was thinking freeRTOS)
but I will look at your project.

Trampas

On Sat, Dec 2, 2017 at 9:32 AM, Freddie Chopin <freddie_chopin@op.pl> wrote:

> I'm resending the message again, this time with proper (not wrapped)
> links (; sorry for that...
>
> ----------------------------------------------------------------------
>
> Hello Trampas!
>
> Your mistake here is that when using placement-new you MUST NOT call
> delete. The memory is not from the heap, therefore trying to return it
> to the heap (via calling delete, which in turn calls free) is just
> completely wrong and forbidden by the language.
>
> Your object must be explicitly destructed manually or via special
> delete-function supplied to the smart pointer (I assume you talk about
> things like std::unique_ptr<>). Therefore you either need to do:
>
> ptrUart->~Uart();
>
> when you are done, or - if you use smart pointers, create a no-op
> function and supply that to the smart pointer during construction.
>
> I have done something like that in my C++11 RTOS for ARM
> microcontrollers. Here is the "no-op deleter" which I mentioned:
>
> https://github.com/DISTORTEC/distortos/blob/master/include/
> distortos/internal/memory/dummyDeleter.hpp
>
> You may create a type alias for your smart pointer to make things
> easier:
>
> https://github.com/DISTORTEC/distortos/blob/master/include/
> distortos/internal/scheduler/Stack.hpp#L37
>
> And then you just assign both the pointer _and_ the deleter to the
> smart pointer object, for example see the highlighted line:
>
> https://github.com/DISTORTEC/distortos/blob/master/include/
> distortos/StaticThread.hpp#L58
>
> With this design the smart pointer can use any kind of memory - the
> only difference is in the deleter you have to supply which will be
> executed at the end. If you want to also use devices which are really
> dynamically allocated (from the heap, with normal `new` or array-
> `new`), then just use a different function, like this one:
>
> https://github.com/DISTORTEC/distortos/blob/master/include/
> distortos/internal/memory/storageDeleter.hpp
>
> Usage example:
>
> https://github.com/DISTORTEC/distortos/blob/master/include/
> distortos/internal/scheduler/DynamicThreadBase.hpp#L214
>
> BTW - if you use C++ and happen to work with an ARM Cortex-M
> microcontroller, you may find my project quite interesting, at least I
> hope so (;
>
> Regards,
> FCh
>
>