Author Topic: stdlib + MCU haters: std itoa() uses less resources!  (Read 17261 times)

0 Members and 1 Guest are viewing this topic.

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #50 on: June 01, 2023, 08:51:07 am »
Sorry but this just sounds like yet another attempt to justify re-inventing the wheel. I wrote to use the Posix API

What %f does is part of API specification. If %f does not work, then it's not conforming. You can shift the blame ("it's not API but implementation which is broken") but the end result is the same: it's not POSIX conforming, it won't work as expected, it requires extra documentation, and it will cause confusion to users who expect standard-compliant behavior. This is of course all fine usually with "competent engineers" but kinda destroys the basis of your argument. Those competent engineers can as well work with another function with another specification (probably simpler).

API is meaningless if the implementation does not stick to API. That's the whole point.
« Last Edit: June 01, 2023, 08:52:57 am by Siwastaja »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #51 on: June 01, 2023, 10:49:55 am »
So, what is your alternative to printf then? Have functions like 'print_text()' 'print_text_1number' 'print_text_2numbers()' 'print_newline()' ? I have come across messes like that... And good luck trying to work with others on such projects.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #52 on: June 01, 2023, 12:42:13 pm »
So, what is your alternative to printf then? Have functions like 'print_text()' 'print_text_1number' 'print_text_2numbers()' 'print_newline()' ? I have come across messes like that... And good luck trying to work with others on such projects.
First of all, you can use C99 _Generic or C++ to put the parameter type variants under a single interface name.  Indeed, Arduino does exactly this with print() interface.

Second, a printf() interface that supports some but not all features is more difficult to work with, than implementing a completely different interface.

While a new interface is extremely easy to utterly fuck up –– and I believe those are what you have encountered ––, better interfaces are eminently possible.

In the thread I mentioned, I was foremost talking about really constricted environments, where every byte matters, and there a string builder approach with different functions to append/prepend data not only makes it possible with minimal resource wastage, it also allows users to prune (or build system to auto-prune) the implementation to only the subset of used functions.  When such interfaces are designed, it is easy to fall into the trap of focusing on specific use cases (the ones I happen to have at hand, for me); and the only way to combat that is to get constructive criticism.

You, nctnico, are only providing the criticism of "I've never seen that work nearly as well as using a subset of printf()", which is not useful, because I myself have, both source (maintenance) and binary code (efficiency, resource use) wise "better than printf()".  It may not look pretty to your eye, but for me and those I've worked with, it has worked very well.  (Granted, the reverse string building I like, can be a bit much to grok... I only use it in very specific situations, where every bit of overhead matters and no equivalent forward-building is available.)
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #53 on: June 01, 2023, 12:58:03 pm »
So, what is your alternative to printf then? Have functions like 'print_text()' 'print_text_1number' 'print_text_2numbers()' 'print_newline()' ? I have come across messes like that... And good luck trying to work with others on such projects.
First of all, you can use C99 _Generic or C++ to put the parameter type variants under a single interface name.  Indeed, Arduino does exactly this with print() interface.

Second, a printf() interface that supports some but not all features is more difficult to work with, than implementing a completely different interface.
My experience is the other way around. Over the years I have setup many microcontroller projects for others to build upon. There has never been a complaint about printf not working as expected. I rarely get questions about my code anyway.

The reality is that a printf that can print text and integers and do some formatting is super small to implement and sufficient for 99.9% of the programs that run on microcontrollers. Don't forget the systems that C was originally developed on, have less resources than the average modern day microcontroller. Also, people are used to printf because it comes standard with C and is used in every textbook. If you are going to provide something different, then this just needs more time to learn. And again, it makes sharing code between projects harder because some projects (or existing code) will use printf. Standarisation is very important in order to be able to maintain various software projects and share code between them.

Many years ago I worked with a brilliant senior software engineer who had created some very elegant libraries for implementing protocol stacks. Everybody found it brilliant work but nobody wanted to touch his code. Way too complicated to use. At some point not wanting to use his code even became a running gag during lunch break. I made a mental note not to become the laughing stock amongst coworkers where it comes to technical abilities. IOW: KISS is king.
« Last Edit: June 01, 2023, 01:17:41 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #54 on: June 01, 2023, 01:38:51 pm »
My experience is the other way around. [...] Many years ago I worked with a brilliant senior software engineer who had created some very elegant libraries for implementing protocol stacks. Everybody found it brilliant work but nobody wanted to touch his code. Way too complicated to use. At some point not wanting to use his code even became a running gag during lunch break. I made a mental note not to become the laughing stock amongst coworkers where it comes to technical abilities.
Well, that's your choice.  My experience, and choice, differs.

