I'm printing Serial output from Arduino to Flash using a socket (with serproxy in between). No Firmata btw. I'm passing multiple bytes (ie 8-bit numbers) and when I want to pass the number 10..... I get no data on the Flash side :( After some searching I found that the decimal value 10 is the ASCII character for a line feed. I do not want this to happen, what's a good way to work around this? I've tried printing as a BYTE (Serial.print(10, BYTE)) but that has unwanted consequences for me on the Flash side and I'd like to be able to avoid it... any suggestions are welcome!
If you're passing data to a device/program that is looking for ASCII control codes, then you should switch to passing ASCII characters instead of raw binary byte values.
Instead of sending a byte that has 132, for example, pass the byte sequence 0x31 0x33 0x32 0x0A ('1' '3' '2' newline). To do that, you want Serial.println(132, DEC);. Then your Processing code should convert a string "132\n" into a number. I don't know the Processing system well enough, but look for string2number or atoi or something.
The point was that I actually don't want to be hindered by ascii commands :) I want the numbers that I'm passing to Flash to arrive good and well. I have a range of 0 - 255, and only when I want to send the number 10 does it not arrive at Flash as that number, since 10 is Ascii for 'new line feed'...
I dunno if I undestand. Why is it that "10 == newline" means that Flash doesn't receive it?
It might be Serproxy instead; there are some funny things that happen "near" newlines to prevent the "visible" version of newline (CR LF) from showing up two "newlines" (since either CR or LF will typically be treated as newline on input.) One algorithm simply discards LFs. A better algorithm only discards LF if it immediately follows a CR. Others want special sequences (telnet says CRLF is one newline, but a bare CR is CR NUL, for instance, so you can send CR NUL LF to get both for sure.) You might see if serproxy has some "raw" option that you can turn on.
Ah, westfw is probably right. Good old Windows. It’s probably not even serproxy’s fault, but the Flash engine that offers you a streaming API. If you open your connection in a “raw” or “binary” mode, it will stop butchering your carriage returns and linefeeds.
Thanks for pointing me in the right direction. Turned out that there was a line in the serproxy config file I should've turned my attention towards:
setting this to 'false' fixed the problem and decimal '10' is now succesfully arriving at Flash.