Yup, that's a bit tricky
The one thing I'm using above has only the display talk to the MP3 module and no Photon in there at all.
But the scenario where I have three devices is not completely finished, but I'm building a "serial ring" Photon TX -> RX Nextion TX -> RX MP3 module TX -> RX Photon.
This requires to set the display to not respond to commands and just rely on the execution and not to query info from the display direct.
Nextion events will not work - or only a very limited workaround (only one event that triggers a MP3 error response).
It is a real pain that there is no easy Serial2 on the Photon - but I also have some Cores, if need be
@ScruffR - āSerial Ringā - Has a ring to it!! Clever idea.
Have you managed to get any graphics primitives working on the nextion display - e.g. draw a line. The pre-compiled display with button responses and moving from page to page is fine - I thought one could send draw primitives commands as well but I canāt see where the functions are defined.
These are not exposed in the original library and are only drawing commands and no graphical objects (unfortunately).
To have graphical objects that can be manipulated after creation ITEAD would have to supply them as components.
@ScruffR: I ordered both a Nextion and Digole touchscreen display, to see which one is best for my room controllers. Looking forward to checking your lib(s) outā¦
Thanks @peekay123 also for the tips!
Thanks I will take a look at these tomorrow - very interested to see how and what you have managed. Did you cover button touch and āun-touchā events i.e. to give the appearance that the virtual button has moved down and then back up?
The appearance change of buttons is usually set up in the Nextion Editor and does not require any action of the MCU.
But the logic for the MCU to respond to the press/release (push/pop in ITEAD jargon) events is already part of the original ITEAD lib which I just ported and extended (or am in the middle of).
How to do that can be seen in the samples provided with the lib.
But if you want to discuss some more about the Nextion lib, I could split this thread and create a new topic for this.
WOW! I looked through the ādocumentationā in your Particulized libs @ScruffR , and I am lostā¦
These are not the most user-friendly displays I found yetā¦
But Iām sure with your example for the MP3 module Iād like to give it a try!
Unfortunately - and I'm sorry, I didn't find the time to comment the lib either
But since I backed their Kickstarter (or was it Indogogo? can't remember) I got some of these displays and I try to make most of them.
I'm still in the phase of giving them the credit of "new product", but these are quirky and the Editor needs a lot of "getting used to" and turning some blind eyes.
But with some onconventional thinking I did get those things to do things that ITEAD didn't intend them to do - I think
I haven't got my hands on Digole or 4D displays yet, so I can't compare.
If you have any particlular questions about the lib, just shoot away.
BTW: What size display have you ordered, so I could send you my MP3 player firmware (HMI & TFT files) tailor made for your display.
At the moment it's only starting and stopping the folder loop, but I'm planning to support the most common player controls, so if you have any special needs, it's still work in progress, so additions will mean no extra effort
As Iām working with OS-X machines, I tried to start up the editor on VM Ware Fusion, where I can only run Windows XP, and thatās what I got:
Right now I canāt make more time for this, but Iāll accept your generous ātaylor-made softwareā offer, so that I can try it out when the display is available.
@ScruffR - Maybe the change of button state was one of those things I missed in the Nextion editor. That was what I meant.
I have had a look at your firmware library on github. I tried out with the original Wu Pengfei pengfei.wu@itead.cc dated 2015/8/12 ITEADLIB_Arduino_Nextion-0.7.0 library last September/October when there were no graphics primitives functions. Thank you for adding NexGraphing!
I am right that you appear to have modelled the functions on the mfGFX library calls (thank you if you have) as it makes porting my software easier?
One further question - when I looked under the covers of the mfGFX library for filling rectangles and drawing triangles it appear to me to be terribly inefficient. I had the joy some 30 years ago of writing a graphics card API for a research project at university - then on a top end Matrox graphics card primitive functions (triangle fill) were done in hardware. Do you how is this done with the Nextion displays - I looked into the NexGraphing.cpp file and it appears you make a series of command API calls.
I have tried to stick close where possible, but some functions (e.g. text rendering) are handled rather different due to the provided functions.
But since this is work in progress, I might find ways to draw closer.
For the Nextion, there seems to be no better way yet, since the firmware of these displays is still closed source and you'd need to go bare metal for more efficient ways.
I have filed a feature request with ITEAD to allow for asm/C code to be uploaded to the display in order to create fast user function which could be called via the serial API, but have not had any reply (ITEAD obviously is nowhere near as agile and open as Particle).
As for mfGFX (and Adafruit_GFX too), these provide a basis that should run on most devices with not too much hardware dependency, but also provide a good base class to build faster, more hardware focused libraries by overloading the respective methods (but for this @peekay123 is the guy to chime in).
Which one exactly?
There was one in connection with the Particle cloud where non-cloud modes didn't work because I didn't wait long enough - this one is solved.
But there is another one that I've addressed on the ITEAD forum which is mainly due to the firmware, but in my develop branch I'm trying to work around this.
It's mainly an issue between the async feedback events of the display and the user commands corrupting/flushing the feedback data.
@armor, there is a huge difference between hardware acceleration and display processor-assisted acceleration. Many low cost displays available on the market are ādumbā in that they provide very few hardware-based primitives with which to build a graphics library. Most only support pixel-only primitives.
The Nextion uses both a firmware-based (STM32 processor) command interpreter coupled with a hardware graphics (FPGA possibly) co-processor for driving the LCD. The co-processor may provide pixel, line and other primitives.
The Digole units use a PIC processor running at 64MHz to drive an LCD using only firmware (no hardware acceleration). The library extensions I wrote for the added primitives makes use of the available firmware-based primitives on the PIC since these are the only commands available to a user app. Since these extensions must send their commands to the unit via serial/I2C/SPI, their performance is substantially impacted (versus built-in).
The GFX/mfGFX libraries were written for generic ādumbā displays and are designed to be adaptable to different devices. I have used mfGFX with a SharpMemory display where only the (lowest level graphic primitive) pixel draw function was modified to suit the display.
If you want speed, you will need to find a display unit that combines both firmware and hardware accelerated graphics. Here are some examples:
Clever idea.
