Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 8 of 8

Thread: 2019 Teensy 3.6 lcd/touch screen larger than ili9341

  1. #1
    Senior Member
    Join Date
    Jan 2014
    Posts
    152

    2019 Teensy 3.6 lcd/touch screen larger than ili9341

    I have used the ili9341 in numerous projects. It was great for the Teensy 3.2,
    but the Teensy 3.6 and upcoming 4 are have so much more potential.

    Given its January 2019 (there are lots of older threads)...

    Is there any functional code for a larger display/touchscreen than the ili9341 ?

    thanks,

    Richard

  2. #2
    Member
    Join Date
    Nov 2015
    Location
    Cold hollow VT
    Posts
    97
    How much larger?

    Look at Buydisplay.com for other size displays. Some larger ones may still be compatible with ILI9341 drivers. Their 8" unit using RA8875 is compatible with a driver written by a fellow here named 'SumoToy'. Beware of some SPI bus quirkyness though that is mentioned in other threads here.

  3. #3
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    2,952
    Unfortunately sumotoy hasn't posted here since June 2017.

    The gamedunio3 has support for Teensy 3.2, Arduino, and ESP8266. There are two versions. I have the smaller version that I got during the kickstarter campaign, but I haven't done much with it other than do the examples when I got it. The display memory is in the unit, so you send it commands to render the screen and handle touch input. It has a SD card on the display and can handle video and sound. The small version at least uses an Arduino shield footprint.


  4. #4
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,385
    Depending on the project details, using a Nextion HMI display might make sense. These exist in different sizes from 2.4 to 7 inch and have touch functionality. They have an integrated cortex M0 processor and a free editor allows designing, compiling and uploading screens, fonts and images. Different components like text box, gauges, progress bars, waveform display objects and much more might be used. Simple event handling can be done directly in the display with an easy to learn macro language. The advantage is that the Teensy does not longer have to draw the screens and to handle the graphics stuff, but it will only receive touch events from and send text, values, and commands to the Nextion, which saves tons of memory and cpu cycles.

  5. #5
    Senior Member
    Join Date
    Jan 2014
    Posts
    152
    Thanks,

    Like so many of us, I enjoy the quest; however, sometimes I just want to get something working.
    I ordered the Gameduino3 and the Nextion.
    Both seem like great solutions. I will update post on my findings.

    thanks for the tips,

    Richard

  6. #6
    Senior Member
    Join Date
    Mar 2013
    Posts
    651
    The down side to the Nextion is the atrocious serial speed (max per datasheet is 115000bps).

  7. #7
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,385
    Quote Originally Posted by Donziboy2 View Post
    The down side to the Nextion is the atrocious serial speed (max per datasheet is 115000bps).
    That seems to be a handbrake at a first glance, yes. But since no graphics, fonts and other heavy payload (it's all already precompiled in the display) has to go over that connection, just the raw data to display and a few 3-letter macro commands, that is not an issue. Updating for example a progress bar will just need to send "pb0.val=50" and (if you aren't using advanced protocol reparsing techniques) three 0xFF bytes as a terminator. The addressed screen element will refresh automatically afterwards. So, you transmit 13 bytes (roughly 1.128ms) only instead of several hundreds to do a full or partial screen redraw from a frame buffer. Especially at higher screen resolutions (available up to 800x480) where a full screen redraw in 16bit color mode would require sending 800x480x2 = 768000 bytes, this makes sense, and on top of that, eats much less Teensy resources.

  8. #8
    Senior Member
    Join Date
    Jan 2014
    Posts
    152
    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, (y) << 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •