I'm sorry, but lost by what the meaning of 2/10/50MHz output actually means.
When a voltage transitions from 0.4V to 2.9V it takes time. You understand that a square wave can be treated as a sum of sine waves, and the faster the square wave, the higher the frequency of the sine wave components.
If a pin is driving a wire off-board, it will radiate energy, exactly like a radio transmitter. The faster the change between the two voltages the higher the frequency. This is 'a bad thing'. The radiated signal is noise which might interfere with other systems.
The facility to slow the voltage change is very helpful if you want to drive a piece of wire more than a few inches.
So even if the state of a pin is only changed, say each microsecond, the rate at which the voltage driven by the pin changes could be different. If it were 2MHz, it would have a much lower frequency component than the same pin, driven at the 1 microsecond, but which is transitioning at 50MHz, i.e. 25 times faster.
How much of a difference will the length of wire between the Maple to the device effect performance? I know that signals stretch out and squares waves get distorted if the cable doesn't meet its bandwidth requirement (since a square wave of a combination of sin waves). But, I figure that the ~12" of cable I'm using shouldn't effect performance much.
USB Full-speed is 12MHz. It has a good ground/earth shield, and differential signalling and is good for a couple of metres.
With a good ground return, you might be okay. It is likely more of a problem for somebody with a radio near bye than for you :-)
It would likely fail any FCC tests, for example. With a 50MHz transition, it'll be radiating at only an octave below FM radio, so harmonics might have enough energy to be picked up on an FM radio (very easy test if you have a radio to hand).
Is the only way to get high GPIO access to bypass the software, and use something like the FSMC on the fancier STM32 chips? I can has a Maple Native?
As long as it is being accessed via the same instructions, the instruction timings for load and store are the same.
Unless the LCD can be memory mapped, in which case each access will do two jobs.
If you could devise a way to use the DMA controllers, then you might get a speedup.
One of my benchmarks I have is filling the screen with a single color repeatedly, a few thousand times. That benchmark yields about ~1 million pixels per second on my ATXMega128A1 @ 32MHz (32MIPS). The same test on the STM32 yields only ~60% of the performance (600 thousand pixels per second).
I've had a quick look at the ATXMega manual, and I believe some of the store instructions claim single cycle execution (ATmega was 2 cycles). So I am impressed, it may well be able change a pin at 32MHz, which would give a pin toggle frequency of 16MHz; not much slower than the STM32F.
Further, the ATXmega does have some nifty load and store instruction addressing modes. For example, a byte can be loaded from memory, and a register, which contains the address of the data, can be incremented, all in a single instruction.
So, I am very surprised, but can just about imagine it might be faster than an STM32F for this job.
But, if that code is representative of filling the LCD with one colour, then I don't really understand why it is so slow. I'd expect it to be a couple of megapixels/second.
I'd have to understand the LCD better and read your code to give you good advice.
How fast can the LCD go?
My knee-jerk reaction is to read the code very carefully, and maybe try to use the whole 16 bits of a port, and/or DMA to go faster.
If you could line things (in time) up exactly, you might be able to drive the pin-toggled LCD_WR_PIN with a timer at a fixed frequency, and use DMA to pour colour data out the port. That would have the nice side effect that almost no processor is used. This would take some serious study of the manual.
On the scope, this got me a sine wave of roughly 18MHz period, i.e. 4 processor cycles per period, 2 processor cycles per transition.
Yes, that's what I got. It is pretty useless code. If all that is needed is a square wave at a fixed frequency on a pin, it would be almost as easy to program one of the timers.
As soon as actual data is retrieved and presented to the pin, the rate that the pin can be changed is slowed.
When I loaded data too, it came down to about 12MHz.
(full disclosure: I am not a member of LeafLabs staff).