Jan 17 2014
ARDUINO DUE unboxing and speed test
DUE pinout
my friend buy from thaieasyelec ( lucky, now out of stock ) and send me hopefully today for test / play.
i want to speed test it and make a PMS3 revision ( oor an cope)
for DUE and MAX32 and compare the results.

actually there is a other question, not sure i can answer, that price is so low that i have problems
to believe its a original, but my usual supplier thaiduino say we can trust them.
as usual in our fast changing world: i need a new arduino revision.
now i download arduino 1.5.5 r2
and here i work on revision PMS33, using last PMS3 V3.2R, the version for RPI,
( where the usb connection is slowed down / not the scope batch ).
and as i adjusted in IDE the
arduino DUE programming port
the compile runs into errors because of a naming conflict,
__AVR__ does not work anymore for DUE and bunch of variables are not defined.
so whats the new name? its not __DUE__ or __ARM__ or __SAM__
ok i found it by search in IDE code: __SAM3X8E__ that would have been my next guess (555==hahaha)
cpu info here and AD converter.
so for speed and volt settings i start with a copy from __PIC32MX__ data,
also a 3v3 board, and need the voltage divider to measure the 5V range.
today the THAI POST EMS was one hour late, but no problem, i was out one hour for running anyhow.
( here in CMS also now test first time image zoom function )





how to connect?
the USB connector is different from the old arduinos, its the small one, but not same as with MAX32.
so actually its the same as with RPI and my LG mobile / charger cable, lucky.
connect, green LED and yellow blink.
but WIN7 as usual driver installation fails.
as some things look different now, here detail snaps of the next steps,
- DRIVER install




- IDE adjust


- compile upload

it's my lucky day!
but instead going into the details of PMS i start with some mini benchmarks,
my menu program template needs update anyhow.
It is more as a menu on the USB interface, you could call it a uOS
because it is prepared for 10 semi parallel tasks, but the examples are all disabled.
so it is running just in a loop and counts,
with diagnostic ON (menu "d" ) it prints the internal time after 1.000.000 loops.
but its not that easy, even if all conti-jobs are OFF, that program still does there 10 IF's each loop,
and it counts also for the serial interface, up to 501,
and checks if there is a operator input, using the Serial.available() function.
and for both counter the IF for the limit reached.
so: in that 1.000.000 loops it counts to 2.000.000 and makes 12.000.000 IF's and
2000 serial avail checks:
for the MAX32 PIC must use MPIDE0023 and rename all .ino to .pde
the print (F()); not known, change back, (!Serial) for leonardo and inputstring.reserve(20); not work with PIC32.
MEGA(16MHz): 17sec
UNO(16MHz): 16sec
DUE ( 84Mhz): 6sec
PIC32(80Mhz): 1.6sec
that is so fast that i blame the changes here and reload that code back to the DUE for recheck.
no rename, no change needed, just compile and upload and see the 6sec again.
yes, i know that for benchmark must give/compare more jobs. here it would be digital I/O, analog read..
or do the opposite, i could try to disable or reduce the serial check assuming that that is a arduino function code flaw
( what i suspect for some time already ). perhaps i do later, lets just say:
compared to Arduino MEGA the DUE is 3 times faster and the PIC32 10 times!
and compared to the UNO, the DUE is more a comfortable spacewagon, not a ferrari.
but that's just a first impression.
and pls note, that above data use the internal timer of the devices!
i have to think about a timer check setup:
could be a slow function ( avoid heavy serial I/O ) like above counter, and send it to processing
where you could report the delta time between the (usb) events over some time.
( assuming that PC time is better as arduino time??? )
until now i have only one valid info, a UNO running a timer ( made from millis )
and send a SMS (with data) all 6 hours ( for month ..)
there we see that the UNO time was wrong/slow about 3min / day.
b.c. the SMS came every day 3 min. later.
but its not all about speed, now i also check the prices,
ARDUINO STORE:
MEGA 39euro + VAT
DUE 39euro + VAT
UNO 20euro + VAT
DIGILENT or at a german store
MAX32 49.50$ / 36.32euro + VAT
ok, back to PMS3.
now first again disable processing and work in line chart mode
there is no speed up of analog in until now for SAM,
because its not a max32 ( using a assembler code with pointer 0 ) and not a AVR using a setup for faster reading.
need to find a good start frequency first,
set pointer to 5 and see 10500Hz.
set a jumper and get confused???
that values does not make sense using jumper GND to A0,A1,A2
and jumper 3V3 to A0,A1,A2
go back to the menu program and check from there, also not ok.
! i did NOT try to measure 5V!
sometimes i see it measures random, not connected values,
and sometimes think channels 1 and 2 are switched??
i see no other way, i try the old arduino 1.5.4
after upload see only speed of 4550Hz ( instead of the 10500Hz )
and the channels (0,1,2) do what what they are supposed to do.
UPS, that was a bad one.
see 4rum, download
hardware/arduino/sam/cores/arduino/wiring_analog.c and replace.
select a slower speed, connect A0 to GND, A2 to 3v3, A1 hold the wire in the hands

