GD2 Slows Down on Custom H/W

[jethronull]

I developed a nice GUI for a controller interface using GD code on a GD2 and a stock Arduino Mega.  Works and looks great.  But I needed to port it to a (non-arduino) ATMega 1284P and a ConnectEVE that the controller uses.  I used an Arduino board config called "Mighty 1284p 16Mhz using Optiboot" (though I use an AVRISP mk2 to program).  I had to spend some time finding the pin definitions and moving them around.  I also had to rotate the display and play with swizzle, but my original code now runs correctly and looks fine.  What's annoying now is how sluggish it is.  The processor runs at the the same 16Mhz.  It did speed up a bit when I took out the Serial.println debug stuff (not sure why).  But it's still way slower than on the Arduino Mega.

Any ideas?

Also, does GD2 actually use the interrupt itself?  I couldn't see that it does from the code.

Also, also, like the GD2 device, the ConnectEVE and the 4D Systems displays don't use the FT800 reset.  This makes starting the display very unreliable.  Is there a startup sequence that helps?

TIA

[jamesbowman]

Hmm. Maybe check that the SPI is running full speed?

No, the GD2 library does not use the interrupt at all.

[jethronull]

OK, some weird observations:

I tried SPI.setClockDivider(SPI_CLOCK_DIVxx) in various places, above and below GD.begin() but had no luck in changing the SPI. I suspect your code just resets it.

I have been used GD.begin(0) because the custom hardware does not have SD support (I saw you'd suggested that in another post). I wondered if that was something to do with the slow down. So I tried without the zero and it starts up in auto-calibrate mode (upside down and wrong colours because it hasn't seen the rotate and swizzle commands yet) and I can go through the calibration process at normal speed (with normal sounding beeps), BUT when that completes the FT800 seems to be running slow (beeps are much lower frequency) though the screen writing and touch response seems to be the same (as slow as with begin(0)). Odd eh? Not sure if this points toward a solution to my problem but suggests that begin(0) does more than just disable the SD support.

TIA

[jamesbowman]

Aha, that makes this clearer. Try this:

GD.begin(~GD_STORAGE);
One of the things that GD.begin() does is to 'tune' the FT800 clock so that it runs at about 48 MHz. Without this step it leaves it running at about 24 MHz.

[jethronull]

That has made it a little bit more responsive (maybe), but the beep pitch is still down from what it is just running on your board and an Arduino Mega. Even weirder, I tried a hybrid of your GD2 board with our custom 1284p board and it's even slower (impressive bass on the beeps now!). But now I think I see two different things going on here:

Something is making either our code run slow (or the SPI interface).
AND
Something is slowing down the FT800 (hence the lower frequency beeps).

The former may be something weird on our board, I'll try some speed tests with simple code.

The latter is probably something wrong with the FT800 clock tuning as you say (though GD.begin(~GD_STORAGE) hasn't fixed it).

[jamesbowman]

One way to see what's going on with the FT800 is to read back REG_FREQUENCY.

GD.rd32(REG_FREQUENCY);
after clock tuning it should be approximately 48000000 (meaning 48MHz).

You can also check the actual running frequency of the FT800 by doing:

uint32_t t0 = GD.rd32(REG_CLOCK);
delay(1000); // wait 1 second
uint32_t t1 = GD.rd32(REG_CLOCK);
uint32_t frequency = t1 - t0;


[jethronull]

Now we are getting somewhere... So, I found the slow down problem on the custom board - the fuse bits weren't being written by the programmer (another story), which meant it was running at the slowest possible speed. But now the FT800 is running normal speed (no more low frequency beeps). Maybe the FT800 defaults to a slower clock if it sees a slow SPI bus? SO, both devices are now running full speed and just lovely. Except (you knew it was coming) I have a new problem related to screen calibration and rotate. I'll put that in a new thread.

Thanks James!