Go Down

Topic: Aduino Due vs. Nano performance (Read 6812 times) previous topic - next topic

HermannSW

I will stop here. Below diff shows the only real changes from Okio.
I did rebuild "system_sam3xa.o" and replaced the one in "libsam_sam3x8e_gcc_rel.a".
Now uploading simple Blink example does not blink.

We need Okio to clarify on what he did and where and how.

Code: [Select]
$ diff system_sam3xa.c.orig system_sam3xa.c
31c31
< | CKGR_PLLAR_MULA(0xdUL) \
---
> | CKGR_PLLAR_MULA(18UL) \
79c79
< PMC->PMC_MCKR = (SYS_BOARD_MCKR & ~PMC_MCKR_CSS_Msk) | PMC_MCKR_CSS_MAIN_CLK;
---
> PMC->PMC_MCKR = SYS_BOARD_MCKR;
$


Hermann.
αβ, xy & L₁/L₂ positioning systems with two 28BYJ48 stepper motors:
https://forum.arduino.cc/index.php?topic=649769.0
stepper PT camera system:
https://forum.arduino.cc/index.php?topic=647703.0
https://stamm-wilbrandt.de/en/Raspberry_camera.html

HermannSW

#16
Jan 09, 2016, 03:50 pm Last Edit: Jan 09, 2016, 04:02 pm by HermannSW
I looked into the Sparkfun posting and found instructions that made overclocking work:
https://forum.sparkfun.com/viewtopic.php?f=42&t=38327#p187184

Okio's lines just need to be inserted as first lines in Setup(), nothing more.
Serial communication does not work anymore, though.
I measured 108MHz by manually counting blinks of Blink example using stopwatch.
αβ, xy & L₁/L₂ positioning systems with two 28BYJ48 stepper motors:
https://forum.arduino.cc/index.php?topic=649769.0
stepper PT camera system:
https://forum.arduino.cc/index.php?topic=647703.0
https://stamm-wilbrandt.de/en/Raspberry_camera.html

ghlawrence2000

Yes, I realised doing it in setup 'something' happens because not only is serial messed up but among other things micros/millis are messed up also. I was after doing this 'properly'... with all features working.

I am still doing battle with Ubuntu even having followed your instruction about setting the environment variable....

Did you try make in the variants/arduino_due_x/build-gcc folder?

Graham
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

ghlawrence2000

#18
Jan 09, 2016, 04:35 pm Last Edit: Jan 09, 2016, 04:37 pm by ghlawrence2000
By the way, if you want to fix your serial while still using the Setup() method, this will do the trick :-
Code: [Select]
#define SYS_BOARD_PLLAR (CKGR_PLLAR_ONE | CKGR_PLLAR_MULA(18UL) | CKGR_PLLAR_PLLACOUNT(0x3fUL) | CKGR_PLLAR_DIVA(1UL))
#define SYS_BOARD_MCKR ( PMC_MCKR_PRES_CLK_2 | PMC_MCKR_CSS_PLLA_CLK)
//Set FWS according to SYS_BOARD_MCKR configuration
EFC0->EEFC_FMR = EEFC_FMR_FWS(4); //4 waitstate flash access
EFC1->EEFC_FMR = EEFC_FMR_FWS(4);
// Initialize PLLA to 114MHz
PMC->CKGR_PLLAR = SYS_BOARD_PLLAR;
while (!(PMC->PMC_SR & PMC_SR_LOCKA)) {}
PMC->PMC_MCKR = SYS_BOARD_MCKR;
while (!(PMC->PMC_SR & PMC_SR_MCKRDY)) {}
SystemCoreClockUpdate();


Regards,

Graham

PS, it doesn't fix SPI speed problems...
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

HermannSW

#19
Jan 09, 2016, 05:09 pm Last Edit: Jan 09, 2016, 05:16 pm by HermannSW
Thank you Graham, "SystemCoreClockUpdate()" call is so cool and fixes Serial completely!

I just ran my sketch from first posting in this thread.
It did measure maximum of 13572 with 1024Hz interrupt frequency @84MHz Due speed.
Now maximum of 17281 (increments of volatile long variable) gets reported!

So the speedup is real, and the program works as if Due was run normally @84MHz, just quicker.

Btw, how to configure for 96MHz and spec reference on how MULA value (18/15/13) translates to Due clock frequency can be found in this posting:
http://forum.arduino.cc/index.php?topic=241503.msg2556836#msg2556836
αβ, xy & L₁/L₂ positioning systems with two 28BYJ48 stepper motors:
https://forum.arduino.cc/index.php?topic=649769.0
stepper PT camera system:
https://forum.arduino.cc/index.php?topic=647703.0
https://stamm-wilbrandt.de/en/Raspberry_camera.html

ghlawrence2000

You are welcome, good luck with your future experiments :D

Regards,

Graham
UTFT_SdRaw now included in library manager!! ;) High speed image drawing from SD card to UTFT displays for Mega & DUE.
UTFT_GHL - a VASTLY upgraded version of UTFT_CTE. Coming soon to a TFT near you! 8) Shipping April 1 2016!

HermannSW

αβ, xy & L₁/L₂ positioning systems with two 28BYJ48 stepper motors:
https://forum.arduino.cc/index.php?topic=649769.0
stepper PT camera system:
https://forum.arduino.cc/index.php?topic=647703.0
https://stamm-wilbrandt.de/en/Raspberry_camera.html

westfw

You don't HAVE to change the system_init() functions (which does indeed look like a real pain in the neck) - the SAM chips let you change the clock frequency at any time.  That probably has it's own complications; lots of Arduino stuff is going to initialize using 84MHz.  But you could probably slip the changes to the PLL configuration into variant.cpp just after the call to SystemInit(); and be pretty safe.   (You might have to temporarilly switch the clock to another source; I don't know if it likes/allows you to change the PLL while you're using the PLL-derived clock.)


HermannSW

#23
Jan 10, 2016, 04:03 pm Last Edit: Jan 10, 2016, 04:10 pm by HermannSW
Thanks,

Quote
You don't HAVE to change the system_init() functions (which does indeed look like a real pain in the neck
that is what I learned yesterday, changing in system_init() does not allow to run any program flashed.

Quote
the SAM chips let you change the clock frequency at any time.  That probably has it's own complications; lots of Arduino stuff is going to initialize using 84MHz.
Interesting, yesterday I did always change the clock in first lines of setup().

Quote
But you could probably slip the changes to the PLL configuration into variant.cpp just after the call to SystemInit(); and be pretty safe
Good to know.

Today I did test two programs from ILI9341_due graphics library with Due overclocking.
The results show that overclocking does not always speed up computation time.

First I tried "graphicstest", and I did sum up the 12 measured microsecond values.
Here are the results:
84MHz1266640μs
96MHz1266640μs
114MHz1273441μs

Next I tested "sdFatTftBitmap", and these are the milliseconds for loading an image from SD card and displaying:
84MHz140ms
96MHz145ms
114MHz153ms

 
The good news is that both programs still work fine, the bad is that 114MHz resulted in slowdown both times.
αβ, xy & L₁/L₂ positioning systems with two 28BYJ48 stepper motors:
https://forum.arduino.cc/index.php?topic=649769.0
stepper PT camera system:
https://forum.arduino.cc/index.php?topic=647703.0
https://stamm-wilbrandt.de/en/Raspberry_camera.html

Go Up