What a great project.

The way you've described the system, I'd look at modifying the firmata GUI program to accept inputs from your server.  Can't say how hard that would be without seeing the source, presuming it is open.

If you're not wedded to a firmata solution, I've published a web front-end toolkit for Bitlash named Bitlash Commander that allows control of an Arduino from a web interface using Bitlash script.  It's a similar architure with Bitlash substituted for firmata.

You could build your control interface as a Commander page and extend Commander to accept input from the indiserver, same as you're looking at for the firmata path.

Bitlash Commander: https://github.com/billroy/bitlash-commander
Bitlash: http://bitlash.net

-br

I wonder if the bootloader is eating your data.

Immediately after the serial port is opened, the Arduino spends about 1500ms in the bootloader waiting to see if you are about to upload a new sketch.

During this time, any serial output sent from the PC side is interpreted by the bootloader, not your program.  Mostly, it is ignored.  Just like what you are seeing.

The unix 'echo' command opens the port and writes to it right away.  This works fine on the serial monitor, but because of the bootloader problem it won't work on arduino.

If this reasoning is sound, you need a little program to open the serial port and wait a couple seconds before sending the playlist length, rather than using 'echo'.

-br

Edit: Another way, besides waiting a fixed time, is to wait for a character string from the arduino to signal 'ready'.  Bitlash, for example, sends '\n> ' as a prompt when it's ready.  You can see this at work in the bloader.js program, which uploads files to Arduino over the serial port:

https://github.com/billroy/bloader.js/blob/master/bloader.js

It is a process.  The good news is that it makes it much easier for the developers to accept a patch, which you can see them doing regularly if you follow the issues tracker.

The issue tracker does accept file attachments, so you could give that a try, but I would not be too surprised if they ask for a pull request.

Issue tracker here: https://github.com/arduino/Arduino/issues

Best regards,

-br

The way this is done on GitHub is to fork the code base in question (which makes a copy to your github account), modify your fork, and then prepare a "pull request" which you send to the Arduino developers.  The pull request is essentially an issue report with a patch that contains only the changes you made, so it's easy for the developers to review and apply.

It's simpler than it sounds, and mostly automated.  More here: https://help.github.com/articles/using-pull-requests


-br

I bet they don't turn on all at once, but rather one at a time, very quickly, since there is no code to turn them off.

Perhaps something more like this:

Code:

int lit = 3; // save the lit one so we can turn it off

void loop() {
if (digitalRead(switchPin)) { // button pressed?
digitalWrite(lit, LOW); // turn off the old one
lit = random(3,10); // pick a new one
digitalWrite(lit, HIGH); // turn it on
}
}

-br

As Holmes says, put:

Code:

   int prog_number;

before the giant if statement, and don't say "int prog_number=x" just "prog_number=x" in the if statement blocks.

It looks like you are setting prog_number to 1 in the fourth giant if statement.  Is that what you intended?

-br

Bitlash Commander should run happily on the pi.  You can browse to it from anywhere on your network:

    https://github.com/billroy/bitlash-commander

-br

Sorry to be late to the party, but I thought I'd throw in the Morse and Morse2 examples that ship with Bitlash as specimens worth study for those coding Morse generators, especially those coming up against the problems of state machines for the first time.

Both examples use a compressed table to store the morse code translations.  The first example is blocking, and the second, Morse2, is fully non-blocking.

They are both in the Bitlash distribution, which you can get at http://bitlash.net.  I've attached them here for reference or you can see them online at https://github.com/billroy/bitlash/tree/master/examples/morse and https://github.com/billroy/bitlash/tree/master/examples/morse2

-br

That gobbledygook is part of the DOCTYPE declaration that is generally found as the first line of a properly written .html file.  The posted text appears to be missing the first character, which is the opening '<'.

-br

I believe what you want is a function call:

Code:

void menu() {
  GLCD.print("start");
  val=digitalRead(button1);
  if (val==HIGH) doSomething();
}

void loop() { 
   …code...
}

void doSomething() {
  …code…
}

-br

The IP address may indeed be the problem, as you suspect.  The one in the program is on a different network from the gateway, which doesn't work.  Change the 3 in the third octet to a 1 to match the gateway:

Code:

//byte ip[] = { 192, 168, 3, 178 }; //ip address -- wrong network
byte ip[] = { 192, 168, 1, 178 }; //ip address -- maybe right network

I say maybe because your actual network might be set up differently.  If this doesn't work, it will next help to tell us the IP address of your PC.

-br

The '328p datasheet (here: http://www.atmel.com/Images/doc8161.pdf), section 19, page 176, is the place to start in understanding parity support in the hardware.

It looks like it both generates the parity bit on output and checks it on input.  See 19.7.4 for Receiver Error flags.

One issue with the Arduino buffered serial input (since you're not managing it yourself) will be knowing _which_ character was in error when the error flag lights up.

Good luck with your project.

-br

Everybody makes that mistake once.  Smart people _only_ make it once.

Good luck with your project.

-br

Your speculation is correct: RX and TX are dedicated to the serial port.

-br

Your arrays look too short by me, off by one.  Unless I am mistaken, the code is trying to put four bytes and a null into a four byte buffer.

Make the arrays longer by one and see if the problem resolves.

-br