Author Topic: setting up a to program a SAM device in C++  (Read 10686 times)

0 Members and 2 Guests are viewing this topic.

Offline SimonTopic starter

  • Global Moderator
  • *****
  • Posts: 18908
  • Country: gb
  • Did that just blow up? No? might work after all !!
    • Simon's Electronics
Re: setting up a to program a SAM device in C++
« Reply #50 on: March 13, 2025, 01:47:31 pm »
Yes sprinf() is certainly useful. What I am doing at the moment is a C++ class that will handle one value to be put on a graphical display. The class holds various details such as if I want it printed right justified, the coordinates on screen, will it flash, will it be colour inverted, how fast it will flash ect.

So my itoa is to simply put the value into a string that will then be put into the display buffer.

I'll try the options suggested in the IDE - microchip studio, if I do end up wanting the ETL or any other library that needs _sbrk dealing with I will need to sort this out anyway.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 17814
  • Country: fr
Re: setting up a to program a SAM device in C++
« Reply #51 on: March 13, 2025, 02:53:52 pm »
Anything calling sbrk means that there are heap allocations. That's something you may or may not want. I think getting rid of the STL was a way of avoiding heap allocations. But using anything related to printf (at least from the newlib library that ships with the compiler) will use heap allocation.

If you manage to get rid of all heap allocations, sbrk shouldn't be necessary.
 

Offline cv007

  • Super Contributor
  • ***
  • Posts: 1061
Re: setting up a to program a SAM device in C++
« Reply #52 on: March 13, 2025, 09:25:54 pm »
If you dig into the newlib source, even if confusing and easy to get lost trying to decipher it, it appears that the use of sprintf/snprintf sets the __SWR and __SSTR FILE flags (FILE struct on stack in sniprintf function), and with those flags set you do not reach any call to malloc. No malloc call, no heap used and no need for _sbrk to do anything useful.

simply providing the _sbrk function that always returns a failure-
int _sbrk(int){ return -1; }
will allow the use of sprintf/snprintf, which WILL also bring in _malloc_r whether it actually gets used or not (and _sbrk_r which calls _sbrk). Since we know the heap is not used for sprintf/snprintf, but to satisfy the potential call from _malloc_r to _sbrk_r and ultimately _sbrk (user provided in the case of the current newlib nano library) that _sbrk function must exist.

This simple single line of code for the _sbrk function will satisfy the requirements to get snprintf working without the need to get into details of using the heap. If the heap is later wanted, or it starts being used without your knowledge (with the resulting malloc failures), then the _sbrk function will need to change to allow it.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->