integer to string

Go To Last Post
117 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This has been covered a few times but I can't seem to find an answer that works.

 

I'm using

void lcd_write_int(unsigned int data)
{
	 char st[16] = "";  //  Make space
	 itoa(data,st,10);
	 lcd_write_string(st);
}

to read data from and A to D and then I'm sending the data to my LCD display. Once over 32,768 the LCD displays - negative numbers. I tried with long but the same negative numbers.

 

Is there a long to string ?

 

Tried this but no numbers at all were displayed.

 

void lcd_write_int(unsigned int data)
{
    char st[10];
    sprintf(st,"%s",data);
    lcd_write_string(st);
}

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

marsheng wrote:
Is there a long to string ?

ltoa()

ɴᴇᴛɪᴢᴇᴎ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An int goes -32768 to +32767.

 

An unsigned int goes 0 to 65535 but you need to use utoa instead of itoa.

 

A long goes -2147483647 to 2147483648 and you use ltoa.

 

An unsigned long goes 0 to 4294967296 and you use ultoa to make a string.

 

see http://www.atmel.com/webdoc/AVRL...

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

… and they all live in the very same stdlib.h file. It's not like they're hard to find. ;-)

ɴᴇᴛɪᴢᴇᴎ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In GCC there is UTOA(Unsigned TO Ascii).  Here is a snippet of my use of it:

 

int main(void)
{
    AVR_INIT();
    spi_init();
    DISPLAY_INIT();

    while(1)
    {
        TCNT0 = 0X00;	//CLEAR TIMER0
        TCCR0B = 0X07;	//CONNECT T0 PIN TO COUNTER

        _delay_ms(1000);	//WAIT 1 SECOND

        TCCR0B = 0X00;	//DISCONNECT T0

        if(TCNT0 < 10000)
        {
            utoa(TCNT0+10000, buffer, 10);
            buffer[0]='0';
        }

        uint8_t cnt;
        dig = 0x05;
        cnt = 0x00;
        while(dig > 0)
        {
            inf = buffer[cnt++];
            Display_Digit(dig, inf);
            dig--;
        }
    }
}

 

I used it somewhere else as well, but I would have to dig for it.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

netizen wrote:
… and they all live in the very same stdlib.h file. It's not like they're hard to find. ;-)

Remember that the family of utility routines under discussion isn't part of standardized C.  So a particular toolchain may or may not have the mentioned routines, and they may or may not have prototypes in stdlib.

 

That said, for LCD work I'd want my numbers right-justified and leading-0 suppressed.  OP's approach gives suspicions of tracks being left behind -- what if the value changes from 109 to 99 to 8?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Sun. Aug 28, 2016 - 01:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Remember that the family of utility routines under discussion isn't part of standardized C. So a particular toolchain may or may not have the mentioned routines, and they may or may not have prototypes in stdlib.

True. But without any mention to the contrary, I'm assuming the standard avr-gcc/libc toolchain. I believe that's reasonable. :-)

ɴᴇᴛɪᴢᴇᴎ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know it's a bit of a radical concept but if one really wanted to know about such things it might always be possible to consult the manual...

 

http://nongnu.org/avr-libc/user-...

 

(and yes, I checked, OP is a GCC user - a June post says WInAVR in fact ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
OP is a GCC user

A hint:

marsheng wrote:
itoa(data,st,10);

Recent deja vu: https://www.avrfreaks.net/comment...

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks chaps. I learned something new. To me, an integer is a whole number. I'm reminded that integer in c and integer is -32768 to +32767 and I see that itoa follows that same format. I never even thought of looking for a ltoa.

 

That said, for LCD work I'd want my numbers right-justified and leading-0 suppressed.  OP's approach gives suspicions of tracks being left behind -- what if the value changes from 109 to 99 to 8?

 

Quite right, I write a blank line before I write the actual data.

 

What is OP ?

 

Lastly, what is wrong with, why no data to the LCD ?

 

void lcd_write_int(unsigned int data)
{
    char st[10];
    sprintf(st,"%s",data);
    lcd_write_string(st);
}

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just realized that itoa is for a signed integer, I presume there is no unsigned to string conversion.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP is original poster, in this instance -you.

%s expects a null terminated string, you gave it an int. %d might be more useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

marsheng wrote:
Just realized that itoa is for a signed integer, I presume there is no unsigned to string conversion

 

Read what I wrote in post #5

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or even follow the advice you got in #8 (though I realise that manuals are only for cissies who have no spirit of adventure). 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And if you don't like the standard versions you can always roll your own...

Below are 2 functions I've used for formatting numbers into a string.

 

//===========================================================================
// String Print a number with Fixed widht and precision (decimal point).
// Signed version.
void SPrintFixed( char* Buf, int32_t n, int8_t Length, int8_t Precision) {
	char Sign;
	ldiv_t	Number;

	if( n < 0) {
		n = -n;
		Sign = '-';
	}
	else
		Sign = ' ';

	Buf[Length] = 0x00;
	Number.quot = n;
	do {
		Number = ldiv( Number.quot, 10);
		Buf[--Length] = Number.rem + '0';
		if( --Precision == 0)
			Buf[--Length] = '.';
	}while( (Length > 0) && ((Number.quot) || (Precision >= 0)) );

	if( Sign == '-') {
		if( Length > 0)
			Buf[--Length] = '-';
	}

	while(Length > 0)		// Fill remaining space with spaces.
		Buf[--Length] = ' ';
}

//===========================================================================
// Integer to ascii, Fixed length.
// Copy from snippets.c Version: 2014-05-06.
static void ItoaF( char* Dest, uint32_t Number, uint8_t Digits, uint8_t Base){
	ldiv_t N;

	if(!Digits )
		return;		// No room to store the number.

	Dest += Digits -1;	// Write the number from back to front.

	if( Number == 0) {
		// Write the first digit.
		// Rest will be filled with spaces.
		*Dest-- = '0';
		Digits--;
		// Bug: Debugged, but this line is still missing in some other projects!.
		// Forgetting to decrement digits writes a space to many to the output.
		// 2014-05-06.
	}
	else {
		for( N.quot = Number; N.quot; Digits--, Dest--) {
			N = ldiv( N.quot, Base);
			if( N.rem > 9)				// Hex digit or similar.
				*Dest = N.rem - 10 + 'a';
			else
				*Dest = N.rem + '0';
		}
	}

	while( Digits--) {
		if( Base > 10) {
			if( Digits == 0)
				*Dest = '.';
			else if (Digits == 1)	// Prefix ".x" instead of the more common "0x"
				*Dest = 'x';		// makes printing columns with numbers more compact.
			else
				*Dest = '0';		// Hex digits always filled with zero's.
		}
		else
			*Dest = ' ';

		Dest --;
	}
}

 

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Need help ??

 

I have used this ADC program before and I got 0-255 as an output.

 

void init_adc()
{
	ADMUX = 0x00;					// Select Channel
	ADMUX = ADMUX | 0x40; 		// Selecting voltage reference
	ADMUX = ADMUX | 0x20;  		// Selecting Justification result
	ADCSRA = 0x07;					// Select Clock Frequency
	ADCSRA = ADCSRA | 0x80; 	// Enable ADC
}

unsigned char read_adc()		// Reading ADC and Returns a value
{
	unsigned char a;
	ADCSRA =ADCSRA | 0x40; 		// Starting Conversion
	while((ADCSRA & 0x10)==0);	// Wait for conversion to complete
	a=ADCH;							// Only read 8 bits
	ADCSRA = ADCSRA | 0x10;		// clearing the flag
	return a;
}

 

I'm using the same ADC routione but the LCD displays 0-65472.  The lowerst value above 0  was 64 but this still gives a resolution of 1024.

		ADC = read_adc();
		lcd_write_int(ADC);

 

 

void lcd_write_string(uint8_t String[])
{
	int i = 0;                             // character counter*/
	while (String[i] != 0)
	{
		lcd_write_char(String[i]);
                i++;
	}
}

void lcd_write_int(long data)
{
	char st[10];
	ltoa(data,st,10);
	lcd_write_string(st);
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
		ADC = read_adc();
		lcd_write_int(ADC);

Intriguing. Which AVR C compiler is this? Almost all of them predefine "ADC" as a dereferenced pointer to the 16 bit data register of the ADC so do you REALLY think it's wise to use such a name for your own variable or do you really mean to try to write back to the ADC register?!?

 

(apart from anything else you should reserve all upper case in C programs for the name of preprocessor macro names so it is clear to the reader/maintainer what a symbol name is).

 

By the way:

void lcd_write_string(uint8_t String[])
{
	int i = 0;                             // character counter*/
	while (String[i] != 0)
	{
		lcd_write_char(String[i]);
                i++;
	}
}

is more traditionally written as:

void lcd_write_string(uint8_t *String)
{
	while (*String)
	{
		lcd_write_char(*String++);
	}
}

You don't need "i" in this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are spot on.

 

ADC is a reserved word and contains the result. After a bit of expreimenting, this works fine. 0-65472.

 

 

void init_adc();

MAIN PROGRAM
	read_adc();
	lcd_write_int(ADC);	      



void init_adc()
{
	ADMUX = 0x00;					// Select Channel
	ADMUX = ADMUX | 0x40; 		// Selecting voltage reference
	ADMUX = ADMUX | 0x20;  		// Selecting Justification result
	ADCSRA = 0x07;					// Select Clock Frequency
	ADCSRA = ADCSRA | 0x80; 	// Enable ADC
}

void read_adc()		// Reading ADC and Returns a value
{
	ADCSRA =ADCSRA | 0x40; 		// Starting Conversion
	while((ADCSRA & 0x10)==0);	// Wait for conversion to complete
	ADCSRA = ADCSRA | 0x10;		// clearing the flag
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With the above code I get a few warnings.  One is on the function void read_adc() line which is

 

../LCD_Ver1.c:144: warning: return type defaults to 'int'

If the function void read_adc() is just running a routine, why does the compiler say of type int ?

 

If I put a void before the calling line read_adc(), the output is always zero.

 

 

Last Edited: Thu. Sep 1, 2016 - 02:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
void init_adc(void);
int read_adc(uint8_t chan);

MAIN PROGRAM
	lcd_write_int(read_adc(0));	      

void init_adc(void)
{
	ADMUX = 0x00;					// Select Channel
	ADMUX = ADMUX | 0x40; 		// Selecting voltage reference
	ADMUX = ADMUX | 0x20;  		// Selecting Justification result
	ADCSRA = 0x07;					// Select Clock Frequency
	ADCSRA = ADCSRA | 0x80; 	// Enable ADC
}

int read_adc(uint8_t chan)		// Reading ADC and Returns a value
{
    ADMUX = chan | 0x60;
	ADCSRA = ADCSRA | 0x40; 		// Starting Conversion
	while((ADCSRA & 0x10)==0);	// Wait for conversion to complete
	ADCSRA = ADCSRA | 0x10;		// clearing the flag
        return ADC;
}

Firstly, why would you have a function called read_adc that doesn't read the ADC? Who are you lying to?

The warning comes from you not having a prototype for your function read_adc, so it defaults to int.

Last Edited: Thu. Sep 1, 2016 - 03:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also don't use "magic numbers" like 0x10 and 0x40. Call them by their proper names which are ADIF and ADSC. It makes the code easier to follow. Also there is no need to use ADIF at all. Just block on ADSC (being set) and it auto-clears (unlike ADIF).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After a bit of reading, I can't find any register in ATMELs handbook called ADC. Is ADC a routine in an XXX.h file ? If so, it is reads both ADCH and ADCL.

 

I need to rename read_adc() to run_adc().

 

I'm still confused why the procedure run_adc() needs to beof  type int.

 

It appears that nothing needs to be returned as the result of running the routine puts the result into ADC.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As pointed out by Kartman, if a routine is not declared (or defined) prior to its usage, it will be assumed to return an int. Placing a declaration of the void function prior to its first usage will eliminate the error about it needing to be an int. ADC is defined as the 16-bit register comprised of ADCH and ADCL.

David

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found the mistake. As you have said, I forgot to define the function before using it. 

 

ADC is defined as the 16-bit register comprised of ADCH and ADCL.

Where did you find this ? I can't find it in the manual. When and where is ADC getting its value. Is it one of those atomic statements when you read ADC? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You didn't find anything - the error was pointed out to you. A number of other fundamental things were pointed out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

first on this computer I only use studio 4, and it has an other way for register setup.

 

for tiny85 there is a iotn85.h file and for things family it use iotnx5.h file that have this

#ifndef __ASSEMBLER__
#define ADC     _SFR_IO16(0x04)
#endif
#define ADCW    _SFR_IO16(0x04)
#define ADCL    _SFR_IO8(0x04)
#define ADCH    _SFR_IO8(0x05)

 

and that is why I use ADCW (and not ADC) in some of my code. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

marsheng wrote:
Where did you find this ?

In the documentation for the toolchain that >>you<< have chosen to use.

 

This newsgroup thread is interesting:

https://lists.nongnu.org/archive...

 

And many prior discussions:

https://www.avrfreaks.net/forum/a...

https://www.avrfreaks.net/forum/a...

https://www.avrfreaks.net/forum/a...

...

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Sep 1, 2016 - 01:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I see. I was wondering where ADC was in the ATMEL manual. It's not in there, it is in the compiler manual.

 

I guess saying it is the document is not sufficient, prefixing it with Compiler or Atmel would help.

 

I haven't worked with h files before other than a quick glance.

 

Thanks for the links. I now sort of understand.

Last Edited: Thu. Sep 1, 2016 - 09:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can some one explain exactly what this is (for any future reference). I see the timers could be read in the same way.

 

#define ADC     _SFR_IO16(0x04).

 

Thanks Wallace

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If we Google avr-gcc sfr

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks - Special Function Register.

 

I wonder if I'm ever going to get on top of programming ATMEGAs (or other micros) without throwing out a rescue line to you guys every time I try something new.

 

I have to say that getting something to work is quite rewarding. Takes me back  45 years when I played with 74XXX logic gates and got an LED flashing.

 

Cheers Wallace.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just about the time I think I've got it pretty well figured out, I get thrown a brand new surprise!.

David

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm hoping that in writing this down I'll see my mistake. This is a dummy routine to check syntax. I expect to print 51 but I get 50.

 

int tov_check(int);
int cntH;

/******************************* Main Program Code *************************/
int main(void)
{
   intH=0;  // Initial Value
   while(1)   
   {
	while(!(PIND & (1<<PD0)))      // wait for rising edge
	{
		cntH=50;
		tov_check(cntH);
		lcd_write_long(cntH);
		//code
	}
	while((PIND & (1<<PD0)))  	        // wait for falling edge
	{
	    //code
	}
    }
}

int tov_check(int data)
{
   data++;
   return(data);
}

Nope, still can't see the fault.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
cntH = tov_check(cntH);
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks. Never even thought of that option.

 

Now all working.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Understand the difference between pass by value and pass by reference.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

…otherwise you're gonna get caught again and again…

ɴᴇᴛɪᴢᴇᴎ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I see it is like arrays and pointers.

 

ltoa seems to not be working correctly - I get -31072 with this code.

 

 

void lcd_write_long(long);
	

/******************************* Main Program Code *************************/
int main(void)
	CODE
	cntH=100000;
	lcd_write_long(cntH);

}


void lcd_write_long(long data)
{
	char st[50];
	ltoa(data,st,10);
	lcd_write_string(st);
}

if I change the line to

	lcd_write_string("100000");

I get the right result.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm I tried

 

void lcd_write_long(long data)
{
	data = 1000000
        char st[50];
	ltoa(data,st,10);
	lcd_write_string(st);
}

and it gave the correct result, so it is something to do with the way cntH and data work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oops cntH is int not long !!!!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

marsheng wrote:
Yes I see it is like arrays and pointers.

Err no. When you supply a value to a function, C does this by 'pass by value', so if you have the variable 'a', it copies the value that is in 'a' and passes that to the function. The function can do anything it wants with that value but it doesn't affect 'a'. Pass by reference means the address of the variable 'a' is passed to the function. That means that the function can modify that variable and 'a' is changed. Pass by reference is using a pointer.

 

//Pass by value:
uint32_t a = 10;

    incval(a);      //this effectively does nothing
    a = incval(a);  //this increments a as we assign a value back to it

uint32_t incval( uint32_t val)
{
    val++;
}


//Pass by reference:
uint32_t a = 10;

    incval(&a);         // & is the 'address of' a
    //a now equals 11
    
void incval(uint32_t *val)
{
    *val++;
}

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a tad curious

 

How many clk does the ltoa take? (just the ballpark of AVG and max).

 

I remember that I looked at it using mul with 1/x to solve it. It can be done in about 300 clk max (AVG is close to the same). 

(it will need the HW mul instruction)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

How many clk does the ltoa take? (just the ballpark of AVG and max).

 

I don't have avg or max, but ltoa (1000000, buff, 10) took 147us with 16MHz clock on an ATmega328P.

The ltoa() used 148 bytes of flash.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck99 wrote:
ltoa (1000000, buff, 10) took 147us with 16MHz clock on an ATmega328P.

That's 147x16=2352 clock cycles!

LOL

ɴᴇᴛɪᴢᴇᴎ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

netizen wrote:

Chuck99 wrote:

ltoa (1000000, buff, 10) took 147us with 16MHz clock on an ATmega328P.

 

That's 147x16=2352 clock cycles!

LOL

 

I encourage you to run your own test so that we can compare the results.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Chuck99 wrote:
I encourage you to run your own test so that we can compare the results.

I am in no way criticizing your test result. I think it's laughable precisely because it's likely accurate.

ɴᴇᴛɪᴢᴇᴎ

Last Edited: Mon. Sep 12, 2016 - 10:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

iota/ltoa/etc are aimed at human eyeballs so I don't think they are the target for strong optimisation. It also does not help that they offer radix 2..36, if they just did decimals he code could likely be optimised for that.

 

But as it is human eyeballs why does it matter?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
But as it is human eyeballs why does it matter?

It of course does not in this regard. It might in so far as it is stealing (potentially precious) cycles from other parts of the code.

Had I been the one who coded it, it would itch like hell… Not that you need to care.

Anyway, it'd probably be much faster with a simpler feature set indeed.

ɴᴇᴛɪᴢᴇᴎ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The great thing about AVR-LibC is that it is open source and a collaborative development. If anyone finds parts to be deficient they can easily pull the source, improve it then push the change. :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If anyone finds parts to be deficient

This stretch is yours alone. :-)

I wouldn't give up 2300+ cycles to put 1000000 in a string. But then I'd probably have to settle for a simpler feature set than ltoa provides. And we both know the reasons it does so go beyond avr-libc…

ɴᴇᴛɪᴢᴇᴎ

Last Edited: Mon. Sep 12, 2016 - 12:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's pretty slow. I estimate a dedicated utoa specialized for base 10 result would take about 20-25% of those 2300 cycles. It would need 5 16x16 bit multiplies, according to AVR200 each such multiply takes about 100 cycles, so 500 cycles total. And I'm sure this is a worst case estimate with plenty of room for optimization, if written in assembly.

Pages