They always make things sooo complicated - why?
Anyway, here should be the installer
They always make things sooo complicated - why?
Anyway, here should be the installer
Fantastic, it works! Thanks for your help in this maze…
@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 firstname.lastname@example.org 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.
Lastly, the ‘timing issue’ is that solved?
I will start using the Web IDE library.
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:
4D Systems also have excellent displays though they are quite pricey.
Thanks for the answers. I was just curious about the speed given commands are going via a serial interface which is slower than SPI.
Do you think it is stable enough to develop upon? I dismissed it back in October 15 as too new and have gone down a route with LCD display and plug-in keyboard when input required (initial WIFI setup onsite).
@peekay123 - more processing power on the display would allow/support fancier segue between screens - I just dim the LED and redraw the screen then re lite the LED. Cost is the real issue - I am using 1.8" and 2.2" TFT SPI displays ST7735 and ILI9341 which I can source for US$4-5 each, really looking at the Nextion for touchscreen with low GPIO use and at a reasonable price. The SPI based small touch displays all seem to be expensive - $27 for a touchscreen display to SPI controller plus the display.
If you want to draw rather than use the HMI components on the devices you’d definetly need to go with a high baudrate (115200 is supported).
If you want some feel for the speed I could shoot you a video of some drawing action.
Another option for some speed might be the onboard scripting which cuts away the transfer time but only works for simple drawing tasks (loops have to be emulated with timers or unrolled, only simple if conditions, …)
About stability, it depends on your expectations, but I never had any issues for what I used them.
Thanks - I will check the library and see how it works with different baud rates.
if you want to try my photon-less MP3 player for 2.4" Nextion display, you can download this zip and give it a try.
Since there is no MCU involved, you might see some occasional timing issues and the play button doesn’t pop out once a file is played, but this might be a building block.
To play a specific song from the MP3 folder tap the SongNr input box (second top left) and type in the number and hit play.
If you want to try a folder loop (as discussed in the other thread) tap the FolderNr input box (first top left) and hit the loop button.
On the far right you have a volume control.
Update: With the new Enhanced Nextion displays you can use the BUSY pin of the DFplayer module to provide “feedback” about the playing state to the display.
Wow, that’s fantastic @ScruffR!
I downloaded your zip allright, but my nextion may still be a few weeks from here…
Meanwhile can you give us a short instruction what to do with the different files?
And how to wire the module to the Nextion? (Photo?)
.HMI file is the “source” file for Nextion Editor.
If you open it with NE you can see how I’ve done the communication by clicking one any component and look at the “Touch release event”. And this way you can also alter the appearance of the controls by replacing the two
.PNG files in the editor.
.TFT file is the “compiled” output of NE which you’d only put on an SD card (root directory), pop that into the displays SD slot, power the display up and wait till the display reports “Update successed!” (yup, that’s what it says ).
Then you take the SD out again and repower the display.
The wiring is easy.
The pins on the display are well marked (+5V red, TX blue, RX yellow, GND black).
Just connect TX/RX to RX/TX on the MP3 module, +5V to the Vcc pin and a 5V supply, GND goes to one of the GND pins of the module and the supply again and that’s it.
Thanks @ScruffR, that’s a short & sweet explanation.
Everything is ready to try it out when the postman rings…
The postman rung twice today:
He finally brought my 2.4" 320X240 Nextion USART HMI TFT LCD Resistive Touch Screen (Model: NX3224T024)
If your files above are applicable to this model, I will try out your combination with the DFPlayer MP3 module this weekend…
Just want to confirm the connections you used:
DFPlayer Nextion display -------- --------------- Rx Tx Tx Rx +5V +5V Gnd Gnd
Yup, the only thing missing in the wiring table is that you also need to connect the supply.
Obvious, but just for completeness
DFPlayer Nextion display Supply -------- --------------- ------ Rx Tx (Tx) (Rx) // not really used +5V +5V +5V Gnd Gnd GND
These files should work since I’ve done them for my display of the same type.
I found some time this morning and eager to try out your combination, I followed above instructions and that’s what I got:
I tried with several micro-SD cards:
First card (4Gb) contains a folder “Garmin”, which I left in, because I need it later. Then I got this message.
Second (32Gb, overkill?) was still new, empty. I copied only your “MP3.tft” file onto it. Same result…
(PS: I do this on OS-X, which may create ‘hidden files’ in a volume/folder…)
YES! All works fantastically! Good job @ScruffR !!!
The problem was indeed the hidden files on the card…
I removed them in VM Ware and tried again: “Update successed!”
Update: Here’s a photo of the music machine:
The Photon is just there for good company and to enjoy good music…
Good to hear that it works for you too.
It’s still a bit fragile in places (e.g. sometimes a play command is not immediately accepted), maybe removing the unused connection MP3 -> display and/or playing with delays in the display macros could help with possible timing issues.
But this is mainly a proof of concept anyway
Having the Photon in there with only one () serial port available will be the next challenge.
It works without the module’s blue wire (Tx) indeed, but I don’t see any change in behaviour…
As a proof of concept it’s of course a success!
If the display could be permanently connected to the Photon, we could also use it for other touchscreen functions.
That would be great!
For my projects it would be sufficient if I can use the touchscreen with the Photon for common control tasks, and then perhaps let it switch the display to the MP3 page to loop one of the selected folders in the background. One extra button on the screen could give control back to the Photon…
Sounds easy, isn’t it?
But I have no idea how to do this…
Thanks anyway for this nice JukeBox!
What are the most problematic points with the current state of the project for you?
That very much depends on the intended interaction between Photon and display for your common control tasks
For a full fledged GUI you’d need bi-directional communication between the, but you only have one interface (well, a second you could free up with an soldering iron ;-))