Teensy 3.2 and Nextion Display

[PaulStoffregen]

b) Fonts - i'd like to use Pauls TTF font-technique. I remember he used a tool to convert them. Hm..i forgot the details after i wrote a short script that converted all the 100s of google fonts month ago... Perhaps there was a linux-tool...

The font conversion code is here:

https://github.com/PaulStoffregen/ILI9341_t3/tree/master/extras

The bdf_to_ili9341 C program converts a single BFD. The Perl script runs otf2bdf and bdf_to_ili9341 many times on a TFT, to convert it to the different bitmap sizes.

I'm pretty sure you wrote another script that runs tft_to_ili9341.pl on many TFT files, but I don't have that code.

 

[fms1961]

Most of the primitives are already in the ILI lib. We can use them.

And how may we adapt greater displays, because I would prefer to use a 4.3" touch panel instead of a 2.2" one ... it's too tiny ...

 

[Theremingenieur]

Have a look at the Nextion editor: it allows to choose the screen type and size.

 

[defragster]

After reading I saw this 3.2" TFT 480x240 resistive - $25 shipped from ebay.

Is that the one under discussion for a new brain?

 

[Theremingenieur]

That's exactly the one I was talking about.

 

[fms1961]

Have a look at the Nextion editor: it allows to choose the screen type and size.

That's not the point. If the editor generates code with calls of the ILI9341 library, they won't work on any other display, I presume. So my question is: how may we adapt other displays beside the ILI9341 compatibles. This has to be cleared in advance, if not, we may turn into a dead end - this is not appreciated.

 

[defragster]

fms1961: This page shows the data sheets for the various size/models if you wanted to be sure if the same interface/SPI pinout?

The 3.2" (not 2.2") is the only one with that 400x240 resolution - though hopefully that is just a res and not controller change.

<edit>: I linked the 3.2 above then mixed the res of the 3.5", opps.
Indeed as noted in that table the other sizes have larger and smaller native resolutions.

 

[Theremingenieur]

A quick google search for a data sheet seems to indicate that the ILI9341 is limited to 320x240. I wonder if the new editor should not be abstract enough to work with different display driver libraries...

@defragster: the 3.2" is 400x240. There are plenty of different resolutions!

 

[fms1961]

A quick google search for a data sheet seems to indicate that the ILI9341 is limited to 320x240. I wonder if the new editor should not be abstract enough to work with different display driver libraries...

Now you're speaking ... so I will plan another tier/layer/mapping, so on the editors side there are our own primitives, and when it comes to code genration, we select which library to use and then the "abstract" (not really ...) primitives will be mapped to existing library calls.

 

[Theremingenieur]

I guess that's exactly what the Nextion system does : The editor generates abstract macro code which is then stored in the flash and it's up to the firmware to do the rendering as a function of the used GPU and resolution.

 

[fms1961]

I guess that's exactly what the Nextion system does : The editor generates abstract macro code which is then stored in the flash and it's up to the firmware to do the rendering as a function of the used GPU and resolution.

I would like to put all non-specific parts on the editors side, and only the hardware specific code will be uploaded to the teensy controller.

 

[PaulStoffregen]

If the editor generates code with calls of the ILI9341 library, they won't work on any other display, I presume. So my question is: how may we adapt other displays beside the ILI9341 compatibles.

So far, ILI9341_t3 still closely follows Adafruit's GFX library API. If code is build using the GFX functions, porting to other displays should be fairly straightforward.

Whether to keep closely following Adafruit's API, or allow lots of new functions and features, is something I've had on my mind. I'm not really decided on this, and really looking for some feedback. At least one awesome-looking pull request is pending now for gradients, and more are likely (and I might do several, after 2 product releases and getting caught up on tons of little stuff). The tough thing about APIs is how easy they are to grow and how hard they are to rein back in, how easily satisfying short-term desires can create long-term issues.

 

[Theremingenieur]

Why not make the editor like platform independent software (à la java) and let the teensy controller load the "true" display lib and do the rendering? Thus, support for new display models wouldn't affect the editor, just the f/w of the teensy controller, depending on the attached display type.

 

[fms1961]

Yes, but this will be done by the editor, so you don't have to play around and look which library the Teensy needs ... it's all handled by the editor.

 

[Theremingenieur]

Great idea, if it works!

 

[fms1961]