To me it sounds like you and your coworkers were the inept kind, making fun of others to hide your own insecurities and lack of ability.  I definitely wouldn't want to work with you or them, if what you told is true.  I believe only a weak-minded idiot values his coworkers opinion above the quality of their work, and I don't work (long) with idiots, as they never produce anything useful or interesting anyway, just the same shit in a new package.

IOW: KISS is king.
No.  KISS is a good principle, but so is the Principle of Least Surprise, too.  I would claim the latter beats the former, when use and maintenance is involved.

Now, this affects the "elegant libraries" you mentioned, too.  Maintainability, usability, effectiveness, robustness, security, and resource use, are the key factors when I evaluate code.  They all need to be baked in to the design at the get go, and cannot be added afterwards (except through a full rewrite, or at least a significant refactoring).  It does sound like the way you used "elegant", does not include those important facets, and only relates to surface appearance or something, in which case that kind of "elegance" is utterly useless and irrelevant to me.  It is like saying a library was written by a very respected author.  Fine; but I've gotten 'PTSD' from maintaining Perl code created by people I really appreciate, so much so I do not touch Perl or Perl code anymore, so having a respected author means nothing in real life.  It only means something to superficial people who care more about appearance than content.

Maintainability and usability are crucial.  Yes, they do need to be tailored to the level of their maintainers and users, but we're not talking about general applications development (which is mostly done by human-shaped trained monkeys), but specialized embedded development, so I do believe requiring more than one might from say average apps developers is warranted.

(Then again, I for sure would never produce code to a bulk production house where quality and security are only found in advertisements on the marketing side, and true commercial demands of today may mean that "we must use printf() because our developers are too stupid to handle anything different".  So, consider my requirements somewhat more stringent than typical software houses or FOSS projects.)
 
The following users thanked this post: Siwastaja

Offline wek

  • Frequent Contributor
  • **
  • Posts: 486
  • Country: sk
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #55 on: June 01, 2023, 01:50:25 pm »
> KISS is king.

And, printf() is anything but KISS.

JW
 
The following users thanked this post: SiliconWizard

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #56 on: June 01, 2023, 02:30:09 pm »
My experience is the other way around. [...] Many years ago I worked with a brilliant senior software engineer who had created some very elegant libraries for implementing protocol stacks. Everybody found it brilliant work but nobody wanted to touch his code. Way too complicated to use. At some point not wanting to use his code even became a running gag during lunch break. I made a mental note not to become the laughing stock amongst coworkers where it comes to technical abilities.
Well, that's your choice.  My experience, and choice, differs.

To me it sounds like you and your coworkers were the inept kind, making fun of others to hide your own insecurities and lack of ability.  I definitely wouldn't want to work with you or them, if what you told is true.  I believe only a weak-minded idiot values his coworkers opinion above the quality of their work, and I don't work (long) with idiots, as they never produce anything useful or interesting anyway, just the same shit in a new package.
Wrong conclusion. It was a classic case of over-engineering and trying to push it onto others as being a good solution. It is like sending a 10 page letter in beautifully worded language while 5 short sentences would have sufficed to carry the same message across. Sometimes you see that in electronics too when engineers get a chance to design a very creative circuit which works wonderfully but in the end it has too many parts and the same goal can be achieved by much simpler circuitry.

A too narrow focus on primary features together with freaking out a bit while losing sight of the big picture.
« Last Edit: June 01, 2023, 03:49:47 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #57 on: June 01, 2023, 03:58:22 pm »
My experience is the other way around. [...] Many years ago I worked with a brilliant senior software engineer who had created some very elegant libraries for implementing protocol stacks. Everybody found it brilliant work but nobody wanted to touch his code. Way too complicated to use. At some point not wanting to use his code even became a running gag during lunch break. I made a mental note not to become the laughing stock amongst coworkers where it comes to technical abilities.
Well, that's your choice.  My experience, and choice, differs.

