I just want make sure no blue smoking or destruction of my DUE... with the issue of 5V versus 3.3V !
Please confirm that I just build a 6 wires ribbon to connect directly my MEGA's 6 pins ICSP connector to my DUE's 6 pins ICSP connector.
Via that ribbon, only +5V, GND, SCK, Slave, MOSI and MISO related to SPI protocol.
Of course, I'll power my MEGA via USB connection of my Macintosh but how about my DUE, should it be powered or just receiving energy via its ICSP ?
P.S. I've been able to download Crosspack http://www.obdev.at/products/crosspack/index.html running OK on my Macintosh, still not clear on my side how to properly sequence different actions of MEGA ICSP sketch, learning curve here since i'm more software guy than hardware. For example, i don't understand how via ICSP sketch one can download the HEX file firmware provided by cmaglie !
Otherwise cmaglie wrote me this private mail The 16u2 doesn't have DFU firmware inside, you must program it with an AVR-ISP (or equivalent programmer) from the ISP connector (the 6-pin header near the power jack). If you don't have an ISP programmer you can emulate one using an Arduino Uno or Mega loaded with the ArduinoISP sketch.
Well i've just installed the latest Xcode 4.6 running on Mac OS Lion so have now the latest DFU-programmer from macports http://www.macports.org/install.php#pkg but see below my terminal Shell results, it does NOT know atmega16u8
Maybe it is available on PC but right now, if really the DUE has the atmega16u2, can't erase it neither flash new firmware on the USB chip from a Macintosh.
It would nice someone provides the port device name handling the USB on arduino DUE, confirm it is atmega16u2 !
Good news: I've done per your instructions and now my Java GUI receives all the local PWM parameters from arduino DUE, upon changing values via sliders, my Java GUI does send new parameters to arduino DUE, at least I see proper reaction of my LED's.
Bad news: when i connect DUE to my iMac USB (no launching of ElectroShaman GUI), the CRCerror LED is faintly ON so for some reason, it detects incorrect HDLC frame (this does NOT happen with same IDE on MEGA or UNO). Now when I launch my Java GUI per your special reset instruction sequence, the GUI sliders will properly light ON the LED's except the CRCerror led stays a bit ON (not normal) and most problematic, the Linkup LED never lights ON.
I cannot see why there would be a bug in my IDE or Java explaining partial CRCerrors, maybe there is bug but I still have serious doubt (please verify or debunk if I'm wrong) because the way i've programmed SerPro is to be free of any endianness issue.
My feeling but just intuitive, there are once in a while garbage data flowing through programming USB port whatever application and that is major issue, not only for my project but is general issue for arduino community.
I think the problem is the same as the one we have noticed here before - when the serial port is opened the Due sends a few lines of serial output, then resets, then starts again. I don't think that problem is solved yet.
Do you think this can be solved by software or is it built-in hardware on arduino DUE board ?
The topic of secure USB serial communication with arduino's was always tricky so Alvaro came up with SerPro. What happened is that my scientific and extreme electronics project required very safe RX/TX error-free so Alvaro added 16 CRC's along with HDLC protocol and other stuff as we both are telco engineers with critical software.
The IDE version i've published on my website has removed the arduino-oscilloscope hence not using anymore ADC's link.
In fact, Alvaro is building a new arduino tech based on ZPU, namely you create your own softcore uC inside a FPGA with dedicated instructions, like emulate part of the Atmega2560 you want keep and build low level instructions not found in the market http://www.alvie.com/zpuino/
Regarding ElectroShaman.jar, I've made for my own projects and might publish on github if there is more interest.
On a side note, you might want to see the type of critical software I'm using with MEGA applied to extreme power electronics going up to 3 KVAR's (public) and 10 KVAR's (private). For example, in this video I'm using the four 16-bits MEGA timers, each being specifically delayed 90°, 180°, 270° with less than 62.5 ns time jitter.
P.S.1. In fact, there really SIX 16-bit timers, two of them are being emulated by my specific protoshield using some 74HCxy chips
P.S.2. You might notice from time 7min 0s in the video that actually I live update by ISR (Interrupt Software Routines) all the FOUR internal 16-bit timers register so you'll se a global frequency sweeping up. Due to the special topology of my circuit, this is equivalent to have arduino MEGA-generate phase locked 8 independent PWM rails aka 8 channel frequency generator.
Just hoping the arduino team will soon fix the USB serial issue (programming port) via a new IDE release, at least on my side I cannot afford to migrate my actual project MEGA software using very advanced timer register tricks since i'm shuttling more than 5000 VAR's with my igbt's drivers, blue smoking and $$$ gone !
Once DUE serial USB will be OK, I'll look deeper on the DUE timers which i feel from datasheet are very very interesting with fascinating new features not feasible with MEGA, same with DAC's and ADC's.
You'll notice some of my boards hosting the MEGA as piggy board are in fact fully space compatible with DUE, the board were designed more than 1 year ago betting DUE will come up.
About MEGA used to induce anomalous plasma-resonance, this old video might be of interest
Many thanks Stimmer to have 3rd party independent tested the serial USB issue on DUE's programming port and validated it works as i've claimed on UNU, MEGA 1280 and MEGA 2560 (all rev).
As I've mentioned before, this SerPro has been used on critical software and power electronics for open source alternative scientific projects in many countries for more than 2 years wether Mac, PC or Linux.