Start a new topic
Not Taken

GPIO simulation in Nextion Editor

Dear ITEAD team!


Wouldn't it be great if the Nextion Editor could simulate GPIOs?


I need to simulate pressing hardware buttons over Nextions GPIOs.


Please, could you think about that?


Thank you!


2 people like this idea

in general, everything is possible. But finally somebody also must pay for such a development ...

so, let's wait and see how many users will vote for this idea ... when there are at least 500 I have a good base to talk to dev-team about ... below, hardly ...

Anyway, when you declare your GPIO's as "Input binding mode", what's more easy to use a temporary button to set the bind variable ... for simulate your I/O?



2 people like this

500 votes required for this feature, really ?


I was very surprised to not see this feature missing when I first ran the editor.

easy speaking, the more the better ...

anyway, the Editor contains a Debugger, not a Simulator ...

 

It's called a simulator in the editor: "Reboot the Simulator", "Send command to: Current Simulator", "Simulator Return Data", etc. Subtle naming differences aside, I think there's an important distinction: Being able to iterate through the development of a design entirely on the computer would massively speed up the development, considering that the use of a real device requires either a relatively slow serial upload or writing to an SD card, swapping it into the display and then switching it on.


It's an important features where you might be using GPIO to switch page, where the design does not include any page buttons on the screen itself. You could type the commands to change page yourself, but that's not a particularly nice development experience. You already have support for serial input from an external MCU so this would wrap things up nicely.

Hey Andrew


  Indeed the wording does say simulator once in the Debugger

  (Debug button needs to be pressed to enter)


Now an external hardware button is usually controlled by input binding

and for this there is a click command that can indeed trigger

see Nextion Instruction Set .. section 2.3


Can you also read your button using pio? Well, indeed

 - such is less possible to simulate an actual mechanical bounce

   of a real hardware button - what physical button is really used?

 - for each type, and age, and variations of wear

   shall there be a new button to declare for the simulation?


So as EEPROM is not simulated for the same reason

   what was the users saved content and how much wear?

EEPROM becomes something not really to be simulated


Much is the same of the GPIO.

 - today you may talk about an input binding for a button

   (use a hotspot that calls click event of bound component)

 - but then there is much more advanced things for GPIO

   and much can be placed on GPIO even though it is

   limited to digital input.


Output can also be PWM, Or Open-Drain, or push-pull

Indeed so many things can be connected although not Analog.

 - How do they all realistically get simulated.


But such is interpreted and not super high precision timing.

- too many variables play into it (such "simulations")


As such even a timer will not simulate accurately in Windows

 which is interrupted by many background processes

that it indeed does not remain a true simulator


But indeed ... a debugger.

Head-to-Head Battleships?

 or Serial over GPIO (mp4 attached)

... just too much to "simulate" in the debugger.


image

mp4

After re-reading the documentation, it appears that GPIO can only really be used to change page if it is bound to a button - Is this correct ? I suppose that the button could be hidden if it was just there to handle the GPIO event, but it would be nice if there an event component like the variable component. (From memory, the variable component doesn't have events - Is that right ? I haven't got the editor installed on this work PC.)


I think that considering things such as EEPROM wear and GPIO debounce is overcomplicating what is actually required in order to make this useful. The debugger / simulator / preview is only likely to be used when developing a new product / project or adding a new feature. I don't think it would typically be used to perform extensive testing or to debug product issues. As such, I think that EEPROM wear can be ignored altogether.


In the same way, button bounce (And wear) can also be ignored as it is easily resolved in hardware with an RC filter.


Things like PWM (And digital outputs) can be relatively easily handled by changing the GPIO simulator UI based on the current GPIO configuration - If a GPIO pin is configured for PWM then display a duty cycle progress bar and frequency count, if it's configured as an output then just show the state, if it's configured for input binding show a button.


Although the word simulation has been used, it doesn't have to be a true simulation to be useful for most situations - Just a general development aid is more than enough as long as all of the features can be exercised.


