I am new to Due, but I had my application running smoothly on the Mega.
In upgrading to the Due, I am spending a significant amount of time waiting for uploading to complete, re-uploading, resetting, disconnecting and reconnecting the programming port, and all the reflexive things one does to recover when the Due hangs, the I2C bus fails, the IDE states it can no longer find the COM port, the COM port no longer exists, or Java exceptions are thrown.
These issues happened sporadically on the Mega, as annoyances to work around. On the Due, they have become a significant headwind. I have tried to notice a pattern to the failures, but every time I think I'm on to it, I encounter an exception. There may be multiple compounding sources.
My setup:
Arduino IDE 1.5.6-r2
Arduino Due R3
Windows XP
USB cable to Due Programming port (provides power)
I2C bus with I/O expanders, RTC, EEPROM
TFT monitor with home-grown RTOS
multiple buttons that drive an interrupt handler
application drives remote relays & motors
The most common fail is the "Board at COMn is not available" message from the IDE before uploading. The Due (or 1.5.6-r2) already is slower to compile than the Mega. The workaround appears to be unplugging/replugging the USB cable and starting the compile/upload cycle again. About 30% of the time, I get the error again, and have to repeat the sequence. While it always recovers by the second recycle, it can triple my upload wait. Occasionaly, I have to reinstall the Due XP driver to continue. There seems to be some correlation between the COM failures and using the serial monitor, but it is not 100%.
Next fail in frequency are a bunch of Java exceptions in the IDE message window. As above, resetting or recompiling doesn't help and I have to unplug/replug the USB cable as above, sometimes twice. I have never drilled into the error messages, as they go away when the Due reboots.
Lowest in frequency, but more distressing, is when the Due locks up during an interrupt event. I have only one interrupt, on a pushbutton, but if the button is repeatedly pushed too quickly, the program freezes. If I push the reset button, the Due reboots but the I2C bus fails (cannot find devices), so all I can do is unplug/replug the USB connection and start over.
Here's my interrupt code. I am using noInterrupts(), but maybe I am not doing it right.
...
setup() {
...
attachInterrupt(NAV_PIN, navigate,FALLING);
...
}
void navigate() {
noInterrupts();
detachInterrupt(NAV_PIN);
menu.buttonCode = tft.readButtons();
attachInterrupt(NAV_PIN, navigate,FALLING);
interrupts();
}
uint8_t fB_TFT::readButtons() {
uint8_t button = 0;
uint8_t buffer = 0x00;
static uint8_t buttonTemp = 0;
static uint8_t buttonLast = 0;
buffer = ~((uint8_t )i2c.read((uint8_t )TSADDR) & 0xFF);
switch (buffer) {
case 0x00: buttonLast = buttonTemp;
buttonTemp = 0;
button = buttonLast;
break;
case 0x01: buttonTemp = 1; break;
case 0x02: buttonTemp = 2; break;
case 0x04: buttonTemp = 3; break;
case 0x08: buttonTemp = 4; break;
}
return button;
}
When the upgrade is complete, I will be powering the Due from an external source, so I wont be wearing out the USB port for every reboot. Still, cycling the power seems like a crude way to run a railroad.
Any help appreciated. Free pizza, etc.
This is a great forum. The Romans invented the word, otherwise we would be calling it a pnyx, from the Greek.