Because according to the Syntax of Serial.write(val), in which -val: a value to send as a single byte- , it should be possibleto 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.

"You gotta fight -- for your right -- to party!"Don't react - Read."Who is like unto the beast? who is able to make war with him?"Hey, it's "bipolar transistor" or "junction transistor" - "BJT" is just stupid.

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

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.

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.

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:

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