Gameduino 3x with Teensy 4.0

DavidHall

Member
I have bought a Dazzler (module, not shield) and I am trying to get it working with a Teensy 4.0. If I just power it up, I do get the 'splash screen' as expected, but once I also make the SPI connections, it goes to 'no signal' on the screen, suggesting that something is happening, but not much.

I am using the normal GD2.h downloaded from the internet, and am trying to run the standard helloworld demo sketch (both version 1.3.4). I have connected the pins as shown below:
• Teensy 12 to Dazzler 22 SPI out (MISO)
• Teensy 11 to Dazzler 28 SPI in (MOSI)
• Teensy 13 to Dazzler 29 SPI in (SCK)
• Teensy 10 to Dazzler 25 SPI in (GPU SEL) (and I changed one line in GD2.h from #define DEFAULT_CS 8 to #define DEFAULT_CS 10). I have also tried using Dazzler pin 27 (DAZZLER SEL).

Plus GND and 5V. The code is shown below; the sketch only gets as far as GD.begin(), where it just hangs. Any users of the same combination who have made it work, please?

#include <EEPROM.h>
#include <SPI.h>
#include <GD2.h>
#define CS 10

void setup() {
Serial.begin(9600);
Serial.println("test1");
GD.begin();
Serial.println("test2");
}

void loop() {
}
 
That looks cool. It shows as 3.3V so that is proper - and it has 5V tolerance.
Up to 36 MHz SPI speed seems nice.
Though here ESP32 sets to 40 MHz: github.com/jamesbowman/gd2-lib/blob/master/GD2.h#L342
But that is using old style set freq instead of that used below for: #elif defined(ARDUINO_ARCH_STM32) where it only sets to 18 MHz
> not clear what the #defines in use are when building Teensy from this look ...

If that is the source of GD2.H then there are things in there that might be improved/fixed with adding code specific to Teensy 1062 ?:'#if defined(__IMXRT1062__)'
> " defined(TEENSYDUINO) " is used at least once and that may work, at least for T_4.0.

Posted sketch code is missing: SPI.begin(); : though not showing in use in his pacman.ino?

THIS "while (1) {" MAY BE THE HANG: github.com/jamesbowman/gd2-lib/blob/master/GD2.h#L1502
Not sure where this might be called?
Code:
#if defined(TEENSYDUINO) && !defined(SPIDRIVER)
static void __attribute__((__unused__)) teensy_sync()
{
  while (1) {
    delay(1000);
    Serial.write("\xa4");
    for (int i = 0; i < 1000; i++) {
      if (Serial.available()) {
        if (Serial.read() == '!') {
          return;
        }
        delay(1);
      }
    }
  }
}
#endif
It seems to be expecting

Saw the pins on pgs 17-18
Seem correct as noted.
CS on T_4.0 could be pin 8 as well as 10 and not have to change code.
Which Dazzler CS is not clear '27 Dazzler_sel' or '25 GPU_sel', would guess use the DAZZLER, but README suggests it should be GPU as you have done.

It shows 270 ms startup time - Teensy typically at least that long esp with Serial.begin() preceding it, but adding a delay(500) before GD.begin(); would assure that all is well with it getting powered and ready.

It shows it takes 180 mA - but if that is coming from USB 5V, and only powering the T_4.0 a proper 500 mA port should not be starving.
 
Thank you, defragster - I have worked on the easy bits first: I have changed the wiring so that I am using Teensy pin 8 instead of 10, just in case. I have wired it to both DAZZLER_SEL and GPU_SEL, to hedge my bets. I've inserted delay(500) just before GD.begin(0) - no result. I have inserted an SPI.begin() too, though since none of examples have that, I guess it's included somewhere else already - anyway no result.

Then I found the code you have spotted, starting at line 1502. I tried inserting a test print statement into it but the compiler didn't like it, and I tried changing the 1000-cycle loop to 10 cycles, but didn't get any result from that. I don't know what I should do to find out if this bit of code is or isn't a problem.

Finally, the early bit about the SPI speed, I'm afraid I don't know what to do with that at all, so if you think it may be the critical thing, please would you tell me how to investigate further.

For the record, current code is:
#include <EEPROM.h>
#include <SPI.h>
#include <GD2.h>

void setup() {
Serial.begin(9600);
SPI.begin();
Serial.println("test1");
delay(500);
GD.begin(0);
Serial.println("test2");
}

void loop() {
}
 
re p#5: just glancing around at 3:25 AM before Zzzzz's
Sounds like that is the GD2.h library source in use. that author has a few repositories and browsing on github on the web is limiting.

Interesting that changing the while(1) code broke build - that means that code is included. Didn't find for what reason the 'TEENSYDUINO' code includes that teensy_sync().
> in the case of the unmounted module it also wasn't clear why the module would count on those "Serial" commands in that function?
> the module appears to only have UART Rx and no Tx back to the 'host' - so that p#4 code must relate to USB Serial? And it is waiting for "!" to come in over "Serial" before returning?
> scanning the PDF there are modes for 'TEXT' and graphic mode? Maybe that is to set it to alternate modes? Except after "Serial.write("\xa4");" that just waits for the '!' : Maybe just send '!' over USB serial and the code will run?, or if that doesn't do anything just make that function return; right away?
> Maybe the define for (SPIDRIVER) should be active for Teensy
As far as the beginTransaction - adding an entry for 'TEENSYDUINO' that recreates that line for ARDUINO_ARCH_STM32 with updated speed entry.

Maybe doing a sketch for the TEXT mode would prove it is working with the SPI connection?

Update with any progress or next steps - don't have one of those modules here. Others might read and see an issue ...
 
I've been studying this library for a while so that it can work with other EVEx chips and boards faster than AVRs and above all, to take advantage of the SDIO reader of teensy boards through the most recent version of the SdFat library.

The library for gameduino 23x (GD2 for friends) works using these files in the following order of appearance:

Code:
GD2.h
wiring.h
GD2.ccp
Both wiring.h and GD2.h have a definition of the display select chip:

In wiring.h is
Code:
#define CS 8

In GD2.h it is
Code:
#define DEFAULT_CS 8

Which one to use? I've always assumed that one of the two was there for debugging purposes when James was designing it; While it is not decided which one to use in the final version of the modified library, the two lines must be changed with the same pin.

Also, in GD2.ccp (lines 39, 40 and 41), I suggest that they stay like this:

Code:
//#if defined(ARDUINO)
#include "transports/wiring.h"
//#endif

This is because the wiring.h file defines the speed of the SPI1 bus; and the most important: the detection/boot routines of the installed EVE chip.

The pointers that allow to identify the installed MCU must be set so that they not only point to ARDUINO, but also to TEENSYDUINO, in order to access all the configuration parameters that the library calls at startup.

James has reiterated that as the library is, it has direct support for teensy, maybe just modifying the chip selection lines (CS, DEFAULT_CS) assigning the same pin number, they will get the Dazzler working.
 
Thank you to TFTLCDCyg and defragster. Here are the latest tests, though none of them have made any difference, I'm afraid. Sorry if I have misunderstood any of your suggestions.

1. Add Serial.println("!"); just before the GD.begin(); statement. No change.

2. Send ! back from the serial window while the sketch is hanging. No change.

3. Modify GD2.h to include several test print statements:
Code:
Serial.println("testing1");  
#if defined(TEENSYDUINO) && !defined(SPIDRIVER)
static void __attribute__((__unused__)) teensy_sync()
{
Serial.println("testing2");  
while (1) {
    delay(1000);
    Serial.write("\xa4");
    Serial.println("testing3");  
    for (int i = 0; i < 1000; i++) {
      if (Serial.available()) {
        if (Serial.read() == '!') {
          return;
        }
        delay(1);
      }
    }
  }
}
#endif

Result – won’t compile, objects to Serial.println("testing1");
Without that statement, it runs, but still hangs at the GD.begin() point.

4. Commented out all of that last bit of GD2.h, lines 1499 to 1515. Still no change, still getting stuck in GD2.h and/or GD2.cpp.

5. Finally, reading TFTLCDCyg’s comments, I have altered GDG2.cpp lines as suggested, taking out the #if and #endif, but still nothing good happening.

Can one of you explain to me what GD.begin() is supposed to do? Does it tell GD2.cpp to run, which then calls GD2.h? Are there ways in which I can test to find out where one of them is getting stuck?
 
Last edited by a moderator:
Added CODE marker selecting the CODE and then hitting the " # " hashtag button on the toolbar to preserve indenting.

Not pulled the code or looked further here. Wasn't sure as noted I had the right code - but finding if and where that teensy_sync() is called might help? It may or may not be that code - it just caught my eye.

It is looking to RECEIVE and .read() the '!' from USB not have it printed if that code is the issue.

With the #ifdef's it wasn't clear which GD.begin() code was running and with what compiled in.

Are there any warnings on building the sketch? Possible changes to build tools made a difference or maybe it worked for T_3.x and there is something unique about T_4.x?
 
There is one warning:

In file included from C:\Users\User\Documents\Arduino\arduino-1.8.19\libraries\Gameduino2\GD2.cpp:40:0:
C:\Users\User\Documents\Arduino\arduino-1.8.19\libraries\Gameduino2\transports/wiring.h: In member function 'void GDTransport::begin1()':
C:\Users\User\Documents\Arduino\arduino-1.8.19\libraries\Gameduino2\transports/wiring.h:119:14: warning: unused variable 'x' [-Wunused-variable]
uint16_t x = __rd16(0x0c0000UL);

I couldn't see anything in wiring.h around that place that seemed interesting or relevant.
 
Unused variable doesn't seem that exciting - wanted to be sure it was building without confusion or side effect from tools.
 
I have followed up defragster's remark about the TEXT mode, which is explained in the Excamera document, https://excamera.com/files/gameduino-3x-dazzler.pdf, which offers the following sample code:

Code:
# include <SPI.h>
void setup()
{
Serial.begin(115200);
SPI.begin();
for (byte i = 8; i <= 10; i++) {
pinMode(i, OUTPUT);
digitalWrite(i, HIGH);
}
digitalWrite(10, LOW);
SPI.transfer(0x41); // Boot from slot
SPI.transfer(0x01); // slot 1
digitalWrite(10, HIGH);
}
void loop()
{
Serial.println("Hello world");
delay(500);
}

The good news is that it compiles and runs without any trouble, the bad news is that it doesn't send anything to my monitor. If I open the serial window, it prints hello world every half a second, but that's all that happens. Does this tell one of you something useful?
 
I also tried writing to pin 8, as that is the one that is currently connected to the GPU_SEL and DAZZLER_SEL:

Code:
  digitalWrite(8, LOW);
  SPI.transfer(0x41); // Boot from slot
  SPI.transfer(0x01); // slot 1
  digitalWrite(8, HIGH);

However I don't have a clue how the code knows where to direct its message to.
 
Please, can you share the modified library that you are using? I have a screen with a FT813 chip and another with a BT817 chip at hand to check the errors it generates when compiling with a teensy 4.1 board
 
Hello TFTLCDCyg - although I've tried out a few changes that people have suggested, right now I am back to using the completely standard libraries, GD2.h and .cpp, versions both 1.3.4.
 
Not sure whether this helps or not but found this *.ino on GitHub ("https://github.com/Dev255/Arduino-ODrive-CNC/blob/gh-pages/CNC_Control_and_Display_-_Ver1_2_3.ino") that seems to give the connections for the Teensy 4.1 to the Dazzler.

* # Pin 8 - OUTPUT - GAMEDUINO GPU select (not yet used - probably won't be used)
* # Pin 9 - OUTPUT - GAMEDUINO SD select (not yet used - probably won't be used)
* # Pin 10 - SPI controlled - CS - GAMEDUINO Dazzler Chip Select (part of MOSI,MISO,CLK,CS - not set with pinMode as controlled by SPI)(REQUIRED FOR MILL OPERATION)
* # Pin 11 - SPI controlled - MOSI - Master Out, Slave In - Gameduino and NRF24L01 radio are the Slave devices, Teensy is the Master (Dazzler CS = Pin 10, NRFL01 CS = Pin 17)(REQUIRED FOR MILL OPERATION)
* # Pin 12 - SPI controlled - MISO - Master in, Slave out - Gameduino and NRF24L01 radio are the Slave devices, Teensy is the Master (Dazzler CS = Pin 10, NRFL01 CS = Pin 17)(REQUIRED FOR MILL OPERATION)
* # Pin 13 - SPI controlled - SCK - Serial Clock - Produced by Teensy to sync communications over MISO,MOSI(REQUIRED FOR MILL OPERATION)

Hopefully it is verification that your connections are correct.
 
At first sight this looks like the connections to the shield. My problems surround the fact that the module version is rather less well supported. I am using connections given in an Excamera document, but it really wouldn't surprise me if there is an error there.
 
@DavidHall - did you order the three pack with the shield mount as seen on the product page? If so a DVM might help verify the routing of the lines from the shield for Arduino connect to the Module edge pins?
 
It's been a while since I touched the base library used in the project.

Let's see: - I downloaded the library from the repository. I have a 5" NHD FT813 screen installed in a teensy 4.1.

Code:
Wiring:
3.3V
GND
TFT-CS-10
SCK-13
MISO-12
MOSI-11

BL-GND
BL-VCC to 3.3V AMS1117 regulator
The first change was in GD.ccp, line 71

Code:
#define DEFAULT_CS 10

The compiler did not present any warnings or errors in the library. The screen shows this image:

CS to 10.jpg

The screen responds and is configured according to the parameters of the 4.3" gameduino´s shield (480x272 px). The installed TFT has a resolution of 800x480 px. So, the wiring is correct but the library needs to load the horizontal and vertical frequency parameters of the TFT.

It is clear that the library responds to the teensy 4.1, it should respond to the teensy 4, without touching anything else in the library.

Now we need to add the screen time table, so that the array shows something.
 
No, only the module itself, unfortunately. I guess I'm hoping for someone who has a shield and might have this information.
 
Good news, TFTLCDCyg. So this is the shield, yes? Do you have means to find out how the pins are connected to the module edges?
 
It's not the gameduino-dazzler shield, I've been waiting for the opportunity to get one for a while now. Hopefully and there will be fortune this 2023. The array I'm testing on is a 5" TFT NHD FT813, with a teensy 4.1

EVE2_01.jpg

EVE2_02.jpg
 
For the record, this thread seems to be dead now. I got no response from Excamera, nor from the forum specifically for the Gameduino range. The people on this forum have tried to be helpful, but right now nothing has made any difference. I can do what I need using a Pi, but there aren't any of those around at the moment anyway.
 
Back
Top