-> let's jump to the dedicated thread!

 

[Frank B]

I'm pretty sure you wrote another script that runs tft_to_ili9341.pl on many TFT files, but I don't have that code.

Yes, i remember now. It wasn't more than 3..4 lines.
Unfortunately i deleted it together with the whole ubuntu - virtual machine when i set up a new one a couple of weeks ago

No problem..that few lines could'nt have been magical..
When we need it again i can make a new script.

 

[SoftEgg]

So far, ILI9341_t3 still closely follows Adafruit's GFX library API. If code is build using the GFX functions, porting to other displays should be fairly straightforward.

It looks like Adafruit has the GFX and TFT libraries as separate modules. The TFTLCD class inherits from GFX class, so the result is the same, but I suppose there is better abstraction that way?

Is there any plan to split the libraries as Adafruit has done?

Whether to keep closely following Adafruit's API, or allow lots of new functions and features, is something I've had on my mind. I'm not really decided on this, and really looking for some feedback.

I'll be happy to port my changes back to Adafruit's libraries if they want them. I suppose it would be easier if the libraries matched more closely in structure, tho.

At least one awesome-looking pull request is pending now for gradients, and more are likely (and I might do several, after 2 product releases and getting caught up on tons of little stuff). The tough thing about APIs is how easy they are to grow and how hard they are to rein back in, how easily satisfying short-term desires can create long-term issues.

Oh, hey, that's my change! Thanks!

I suppose one could also make an "Extended Graphics" class that inherits from the TFT class with the new stuff in it. Then it would be up to other folks to fork that to port back to Arduino or whatever...

 

[Raymond_B]

Just an update, there's a new version of the Nextion editor available. Haven't really messed with it yet, but I do not see anything groundbreaking.

 

[Donziboy2]

I think some in this thread(yes its a few months old) are looking at the Nextion all wrong. Its not the kind of display that you send commands to. Its the kind of display that should be capable of doing most of the clearing and drawing on its own if setup correctly. Im looking at it and thinking it may work perfectly well in my CC Dummy Load Project. Why you ask? Because I need something I can fire and forget data to. Based on what I have seen I can just stuff data into the Hardware UART on the Teensy and feed a stream of sensor data and maybe a few commands here and there to say change menu's(use the extra IO's for flow control?).

For those who have worked with the Nextions. Is what im saying correct or am I misinterpreting the Nextion?

 

[sumotoy]

Just an update, there's a new version of the Nextion editor available. Haven't really messed with it yet, but I do not see anything groundbreaking.

I hate to say but, the editor it still indigestive (and I forced myself to use a polite word). The biggest change is the ability to react at negative numbers (!).

 

[Constantin]

I recently bought it to work as a GUI for a Energy Recovery Ventilator (ERV) rebuild. Yanked the PSC motors (to be replaced by BPMs) and the crummy control system. Built a teensy based PCB to run the ERV (lots of DAQ) and liked the simplicity of the Nextion. Main reason I bought it however, is that the makers of the Nextion 'get' the need for a display case, i.e. The ability to mount the thing in an enclosure or bezel.

I still scratch my head at the multitude of display vendors who simply push out a display without any options to mount it securely. Nuts. Nextion freely distributed STL's for that purpose that you can then send to any 3D printing house. So I'm willing to suffer some in return for the convenience of the hardware having a relatively presentable solution.

That said,I would totally prefer a Teensy based solution. But consider spending the extra time to create STLs and similar mounting options so the tindie customers (or whoever) can also mount the thing on a wall without embarassment.

 

[Frank B]

I think some in this thread(yes its a few months old) are looking at the Nextion all wrong. Its not the kind of display that you send commands to. Its the kind of display that should be capable of doing most of the clearing and drawing on its own if setup correctly.

Yes if (simple!) gui is enough for you. More dynamic contents with fast updates are not possible. The only remaining plus is the memory and the existing "editor" (which is crap)..

 

[Donziboy2]

They seem to be making improvements so maybe if we annoy them enough they will at-least give us more speed. Based on the specs they should be able to handle a higher baud rate.

Just watched a nice video using a 7" screen I think this may just be what my CC Dummy Load needs.

edit...
Or would it be cheaper to use an East Rising RA8875 and Teensy 3.2 or ++?

 

[Phitar]

Youngsters! Never developed in dBase/Clipper ?

I did. Loved it!