Arduino Duemilanove + MaxMsp = Broken?
Hi,
We use Duemilanove Arduinos as show controllers for installations.
The chip on those is the ATmega 328.
We use it to receive a push button on pin 10 to start a show built in Max. I use Maxuino004 to read the serial command. When I first uploaded the Firmata v1 on it it worked fine but after a while, the board became completely unresponsive.
We went through 4 boards. They all stopped working about a week after the exhibitions started. I made some experiments and it seems to work only if, after opening the max patch, I push the Arduino's reset button. If I upload simple patches (blink, Button...) they work perfectly well. It seems that only the serial part of the Arduino is broken...
I tried with different "protocols" (simple message, messenger...) to no avail.
What is strange is that I used the Diecimila for the exact same setup with no problems in two years of continuous use.
Setup:
Arduino Duemilanove ATmega 328
Arduino 015
Mac Book 2.0GHzIntel Core 2 Duo; 2GB DDR3 Memory; NVIDIA GeForce 9400M
OSX 10.5.6
Maxuino 004 (Firmata 1)
MaxMSP 5.0.7
Any ideas?
a similar message was posted on the Arduino Forum
First, might want to update to Arduino v16. There was some funkiness with v15.
It use to be that you had to hit the reset button on the older arduinos in order to get them to work. I have a whole herd of arduino pro minis with the 328 chip that don't need a manual reset, so I don't think the chip is the issue.
Anyway, first, check and make sure your baud rates match between max and the arduino. Next, since I'm not familiar with maxuino, try this as your sketch. It simply reads data from the the first analog pin (a0) and passes the number along every 50 ms. You don't need a sensor on a0...it'll still pass on a number. Also flashes the built-in status LED every time it sends a number so you know it's working:
int statusLED = 13; // status LED on Arduino
void setup()
{
Serial.begin(57600);
pinMode(statusLED, OUTPUT); // declare pin as output
for (int i=0; i
digitalWrite(statusLED, HIGH);
delay(20);
digitalWrite(statusLED, LOW);
delay(20);
}
}
void loop()
{
digitalWrite(statusLED, HIGH);
int a0 = analogRead(0); // read analog input 0
Serial.print("a0=");
Serial.print(a0);
Serial.println();
delay(25);
digitalWrite(statusLED, LOW);
delay(25);
} // end loop
And this as your patch:
That should at least test the communication.
BTW: if you were losing boards, I have to ask how you were powering them and what was connected to them? It sounds more like you fried the boards either by drawing too much current via your sensors, or perhaps sending it too high a voltage? In other words, if it stopped after a week, I don't think your issue is software, but try the above just in case.
HTH,
David
Thanx for the reply David,Quote:First, might want to update to Arduino v16. There was some funkiness with v15.
I forgot to mention that v15 was used for programming at first. I then used both v15 and v16 while troubleshooting.Quote:first, check and make sure your baud rates match between max and the arduino
I had matched them to 115200Quote:I have to ask how you were powering them and what was connected to them?
We were powering it through the USB port of the Macbook. I tried to power them externally with a 6v power supply while troubleshooting but got the same behavior.Quote:it sounds more like you fried the boards either by drawing too much current via your sensors
I actualy only use a switch that connects pin 10 to the 5v pin. Pin 10 is also connected to ground to prevent random values to appear. Ther is nothing esle plugged to the board.Quote:try this as your sketch
I did, and it just made me scratch my head even more. Here is what happens:
Upload to board works fine.
Led flashes as it should until i open the patch.
As soon as the patch is open (without me having selected the board in the drop-down menu) the led stops flashing. After selecting the Arduino in the drop-down menu, nothing appeard in the message object at the bottom of the patch.
Since I didn't know if it was normal for the LED to stop flashing when the patch opens, I closed the patch and, after reseting the board, I created a new empty patch. The LED kept flashing with the empty patch. So I created a new object and typed serial in it. After I pressed enter, the LED stopped flashing. Is this normal? I find it strange.
Also, I figured I'd check the serial monitor of the Arduino software. I am uploading a sample of what i got. Again, I find it strange.
I only tested with the "broken board" that was sent back to me from the installation. I will try with a fgresh board on monday.
Thnx again
Several things:
1. you have created a short! Basically when your switch is either open or closed or however you have it set up you have power connected directly to ground...that's a short, and that's bad. Did you notice your arduino getting hot at all? I would say there is a really really good chance the board/chip/something has been fried, especially looking at the data.
You need to throw in a high value resistor in the circuit to absorb some of the energy. It's just like electricity in your home...connect power and ground and unpleasant things happen. Put a light bulb in between to absorb the energy, things are much happier. An example would be:
5V
|
|
10kOhm resistor
|
|--------arduino
|
switch
|
|
|
ground
when switch is open you'll get a 1, closed a 0. And no short!!
2. why 115,200? That's a really fast baud, and although the arduino's can, in theory, work OK at the higher baud, if they don't need to, don't. If all you are sensing is a single switch, use 9200. I try not to go over 57.6k if I can avoid it.
3. usually if you data looks "odd", then 90% of the time it points to a buad rate mismatch (CPU and arduino talking at different rates). However this data just looks bad, and since you are using one of the "fried" boards, I would guess this is your issue.
David
If the Arduino code is using the millis() function for timing, be aware that the the internal clock rolls over (it goes back to 0) after some time - in theory 40 days, but in practice a lot shorter. This is because there are simply not enough digits in a long integer to keep track of long time spans.
If you are using code like this:
if ((millis()-lastEvent > interval) {do some stuff; lastEvent = millis()}
and millis() has rolled over and gone to 0, {do some stuff} will never happen!
I usually add some code like this:
if (millis() < lastEvent) {rollover = true;}
and then do something like
if (millis()-lastEvent > interval || rollover) {do some stuff; lastEvent = millis}
Then if a rollover occurs, I'm guaranteed to trigger the event. There are more elegant ways of doing this, such as keep tracking of the difference between millis and and last event, but generally, since I was using timing for fast cycle stuff, a little hiccup every few days was not a problem.
Gpvillamil,
Thanx for the info. Maxuino does not use the millis() function but that is valuable info none the less.
David,Quote:1. you have created a short!
I forgot to mention there is a 10k resistor between pin 10 and ground (sorry for that). So technically, there shouldn't be any shorts...
Quote:2. why 115,200?
Firmata v1 work with a baud rate of 57600 witch was used at first (both in max and in the board). When troubleshooting, i stumbled across a few forums mentioning that it might be better to use 115200 with the atmega 328. Hence, my decision to change 57600 to 115200.
Further readings brought a suspicion to mind:
Considering that the Duemilanove resets when a patch opens and considering that the switch might have been wired incorrectly (in a normally closed state). Is it possible that the reset cycle change the digital pins to output mode (even for a short while) and a short happens between pin 10 and 5v?
Since the venue is a 3 hours drive from here, I never got a chance to look at how everything was put together. I will however be going there the first week of august to replace the arduino with a cannibalized gamepad. I hope to gather more clues then...
Thanx again, you guys have been a great help!
That is very possible. I personally disable the auto-reset function on Arduinos in installations, precisely for that reason.