uint8_t question

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi all, i am new to AVR..what is uint8_t exactly? is it an unsigned 8 bit integer datatype? i have tried to search the forum but havent seen a complete answer. appreciate any help..

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

yes

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

After several decades of programmers inventing their own short macro definitions for the standard c variable types like 'unsigned integer', they were finally standardized in a header file 'stdint.h'. Having a standard declaration theoretically improves readablility, but I didnt have much trouble understanding what an unsigned integer was.

Imagecraft compiler user

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

Quote:

but I didnt have much trouble understanding what an unsigned integer was.

Maybe not but you'd have a difficulty saying how many bits wide it was. On AVR 'int' is 16 bits wide while on ARM and x86 it is 32 bits wide. However int16_t is a 16 bit wide integer no matter what CPU architecture you are programming on - that's the whole point of embedding 8, 16, 32, 64 in the stdint.h type names. When you see int16_t you know that the programmer expects the object to hold -32768..+32767 just as uint8_t holds 0..255 and int8_t holds -128..+127

It's all about making your code more readable and obvious for the maintainer who comes to it in 6 months time (which may actually be you!). Anything that aids an understanding of what's going on, numeric ranges and so on is MOST welcome.

Cliff

PS npat_avr, which c compiler are you using? - in your other thread your were asking about LCD - I think all but IAR come with example HD44780 code

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

The size was clearly explained in the fine compiler manual.

Imagecraft compiler user

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

OK then if I write:

#include 

int16_t m=32767;
int n=32767;

int main(void) {
 printf("m=%d", ++m);
 printf("n=%d", ++n);
}

What will be output? I suggest you cannot predict the n value unless you know which architecture this was written for (and, like you say, it'll probably involve a visit to the compiler's manual). Meanwhile you can totally predict what m will be without knowing the architecture or needing to consult any manual.

Cliff

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

Quote:

What will be output? I suggest you cannot predict the n value unless you know which architecture this was written for (and, like you say, it'll probably involve a visit to the compiler's manual). Meanwhile you can totally predict what m will be without knowing the architecture or needing to consult any manual.


Hmmm--this may be a good example to make your point, or maybe not.

The printf "%d" will only handle up to the int width of the environment. You only learn that by RTFM so there is a visit there anyway.

[IIRC int cannot be narrower than 16 bits so I guess that you are safe with your example.]

Lee

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

OK make that "%ld" then to remove that unknown or forget printf() all together - stop it in the debugger and inspect m and n

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

Is it supposed to be -32768?

Imagecraft compiler user

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

I haven't decided which CPU architecture it is yet so cannot tell you. THAT is my point.

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

Yeah, the standard header file is ten years too late for me. I got my header file and I'm sticking with it.

Besides this stuff looks like C to me. C++ programmers spend their days defining types and they don't usually end them with _t, or any special suffix.

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

I figgerd out that its 0x7fff plus 1. So I know the bit pattern of the answer.... 0x8000... how that gets printed out doesnt have much to do with cpu archtecture I hope...

Imagecraft compiler user

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

Observe:

root@ubuntu:/home/cjl# cat test.c
#include 
#include 

int16_t m=32767;
int n=32767;

int main(void) {
  printf("m=%ld\n", ++m);
  printf("n=%ld\n", ++n);
}
root@ubuntu:/home/cjl# gcc test.c -o test
root@ubuntu:/home/cjl# ./test
m=-32768
n=32768

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

Cool. I was right. If I'm so darned smart, how come I aint rich yet?

Imagecraft compiler user

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

If I had built that same program on an AVR the answers would have been:

m=-32768 
n=-32768

So 'm' was completely predictable, 'n' not so.

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

Unless one had read the manual, right?

Imagecraft compiler user

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

The last thing one wants when looking at some code is to have to dig out a load of different manuals - if the programmer was a professional he'll have done everything conceivable to make the code completely self documenting. One way to do that is stdint.h, another is to use constructs such as:

ADCSRA = (1<<ADEN) | (1<<ADATE) | (1<<ADIE) | (5<<ADPS0);

or

// Enable ADC, free-run, enable interreupt, prescale /32
ADCSRA = 0xAD;

when I see just:

ADCSRA = 0b10101101;

it really depresses me - evidence of someone who's never had to worry about maintaining their own code or that of others.

Same goes for interface to external devices -the driving code should document data out of the datasheet for the functionality being exercised to prevent the casual reader having to go off hunting for the relevant datasheet (sometimes almost untraceable)

stdint.h is just one of the tools for making code more self-documenting. To be honest I don't really mind if it's stdint.h itself that's used or something equally obvious (UI8, I16, UI32, etc) as long as the programmer has made SOME effort to help the maintainer.

Cliff

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

I think that it has less to do with self documentation and more to do with keeping the code working properly. Suppose you had a routine in a library that took an int. Compiling that library on a machine that has 32 bit ints it might work just fine. Re-compiling it to a machine that uses 16 bit ints, it might not work properly. But if you used int32_t, it will work no matter what target you compile it for.

Regards,
Steve A.

The Board helps those that help themselves.

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

Steve,

That's quite true, but for me, it's main advantage is self-documentation - maybe only secondary, but important none the less - well it is for me anyway.

But clearly my example above shows something that would behave differently between AVR and x86 - an int holding 32767 that is then incremented - if this had been used for more than just printf() the consequences could have been far more far reaching.

Cliff

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

Software Portability and Reuseability have been desired for decades. As you point out, even c source has portability problems between targets. Anyone have any examples of portable and reuseable object code except for math libraries? That concept wasnt the Next Big Thing either. Interpreted p code? c#? Hard to predict the future huh?

Imagecraft compiler user

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

thanks Cliff.. that was very useful.. this debate has been very informative.. thanks guys..

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

clawson wrote:

ADCSRA = (1<<ADEN) | (1<<ADATE) | (1<<ADIE) | (5<<ADPS0);

or

// Enable ADC, free-run, enable interreupt, prescale /32
ADCSRA = 0xAD;

ADCSRA = 0b10101101;

The snag with the first of these is that it doesn't make it clear that bits unset might be important too...

I have been known on the more confusing parts to use

(0<<ADEN)

or similar to clarify.

Neil

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

Quote:
Anyone have any examples of portable and reuseable object code except for math libraries?

Bob there's loads of stuff besides math libs that is CPU agnostic. Try zlib or RSA or AES or DES or TCP/IP (apart from the very lowest level interface to the chip). If it's written portably then it should work as well on an AVR as an ARM or an x86 (resources permitting)

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

Removed spam.

Last Edited: Thu. Oct 29, 2015 - 06:52 AM