Your Serial over GPIO is interesting and definitely shows limitations of the proposal, although I'd argue that particular usage is an edge case. I'd also wonder if it is better to use the real serial port and send commands (Set a variable with a byte of data, then set another variable to trigger an event to handle that byte) rather than implementing software serial over the GPIO port - I'd expect the hardware serial implementation to be quicker even with the additional command overhead.

In each use of GPIO presented and then debated

the closest answers for how to solve for simulation is always only a partial.

 - in each and every GPIO use case,

    you only watered down the capabilities so maybe it might fit.

    the use always returned to the more simplest of cases

    and complexity is rapid, only needing simple combinations

But the ultimate of watering down is to send over to the Nextion device

    where accuracy is realized on the actual device.


In Serial over GPIO

It would be senseless to send data out the real UART port ...

the whole point of Serial over GPIO is Nextion Logic standalone

 ... and as such, there is no MCU to catch from the real UART ??


I would argue Serial over GPIO is not such an "edge case"

One only needs an active imagination and all is suddenly an "edge case"

And I think that is the point.


Why only some simple cases and not the actual "in use cases"?

In this I mean Serial over GPIO is actual, it has really been built.

The intended purpose of what you propose has not been built.


I would argue, that even if you had simulation (partial simulation)

 - as soon as build your project, you realize the simulations limits

 - with its simulation limits reached, you are filing a Bug Report.

 - and you are filing yet another Feature Request


I am less certain this Pandora's box is one that should be opened.

The main target is industrial

So, until it could actually simulate Nextion and real world conditions

   including the unlimited items that can attach to it (built or imagined)

   a half-baked simulation GPIO is perhaps more harmful than none.


So we are back to sending project to the device for accuracy


image


As for your assumptions after re-reading

   you need more imagination

   Buttons are not the only component that can be bound

   there is not one button used in Serial over GPIO or Player Piano

   triggered sets of commands are not limited to the page command

   GPIO bindings are local, as events are not global.

   Hiding is the wrong logic - also hides events

   PWM duty cycle is fixed - it is frequency that can change


Variables do not have events - this is correct.

No need for an Event Component, almost all are already Events

In regards to Serial over GPIO, if we're talking about sending data directly between Nextion devices as you have shown - Wouldn't it be easier if there was a send command which simply sent a Nextion command out of the hardware serial port in a similar way to the sendme command ? That would be a lot simpler to implement, use less resources on the Nextion and should work fine for your example project without a microcontroller.


The reason why I would argue that buttons over GPIO are a more-intended use case is that you sell a button board. I don't think it's unreasonable to expect the functionality on that to be matched in the simulator, given that you offer that hardware - and certainly wouldn't call it imagined.


Can you give an example of how GPIO binding can be used to directly trigger some code (E.g. to change page) without the use of a button or hotspot ? The documentation only mentions about binding to buttons and the press / release events in particular.


Also the documentation suggests that the PWM duty cycle may be adjusted using pwm4 to pwm7:

https://www.itead.cc/wiki/Nextion_Instruction_Set#cfgpio:_configure_GPIO_-_Enhanced_Model_Only

maybe FreeChat is the better place for discussing ...

this is still FeatureRequest ....

GPIO examples are already given in full blown tutorials already posted in Free Chat

Documentation gives all state combinations, a few examples provided

But if the example of t0.txt="Wednesday" is used

  - does this now also limit t0's use to merely displaying weekdays?


Argument of you can buy Expansion Board?

 - Expansion Board also has header out for ... ?  Anything!

 - Also sold is the bare Adapter to accommodate?  Anything!

What is Anything?  Completely up to users imagination.

So, I think the word accurately reflects the use case imagined


GPIO over serial - command to send 

  - yeah, that was pretty much what I built in user code

  - I hardly doubt such command is common place

And why should such bloated command clog firmware of users who have no need for it?