ok 155r2mod looks good now.
but possibly it was not only analog in wrong, also a timer? nope, 6 sec again.
so for the default timing of scope i need to adjust the delay array.
now that's not only time consuming, its also not easy to understand.
there is a pointer 0 .. 15 to a array of tunable numbers ( DELAYs )
but, the first 2 values are 0 delay.
pointer 0 means a delay where the board measures A0 only ( one channel, no delay )
in the code it is getting more difficult, because a delay of small values gives errors, so the delay must be disabled.
pointer 1 ( also no delay ) means you measure (with PMS3 ) 3 channel as fast as possible.
pointer 2 .. 9 are delays between measurements of 3 channel by delayMicroseconds
pointer 10, 11are delay by delay what are millis,
pointer 12 .. 15 are delay by delay what are millis, but here we not read first the batch and send later,
here we are so slow that we can do read Ains, write USB in conti modus.
( that's not a concept you think up first, its growing )
and that array exists for PIC32MX ( 2 channel, 3 channel )
AVR ( 2 channel, 3 channel, 3 channel fast ADC setup )
and now we do for SAM3X8E
the delay means a final Hz sampling rate, and that is not adjustable accurate,
but the step size should be usable.
to keep track of this and visualize it outside of the code, pls see spreadsheet here
looks like now, in the pointer range 1 .. 4 DUE is faster as the PIC and i could tune,
and for pointer 0 with 188kHz samplerate its not only 5 times faster as the speeded AVR (35kHz),
what at default had about 8kHz only, it is not too far away from the 520kHz of the PIC32 assembler routine.
it can take me some time to find something for the SAM, but i know already that there is a default adjustment by arduino possible. you can adjust analogReadResolution(bits), 8, 10 default, 12
but i not see mentioned if that is relevant for speed ( but it should).
But as we do a comparison here its not fair now switch from 10 bit like UNO..
to a 8 bit resolution, just to get impressive speed numbers.
The first checks in 4um show a 1MHz sample rate is possible.
but first did small tuning like pointer 2 means now 50kHz..25 ..15..10..5..2.5
for the SAM speedup ( first for A0 only ) start with a separate program following the forum info.
starting with the example from STIMMER for fast 2 analog in and test with
arduino 1.5.4 > 500kHz
arduino 1.5.5 > 333kHz ( r2 with fix )


using STIMMERs one channel version reach 666kHz instead of 1MHz,
and build it into PMS33. using the same variable and function names and program structure as with PIC32.
but keep the #if defined(__SAM3X8E__) separated for understanding and maintenance.
there is one more thing i not understand, the result is 4095,
like for a 12bit value, but that does not say anything. i just divide it by 4.
there now i have 2 problems, if i use that code the measurements at delay pointer 0
seem not to fluctuate same on open / touched wire ( so need a good test signal for check )
and when i change ( by + ) back nothing works on all 3 channels, but only when i use arduino 1.5.5
while with arduino 1.5.4 the speed at 1 is only 8kHz, at 0 its 1MHz ( Stimmer code works ) and i can switch back to 1 ( 3 channel) successfully.
no, not very funny!
with pic i not needed to set parameters back, on DUE with STIMMER code and 1.5.5 it seems to be necessary to reinstall default settings, i have to find that code first, search "adc_init", but i don't want to make a system init.
other way is to find the way to switch between STIMMER code 1 channel / 3 channel ( but then i can use 0,1,2 only or my channel 3 select A0 ..A5 gets difficult )
so the adc_init works, and also under arduino 1.5.5 i can switch back from 1 channel to 3 channel mode.
the only issue now is that in 1 channel mode, A0, i see only 333kHz, and not 666kHz for 1.5.5 or 1MHz like for 1.5.4.
but now test with the "real world":
-0- switch to processing mode ( means send no chart line, only numbers, and batch of 360 records )
-1- rev PMS33 use processing 2.0.3
-2- use a 3 channel voltage divider
SIGNAL _ 10kohm _ Ax _ 1kohm _ GND == factor 11 ==> measuring range 36V
-3- make a puls (5V) by arduino UNO Dout7 with delay 100usec
-4- connect: A0 to UNO puls, A1 to 3v3, A2 to 5V USB ( on DUE board ) ! using above voltage divider !
-5- run PMS33 DUE via processing PMS33 at pointer 1, see 3 channel at 70kHz ( use 1V/DIV )
-6- switch to 0 ( fast button in scope ) see 1 channel at 333kHz



summary:
at the end of this tests i more think its a not a ferrari
but a spacewagon with a porsche motor.
bad luck that some transmission dimensioning ( arduino 1.5.4 / 1.5.5 ) not optimal.
pls download here
update: i not remember what i tested yesterday, but today i used that feature from STIMMER to do a analogread(0) first and then set the ADC free running mode, because in pointer1 last read cycle was from A2, now with doing one more read from A0 the "focus" is on A0 and the fast ADC code now works with 666kHz ( under 1.5.5 ) ( without it was the 333kHz ), but i noticed now i can not switch back to slower, it hangs after the adc init???
with 1.5.4 i see >900kHz, and i can switch back to slower, ( but that is all that old 8kHz slow ) .
now as i have the first time a board with DAC a real analog output i want to play with that too, in 2 steps:
- a - signal generator
- b - PID control (pls see here )
and with that i not need all the super speed crap...
as i use the DUE for that 2 little projects, i need the MAX32 as scope and for that i just try there the above latest PMS33 beta (a)
to confirm it still runs with it. ( for mpide0023 need rename all *.ino to *.pde ) ok
for the signalgenerator i start with the last version what had
- a PWM output on D3 ( where A2 from poti sets the pulswidth )
- a myPWM on D7 ( where A2 from poti sets the pulswidth and A1 from poti sets the basefrequenzy )
- and add on DAC0 the new analog OUT
because the waveform table thinks in 4095, the output resolution is set to 12 bit and that
is valid for DAC and PWM! so all output parameter match now with 4095. This can now only run on DUE!

download here