To me it sounds like you and your coworkers were the inept kind, making fun of others to hide your own insecurities and lack of ability.  I definitely wouldn't want to work with you or them, if what you told is true.  I believe only a weak-minded idiot values his coworkers opinion above the quality of their work, and I don't work (long) with idiots, as they never produce anything useful or interesting anyway, just the same shit in a new package.
Wrong conclusion. It was a classic case of over-engineering and trying to push it onto others as being a good solution. It is like sending a 10 page letter in beautyfully worded language while 5 short sentences would have sufficed to carry the same message across. Sometimes you see that in electronics too when engineers get a chance to design a very creative circuit which works wonderfully but in the end it has too many parts and the same goal can be achieved by much simpler circuitry.

A too narrow focus on primary features and losing sight of the big picture.
Well, like I wrote later on in that post, I don't know exactly what "elegant library" means.

I don't do "elegant".  I strive for useful, maintainable, robust, and secure.  Robust includes things like not silently ignore errors that indicate possible data loss, and things like doing something sane when inputs are outside the expected range, not just silently hope for everything to be okay.

Some stuff, like certain linear algebra operations in a fully hosted environment, I target towards "minimally proficient developers", but anything embedded or resource-constrained or security-sensitive, I definitely expect/demand more than a minimal skill to maintain or use.

It is like sending a 10 page letter in beautyfully worded language while 5 short sentences would have sufficed to carry the same message across.
Ha ha.  :(
I am not verbose because I want to, I am only verbose because I consistently fail to be concise.  I wish I was less verbose, and quite often envy other members who manage to say what I tried to convey in a prior long message with just a couple of sentences.  Me fail English, and I know it.

I read and write a lot of technical English, but speak or deal with social stuff only rarely.  This makes English quite difficult for me, and this is the best I can do for now.  I'm working on it.

Sometimes you see that in electronics too when engineers get a chance to design a very creative circuit which works wonderfully but in the end it has too many parts and the same goal can be achieved by much simpler circuitry.
As a hobbyist, and looking at teardowns by Big Clive and others, I tend to only see the other kind: cutting corners and copy-pasting without true understanding.
I cannot tell from Dave's examinations of test equipment if any have overengineered circuits – even parts "gilding the lily" seem to actually help keep the devices within their specified operating parameters.

On the software side, I consistently see developers like DJB and their work product being laughed at, while their bug density is much lower than just about anyone elses.  I recall a time around the turn of the century when I used exclusively qmail for a mail transfer agent (email server), and got utterly stupid flak about not using Sendmail instead.  (Why?  Because Sendmail, being the "recommended solution", is about as secure as handing a random tweaker the keys to your house, and telling you're off to a long weekend vacation.  Just go look at the CVEs regarding it.  Qmail/netqmail isn't exactly bug free either, but it is closer than anyone else has gotten in the mail service field.)

So yeah, I really don't put much weight to when a random person laughs at some code.  Without seeing the code for myself, it is equal chances to be either ridiculous code, or a ridiculous person laughing at something beyond their skill level and suffering from Dunning-Kruger.
 

Offline AVI-crak

  • Regular Contributor
  • *
  • Posts: 124
  • Country: ru
    • Rtos
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #58 on: June 01, 2023, 06:47:00 pm »
I'm a little lost on the thread of the conversation, who wins?
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #59 on: June 01, 2023, 07:49:16 pm »
I'm a little lost on the thread of the conversation, who wins?

Like you said.
 

Offline wek

  • Frequent Contributor
  • **
  • Posts: 486
  • Country: sk
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #60 on: June 01, 2023, 08:18:12 pm »
Like you, sad.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #61 on: June 01, 2023, 08:33:59 pm »
I'm a little lost on the thread of the conversation, who wins?
If you think a conversation is about winning then the content is lost on you indeed   8)
« Last Edit: June 01, 2023, 08:43:14 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline AVI-crak

  • Regular Contributor
  • *
  • Posts: 124
  • Country: ru
    • Rtos
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #62 on: June 01, 2023, 08:52:01 pm »
If there is no winner, then I will continue to use
printo("text", double, float, uint(8-16-32-64)_t, int(8-16-32-64)_t )
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #63 on: June 02, 2023, 10:24:58 am »
I'm a little lost on the thread of the conversation, who wins?
At this point, we have established that nctnico and I have opposite experiences on what kind of output/string construction API in embedded environments are useful and maintainable.

