int and unsigned int

Here is my test code that shows in the serial monitor what am talking about, displays a int value that has 32bits and an unsigned int that has 16bits.

byte temp;
unsigned int result = 7000;
unsigned int Display_RPM_A;
int Display_RPM_B;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  
  temp = result/1000;
  Display_RPM_A = ~((1 << (16 - temp))-1) | ((1 << temp)-1);
  
  temp = result/1000;
  Display_RPM_B = ~((1 << (16 - temp))-1) | ((1 << temp)-1);
  
  Serial.println("unsigned int value");
  Serial.println(Display_RPM_A, BIN);
  
  Serial.println("int value");
  Serial.println(Display_RPM_B, BIN);
}

void loop() {
  // put your main code here, to run repeatedly: 
  
}

(Changed code above because the wrong lable was being printed).

Really useful to match printed label to type.

To save me compiling, and uploading, how about you show your output? Then we can see what you are talking about? Don't just describe it.

The whole thread is complaining about what you see in the serial monitor. Why not post what you see?

Sorry Nick. Here is what i see in the serial monitor below.

unsignd int value
1111111001111111
int value
11111111111111111111111001111111

I'm a way from the source at the moment, but reply #6 seems plausible.

Westfw is right, I think. The actual printing method is this:

// Private Methods /////////////////////////////////////////////////////////////

size_t Print::printNumber(unsigned long n, uint8_t base) {
  char buf[8 * sizeof(long) + 1]; // Assumes 8-bit chars plus zero byte.
  char *str = &buf[sizeof(buf) - 1];

  *str = '\0';

  // prevent crash if called with base == 1
  if (base < 2) base = 10;

  do {
    unsigned long m = n;
    n /= base;
    char c = m - base * n;
    *--str = c < 10 ? c + '0' : c + 'A' - 10;
  } while(n);

  return write(str);
}

Other methods cast and muck around, but end up here. By sign extending into the unsigned long argument you will end up with extra "1" bits.

The unsigned int variable or delcared as a word is what i was wanting to create and works great in my main code. But because at first i had the variable "Display_RPM" delcared as just an int and seeing 32bits in the serial monitor just didn't add up. The documentation for a int value in the reference section says it's meant to be 16bits not 32bits that am seeing in the serial monitor. So because am a beginner at C++ and Arduino this was very confusing for me and thought my understanding was wrong, hence why i thought it was a silly question in the first place.

How do you report a bug?

Why are you looking at it in binary in the first place?

Who wants to see RPM in binary?

How do you report a bug?

http://code.google.com/p/arduino/issues/list

And how did you manage to get negative RPM?
It's not clear to me what the "correct" method of displaying a negative number in binary would be, or whether it would be worth the special case code to limit the binary display to 16bits for an "int."

Why are you looking at it in binary in the first place?

Who wants to see RPM in binary?

Because i don't have a shift register at the moment so i was using the serial monitor to to show me what the output / effect would look like if i did send the information to a shift register. 1 = LED on and 0 = LED off and i will have 16 LED's.

[And how did you manage to get negative RPM?
It's not clear to me what the "correct" method of displaying a negative number in binary would be, or whether it would be worth the special case code to limit the binary display to 16bits for an "int."

It's not a negative number because my variable is a unsigned int / word and they don't hold negative numbers according to the reference section. If i set my variable Display_RPM to an int and display the created value in the serial monitor, then i get a negative number. If i set my variable to unsigned int/word then i get a positive number and that is what i want.

#define pin A0 //Pot connected for testing.

byte temp;
unsigned int Display_RPM;
unsigned int result;

void setup() {
  Serial.begin(9600);
}

void loop()
{
  result = map(analogRead(pin), 0, 1024, 0, 8000); //Maps the pot value to simulate RPM value.

  temp = result/1000;
  Display_RPM = ~((1 << (16 - temp))-1) | ((1 << temp)-1);
  Serial.println(Display_RPM, BIN);
  Serial.println(Display_RPM);
  delay(900);
}

1 = LED on, 0 + LED off
below is what i think i would see on a 16bit shift register when i buy one.

1000rpm = 1000000000000001
2000rpm = 1100000000000011
3000rpm = 1110000000000111
4000rpm = 1111000000001111
5000rpm = 1111100000011111
6000rpm = 1111110000111111
7000rpm = 1111111001111111
8000rpm = 1111111111111111

Does that explain everything now.

If i set my variable Display_RPM to an int and display the created value in the serial monitor,

I think you're confusing how a number is represented internally with how the Serial object happens to present it.

Ok thanks AWOL but can you understand what am trying to achieve here. I will try and get a shift register this week and then see how wrong my code is when it don't display the results i was hoping for because my code is bound to be wrong.

Pavilion1984:
below is what i think i would see on a 16bit shift register when i buy one.

1000rpm = 1000000000000001

2000rpm = 1100000000000011
3000rpm = 1110000000000111
4000rpm = 1111000000001111
5000rpm = 1111100000011111
6000rpm = 1111110000111111
7000rpm = 1111111001111111
8000rpm = 1111111111111111




Does that explain everything now.

Not really. What's that got to do with RPM?

That's how I want to show the rpm value on a row of LEDs as part of a digital dash for my track car. A good example would be the f1 steering wheel then you might get the idea. I think the original question has been missed here now.

Oh, OK, but the engine won't generate negative RPM will it?

As for the original question, the writers of libraries are trying to cram stuff into 32 Kb of program memory (even less on the earlier models and other chips). Getting the number of digits right, for negative binary numbers, which would increase program size, but benefit practically no-one, was probably not a high priority for them.

Ok thanks Nick. No it wont. What am doing is getting the data over the OBD port on the vehicle and storing the value in a unsigned int as a DEC number between 0 and 8000 and that works great. So what am trying to do here is take that number and turn on some LED's (depending on what the RPM value is) over the SPI port to a 16bit shift register. Sorry if i have not really explaind myself properly here but i will try and explain as best as i can again.

I will have 16 LED's in a row (1 = LED on and 0 = LED off).
For example my RPM value is 5000. Out of 16 LED's i want to turn on 5 LED's on the left and 5 LED's on the right. So the efect i want on my LED's is below
1111100000011111 <- (binary number)/(63519, dec number) 5000RPM
1111110000111111 <- (binary number)/(64575, dec number) 6000RPM, turn on 6 LED's either side
1111111001111111 <- (binary number)/(65151, dec number) 7000RPM, turn on 7 LED's either side

So i hope you can see what effect am trying to create (LED's light up from the left and right at the same time and meet up in the middle at max RPM).

Thats why am using binary (bitshift)

Display_RPM = ~((1 << (16 - temp))-1) | ((1 << temp)-1);

to create that efect everytime i read a new RPM value then send the effect out to the shift register. I was going to use a lookup table for patterns but i was told a better way would be to use bitshift and if only 1 line of code.

Hope that makes sense, if not then slap me with a fish lol. I will post my project on here when i think it's ready to share.

I ran into this problem today also. It's annoying to see an output of 0x73 for your forward motor and then 0xFFFFFF8C for the backward one (I'm printing in hex because I am debugging a program that was printing in binary and I was looking at the output of that program with a hex editor)

I think if the sign extension was gotten rid of by using reinterpret_cast<unsigned long> rather than (unsigned long) before calling printNumber (in Print.cpp) it would work better.

Pavilion1984:

Display_RPM = ~((1 << (16 - temp))-1) | ((1 << temp)-1);

As a style issue, it is generally better to do such shifts as unsigned. If you use the U/u suffix on the 1's, the resulting type of the operation is unsigned:

Display_RPM = ~((1u << (16 - temp))-1u) | ((1u << temp)-1);

And just to answer the original question, the best way to determine the size of an object is to use sizeof(), since that tells you the size the compiler is using, which is what counts.