How about add option to reconnect user MCU Input on new Debug session? For now i must set port and baud manually all the time.
Most debugging is done more quickly within the debug simulator
catching the error here before sending to the TFT is much better than
uploading TFT and check for error there, otherwise debug has no purpose.
Perhaps this request could be considered to retain last settings and use last settings
if and only if system communication ports only enumerate to a one single com port
if and only if the user signs a waiver to only own one Nextion device.
Such an Auto setting is not easily applied with multiple devices or multiple ports.
- it would certainly interfere when dealing with device swaps or dual/triple configs.
- confining the user to a single configuration is not so wise
- perhaps they plug them in in a wrong order.
Most easy solution for user flexibility is the user choses com and baudrate per device.
Thinking about how my own workflow proceeds
In a given project, I may launch the Debug simulator 25 times
Of these 25 times, perhaps 3 are connected to the Nextion (MCU)
In a more complex project, perhaps 50 times Debug is launched
And yet still connecting to the Nextion (MCU) is only around 3 or 4.
There are few factors I can think of that apply to the reasoning
1) is I use microSD to upload my TFT which is way more speedy
on a 12 MB TFT than waiting for a serial connection upload.
2) microSD also does not stop mid upload, and have to start again
3) Perhaps my trust that the Nextion will do what I asked does not
require me to connect and test Nextion current values as often
- this trust comes with time and experience
4) When testing values or routines while building the HMI, I employ
techniques that includes a visual display of my value, and button or
hotspots to trigger expected conditions that I can simply remove
later before I release the TFT
Pondering your wording of reconnect user MCU
- the purpose of the Nextion Debug Simulator is to connect with the Nextion
If you are connecting your Arduino or PIC (an MCU) to this you are using
it in a manner beyond what I believe it was designed for.
Testing MCU programming is done via compiler tools, not Nextion Editor
Testing Nextion device is done via Nextion Editor
The screen wording of MCU in debug was referring to the STM/GD on board Nextion
Iam not have a physical device of nextion, just arduino and usb serial-to-ttl adapter which i use to simulate and test my project before i buy real nextion display.
I think "reconnect to last used MCU" button isn't that hard? :)
Then without the experience of a single nextion device,
or knowing the complexities of handling multiple nextion devices
you make recommendations of what should maybe be fixed.
I am glad that you have been able to find an extended use of Debug
- but as stated its purpose is to communicate with Nextion device
I would have to take the standpoint that the company has to make considerations to not impact those that have paid for a Nextion device and even greatly more considerations to not impact those that have for many Nextion devices. Even if such a button maybe would make life easy for the one or no Nextion user, it does not seem to be a good strategy to make it more tough for those that have paid for many devices as these many device Nextion users are very important financially to keep the company going. No?
So making the job of the 50 device Nextion user or the 1000 device Nextion more difficult, they should continue to make a many purchase? All to the benefit a misuse of Debug and not its designed and intended purpose?
Facts, when dealing with Multiple Nextions, the com port being tested is dependent on which Nextion device is to be currently tested, this generally will not be the last device - it was just tested. Dependent on the project the Nextion device will need to operate at differing baud rates. A Nextion device connecting to an ESP or STM MCU or computer system can certainly take advantage of 115200 baud. A Nextion device connecting to a PIC12F MCU will most likely need to use a much lower baudrate perhaps 9600. A PIC limited to 31250 may require to select a common denominator between its connected devices and its Nextion and because of these limiting factors may need to communicate to the Nextion at 19200. There are 7 such Nextion supported baud rates, and the requirements of the project may require varied rates at different segments of the project. For this purpose flexibility is required to select com and baud.
Such an auto connect not only increase the added steps to disconnect so they can reselect, but would also generate unnecessary signals - most likely unwanted signals, but potentially harmful signals at an unwanted uncontrolled time.
I do support many requests, and personally make my recommendations to the dev team, But again, I am failing to see why I would want to make a recommendation to support a feature that would cause more grief to the user segment that is rather kind of so important to the health of the company.
I mean this. This settings is always same for me, and if i only close this window, and open again, both port/baud must set again. It's only this. Maybe you can add near "start" button new button "use previous settings to connect", or just set this select option to last use and not defaut (in my case it's always com1 and 9600)
This one I can see if they will add a setting pair perhaps in the layout_temp.ini settings.
It should not be allowed to auto connect, but perhaps it may prepopulate.
I will put this modified request through, they will have the final decision.
And I bought today one display for more tests, this time real.
Plus one for remembering this setting, especially the Com Port and Baud rate (but I think a case can also be made for remembering which of "keyboard" or "user MCU" was selected.
Yes, I am requesting that a pair be added into the layout ini files for this
- but it will not trigger the actual connect, just prepopulate
Right, thank you.
MCU COMM port and baud rate remembered in V0.43.
Yay and thank you.
I checked, and the pair wasn't added into the .ini
I think in compromise it will persist throughout the session
but reset after the session ends and Editor loaded again.
It remembered my settings when I restarted after closing the Editor. All good.