Anyone else have worked with others on this arena?  Do you have clear experiences on this?
 _ _ _ _ _

Documentation, and comments describing intent rather than operation (i.e. "We need to compensate for ..." instead of "Decrease variable count"), make a huge difference here.

I've mentioned before that I myself never try to memorize details like the order of parameters for memset(); I always keep a browser window (to man7.org) or a terminal window (for man) open for quickly verifying things.  I make a point of finding good documentation I can use to find things quickly and efficiently.  It is better use of my time.

At one point at the university, I did sysadmin and development stuff in a cubicle.  A couple of my cow-orkers initially looked at the way I kept references open when writing code, "humorous"; as if "proper" developers didn't do that.  In a month or two, seeing the code quality and the very low bug rate, they changed their mind and started doing the same.

This also means that when I create a library for others to use, I believe half the job is proper documentation and examples.

(This includes documenting which functions are async-signal safe, if run on POSIXy systems, as well as any locking schemes applied or applicable.  I personally do prefer using compiler-provided atomics in POSIX C (these) in libraries to implement lockless thread-safe schemes if possible, even if it is not standard C and thus absolutely portable.  Practice trumps theory and standards.)
 _ _ _ _ _

I can see that in environments where consulting man pages and documentation and references is seen as a "weakness" or "lack of 1337 coding skillz", an interface that reminds developers as much of printf() as possible, is preferable over a new interface.

However, there are many standard C -related details (like how the compiler can replace a printf("...\n") without any formatting specifiers with a puts("...")) can that can create surprising problems via that approach.  (It is why one does not change just some parts of the standard C library, but replaces it wholesale, on top of freestanding environment, even when running under an OS.)

I agree with Siwastaja that when one implements an API, it is important to implement the full API, or otherwise one is just undermining the API in the first place.

Sometimes, it is reasonable to cater ones interface towards most inexperienced programmers.  But when it comes to embedded development, Arduino already does that, and anything serious should be targeted towards more experienced programmers – the kind that does not worry about whether their coworkers will laugh at them for keeping the documentation to the libraries constantly open and accessible.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #64 on: June 02, 2023, 01:30:30 pm »
Nah, it's just classic nctnico pattern: nctnico knows what is the generally right way to do everything, and those who prefer to have choices and base their choice on thinking/design are wrong. Goalpost shifting is also always involved to make it look like those who originally wanted to keep all doors open, including nctnico's preferred way, now seemingly are generally against whatever nctnico is suggesting while no one ever made such claims. This is called projection: nctnico projects his own inability to understand multitude of options to others.

Now I do admit that if you have to do cargo cult engineering and if you need to dumb down the design to some rules of thumb, nctnico's rule set is relatively good, and infinitely better than letting 1000 random monkeys produce random work from scratch. This is why nctnico probably has been mildly successful in many medium-difficulty projects, and the projects that have failed due to being deemed impossible to achieve are easy to dismiss just as that. nctnico is probably a successful manager in a semi-large team of mediocre programmers / implementors who do little to no design.

I use printf in some projects and in some projects I do not, it's simple as that.
« Last Edit: June 02, 2023, 01:41:12 pm by Siwastaja »
 
The following users thanked this post: SiliconWizard

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #65 on: June 02, 2023, 01:54:28 pm »
BTW, the interface of printf utterly sucks: to print out int64_t type you have to type:

Code: [Select]
printf("%" PRId64 "\n", var);
This is, when you do care about portability, type correctness, and code that does not produce warnings and questions about whether it works correctly or not. So even if possible to hide the type with function overloading in C++, I don't really mind using self-made functions like itoa_64 over the bullcrap shown above.

But such details about performance, correctness and ease of use are not important to everyone. One-size-fits-all function which is most familiar to beginners (yet misused by most said beginners) must be the best in all use cases because nctnico says so.
« Last Edit: June 02, 2023, 02:22:48 pm by Siwastaja »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #66 on: June 02, 2023, 03:17:24 pm »
Nah, it's just classic nctnico pattern: nctnico knows what is the generally right way to do everything,
An ad-hominem attack does not prove your point and is rather childish as well.  :palm: Maybe just stick to the subject and play the ball.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #67 on: June 02, 2023, 04:37:11 pm »
Nah, it's just classic nctnico pattern: nctnico knows what is the generally right way to do everything,
An ad-hominem attack does not prove your point and is rather childish as well.  :palm: Maybe just stick to the subject and play the ball.

