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..
uint8_t question
Author
Message
yes
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.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
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
The size was clearly explained in the fine compiler manual.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
OK then if I write:
#includeint16_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
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
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
OK make that "%ld" then to remove that unknown or forget printf() all together - stop it in the debugger and inspect m and n
Is it supposed to be -32768?
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
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.
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...
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
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
Cool. I was right. If I'm so darned smart, how come I aint rich yet?
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
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.
Unless one had read the manual, right?
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
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
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.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
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
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?
thanks Cliff.. that was very useful.. this debate has been very informative.. thanks guys..
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
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98695 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
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)
Removed spam.
Last Edited: Thu. Oct 29, 2015 - 06:52 AM