Just curious - I am running a UC3A1512 with a 12 MHz oscillator. Using the gpio_tgl command in a while loop, I have reached 1.6 MHz square wave output.
Anyone with a higher output? Trying to see if I have got the UC3's gas pedal on the floor . . .
David
I have never used a UC3 or even read a UC3 datasheet.
I would guess that there will be a PLL to drive the Peripherals and a PLL to drive the Core.
So you can probably run both faster than the 12MHz clock.
.
And most microcontrollers have hardware timers and PWM that can toggle at 1/2 the Peripheral clock frequency.
e.g. a 20MHz Mega (without a PLL) can produce 10MHz.
e.g. a 32MHz Xmega can produce 16MHz.
.
David.
I have never used a UC3 or even read a UC3 datasheet
Neither have I (but have played with the AVR32 cores in some of the mXT touch controllers)
I would guess that there will be a PLL to drive the Peripherals and a PLL to drive the Core.
I would think that'd be a very good guess.
A quick look at the Product Page confirms:
Two Multipurpose Oscillators and Two Phase-Lock-Loop (PLL) allowing Independent CPU Frequency from USB Frequency
Are you using the ASF gpio_tgl_gpio_pin() routine ????
If so, then if you examine the code in that procedure you will see that it does 3 things ;
1: a bit toggle,
2: a 'set the pin to be an output'
3: a 'set the pin to be an I/O pin'
Generally, items 2 & 3 only need to be performed once, so you could configure the pin and then write you own routine to do the toggling.
Even faster would be to configure the pin for I/O output, enable the local-bus feature and then use the local-bus addresses (eg gpio_local_tgl_gpio_pin(); )
Hey guys - thanks for the replies. I am sure there are other ways to get faster wave forms that using gpio_tgl_pin, but I was interested in using that since that is the method I write to my LCD displays for such bits at write, reset, cmd/data.
Using gpio_local_tgl_pin upped my output to 7.00 Mhz.
I am using the pll to drive the processor - at 66MHz, I think.
Kind regards,
David
I am using the pll to drive the processor - at 66MHz, I think.
If you're not sure, then route the clock to an output pin - and measure it!
Like any compiler GCC sometimes outputs "less than optimal" code for your uC.
If speed optimisation at this level is important to you, then generate a list file and study the C -> Asm translation of the compiler.
The arduino lib's are notorious for slow I/O (with their digital out () funtion), so when I wasy playing with tha adafruits lib for a 3" graphical LCD and I saw that they used the digital_write() to toggle the data read pin of the lcd I was horrified.
Changing those 2 lines to direct port manipulation gave an instant performance boost by halving the time for the demo program.
That also was a bit surprising. Because there are so many calls to this function when writing to the lcd and the horrible way digital_write() works I would have expected a much bigger boost.
I also had a go at optimizing the datapins between AVR and the LCD (see Adafruits "pinmagic.h") but that had a much smaller impact.
That's where I stopped trying to mate an AVR with a graphical LCD and switched to ARM.
STM32F103C8T6 is about the same price as an AVR and I'm sure it will give the performance boos I'm looking for.
Morel of this story?
It's good to want to write clean code (Always!!!) and have a general idea of optimisations, but don't stare at them untill it blinds you.
Like any compiler GCC sometimes outputs "less than optimal" code for your uC ... The arduino lib's are notorious for slow I/O ... Changing those 2 lines to direct port manipulation gave an instant performance boost
Note that this has nothing to do with compiler optimisation - it is entirely down to the way the library itself is written.
"Optimisation" is always a trade-off. AIUI, Arduino here optimises "ease of use" by the programmer - at the cost of runtime code size/speed.
So the key thing is to understand any "libraries" or functions you are using.
It is in the very nature of general-purpose functions they they will not be optimised to any specific requirement!
