I simply can't do it...

I've been trying, fruitlessly for the past week to communicate properly with my Arduino and Flash.

I simply can't do it. :frowning:

I've tried every Flash code out there for the arduino, and nothing works at all...

For example, following this tutorial:

I send a byte to the arduino from Flex using its built in socket.writeByte(byte), and have the arduino immediately send it back, reading it again using socket.readUTFBytes(arduinoSocket.bytesAvailable).

But my luck is as it is that I get stuff like this:

Arduino Code:

uint8_t inputByte=0;

void setup()
void loop()
static int onVal=0;

while (Serial.available() >0)
inputByte = Serial.read();
Serial.print(inputByte, DEC);

I've tried as hard as I can to do this alone for the past few days, but I really really can't.

I am literally begging for help. Please please please help me :cry:

Hi Neodudeman;

The first thing I can see is that you appear to be sending a byte to the arduino, which then echos it back as a decimal (base 10, string) and Flex is supposed to take the string and read it into a UTF character.

i.e. '\x08' 8 (UTF Character 8)

Keep the data the same format - byte, byte, byte and you will get the same back as you sent. (you appear to be sending byte, echoing decimal string, receiving UTF char) and that is why it isn't working for you as you expect.

it should be something like:


byte bData[1];
bData[0] = (byte)Serial.read();

Serial.write(bData, 1);



No luck...

That type casting the Serial.read() was a good idea though; I didn't know it could be done. It's too bad it didn't help :-/

byte inputByte[1];

void setup()
void loop()

while (Serial.available() >0)
Serial.write(inputByte, 1);

I think I should also point out that the Arduino's serial connection works fine:

So maybe there must be something missing in the Flash->Serproxy->Arduino chain of communication?

What exactly are you writing? Is it a byte (chr(0)... through chr(14)) based on the dropdown? or the text '1' '2' '3'...

When I click the 'Send' button, it takes the number from the stepper as an int, and sends it to the function 'sendData'

      public function sendData(data:int):void

The textbox is left over from earlier testing when I tried sending all sorts of different data to try to determine what is going on.

Ok, nothing obvious there - how do you print the retrieved value from the arduino back out in Flex?

The way I have it set up is that Listbox in the flex program is bound to an array of objects. When the arduino sends a byte back, it raises a flag, and calls my arduinoReadHandler function.

The function reads the byte in the socket, and then adds it to the array.

Then it does some other asthetic stuff like automatically add 1 to the stepper so I can just click Send to send new bytes, and makes sure the array doesn't get too long.

private function arduinoReadHandler(event:ProgressEvent):void
        var intensity:int = arduinoSocket.readByte();
          transactions.addItem((txtdata.text).toString()+": " +intensity);

Variable name is intensity because the tutorial had it as that name. This originally was supposed to read analog data from a photocell, as per the tutorial I linked: http://home.teampaulc.org/arduino/arduino-to-flash-communications

Ok, so ... hmmm.

I see the original arduino code for the project would print back a number, related to the AD value. (Lets say the value is 950...)

The proxy, I assume would send that text to a network port, which Flex can read.

Flex is somehow reading an ASCII string in the ReadUTFBytes - and returning a string ("950"). I guess this would work for numbers the arduino was sending, since UTF can be single-byte too.

However, I don't see how this would always work. :o

For example, if you start a read half-way through the samples (let's say Flex missed the '0' in the first sample because it started late...

The next read may be '0950'. If the network is slow, it may be 09. Nothing appears to be signalling to Flex when the end of transmission is. (or the beginning, for that matter).

If you changed the arduino code to report back only after you received a command to sample, you may have better luck. But - in the Flex code, you are still going to want to wait for a terminating character (like /r/n) to indicate the sample is finished.

Remember that the network or even the serial may wait until a buffer is full, or until a delay to actually pass the data onward - you may receive samples like '95' '0', or '9' '50'. If you put all the data into a buffer and then only reported that buffer when you received a '\r\n' you know you have the full sample.

I simply can't do it (with that code) either...

That's definitely an interesting thought.

Though, like you, I'm not sure how I would do that; but, I'll give it a shot, and keep it in mind.

Thanks a lot for your help, Spinlock; you were the only one brave enough to attempt an answer, lol. I appreciate it. :slight_smile:

I didn't realize the arduino was already looking for input before transmitting - I looked over it again this morning and saw I goofed a bit in my last post.

I think I have an idea... Hold on a bit...

in arduino:

while (Serial.available() >0)
    inputByte = Serial.read();
    Serial.print(inputByte, DEC);

In flex, I would do basically the following: (Forgive me for not posting code... I have no idea about Flex-anything...)

  1. Create a temporary buffer. Initialize it to "".
  2. When data comes in, append the network data to buffer.
  3. find the first occurrance of ] in the static buffer (not the just-received buffer). Walk backwards in the buffer until I find [.
    3a) If I can't find [, then I started receiving late. Throw away the ] to the beginning of buffer and goto 3 again.
  4. The characters between [ and ] have my sample number!
  5. Remove the bytes up to ] from buffer and then loop back to 3 until I don't find more samples.

This way, you can make the arduino just spew the samples rather than waiting for byte inputs first.

You will always know that the sample is intact because of the markers [] around it.

Does that help, or make things worse?