[riot-devel] 6LowPAN on STM32F3

Hauke Petersen hauke.petersen at fu-berlin.de
Mon Sep 22 09:54:38 CEST 2014


Hi Abhinav,

in the cpu/stm32f3 folder you find the syscalls.c. The malloc 
implementation of the newlib should end up somewhere in the _sbrk_r() 
call, not sure actually how the free call is implemented... But if its 
working for you for now.

Cheers,
Hauke


On 20.09.2014 01:38, Somaraju Abhinav wrote:
> Hi Hauke,
> hope you had a nice holiday and thank you for the input. I have removed oneway_malloc.c from my build paths and the malloc and free are now working fine for me. It is a bit strange but I am not able to tell for sure how this is working. It seems that there is a some standard implementation of these calls that the gnu-arm compiler knows where to find. So right now my program is working okay. I will let you know how things are going if I find out more.
> Regards,
> Abhinav
>
>
> -----Original Message-----
> From: devel on behalf of Hauke Petersen
> Sent: Sat 9/20/2014 12:29 AM
> To: RIOT OS kernel developers
> Subject: Re: [riot-devel] 6LowPAN on STM32F3
>   
> Hi Abhinav,
>
> sorry for the late reply, just came back from holidays...
>
> You have to be careful about using dynamic memory allocation on the Arm
> Cortex-M platforms (especially the ones I ported, which include the
> discovery boards). As malloc is implemented, free does nothing. So
> switching from oneway_malloc.c to libc calls won't really bring any
> benefits at the moment. The only viable workaround is to use static
> memory and manage it yourself (-> which is what Martine is preparing as
> we speak...).
>
> Cheers,
> Hauke
>
> On 17.09.2014 08:52, Somaraju Abhinav wrote:
>> Thanks Martine,
>>
>> I have been using the oneway_malloc.c implementation and not libc! I
>> will change that now. I definitely like the idea of a static
>> implementation much better.
>>
>> Regards,
>>
>> Abhinav
>>
>> *From:*devel [mailto:devel-bounces at riot-os.org] *On Behalf Of *Martine
>> Lenders
>> *Sent:* Mittwoch, 17. September 2014 08:50
>> *To:* RIOT OS kernel developers
>> *Subject:* Re: [riot-devel] 6LowPAN on STM32F3
>>
>> Hi,
>>
>> currently the reassembly buffer is implemented with libc's malloc/free
>> but my new implementation will utilize a static approach via my own
>> packet buffer implementation [1]. For your purposes I think it is ok
>> for now to use malloc/free as a workaround, but keep in mind that for
>> some boards where the libc is not offering this, there is currently
>> not even a free implementation [2].
>>
>> Regards,
>>
>> Martine
>>
>> [1] https://github.com/RIOT-OS/RIOT/pull/1638
>>
>> [2]
>> https://github.com/RIOT-OS/RIOT/blob/master/sys/oneway-malloc/include/malloc.h#L60
>>
>> 2014-09-17 8:43 GMT+02:00 Somaraju Abhinav
>> <abhinav.somaraju at tridonic.com <mailto:abhinav.somaraju at tridonic.com>>:
>>
>> Hello Martine,
>>
>> Thank you for the quick reply. I am trying to figure out work around
>> this problem. Do you think it makes sense for me to use the libc
>> malloc and free functions? I am a bit hesitant to include the library
>> because it might be too big and/or interfere with how the RIOT core is
>> using the syscalls.
>>
>> Thanks,
>>
>> Abhinav
>>
>> *From:*devel [mailto:devel-bounces at riot-os.org
>> <mailto:devel-bounces at riot-os.org>] *On Behalf Of *Martine Lenders
>> *Sent:* Dienstag, 16. September 2014 17:18
>> *To:* RIOT OS kernel developers
>> *Subject:* Re: [riot-devel] 6LowPAN on STM32F3
>>
>> Hello Abhinav,
>>
>> I'm currently refactoring this part, so thanks for pointing that out.
>> I will look out for this.
>>
>> Regards,
>>
>> Martine
>>
>> ________________________________________________________
>> The contents of this e-mail and any attachments are confidential
>> to the intended recipient. They may not be disclosed to or used
>> by or copied in any way by anyone other than the intended recipient.
>> If this e-mail is received in error, please immediately notify
>> the sender and delete the e-mail and attached documents.
>>
>> Please note that neither the sender nor the sender's company
>> accept any responsibility for viruses and it is your responsibility
>> to scan or otherwise check this e-mail and any attachments.
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org <mailto:devel at riot-os.org>
>> http://lists.riot-os.org/mailman/listinfo/devel
>>
>> ________________________________________________________
>> The contents of this e-mail and any attachments are confidential
>> to the intended recipient. They may not be disclosed to or used
>> by or copied in any way by anyone other than the intended recipient.
>> If this e-mail is received in error, please immediately notify
>> the sender and delete the e-mail and attached documents.
>>
>> Please note that neither the sender nor the sender's company
>> accept any responsibility for viruses and it is your responsibility
>> to scan or otherwise check this e-mail and any attachments.
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>
> ________________________________________________________
> The contents of this e-mail and any attachments are confidential
> to the intended recipient. They may not be disclosed to or used
> by or copied in any way by anyone other than the intended recipient.
> If this e-mail is received in error, please immediately notify
> the sender and delete the e-mail and attached documents.
>
> Please note that neither the sender nor the sender's company
> accept any responsibility for viruses and it is your responsibility
> to scan or otherwise check this e-mail and any attachments.
>
>
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20140922/1fa2c45c/attachment.html>


More information about the devel mailing list