serial.write(0x00); gives an error

[Jan4ard]

In my programm I have to sent a byte 0x00 to a serial device, I do so with the command: Ser1.write(0x00);

However the upoad-button of Arduino 1.0 generates the error message:
call of overloaded 'write(int)' is ambigious
serialtest00.cpp: In function 'void setup()':
serialtest00:11: error: call of overloaded 'write(int)' is ambiguous
E:\arduino-1.0\libraries\SoftwareSerial/SoftwareSerial.h:92: note: candidates are: virtual size_t SoftwareSerial::write(uint8_t)
E:\arduino-1.0\hardware\arduino\cores\arduino/Print.h:49: note:                 size_t Print::write(const char*)

Because according to the Syntax of Serial.write(val), in which -val: a value to send as a single byte- , it should be possible
to sent the byte 00 ( or 0 or 0x00), I therefore think that there is a bug in this piece of software.

Can somebody help me out because I have to sent data (incuding 0x00) to my serial device.      Jan.

[runaway_pancake]

I get that, too.
But...
If I make a variable -
byte zero = 0;

and then
Serial.write(zero);
it compiles.

Test that out.

[PaulS]

I therefore think that there is a bug in this piece of software.

No, there isn't. The compiler is telling you EXACTLY what the problem is. The value 0x00 is not typed, so it could be a char (NULL), a byte, or an int. The compiler is refusing to guess which method you want to use.

You can do as runaway_pancake suggests, or you can simply tell the compiler how YOU want it to interpret the typeless value:
Ser1.write((byte)0x00);

[lefstin]

I The value 0x00 is not typed, so it could be a char (NULL), a byte, or an int. The compiler is refusing to guess which method you want to use.

Actually, isn't the problem that the literal constant 0x00 is typed - but as an int?

[PaulS]

Actually, isn't the problem that the literal constant 0x00 is typed - but as an int?

No, it is not typed. However, in the absence of directives the the contrary, literals that can be interpreted as ints will be. Whether the value fits in an int, or not. The problem is that the literal can be interpreted as an int, but there is no write() method that takes an int, so the compiler needs to be told more information, so it can choose the right overloaded method to call.

[Jan4ard]

Thanks for the practical solution for my problem, for the theory behind it I have to start studying:
what I do not understand is that sending 0x01 (or other hex-values) does not give a problem (as being a hex-value for data) while 0x00 is not accepted as hex-data.
As PaulS stated ''The value 0x00 is not typed'', my (study)problem is then why is 0x01 ''typed''
or differently: if I have to declare 0x00 to be a byte ((byte)0x00),
why is it not necessary to have 0x01 also to be declared to be a byte ((byte)0x01).
I have just read the answer of PaulS on Professor Chaos: I have to admit it is above my knowledge-level.
Therefore again: thanks for the help.   Jan.

[westfw]

"0" is magic because it is also the value of a null pointer.

note: candidates are: virtual size_t SoftwareSerial::write(uint8_t)
note:                 size_t Print::write(const char*)

The actual complaint from the compiler is that it can't tell an int (uint8_t) from a null pointer (const char *), not that it can't tell an int from a char.
I think this was/is because C compiler geeks are lazy and didn't want to write ((char*)0) around all the null pointers they were passing around.  Proper usage would be:

Code: [Select]

Serial.write((uint8_t) 0);
(please don't use "byte"; it's a terribly overloaded term that is being removed from all sorts of official libraries!)

[michinyon]

How is 'byte' an overloaded term ?  It has precisely one meaning.

Where as 'char'  for example is very problematical.    Since someone decided that 127 chars were not
enough,  char has become a nightmare which I avoid as much as possible, because you can never
tell what it means any more.