Hello all,
I started this thread cause I needed to use a larger display due to my gorilla fingers.
Thanks for the pointers to the Nextion and to the GameDuino. I purchased a few of both and have been developing hardware and software to test both.
Probably a lot of what I will say is obvious to some but here goes anyway.
I have both working. I ran into some crashing of GameDuino - I shortened the wires and it appears stable - and learning curve for Nextion.
It appears that both use the same display and touchscreen overlay. Both have unacceptable angle degradation past about 45 degrees.
Both attach their own hardware interface.
Nextion for user interfaces - and really pretty much only for user interfaces. The 7” display is 800 x 480 pixels for both.
GameDuino as a general display for anything that requires high bandwidth.
Both communities are somewhat limited so finding info is challenging.
There are a variety of display sizes for both. You can buy the Gameduino at local suppliers (e.g., Amazon, Adafruit, or direct from excamera.com. You can buy the Nextion at local suppliers with a rather large overhead or from China (Banggood) for much less (e.g., Nextion Enhanced 7” is $63.99 at Banggood, $78.65 at RobotShop and $107.88 at Amazon). I bought mine from Banggood and they are legit – but expect a 2-3 week delivery.
The GameDuino is a very thin interface between the host and the SPI of the display.
The GameDuino includes a headphone output and an on-board accelerometer.
The GameDuino 2 and GameDuino 3 are software compatible so the Arduino library for GameDuino 2 works with the GameDuino 3 display.
I want to start with a MAJOR downside of the GameDuino; that is, the mechanical mounting.
The Gameduino board is double sided taped to the raw LCD and touch screen and that is what you get.
There are absolutely no mounting holes, or as far as I could determine, bezels to make life easier.
I am not a fan of touch screens recessed from the front panel and this was a problem because there are elements that stick out from the top of the LCD including SC card and audio headphone jack.
I queried the forum and found a couple of people that 3D printed (after getting tired of taping).
This was definitely not thought out.
The Gameduino board, taped to the back of the LCD, has two rows of pins intended for an Arduino board. This also makes interfacing a bit awkward.
For those that have used the ili9341, it will seem very familiar. Outside of the actual low level access to the Arduino library, the code from the ili9341 should port over easily.
You will connect the necessary SPI wires (watching closely the wire length and quality of wire and connectors) as SPI is touchy.
As a thin interface, all of the coding is up to you and runs in the host (e.g., Teensy 3.6)
The arduino library GD allows for setting of Tags to identify any object that will be providing input to the host (e.g., touch)
or receiving output from the host.
These might include user interface widgets such as button, sliders, gauges text strings.
There is a lot I haven't played with yet, like 3D or video (left for future endeavors).
The interface is OpenGL'ish in that it is state based. For example, there is a single color that, once set, is used for all subsequent draws.
Thus, the color must be changed anytime a different color is required. You define objects, like rectangles, with context dependent code, for example:
GD.Begin(RECTS);
GD.ColorRGB(0x0000ff);
GD.Vertex2f(x1*16, y1*16);
GD.Vertex2f(x2*16, y2*16);
The Begin(RECTS) alert the Gameduino that following will be two vertex commands that dictate the top-left and bottom-right corners.
NOTE: there are two ways to specify a vertex:
GD.Vertex2ii(x, y) where x and y are pixels and
GD.Vertex2f(x, y) where x and y are 1/16th subpixels (see above example).
Currently, there appears to be a bug in the library when using the Vertex2ii (probably some bit masking limiting the vertex x or y coordinate to 9-bits. For the early smaller display 480 max dimension this was fine, but for the larger 800 display this caused failure. A user was kind enough to let me know that the Vertex2f (not a floating point) did not exhibit this bug. James Bowman, designer, suggests
#define VX(x, y) GD.Vertex2f((x) << 4,
<< 4)
To remove the x16. No biggie, just pointing that out.
Touches are debounced internally.
On the Teensy end, when an input arrives, it is identified by a tag which would be one of the Tags you defined for your widget.
Now, for a first look at the Nextion.
Again, this is for user interfaces and not intended to be used as a graphics display.
There are some graphics commands, but they are slow.
The Nextion is based on an Arm M3 processor.
You need to program both the Nextion M3 and your host micro.
The interface is serial and I connect to Serial 2 (which is the library default).
An Arduino library is provided for interfacing to the host micro.
Forget about the high quality of the Teensy libraries, this code, while it appears to work just fine
Has a bunch of warnings (mostly variables not used), that I fixed (as much as I hate diddling with libraries, I hate warning messages more.
The Nextion M3 code has to be downloaded into the M3. The M3 has one 4-wire serial connector (+5, Gnd, RX, TX). It is 3.3v tolerant and I connect directly to Teensy pins.
My preferred way of downloading is through an SD card. Steps:
1. Develop M3 code using the Nextion graphical editor (more on this in a sec).
2. Compile and copy to the microSD card.
3. Turn off Nextion.
4. Insert card.
5. Turn on Nextion.
6. Observe Nextion upload code.
7. Turn off Nextion.
8. Remove microSD card.
9. Turn on Nextion.
Painful right? There is another interface though. You can wire a DPDT switch to switch the Nextion RX and TX to either connect to the Teensy or to a USB-TTL converter connected to the host computer.
Then the editor allows you, once compiled, to upload directly with a single button push.
That seems much better, until you try it. Expect a minute or two.
This, in and of itself would be a show stopper, if it wasn’t for the, what I consider, excellent graphical editor. You can pick and place your widgets and then compile. It is similar to the Microsoft Visual Studio in that there is a properties panel for each widget where you can set parameters. Like Visual Studio, you can select multiple widgets and change a property in all. Somehow, the designers, seem to have the necessary features to make this work.
Then, even better yet, is the Debug button which will allow you to somewhat test the interface making sure you like it.
The debugger also has a second purpose, and that is an editor to build code for the M3. For example, buttons have Touch Press Event and Touch Release Event panels. Checking the “Send Component ID” box will cause the M3 to send an alert to the Teensy when the Press or Release occurs. Within the panels, one can write pseudo C code to have executed. This is really great as I have built number pads, dual-state buttons, that do all of the operations I desire within the M3 itself limiting the code in the Teensy. The Debugger lets you see it operate.
Thus you won’t be downloading very many times (REMEMBER: the Nextion is for user interfaces).
On the Teensy, The Component ID is provided in the serial transmission, which can be identified.
Each element has an page id, component id and component name. Within the Teensy code, each must be included in a call to the widget constructor. For example,
NexButton myButt = NexButton(0, 2, "b0");
Identifies a button called myButt as a Nextion button that is on page 0, has an id of 2, and a name of “b0” as defined by the Nextion editor. Callbacks are then provided in the Teensy for handling the events.
Care needs to be taken here.
Within the Nextion editor the widget id’s are assigned incrementally beginning with 1. You cannot change this number; however, the Nextion editor can, if for example, you remove a widget. Say you remove widget 3 in a UI of 10 original widgets 1-10. You have identified in your code these widgets using 1-10. Thus, the Teensy code has to be changed. Symbolic enum{} are called for here so that you can remove a widget symbol from the enum an the numbers adjust.
The debugger allows notifications to be sent to the Nextion (if connected using the USB-TTL) and I haven’t played with this yet.
Hope this was helpful.