You make fun of your coworkers and play their contribution down because of your own job insecurity - and I'm making fun of you in response. I'm describing your repeating pattern, maybe you see it as an attack against your person but it really is against your position* and your opinion about others, and the absolute, generic, exception-less nature thereof.

*) Oxford Languages says: Ad hominem: (of an argument or reaction) directed against a person rather than the position they are maintaining.

Rockstars in software design are a risk and you clearly want to mitigate that, but you miss they are also an opportunity. Integrate them into your community and you can be more successful than when aiming for mediocre.

I admit of being such a rockstar nature and I thus have both colossal failures but some successes too. It depends a lot of the environment, too.

What you really need to do for your company to thrive on Bell Labs level is to detect skills, accept the fact some people are brilliant without getting envious about it, and then invest resources not only to enable them to work, but also get them some minions who will help them in documentation and learn about their thought process.
« Last Edit: June 02, 2023, 04:56:13 pm by Siwastaja »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6171
  • Country: fi
    • My home page and email address
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #68 on: June 02, 2023, 05:19:11 pm »
In the Linux kernel, the printk() interface is used for kernel logging (because the compiler can verify the conversion pattern against the parameters specified, and complain at compile time if they do not match).  However, to extend the formats, they add additional characters after the conversion specifier.

The full printf() formatting rules are quite extensive.  Many do not realize you can refer to specific parameters by their order, as long as you do it for all parameters.  (This is required for things like localization, or localized formatting patterns via e.g. gettext(), to work.)

Similarly, full string escaping rules in (POSIX) C are nontrivial.  Just look at e.g. C17, and check if yours support \L…, \u…, or \U….  Also verify that '\x123' != '\0443' (even though 0x123 == 0443), because of how octal and hexadecimal escape sequence parsing differs.  Hint: '\0443' == '$3'.  See C17 6.4.4.4; it even has examples describing these.
 _ _ _ _ _

In C99 or later, even in very memory-constrained situations, it is possible to write a macro that expands arguments (starting at a specific argument) into separate calls, which in turn are expanded via the _Generic facility to type-specific function calls.  For example,
    emit(FOO, BAR, BAZ);
can be expanded to
    emit_init(); emit_int(FOO); emit_float(BAR); emit_str(BAZ);
where the _Generic selects emit_int() for FOO, emit_float() for BAR, and emit_str() for BAZ.  You can also have common initial parameters, for example specifying the string buffer to construct the string into.  The number of macro arguments is limited, but in practice is several dozen at least.

This can actually save a lot of resources, because you do not parse anything at run time.  Something like
    emit(buf, "Command ", cmd_id, " complete.\r\n");
can be transmogrified by the preprocessor into say
    emit_init(buf);
    emit_str(buf, "Command ");
    emit_uint(buf, cmd_id);
    emit_str(buf, " complete.\r\n");
which is definitely useful.  With a good _Generic statement, you'll even get reasonable error messages if your variable type is not supported.

I also like to have a final emit_end(), which terminates the string buffer and returns the length of the constructed string if successful, or negative error code if an error occurred –– for example space ran out.  In that case,
    err = emit(buf, "Command ", cmd_id, " complete.\r\n");
actually expands to
    err = ( emit_init(buf),
            emit_str(buf, "Command "),
            emit_uint(buf, cmd_id),
            emit_str(buf, " complete.\r\n"),
            emit_end(buf) );
where err is assigned the return value from emit_end(buf), so it is basically equivalent to
    emit_init(buf),
    emit_str(buf, "Command "),
    emit_uint(buf, cmd_id),
    emit_str(buf, " complete.\r\n"),
    err = emit_end(buf);
The functions are called in the specified order, but the other return values are ignored.  This is because of the C comma operator behaviour (see C17 6.5.17).

