noob question on data types in Creator

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

 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?  

0 Likes
8 Replies
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
JiGi_284761
Level 4
Level 4
Welcome!

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..

0 Likes
Anonymous
Not applicable

 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?

0 Likes
JiGi_284761
Level 4
Level 4
Welcome!

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.

0 Likes
Anonymous
Not applicable

 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)?

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

A signed 8 bit ranges from -128 to +127

   

 

   

en.wikipedia.org/wiki/C_data_types

   

 

   

Regards, Dana.

0 Likes
JiGi_284761
Level 4
Level 4
Welcome!

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.

0 Likes
Anonymous
Not applicable

 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). 

0 Likes