Electronics > Microcontrollers
stdlib + MCU haters: std itoa() uses less resources!
DavidAlfa:
Just had to show this to the old "I never use std libs in MCU" dogs ;), showing it's not always the case.
(Sure enough, the flash usage will blast off when using any std print function)
Custom itoa, taken form here (Can it get more simple than this?):
--- Code: --- char* _itoa(int val, int base){
static char buf[32];
int i=30;
for(; val && i ; --i, val /= base)
buf[i] = "0123456789ABCDEF"[val % base];
return &buf[i+1];
}
--- End code ---
End result was standard itoa using less resources overall ::). In custom itoa, sdtlib is not used at all.
Siwastaja:
You have invented a pretty interesting strawman. stdlib haters? I have never heard anyone criticizing itoa() as big or bloated. Maybe you are confusing itoa() and printf()? I do use my own itoa()-like function, but it's not because of assumed size or resource use, it's usability: my own returns a pointer to the end of the string, allowing easier chaining and thus more maintainable code.
(It would make very little sense to duplicate itoa(). Try with fixed base 10 instead - that would bring the code size down a bit; of course assuming base 10 is all you need.)
DavidAlfa:
I guess the compiler optimization should already notice that, as the function is called only with base 10?
C'mon, we've all seen lots of very polarized duDes here, still thinking we're in the 64-byte ram MCU era!
#include <std- STOP YOU FOOL!! Inefficient!! Wasting resources! Make it from scratch! Baremetal only! Waah!! :-DD
Siwastaja:
Alcohol?
Funny rant, but you are fighting against a made-up enemy. Your output would not make you look as ridiculous as it's now if you took a few moments to learn the basic concepts. A few points that would be helpful, but seeing you are a "us - them" direction brain, you are likely to ignore the chance to learn:
* bare metal refers to not using an operating system, such as RTOS. I'm sure your projects are mostly that way. A weird enemy to pick; maybe you think it means something else?
* I really can't remember anyone advicing against using the C standard library at all. It's part of the C standard and thus portable. Some particular functions are heavier (e.g. printf) than others (e.g. memcpy), and some are not always relevant on MCUs (e.g. fopen()). But using anything from C standard library considered harmful? A weird idea. I do remember Nominal Animal criticizing some C standard library interfaces, in particular file access functions (opendir() etc.), but this isn't very relevant in microcontroller systems.
* Recurring critique against some vendor-specific hardware abstraction libraries which abstract hardware poorly, limit the feature set of peripherals and lock in to a single vendor is what I have seen, and it's mostly spot-on. It's your call to make the right choice and you'll be responsible to your customers.
* Small RAM and ROM is pretty much still a thing. Very small and cheap gadgets have their place, not only in super inexpensive gadgets, but distributed IO controller nodes etc., too.
* Bigger reason than performance* to do things yourself is you get what needs to be done. Using existing work will limit the scope to that provided by said work.
*) not to say performance never matters
Last point is important; your opening post is a good summary of this recurring misunderstanding we are seeing, in other words:
>I need to do X
<Use libxxx, it does X, Y, Z, Å, Ä and Ö, and doing X requires doing Q, W, E, R, T, Y, U, I, O
>But I just need to do X so I wrote this 100 LoC piece which does X, why is it wrong?
<Geez, libxxx is 170kLoC and developed over tens of thousands of man-hours, why would you do all that from scratch?
>No but I'm not doing all that from scratch - guess what, nevermind.
Your opening post demonstrates this because you replicated the interface of itoa(), i.e., made another itoa implementation and compared performance to the existing work. Save for some very special cases, such work is not usually fruitful. Instead, you would write something similar (but not identical) to itoa(), but which solves your actual problem better. The reason for that work would not be poor performance of itoa(), but poor interface or functionality of itoa() for solving your particular problem.
The most important feature for a successful developer is to correctly identify when you are solving a truly complex problem which already has a solution you can reuse, and when you are not doing that.
T3sl4co1l:
Nice buffer overrun. :D
ASCII is built intentionally so that this kind of thing is easy: save memory by using digit = value % base + '0', and add 'a'-'0' - 10 (or 'A' if you prefer) when the remainder exceeds 9. Or don't even bother with the subtraction and set the bit(s) directly, since number and alphabet sequences are aligned.
You'll also save stack frame size and initialization by setting that string to static const. Always sanity-check your output when optimizing!
The one thing an implementation (as opposed to a fixed library blob) does gain is, if you're only using it for one base, the compiler can potentially collect and propagate const params and use multiplies or shift and mask for the arithmetic (if applicable). (Remainder is possible by multiplication, but I think it's not commonly implemented by compilers?)
Tim
Navigation
[0] Message Index
[#] Next page
Go to full version