(If we want to add optional formatting, things get complicated.  The best option I've discovered is to wrap the value in a macro, say FORMAT(variable, fmtspec), which expands to a ((const struct formatted){ .ref = &(variable), .spec = &(fmtspec)}), and thus via _Generic detecting that structure type to emit_fmt(buf, ((const struct formatted){ .ref = &(variable), .spec = &(fmtspec) })); assuming the fmtspec also defines the type of variable.  The fmtspec itself could be a const structure (with common field specifying variable type, and an union of substructures, one per type), a simple string, a pointer to the formatting function to use, or even a struct initializer (with a small modification to above), depending on what is most useful way to implement emit_fmt() or its equivalent(s).)
 _ _ _ _ _

On 8-bitters that emit such constructed strings via UART or similar, having to construct the string into a linear array first, consumes unnecessary memory resources.  Instead, it would be better to record the formatting recipe, and have the UART interrupt generate the next character in the recipe dynamically, using minimal amounts of RAM.

One method is to have two reserved pointer values, END (0) and VALUE (-1), so that the recipe is just a sequence of pointers to ROM/Flash strings (stored in ROM/Flash) terminated with an END pointer.  Whenever current sequence pointer is VALUE, the next character in the associated RAM buffer (where the pre-converted values are stored) is emitted; if the current sequence pointer is not END, the next character in that ROM/Flash string is emitted.  The UART interrupt overhead should be quite small and not vary too much.  In RAM, we need the space for the converted values as strings, one pointer to a ROM/Flash pointer to ROM/Flash, one pointer to ROM/Flash, one pointer to RAM, and a status byte (for quick return when there is nothing to be sent), or so.

Unfortunately, I have NOT found any sensible way for describing such in C99 or later.  Preprocessor macros can be magic, but the best I can do thus far is similar to emit() above, constructing all (including the pointer array) in RAM, which is not optimal.  Having the UART state buffer be global, with dedicated uart_emit() function to append to the state buffer, makes for an acceptable interface, I guess.  You do need to reserve some "extra" for the conversion buffers, and take care you interact correctly with the UART TX interrupt, but it is possible to buffer another message while one or more previous ones are still being sent, as long as there is sufficient RAM for the pointers and the stringified values.  To avoid sending partially constructed strings, the state needs to have shadow copies for the pointers and status byte, fixed at the emit_end() phase.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #69 on: June 02, 2023, 05:51:10 pm »
Nah, it's just classic nctnico pattern: nctnico knows what is the generally right way to do everything,
An ad-hominem attack does not prove your point and is rather childish as well.  :palm: Maybe just stick to the subject and play the ball.

You make fun of your coworkers and play their contribution down because of your own job insecurity
You are grasping straws here -again-. Read again, I never wrote that I was making fun of someone. I wrote somebody got made fun of by others without naming names. And FYI that has been going on long before I joined that particular company. If my posts irritate you, just ignore them. This is a free world.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #70 on: June 02, 2023, 06:01:13 pm »
I've mentioned before that I myself never try to memorize details like the order of parameters for memset(); I always keep a browser window (to man7.org) or a terminal window (for man) open for quickly verifying things.  I make a point of finding good documentation I can use to find things quickly and efficiently.  It is better use of my time.
I do that too. There is no need to memorise that what can be looked up quickly. Books and internet are great for that.

Quote
This also means that when I create a library for others to use, I believe half the job is proper documentation and examples.
And getting the documentation out there & actually read by others is equally important. I do quite a lot of specification and documentation work as part of systems design. Despite the documentation being shared online with the various teams I'm part of, I regulary get questions that are clearly outlined in the documentation. I've given up getting bitchy about that a long time ago. I just answer the question with saying sorry for the documentation not being clear.

From that I also learned that it is easier to stick with code that has been documented already. In the past I regulary introduced a version of strcpy that takes the size of the target buffer and makes sure that a terminating 0 is at the end of the string even if that means the string is cut short. This to avoid dangling strings and all the mayhem this could cause. I noticed though that using this unknown function confused some and it was hard to keep track of whether it was used properly. Nowadays I mandate the use of snprintf() for simplicity sake. It is known to exist and well documented.

Quote
I agree with Siwastaja that when one implements an API, it is important to implement the full API, or otherwise one is just undermining the API in the first place.
It is industry practise to do this though for space and performance reasons. In uclibc, newlib and many other small C libraries a lot of functionality has been cut. In the end something has got to give. In most C libraries targeted for microcontrollers, printf() doesn't support printing floating point numbers for example. Are those implementations suddenly useless?
« Last Edit: June 02, 2023, 06:38:06 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 8106
  • Country: fi
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #71 on: June 02, 2023, 06:39:45 pm »
Are those implementations suddenly useless?

Not at all! Just that somebody has said:
"There really is no reason to avoid using printf and it's cousins"
I can see many reasons, including need to print floating point numbers in less than 20K.

"Adhering to Posix is a good idea in general. "
But these do not adhere to POSIX, so  :-//

A bonus:
"Re-inventing a wheel is never good."
If wheels were never reinvented, we wouldn't have any of the nice things of today as our wheels would be still made out of wood. Re-inventing a wheel is sometimes absolutely required, and you should be able to separate re-inventing the wheel from duplicating a wheel. Latter is futile work if you can go and buy the exact wheel you need. And I think this is what the inventor of the saying was actually thinking, but ended up with a crappy saying.
« Last Edit: June 02, 2023, 06:52:06 pm by Siwastaja »
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #72 on: June 02, 2023, 07:25:57 pm »
That's for sure.

Everything must have a good rationale in engineering.

If you can't trust an engineer to write a simple itoa() like function, correct, in a matter of a few minutes and with your team's codestyle and coding guidelines (which can be a non-negotiable aspect in some environments that almost no third-party code will bring you), why would you ever trust them to code anything at all? It's probably going to be a completely trivial and negligible piece of code compared to the rest of the firmware anyway.

Some reasonable measure should be used instead of cargo cult approaches. Obviously there's a world between writing a few, relatively simple functions and writing, say, a full TCP/IP stack.

As I said in other threads though, engineering management is difficult, and in many ways is unfortunately orthogonal to engineering in general.
So yes, as a manager you often have to make decisions that will cause the least discomfort if anything goes awry (which often means deciding whatever is easy to justify to your upper management), whereas as an engineer, what you want is design correct stuff, and if anything needs fixing, having devised a reasonable design that is easy to maintain and having reasonable tools to fix it.

As a side note, adhering to POSIX for MCU development (at least generally speaking) makes little sense. On a more elaborate:standard platform, essentially a hosted one, it does.
 
The following users thanked this post: Siwastaja

Offline AVI-crak

  • Regular Contributor
  • *
  • Posts: 124
  • Country: ru
    • Rtos
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #73 on: June 02, 2023, 07:32:27 pm »
The general tone of the conversation is reminiscent of a Sunday fight between two Yakozuna.
It doesn't matter how the debug information is printed. It doesn't matter the number of ways to print debug information in the whole project. It is important where and how the print is applied.
The fact is that debugging information is not needed by the finished program, it is simply not needed. When all the bugs and errors are revealed, leaving protruding ears is simply stupid.

All programs are made up of functions that call functions that call functions, and so on. This is not related to stack depth, but has a dependency on individual project files.
You have an open project file, the very first function you wrote (conditionally), and it has bugs. For debugging, you need a lot of lines of diagnostic information, and that's okay.
When a function (or a whole library) starts working without errors, the internal debugging information can be removed, it is no longer needed. However, control of input parameters is necessary!!! Because even a serviceable function can produce wild nonsense with inadequate input parameters.

Ok, you have a new 100500th project file, completely without errors, with adequate function calls from the first file. Now from the first file (library) you can remove the control of input parameters.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: stdlib + MCU haters: std itoa() uses less resources!
« Reply #74 on: June 02, 2023, 07:36:50 pm »
As a side note, adhering to POSIX for MCU development (at least generally speaking) makes little sense.
There is a bit of a disconnect here. Let me try to clarify once more: there is no need to implement everything from Posix if it is not necessary (see the many small, limited C libraries out there) but just take from Posix what suits you. In the end it will make things easier because you start from a well defined standard instead of making up your own. There is no need to jump between black & white and start nitpicking over 'completeness' (when there is a new version out, completeness is redefined anyway). In a restricted environment something has got to give and that is clear to everyone. If more functionality is needed for a project (for example to use an existing piece of code), you can always add that later on.
« Last Edit: June 02, 2023, 09:07:45 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf