I have very very simple code. Just trying to divide array element by 4. Result is wrong. help me understand what i am missing ..
uint8_t desti[8] ;
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
desti[1]=124;
}
void loop() {
// put your main code here, to run repeatedly:
Serial.write(desti[1]/4); //227
}
You are not dividing anything yet in your code. You need to do
double result = desti[1]/124.0;
The .0 at the end of 124 indicates that you are doing a floating point division, otherwise, you will end up with integer division which rounds up the result!
arduino_new:
In your code desti[1] = 124
In your title it says: 140/4
So which one is it?
It does not matter. all numbers above 120 gives me error
Delta_G:
Serial.write isn't the right thing to use there. You want Serial.print if you want to see the result of the division. Serial.write would send out one raw byte and the serial monitor will treat it as ascii. So you'll see whatever character has that ascii code.
nope i am using another serial monitor which shows dec values. it gives me 140 for 140 and gives me 227 for 140/4 ... Also i am trying to avoid using serial.print because it is not reliable .
Did you ever use any other mcu ? did you ever read output of serial.print from other serial monitors? did you ever did byte stuffing? did you ever use bitwise operations ? did you ever create your owm serial packeting protocol? if your aanswers are all yes please send me your codes as a proof .
karaposu:
It does not matter. all numbers above 120 gives me error
nope i am using another serial monitor which shows dec values. it gives me 140 for 140 and gives me 227 for 140/4 ... Also i am trying to avoid using serial.print because it is not reliable .
Hmm. Well, 140/4 is 35. An ascii 35 is a hash/pound symbol, and that's what the serial monitor should be displaying as the ASCI output. If it converts to decimal, it should display '35'. Which is '23' in hex. Hmm.
140 is > 127. Could we have a sign extension issue? 140 is negative 116 if it is treated as a signed byte (which shouldn't be happenning, but let's go with it). 116 is 0x74 … nope. No help there.
227 - greater than 127. Parity issue? Without the top bit, it's 99, 0x63, ascii 'c'. Naaah - that ain't it either.
Baud rate mismatch? Nope - some of the results are right.
'all numbers above 120 gives me error', but 'it gives me 140 for 140'. Presumably the OP means 'all numbers above 120 when divided by 4' … no, hang on: that makes even less sense.
You know, I'd like to see what errors other numbers give. Maybe there's a pettern. We only have one data point, so it's a little difficult to work out what might be going on.
I ran exactly your program, with "140", going to the normal Arduino Serial monitor, and I get a string of "######", which is 35 - exactly what I'd expect. (124/4 = 31 is a non-printing, so it would be harder to detect.)
140/4 = 227 would be what I'd expect if your variable were a signed char. 140 is actually -29 (0x8C), -227/4 = -29 (0xE3 = 227) - but if that were happening, I wouldn't be seeing ###'s.
avr-gdb, not connected to anything. Since I'm only using "local" variables, it doesn't need a live system.
(I would have used a native x86 gdb, but apparently the XCode command line tools don't include it )