Command to send out over serial - indeed. It already exists

But then ask yourself Serial over Serial,

   um yeah - how popular - where is there any accomplishment?


Use less resources on the Nextion? compared to what?  and why?

Resources for GPIO over Serial hardly dented Nextions capacity

And what addtional value is an empty unused resource?


Re-read the Nextion Instruction Set

  duty cycle can indeed be adjusted, but not after cfgpio sets the pin to PWM.

  So while pin is configured to PWM, only pwmf frequency can change.


But again, it is a debugger and not a simulator.

  a few more days of playing around will

    - show why it is a debugger and not simulator.

Simulator requires accuracy to what hardware will produce.

As for the Feature Request of GPIO simulation in Nextion Editor.

- request has been noted

- will be represented as having been requested

- need to have a real simulator before GPIO can be added


Chance of this being successfully implemented

 - in honesty, very low at this point

 - other requests currently have much higher priority

- need to have a real simulator before GPIO can be added


But stay tuned, who knows, it might happen

 - we will be the first to tell of if it does happen

Until then, the "No Vapourware Policy" is in effect.

And don't forget to up-vote favourite feature requests.

Without such, ahhh ... other features will have more priority.


I think I've made as much of a point for the GPIO simulation as I can, but I want to follow up on some of the documentation points as I think there's a few holes here - I know this is going off topic but it makes sense here in the context of the rest of the conversation here so I'll try and be brief.



GPIO examples are already given in full blown tutorials already posted in Free Chat

Documentation gives all state combinations, a few examples provided

But if the example of t0.txt="Wednesday" is used

  - does this now also limit t0's use to merely displaying weekdays?

I don't believe it's right to expect customers to go trawling through a free chat forum in order to answer specific API questions - The Nextion Instruction Set page gives very little information on GPIO input binding. The only information it gives is:

cfgpio 2, 1, b0   //Configure GPIO2 as input binding mode, the binding component is button b0. 
                  //Falling edge of GPIO2 will trigger b0's button press event, rising edge of 
                  //GPIO2 will trigger bo's button release event.

When configure a GPIO to input binding mode, only components in current page can be bind. It is recommended to put the instruction in the preinitialize event, because binding event wont not be triggered after page refreshing or switching.

The implication here is that you can bind to components which have a press and release event. There are no suggestions that you could set a variable or execute another instruction without a visible component. I'm of course not calling for an exhaustive list of statements you can write, but I would expect an exhaustive list of behaviours that can be performed within the main documentation.



GPIO over serial - command to send 

  - yeah, that was pretty much what I built in user code

  - I hardly doubt such command is common place

And why should such bloated command clog firmware of users who have no need for it?


Command to send out over serial - indeed. It already exists

So from trial, it appears that the print command does this. The documentation however, does not directly suggest that this sends out over the serial port:

print: Get variable variable/constant value without format

 

Use less resources on the Nextion? compared to what?  and why?

Resources for GPIO over Serial hardly dented Nextions capacity

And what addtional value is an empty unused resource?

This comment is in reference to the limitation specified in your own PoC, where you state that the speed is 5.4 characters per second. I don't have enough hardware to test this myself, but using hardware serial to directly send commands should be much faster which is what lead me to question the purpose of Serial over GPIO.



Re-read the Nextion Instruction Set

  duty cycle can indeed be adjusted, but not after cfgpio sets the pin to PWM.

  So while pin is configured to PWM, only pwmf frequency can change.

Again the documentation on this is not clear, the text suggests that a PWM duty cycle must be specified before PWM is enabled, but does not mention that this cannot be adjusted while in PWM mode.

cfgpio 4, 3, 0   //Configure GPIO4 as PWM output mode, you should use system variable pwm4 
                 //to set duty cycle before you use the instruction



In summary, there are a number of assumptions of knowledge within the documentation and examples in the forum are no substitute for detailed documentation - Especially when there are 98 pages to go through.

Login or Signup to post a comment