Its quite common to see these data types today in most development software. You can still use Int and double and so on and so forth but the greater diversity of data types helps the complier to maximize memory on the chip.
When you learned C, 8 bit was all you had. Perhaps 16. But today there are many, many more types of data. 64 bit is very common. You can even make your own.
The "u" is a hex constant suffix saying that it is unsigned and that is the way you want it.. A constant is always an int unless you append a suffix to it. You might want a " l" for long or a "ll" for Long Long. You can also mix them as in 0x22ul. It most cases it dosent matter unless it is being used in an equation and you don't want it to be considered negative or truncated..
Thanks Dana, that helps a lot.
You said a constant is always an int unless you apply a suffix. So let's say I had a function expecting a 16-bit number as an argument, and I wrote "0xFFFF", would that give an overflow type of error because it would assume it was an int, not an unsigned int?
Or are you talking strictly about defining constants in the program (i.e. #define)?
It seems a bit strange that the SPIM function call wrote had 0xFFu as an argument... or is it just redundant but good coding technique when you get to 16 bit numbers?
It dosent really matter until you get above 127d = 01111111
signed 11111111 = -1 and unsigned 1111111 = 255 because the 8th digit is the sign, signed starts drecrementing from there and unsigned keeps incrementing.
Refresh yourself on signed and unsigned data types.
I understand the difference between signed and unsigned data types, but I guess what I am wondering is... you said the compiler assumes signed unless specified otherwise... so if I passed 0xFF that would be considered -1 and 0xFFu would be 255?
For example the SPIM_Master component example uses SPIM_WriteTxData(0xFFu). Without the u, that would either generate an error or pass the wrong data as it would be assumed to be signed (i.e. an int instead of unsigned int)?
When dealing with hex constants they are usually in the form of:
0x01,0x02,0x03...0x10 for positioning
0x01,0x02,0x04,0x08,0x10,0x20,.... Bit masking
The negative problem never shows.
Usually it pops up in commands for SPI and I2c where you are sending a 8 bit cmd set to a device. I usually just use a binary number for these. Most people do because it is easier to understand the relationship but some people are purists or use command tables that are already written in hex so the "u" becomes mandatory.
But generally, you will rarely find yourself in a position to use the hex suffix in embedded programming unless you are using someone elses work. When most people want a negative number, they just write a negative number and the complier converts it. No need for hex there.
I had to smile reading your post - you hit the nail on the head.
The reason this all came about is because I was trying to communicate using SPI. I have gotten used to hex over the years (old habits die hard, I suppose), and I like having all my numbers line up in array definitions and such, as opposed to decimals.
But what you wrote makes perfect sense. Thanks for the help - much appreciated.
(and just to tie up loose ends... the problem ended up not being the nomenclature... turns out the Chinese PCB I was trying to send data to had the clock and data lines reversed and labeled incorrectly. Talk about a hair-puller).