Timing (in)compatibility between GD3X and Teensy 3.5?

[janb]

I want to use the GD3X as an i/o device to my small weather station application, running on a Teensy 3.5.

I bought the GD3X last year from CoolComponents, and did try to run samples using an Arduino Uno board underneath the GD3X, with mixed results. The 'selftest' failed more often than it was successful (various problems), so I did suspect that there might be HW problems. I also had SD card problems, until I got the type Jim recommended.

Since a month now, I'm driving the GD3X with a Teensy 3.5, not using the GD3X's SD card reader (but the Teensy 3.5 reader).

A Teensy 3.5 is MANY, MANY times faster than an Arduino Uno board. Could this cause "timing problems"? Is it possible to "choke" the GPU?

I've used the 'widgets' sample program as a "starting point" for my i/o device programming, and have found unexplicable problems...
If I run 'widgets' "asis", it's not stable! Quite easily I can make it "hang", by moving the 'dial' round and round fast. It always "hangs" on the same instruction, 'GD.get_inputs()'; it NEVER returns! I can't even restart just by reloading; I have to power off/on the GD3X. The setup routine "hangs" on the GD.begin(~GD_STORAGE)' instruction! BTW, what does the '~GD_STORAGE' parameter do; it's not documented?!
If I let 'widgets' run W/O touching the screen, it can run ok for "a while"(i.e doing "NOTHING!"), but fails on the 'GD.get_inputs()' eventually.
However, If I at the top of 'loop' add code to control how often the rest of the 'loop' code will run, the program suddenly becomes "rock stable"!
If I delay 'loop' only a few milli-secs, it stops running after a few seconds! If I delay for 18 milli-secs, 'loop' runs for many seconds but will fail. If I delay for at least 19 milli-secs, the 'loop' won't stop; no matter how hard I excercise the 'dial', 'slider' or 'toggle'!

WHY???

Below is my 'widgets' code with "tracing" lines included, marked with 'JBn'

Jwidgets.ino (4.4 KB)

[janb]

I forgot, I'm using Arduino IDE 1.8.12, Teensyduino 1.51 and Gameduino2-v1.2.2...

[jamesbowman]

GD3X is tested with Teensy 3.x and 4.x. I haven't seen this problem, so I'm interested in finding the root cause.

The parameters to begin() control which systems initialize. The ~GD_STORAGE switches off the microSD initialization. 

GD.begin(~GD_STORAGE);


First two questions...

Just to be clear, is there a microSD card in the GD3X slot, or is it empty?

How are you hooking up the Teensy? I use 100mm jumpers.

[janb]

James, I'm sorry I didn't notice your reply; I thought the "system" would send an email when/if there was a reply...!
Anyway, I DO have a (valid) microSD card in the GD3X slot and I too use short jumpers...
The GD3X +5V is connected to Teensy 'Vin' pin and I power with my laptop USB connection to the Teensy.
I've added "timing code" to the 'widgets' program and the loop code seem to execute below 1 ms.
With my weather station program I get all kind of problems using GD3X. Some/most of them are probably caused by my programming "errors" elsewhere in the code, but quite often the 'GD.get_inputs()' either hangs, or longest execution time can be up to thousands of milli-secs...!

[jamesbowman]

OK, some microSD cards interfere with the SPI traffic - even when not selected. It varies by brand.

So everything can be running fine between the controller and the Gameduino, but at some point the microSD sees what it thinks is a command, and starts writing on the SPI bus.

Is it possible for you to run your application without mircroSD?

[janb]

I've even tried to "manipulate" the GD2.cpp code! I tried to "skip" the 'finish()' line, since I delay my runs of my GD3X code with 20ms anyway, but that doesn't seem to help either; it will still "hang" (or "stop")...

[janb]

Without the microSD card the code "hangs" on the Begin statement during Setup!

[janb]

James, in the 'gd2book_v0' documentation, it talks about 60 updates per seconds (i.e 60Hz), meaning 16.7 milli-secs in between...
To me it seems as if the GD3X actually "chokes" if it is accessed more often than 19 milli-secs in between!
I've used the 'widgets' sample program, with "measurement capabilities" added, and I don't touch the screen at all:

