simple way to get rid of leading zeors in a string in C

[cv007]

I want to stay away from printf, because it is not suited for small microcontroller due to its size!

Which mcu is in use? Which compiler?

[DavidAlfa]

If you only want to generate a string, try itoa() or ftoa(), much lighter than(s)printf, but you can't configure the output in any way.

Doesn't print leading zeros, though.

[kgavionics]

I want to stay away from printf, because it is not suited for small microcontroller due to its size!

Which mcu is in use? Which compiler?

Currently, I use a stm32f401 under keil arm uvison ( gcc), but I'm using avr 328p for other projects under Atmel studio ( gcc as well)!

[kgavionics]

If you only want to generate a string, try itoa() or ftoa(), much lighter than(s)printf, but you can't configure the output in any way.

Doesn't print leading zeros, though.

I looked for these function under stdlib (arm gcc), but they are not there! Where can I find them?

[AVI-crak]

I'm using gcc-arm-none-eabi-10_3, and RISC-V Embedded GCC - I don't get these errors.
Keil_v5 practices stricter code rules that are partly incompatible with GCC.
Rewriting code for Keil will require a separate project, and time. But I don't use Keil.
monitor.c is shared with the embitz1.1 IDE, I doubt you have it.
I explicitly indicated to write my own version of the soft_print(char* txt) function, because this is an output to a physical communication channel.
Here is a part of my code, it works without warnings, although a little meaningless GCC.
https://rextester.com/ODE66849

[cv007]

Currently, I use a stm32f401 under keil arm uvison ( gcc), but I'm using avr 328p for other projects under Atmel studio ( gcc as well)!

Neither case is an mcu to avoid printf/snprintf.

The avr printf is lightweight and easy to use. The arm takes some work to hook up printf to a destination, but snprintf is easy to use and is used the same for any mcu or pc, and your particular arm could fit printf on its little pinky fingernail. You can be 'bare metal' and still know when its better to use something that already exists.

avr printf (no great need to avoid printf in favor of snprintf as hooking up printf to a function is easy)-
https://godbolt.org/z/dGxG5a6Gh
(printf library increases code size by about 1.5k)

pc printf can be used to test-
https://godbolt.org/z/5qz7T6Mee


With the standard printf/snprintf you will have documentation, the ability to use/test on any mcu or pc, can get rid of all the little custom formatting functions you may be trying to use now, and once you start to use it you will wonder why you were trying to replace it.


An snprintf type for the arm where the buffer is on the stack, formatted, sent away to a function (which could put it in its own buffer, or direct to hardware), and returns when done (buffer on stack gets destroyed on return, but is ok since already transferred/used)-
https://godbolt.org/z/q7K3n5Mzz should be vsnprintf, not snprintf
https://godbolt.org/z/e1casGbbn
(vsnprintf adds about 3k in code size)

Lots of variations to get the same results, but the common denominator is you are dealing with the same printf style format description syntax.

[AVI-crak]

I hope I'm not doing someone thing stupid here!

I cleaned the functions from GCC features, now the code should build in Keil without errors.
As before, you first need to create a buffer

Code: [Select]

char print_buf12[12]; , and pass a pointer to the last element to the function.

Code: [Select]

&print_buf12[11]  This method allows you to avoid errors - you can immediately see the size of the buffer.

Code: [Select]

char* u32_char_m3 (char* tail_txt, uint32_t value)
{
    uint32_t res, tmp, drr;
    drr = 3435973837UL;
    *tail_txt = 0;
    do{
        tmp = (uint32_t)((uint64_t) value * drr >> 32);
        res = value + '0';
        value = tmp >> 3;
        tmp = value + (value << 2);
        res -= tmp << 1;
        *(--tail_txt) = res;
    }while (value);
    return tail_txt;
};

char * i32_char_m3(char* tail_txt, int32_t value)
{
    int32_t mi = value >> 31;
    if (mi) value = 0 - value;
    tail_txt = u32_char_m3(tail_txt, (uint32_t)value);
    *(tail_txt - 1) = '-';
    tail_txt += mi;
    return tail_txt;
};
The functions are already optimized for high speed, and small size. Despite the large number of symbols, the assembler code is compact and fast. Slow commands (divide and take a percentage) are not involved.
However, I strongly advise you to abandon Keil in favor of a more modern IDE.

[kgavionics]

However, I strongly advise you to abandon Keil in favor of a more modern IDE.

Do you have any suggestion please?

[AVI-crak]

You have no restrictions, unlike me (Russia).
I prefer to use frozen IDEs that don't update on their own with the complete destruction of all projects: embitz1.1, MounRiver Studio, Code::Blocks, as well as a large list of fast online services.
I highly recommend installing TortoiseGit (for home), and Git for the outside world. It's very hard to write anything serious without version control. You will be haunted by mistakes that cannot be corrected.
The list of IDEs available to you - can be found through search engines in a couple of minutes.

[kgavionics]

You have no restrictions, unlike me (Russia).
I prefer to use frozen IDEs that don't update on their own with the complete destruction of all projects: embitz1.1, MounRiver Studio, Code::Blocks, as well as a large list of fast online services.
I highly recommend installing TortoiseGit (for home), and Git for the outside world. It's very hard to write anything serious without version control. You will be haunted by mistakes that cannot be corrected.
The list of IDEs available to you - can be found through search engines in a couple of minutes.

Thank you for the heads-up AVI-crak!

[dobsonr741]

I prefer to use frozen IDEs that don't update on their own with the complete destruction of all projects

I was in this camp, until I realized it’s not sustainable. So I switched to Cmake + vs Code.
This way the build is not dependent on the IDE, and the build can run from the command line any time. Or from CI, if I really want to be fancy.

I agree, git is a must.