- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm getting into embedded programming - my last experience was C/ASM about 20 years ago....
I am trying to use the SPI component to transmit some data. I looked at the example SPI_Master project, and a couple of things I don't understand...
One of the lines states
SPIS_WriteTxData(0x22u);
what does the 'u' signify at the end of the number? It was my understanding that writing 0xFF signifies a hex number. But I see tons of examples where people write hex just as "0xFF" without any suffix... so is the 'u' needed? What other suffixes are there besides the 'u'? How does one denote binary, hex, decimal, etc?
Also,
As I understand, there are C standard datatypes of char, int, long, double, float, etc. I used PSoC Designer in the past and used these data types. But in many examples, I see uint16, uint32, etc. What is the reason that Cypress has these other data types listed? Or are they something from Keil? Is there any advantage to using uint16 instead of just unsigned int?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This should help -
http://www.rapidtables.com/prog/cref/const.htm
The file cytypes.h in workspace explorer (after you build) shows type defs.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Dana, that helps a lot.
SCAS,
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When dealing with hex constants they are usually in the form of:
0x01,0x02,0x03...0x10 for positioning
0x00=False 0x01=True
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SCAS,
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).