In Processing 1.5 I used
Locale.setDefault(Locale.US);
in the
setup() to make
nf() produce decimal points for floats. If I did not, it would use decimal comma, as my window-pc is localized for Denmark. I need the decimal point as I am generating files, to be read by other programs.
In Processing 2.0 the line failed with that it can not find the routine/constant - until I include
import java.util.Locale;
The reference notes that nfc() is locale sensitive - but no clue how to override. It fails to note the locale sensitivity for the nf(), nfp(), and nfs() routines. (Those are the ones I have discovered, there is probably the same for input formatting of strings. The print() is not affected by locale - it is hardwaired to US/English it seems.
There are no hits on Locale or similar in Processing, its wiki or otherwise.
So I am doing various minor test to do serial processing between my WinXP and the Arduino. I have two, a small (older) ATmega328 and a new Mega2560.
The programs work fine if I use the Serial monitor with the Arduino IDE.
The programs work fine with my own serial connection using Delphi(Pascal)
The programs work fine with the (6 month old) Arduino Duemilanove ATMega328 and the Processing (latest) with the Serial calls
The programs do NOT work with the ATMega (that uses the ATMega8U2 chip) the Processing (latest) with the Serial calls
Yes, I have checked the correct COM port, the right Arduino board and serial baud rate. Umpteen times. It is only that specific combination The Mega/8U2 and Processing Serial lib.
Symptoms ? Thing goes haywire; the RX lights up nearly always, the LED13 lights up. Irrespectve of what program is or is not loaded in the Arduino (like the starter Blink code). I suspect something makes the Arduino go into its bootloader - some setting of the DTR/CTS/or-more-subtle item. Apart from that it will not talk to Processing.Serial the board works fine otherwise.
Bug in Serial? Unusal H/W failure on my board? Wrong phase of the moon ?
