Start a new topic

wepo/repo in debugger not completely supported?

 Hi all,


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.


1 person likes this idea

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.





1 person likes this
Yeah, thought so myself, but thank you for the clarification, Patrick!
I know the code works as soon as I upload it to the screen, so no much worries here :-)

 

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

[0] 22 [1] 33 [2] 44 [3] 55 [4] 22 [5] 44 [6] 88 [7] 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

[0] 31 [1] 32 [2] 33 [3] 34 [4] 35 [5] 36 [6] 37 [7] 38 [8] 00

And the same .txt from a component where txt-maxl is 63 will have the same data but bytes [9] through [63] 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).


wepo "JanFebMarAprMayJunJulAugSepOctNovDec",0

sys0=rtc1-1*3

repo t10.txt,sys0 


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


Not so when length of receiving field is 3, as stated. Tested on a real Nextion (for Jan).

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

 

 

So Lance,


Since you realized your Feb - do you realize what you have?

Not sure what you mean. I realize that I have a way to get a text indicator of the month, given the value of rtc1, that works on an enhanced Nextion, but not in the simulator.

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


Michael


What do you make of Lance's month name eeprom implementation?

Notice anything intriguing?

The scope of pondering what I am ignorant of is too great, but thanks for another instance of the use of the b[] array.
Well, yes, that is the substr() mechanism I had in mind, but for the slowness and limited life of the EEPROM it makes not that much sense. If the source string would be in SRAM, though...
Login or Signup to post a comment