it looks like the repo/wepo commands are not fully implemented in the debugger - or do I miss something here?
If I do a "wepo n1.val,4", I would expect a "repo n1.val,4" would restore n1.val to whatever I had written to offset 4 in the EEPROM. In the debugger, though, I always will get back a 0 value.
Ummm, yeah. It is easy to replicate the RTC from the enhanced as your computer also has one and they are pretty much a standard, accepting a time drift variance.
The eeprom should also have been fairly easy to simulate, but it hasn't yet been included into the debug simulator, perhaps they are working on it. But the greater difficulty to replicate with a real life like eeprom becomes more complicated than simply storing and spitting back a number. What do you do for persistence across projects, or to distinguish which display you are working with where the eeprom already has data stored? Yeah, so that really becomes quiet the challenge, 4 displays of the same model, which eeprom is this editor HMI to use?
So is wepo/repo suppose to give you a variable location and spit it back to you?
Or is it suppose to also suppose to be life like?
- When you write a number at 0, 2, 3, and 5 - what should a repo n1.val,1 report?
- from where?
And do wept/rept also become simulated out of ?
And the GPIO pins - but what are they actually connected to?
So maybe it is enough to know that if I issue a wepo n1.val,4
that I know bytes 4,5,6,7 are written to and I will be able to read them later.
Thanks for the info. i was trying wepo and repo on the emulator because is too esay and quick to test in. without repo an wepo I can't do the job, It's a must have (the gpio are phisicaly not emulable) but rtc and eeprom is EASY, put a reset eeprom button for begining and in the future you could do better, but do it!!!
I have a basic LCD but I need eeprom on emulator to know if enhanced one fits for me. The basic does not fit for me, and I dont want to waste other 30€ in other LCD an when it arrives goes to de recicle bin like the first one because not fit my idea...
Ok I will byte. =) So again - Ivan
You want eeprom simulation in the editor: And I asked - for what do we simulate?
Some real life advanced legitimate usage replication, or some kiddy scripts?
I certainly am not interested in having an eeprom simulation to hold ssid/password. Or what the temperature was in the last 24 hours. You say a reset button, and I say a reset button doesn't simulate anything close to what I use my eeproms for. I dump unique to each display data to mine on arrival, and I have no plans to reuse the space but what my eeprom data is used at runtime for is now essential to my HMIs .. wink
Seriously, I get the economics, and it is a 1K eeprom. 1024 bytes. Reliable SLOW storage.
Probably get more than a million reads out of this puppy.
Each number wepo takes 4 bytes, a string wepo uses txt-maxl+1 for null termination. So here is what happens when I store hex number 55443322 at 0 and store hex number 33884422 at 4
 22  33  44  55  22  44  88  33
Now if we repo 0 and repo 4 .. we get exactly the two number back. If I repo 1 and repo 6 - not my two numbers - I will have hex 22554433 and xxxx3388. and this is no mystery, it is exactly what to expect from an eeprom and the limits of writing and reading numbers. So what about text?
If I write a string "12345678" from a component where txt-maxl is 8 it chews up 9 bytes
 31  32  33  34  35  36  37  38  00
And the same .txt from a component where txt-maxl is 63 will have the same data but bytes  through  are unreliable. If I repo the text at 0 or any other address, it reads until it hits the null byte 00. If there is no null byte 00, then hmm undefined errors.
So you want to make the argument that this is EASY ... concept is simple for store SSID/Pass and Time, Temperatures where you are reading back from the same addressing that was written ... but sorry, that is a kindergarten application usage of the eeprom ... more advanced usage of the eeprom will require persistence and remembering which Nextion device is being used in the simulation - that to me just introduces another point of failure, and what about writes made at run-time outside of what is preloaded - there is no way to simulate that dynamic. A reset button on mine - no way, far from desired.
No, you don't NEED an eeprom emulator to know if a 1K fits your need.
So back to your economic argument, is it worth another 30 Euros. If you throw away a good LCD without repurposing it, economics doesn't play into it and your argument is flawed from the beginning. But unless your HMI application is to be completely driven within Nextion logic and you have no connecting MCU - only then does it really fit a NEED. All else is fitting a desire and a convenience. True economic arguments will be to put an eeprom on your connecting MCU side, and if you are doing that - hmmm 1K in an eeprom flash or 32GB in a spi flash ... I really can't think where 1K ever became the make or break for a deal.
Finally, what is the value of a 1K eeprom on the Nextion side of Rx/Tx ... ahh, and THAT depends on what you program. THAT all of a sudden brings a value much great than any 30 euros or 3000 euros ... so it truly is dependant on what you end up doing with it and has nothing to do with the 0.30 euro part.
I would argue that in simulation, wepo/repo should work at least for the duration of the current debug session. This should give me, in simulation, a t10.txt value of "Feb" (when rtc1 is 2 and the t10.txt_maxl=3).
Yes, I know this can be done in code with "if" statements, and yes, the wepo statement would be removed after the real Nextion eeprom is loaded the first time.
So, you can not read Feb out that way.
You will return FebMarAprMayJunJulAugSepOctNovDec
read until null
I regress Lance, with maxl of 3, it might be actually possible.
But if I continue on the debate of eeprom in simulation,
With multi-devices and multi-eeproms, managing which eeproms should be simulated is a nightmare at best
It also creates another layer of complexity with customer customization -those that order with larger eeproms
The debugger may require a fair amount of rework as it is
But I'll share something a bit interesting
- when I created my Nextion Side EEPROM Editor,
- the response was more like - why?
Shouldn't people already know what they stored
And when the Debug doesn't always send what is expected
- your eeprom results will not be as expected.
So why does Debug not send what you expect?
The code editor translates characters for the iso
- this is rooted in windows, and not on a 2K PIC
But for .txt values - they need to support not just English
but Russian, Greek, Hebrew, etc ....
I would argue then, that much rework would be needed for eeproms
(It could also perhaps fix timers while it is being reworked)
But the main point of the Editor was for the HMI design
The debate can certainly be argued successfully on both sides
Since you realized your Feb - do you realize what you have?
You'll need to ponder it more
But I will give you a way to grab months without eeprom, much quicker.
create 12 text variables, with sequential .id, txt-maxl of 3
look at the .id of the first of these variable .id, later you will sub 1
- so if your id is 1, b[rtc1].txt
- but if your first .id is 36 then access it by b[rtc1+35].txt
What do you make of Lance's month name eeprom implementation?
Notice anything intriguing?