hi...
i just got some new decimilias and i found something strange with the serial port. first of all i recognized, that the delay between sending and recieving data got longer with the decimilias(compared to the NG). my second problem is, that simply sending a number and recieving it doesn´t work with processing. i tried the same code with the ng and it works perfect- so it must be something with the decimilia. is there something new one has to take care of or is it a bug?
timm
There is a difference in the Diecimila, in that opening a serial connection to the board will reset it. This means that for the first second or so, any serial data you send goes to the bootloader, not your sketch. You can avoid this by having a slight delay after opening the port but before writing data to it. Or, if your program sends and receives the same type of data repeatedly, it should work, it's just that the first few pieces of data might not arrive.
what my programm does is to send data to the arduino to compare it to the data of the sensor(on arduino side). to test the decimilia i made a simple programm just sending every second an int to the controller and print out everything that comes in. problem is(so far) that nothing is coming back. and it´s not a code thing as it works fine on the ng. would the arduino react differently with a pin0 pin1 connection?
Possibly. Do you have something connected to pins 0 and 1?
no, so far i don´t. it´s just a bit more complicated(would have to use a MAX232, don´t i?)...and i don´t have too much time. but do you know, if a connection via those pins would go to the bootloader as well?
I would try inserting a delay before you write to the Arduino. Something like this:
import processing.serial.*;
Serial port;
boolean first = true;
void setup() {
size(256, 256);
port = new Serial(this, Serial.list()[0], 9600);
}
void draw() {
if (first) {
delay(2000);
first = false;
}
// rest of sketch goes here.
}
took a while now, till i found some time to look at it more carefully... it is working with this kind of delay, but it must be quite big. right now i´m using about 11 seconds and it´s doing fine with this. less didn´t work.
Huh. It shouldn't need to be anything near that large, since the bootloader is supposed to time out after a second or two. Can you post the whole sketch (or a simplified version that shows the same problem)? I'd like to try it out for myself and see if I can do anything about it.
actually, for testing, there is not a lot of code. but i tried it again and i´m getting back null(all the time) when using less then 11seconds...
void draw() {
if (first) {
delay (11000);
println("ab geht´s!");
first = false;
}
myPort.write(send);
delay (100);
background(0);
inString = myPort.readString();
println(inString);
send++;
delay(100);
}
and on arduino side it´s simply this
if (Serial.available() > 0) {
incomingByte = Serial.read();
Serial.println(incomingByte, DEC);
}
i tested several of the new boards and all of them reacted equal.
(btw: first code comes from processing)
Strange. Can you post the whole sketch (just so it's easier for me to paste in and try out)? I'll see if I can figure out what the deal is.
well, there´s not much more:)
import processing.serial.*;
Serial myPort;
String inString;
int send = 30;
boolean first = true;
void setup() {
size(20,20);
println(Serial.list());
myPort = new Serial(this, Serial.list()[2], 9600);
}
void draw() {
if (first) {
delay (11000);
println("ab geht´s!");
first = false;
}
myPort.write(send);
delay (100);
inString = myPort.readString();
println(inString);
send++;
delay(100);
}
the arduino code is the one of the 'Serial.read "".println' example
now i´ve got another strange behaviour of my decimilia: every time i restart the serial communication(via processing), the arduino resets.
(i made a programm which needs ~5 minutes to adapt to the specific situations and restarting means to loose all those values. besides i´m using all pins which means when restarting i´m having some on/offs on pin 13... so restarting the serial port right now means crushing the whole installation...)
on the description it says "it is programmed to ignore malformed data". seems like this doesn´t work on mine(i didn´t try all of them, but three different ones, all having the same behaviour). can i do something to get around this?
The Diecimila does in fact reset every time you open a serial connection to it. There are a few ways to get around it. The easiest might be to remove the capacitor that allows the automatic reset (although if you do, you'll also need to replace the bootloader with the NG one or you'll have a hard time uploading new sketches). It's the last thing (closest to the ATmega168) in the column of components that includes the L led and the RX and TX leds, I think.
Or you could use some sort of proxy (i.e. another simple Processing sketch) that keeps the serial port open all the time and forwards data to the other sketch over a local network connection (or some other means).
There's another trick, but it will probably require you to modify the Processing serial library and or the RXTX library that it uses. If you unset HUPCL when you have the port open, the next time you open it, the board won't reset.
I experienced the same problem relating to this issue.
I just got my decimila and tried using the example program 'physicalpixel' ; I was only able to get the processing program to interact with the arduino by adding a delay of about 12 seconds along the lines suggested in the previous replies.
Could you explain why it is necessary to do this, since I presume that the previous versions of the board did not require it?
You may want to amend the example programs as I am sure a lot of folks like myself will try the communications examples, such as physicalpixel and be a bit disappointed when they dont work.
I think you may have gotten a Diecimila that was accidently burned with the wrong bootloader (the NG one). The Dieicmila resets when you open a serial connection to it, however, the new bootloader quickly times out and starts your sketch, even with no delay in Processing. I should probably add in code to include the delay, but commented out, so that other people with these boards with the wrong bootloader can uncomment those lines to get the example to work. You might also want to burn the correct bootloader onto your board. For example, uC Hobby has instructions for doing so with a parallel programmer: https://web.archive.org/web/20200610013744/https://www.uchobby.com/index.php/2007/09/12/how-to-update-the-arduino/, or you can use an AVRISP mkII and the burn bootloader command in the Arduino environment.
Hi, I am not sure how to burn an up to date bootloader with the environment. Where would I find the latest bootloader and instructions on how to do that? is there any way to check to see if I do indeed have the NG bootloader by accident?
thanks for your help! I love the arduino and the way that you can simply interface to it.
I just realized that the solution you suggested would involve me getting a parallel or other programmer for the chip. Unfortunately i can't afford that. Could I return the board and have your distributor (MAKE magazine store) replace it with one with the correct bootloader?
There is a difference in the Diecimila, in that opening a serial connection to the board will reset it.
When doing a "tail -f /dev/ttyUSB0" the first time after connecting the diecimila to the computer, it will reset and its program will run from the start; breaking out of tail (ctrl-c) and restarting it will not do that (inbetween readings are lost though). I am just too lazy right now to check what happens when the computer is rebooted while the diecimila grafts.
PS: stty reports that HUPCL is set to off on the port. Trying above procedure with the arduino-IDE serial monitor will perform the reset all of the time.
Interesting. hungerbug, are you on a Mac? Did you unset HUPCL explicitly with stty? Does the board rest if you connect to it with Processing? I'd love to find a good way for people to prevent the board from resetting every time the port is opened.