-5 milli-secs ”delay” between ”loops”, stops after 15 seconds, with following shortest/longest execution times:
Shortest=606micros
Longest=606micros
Longest=7170micros
Longest=11446micros
Longest=11720micros
Longest=11997micros
Longest=12098micros
Longest=12187micros
Longest=12215micros
Longest=12258micros
Longest=12260micros
Longest=12265micros
Needs Power OFF/ON to Restart!

- 10 milli-secs ”delay” between ”loops”, stops after 13 seconds, with following shortest/longest execution times:
Shortest=606micros
Longest=606micros
Longest=3420micros
Longest=6687micros
Longest=6956micros
Longest=7216micros
Longest=7254micros
Longest=7255micros
Longest=7270micros
Needs Power OFF/ON to Restart!

- 15 milli-secs ”delay” between ”loops”, stops after 8 seconds, with following shortest/longest execution times:
Shortest=604micros
Longest=604micros
Longest=3426micros
Needs Power OFF/ON to Restart!

- 16 milli-secs ”delay” between ”loops”, stops after 28 seconds, with following shortest/longest execution times:
Shortest=605micros
Longest=605micros
Longest=1679micros
Needs Power OFF/ON to Restart!

- 17milli-secs ”delay” between ”loops”, stops after 142 seconds, with following shortest/longest execution times:
Shortest=604micros
Longest=604micros
Longest=605micros
Longest=1451micros
Longest=1810micros
Longest=1827micros
Longest=1832micros
Needs Power OFF/ON to Restart!

- 18 milli-secs ”delay” between ”loops”, stops after 123 seconds, with following shortest/longest execution times:
Shortest=605micros
Longest=605micros
Longest=606micros
Longest=607micros
Longest=770micros
Longest=789micros
Longest=824micros
Longest=834micros
Needs Power OFF/ON to Restart!

- 19 milli-secs ”delay” between ”loops” does NOT “hang/stop”, with following shortest/longest execution times:
Shortest=605micros
Longest=605micros
Longest=606micros
Shortest=604micros
Longest=637micros
Longest=639micros
Longest=640micros
Longest=641micros
Longest=642micros
Does NOT need Power OFF/ON to Restart!

As can be seen above, the "delay" value plus 'Longest' runtime always seem to become 17-18 milli-secs before it "hangs"!

My conclusion is that, at least with MY Teensy 3.5 and MY GD3X, I MUST "delay" at least 19 milli-secs between GD3X accesses!

[janb]

"Just for the fun of it", I modified 'GD2.cpp' & 'GD2.h' to make 'GD.get_inputs()' accept a 'long' input parameter, where I can specify how many milli-secs to "delay", before continuing with the 'GDTR.finish()' instruction. And it works...; I could remove my own "delay" code at the beginning of my "loop". BUT for this modification to work, the 'get_inputs()' probably must be the first access call to the GD3X for each "loop". I did this trial more to get a better understanding for how things work & interact, rather than a "solution" to my problem... For that, I can just as well keep my "manual delay code", rather than modifying 'GD2.cpp'.
I'm not really bothered with this "delay problem", since my interactions with the screen are few and far in between. I poll it to detect "button commands" or text command strings, and use it to display weather values and replies to user commands...
BUT, I DO think that this undocumented GD3X "feature" SHOULD at least be documented, or even better, fixed somehow!

[janb]

James, I stand corrected! With a 1500mA Net Adapter also hooked up to the 'Vin' pin on the Teensy, I don't need MY "delays" for my application to run w/o "hanging" on the 'GD.get_inputs()' stmt! BUT, the GD3X still "runs" with 60Hz! My code now takes approx. 16.3ms from top to bottom, instead of 300-400 micro-secs when I used my own 19ms manual "delay" between calls.

The 'GD.begin(~GD_STORAGE);' still "hangs", if there's no SD card in the slot...