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.
Write once, read many. Yes, thanks.
Think about your eeprom use, 512 bytes of my 1K is written when received
from this point, reads are much better
but certainly try not to write in each every loop / compare
wepo "JanuaryFebruaryMarchApril",40 in an init and then removed
then it is always there - only reads are needed thereafter.
writes use cycles, reads aren't counted this way
But that is the gist of my substring.
I certainly agree a command for such would be much better
It's certainly possible to hammer eeprom to death, but what's the expected life of this eeprom--100,000 writes? (I'm ignorant of the real number.). It might be usable, especially if the base strings are constants.
Much better, though, would be real string find and substring commands.
Yes, for eeprom substringing, it works. I haven't looked at Patrick's substringing code, and for all I know it could be the sam.
For any valid position, and valid start and end (s0 and s1), with length of va0 of 1, this works (not in simulation)
Puts "March" into t1.txt.
What do you make of Lance's month name eeprom implementation?
Notice anything intriguing?
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
Since you realized your Feb - do you realize what you have?
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, you can not read Feb out that way.
You will return FebMarAprMayJunJulAugSepOctNovDec
read until null
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.