Symbol, eeprom and data format

[BCJKiwi]

eeprom data as a symbol

Have some 50 configuration variables stored in eeprom. (28X1 FW ver A.1)
There are too many to store in normal variables and leave them there.

Storing to scratchpad would be OK but entails some overhead in setting the pointer or reading the scratchpad directly to a variable i.e. no gain over a read eeprom address.

I finally hit on the idea of reading the eeprom to a ptr and creating a symbol from the ptr.

The objective here is to save on program size (hitting the limit), and improve processing speed.

let b0 = 110 'testing only,
write 137,b0 'normally a permanent value
read 137,@ptr
symbol ee137=@ptr

The idea was to do this for each eeprom value at the initialisation of the program and then use the symbol directly in the program.

This all passes the syntax checker and looks good in the simulator, and tested by sertxd("ee137 ",#ee137) which produces the correct result anywhere in the program.

However when running the simulator with;

 b21 = ee137
 b20 = ee137 /20 +ee137
 If b1 > b20 Then
  Goto SpeedEnd
 EndIf

in place of;

 read 137,b21
  b20 = b21/20+b21
 If b1 > b20 Then
  Goto SpeedEnd
 EndIf

b21 is 44 instead of 110,
and,
b20 therefore becomes 46 instead of 115

The simulator shows all the expected values being stored in eeprom, scratchpad, and symbol during the initialisation phase.
However when using the different symbols in the program, the symbol seems always to be 44 even though a sertxd reports the expected value for the symbol.

Any help gratefully received.
Thanks

 

[hippy]

SYMBOL means replace one symbol with another, so in this case your code becomes -

- b21 = @ptr
- b20 = @ptr / 20 + @ptr

If 'ptr' isn't pointing to the right place then '@ptr' won't return the correct value.

SYMBOL is a compile time directive, not an executable statement so your ...

- read 137,@ptr
- symbol ee137=@ptr

doesn't set ee137 to whatever value @ptr got from the read, it sets it to the name of "@ptr".

 

[BCJKiwi]

This did not seem to be what was happening but further tests indicate it is.

Nowhere in the manual does it indicate that symbol is a directive - it is always referred to as a command. However I guess there is a clue in "Symbols have no affect on program length as they are converted back into ‘numbers’ before the download."

So is there any way to get the value stored in eeprom into something that can be used repeatedly and directly in a calculation without all the overhead involved in repeatedly reading the eeprom to a variable then using the variable?

 

[Dippy]

Do you mean like an array element? Like A(25) could be the 25th byte stored in EEPROM or words to that effect?

 

[BCJKiwi]

These 50 odd eeprom data elements are looked up and used in calculations each cycle of the program.

Currently they are accessed by;

 Read 138,b26
 If b26 = 5 then goto G5 
 If b26 = 4 then goto G4 
'G6:
 read 144,b21   ' 6th
 If b20 =< b21 then
  let b27= 6
 EndIf
G5:
 read 143,b21
 If b20 =< b21 then 
  let b27= 5   ' 5th
 EndIf
G4:
 read 142,b21
 If b20 =< b21 then 
  let b27= 4   ' 4th
 EndIf

and

 Let b6=0
 read 137,b21
  b20 = b21/20+b21
 If b1 > b20 Then
  hi2cout [IO_3],$13,(%11111111)
  Goto SpeedEnd
 EndIf 
 If b1 >= b21 Then
  b6=180
 EndIf 
 read 136,b21
 If b1 >= b21 Then
  b6=179
 goto SpeedOut
 EndIf

and other similar blocks of code.

There are not enough variables to hold them all, and I don't want to read all the eeprom data into variables at once for that routine as the logic might quit the routine at an early stage - a couple of these routines could check 15 values each if they run to the end.

Have used branch and such where the data can be accessed directly but unless the eeprom values can be moved into some directly accessible location, am unable to use cleaner logic structures or tighter code.

So I'm not entirely sure what construct you are suggesting with the array. If it's the ptr/@ptr i'm not sure it would be any more efficient as the pointer has to be located to the correct address. I have not experimented with ptr, @ptr, @ptrinc/dec in this context yet. There are around 75 unused scratchpad locations (in a block) so this could work I guess - will have to experiment.

 

[hippy]

Is it possible to put the blocks of code in some sort of loop ?

 

[BCJKiwi]

I've just tested the ptr approach and it saves some 75 +bytes of program space as the eeprom values are mostly in series so @ptrinc/dec can be used to advantage. I trust this will be faster in execution than read eeprom to var, then test.

Program size is now down to 3507 bytes (was over 4096 by some 200 bytes at one stage) so I should be able to fit in the final refinements.

Block 2 from post #5 above now looks like;

 Let b6=0
' read 137,b21
 ptr = 37
 b20 = @ptr /20 + @ptr       'add 5%
 If b1 > b20 Then    
  hi2cout [IO_3],$13,(%11111111)
  Goto SpeedEnd
 EndIf 
 If b1 >= @ptrdec Then     'ee137 / ptr37
  b6=180
 EndIf 
' read 136,b21
 If b1 >= @ptrdec Then  
  b6=179
 goto SpeedOut
 EndIf 
'... 4 times more!

A simple for/next loop is used to read the required eeprom data into individual scratchpad addresses at the initialisation phase - i.e. This only executes once per power-up.

ptr=12
for b0 = 112 to 150
read b0,@ptrinc
next

Hippy, the issue with putting the code in a loop is that in the second example above, the value of b6 alternates within each block and there is a series of 5 blocks in the sequence (eeprom 137 down to 128 in this case). I could not get my head around how that might be achieved with the read eeprom approach as this could not be done inside the If /endif test logic. There are similar constructs in other blocks of code.

Now that I have a logical block of data that can be sequentially read directly - i.e. @ptrinc / dec, I will have a look at trying to get more of it into loops.

One issue is that I don't want to slow it too much so as long as it fits in 4096 bytes, I will try to keep it as direct as possible.

About a third of the code is in the configuration / setup routines which only get used once and that's as tight as I can make it (reads settings via irin) as I don't care how slow this executes.

Have also found some of the constructs (such as branch & select case) don't actually save program space compared to if / then /endif repeated, depending on how much you can do with the conditional test at each case. Previous tests indicate these are also slower than if / endif repeated.

It would be great if the eeprom address could be used directly as you would a variable!

 

[BCJKiwi]

Well Guess what?
Finally sorted and tested the code in the simulator and went to download it only to receive an error message!

It seems I need FW A.2 (and only have FW ver A.1) to use @ptrinc / dec as a destination.

This is around the third programming issue with FW ver A.1

Wonder if Rev-Ed / Technical will give me a credit on the beta PICAXE?

Found a workaround for this 28X1 fw A.1 problem;

ptr=12
for b0 = 112 to 150
read b0,@ptrinc   'complie error - requires firmware A.2
next

with this construct;

ptr=12
for b0 = 112 to 150
read b0,b1
@ptr=b1
inc ptr
next