"Unexpected" behaviour with a PEEKSFR .. @BPTRINC

[AllyCat]

Hi,

For a current project, I needed to know the approximate time delays between a sequence of READADCs. Of course I could have put in some marker pulses and used a 'scope, but it seemed easier to read the Timer 1 High byte (which increments every 256us) and store the values in (indirect) RAM. However, the results contained a suspiciously high number of zeros, so I stripped the code down to the absolute basics as follows (typical results are included at the end of the listing) :

; peeksfr+@bptrinc bug?
; Allycat May 2015 

#terminal 4800
#picaxe 14M2
#no_data
  symbol TMR1H    = $17       ; Timer 1 High byte
main:
   pause 100
do
   bptr = 30                  ; Pointer to test times
;  pokesfr TMR1H,0            ; Test option
   peeksfr TMR1H,@bptrinc
   peeksfr TMR1H,@bptrinc
   pause 1
   peeksfr TMR1H,@bptrinc
   peeksfr TMR1H,@bptrinc
   peeksfr TMR1H,@bptr    
  
   sertxd(cr,lf,"t=")
   for bptr = 30 to 39
      sertxd(#@bptr," ")
   next 
   sleep 2
loop
#rem   Typical Output:

t=0 184 0 187 0 195 0 197 200 0
t=0 227 0 230 0 237 0 240 242 0
t=0 191 0 194 0 202 0 204 207 0
t=0 227 0 230 0 237 0 240 242 0 
#endrem

It appears that the INC is being executed twice (the zeros are not written they are just the result of initialisation), but I can't see any obvious reason for this. I've only tested the above with a 14M2 and PE5 (5.5.6) and PE6 (6.0.7.1). Am I doing something wrong, or is this a known "feature" (I can't see anything in the Revision History)? Or is it (hopefully) a PE issue?

Thanks, Alan.

 

[grim_reaper]

...
[color=Purple]bptr [/color][color=DarkCyan]= [/color][color=Navy]30                  [/color][color=IndianRed]; Pointer to test times
;  pokesfr TMR1H,0            ; Test option
   [/color][color=Blue]peeksfr TMR1H[/color][color=Black],[/color][color=Purple]@bptrinc
   [/color][color=Blue]peeksfr TMR1H[/color][color=Black],[/color][color=Purple]@bptrinc
   [/color][color=Blue]pause [/color][color=Navy]1
   [/color]
...

It appears that the INC is being executed twice (the zeros are not written they are just the result of initialisation)...

I don't want to appear ignorant - and I'm not particularly knowledgeable in this area [the code, not ignorance ] - but you're peeking twice... so the INC is being executed twice?
I don't think I understand what you mean! Would you mind re-phrasing it for us not-so-familiars?

 

[techElder]

What happens if you use "peeksfr @bprt" instead of "peeksfr @bprtinc" ??

 

[AllyCat]

Hi,

Thanks for your replies. Each instruction (line) should be doing a (single) post-increment to the byte pointer after each instruction, but it appears to be doing two (one may be a pre-increment; note that the first "output buffer" byte at address 30 is a zero). AFAIK the PEEKSFR does not itself perform a post-increment, but if it did, it would/should be to the SFR address not to the BPTR.

Without the INC, the pointer doesn't move. Note that each line of my test code output has no spurious zero before the last (valid) output byte. If @BPTR is used in earlier lines then the data byte is lost (overwritten).

Cheers, Alan.

 

[hippy]

We would have to investigate further but it does appear the bptr increment is happening before the write and then again after it.

A workaround would be to code as "peeksfr TMR1H,@bptr : bptr = bptr + 1".

 

[Technical]

peeksfr was never designed to be used with the @ pointers. We will adjust the compiler to give a warning if this is attempted.

 

[AllyCat]

Hi,

Thanks hippy and technical. Personally I "like" @BPTRINC because it seems to execute as fast as @BPTR. In my particular example I was trying to make the "diagnostic" code as "non-invasive" as possible.

Yes, it definitely seems to be a "spurious" pre-increment because the following code actually does exactly what I was attempting to achieve (i.e. storing 5 bytes contiguously) :

   peeksfr TMR1H,@bptr
   peeksfr TMR1H,@bptrinc     ; Also gives a pre-increment!
   pause 1
   peeksfr TMR1H,@bptr
   peeksfr TMR1H,@bptrinc     ; Also gives a pre-increment!
   peeksfr TMR1H,@bptr  

So I hope the PE gives ONLY a "Warning" and not the total "block" as occurs with other potentially "useful" commands such as a PULLUP on the SO and SI pins

I don't know if it also occurs with POKESFRs, but the following might be quite elegant (even if logically incorrect) : pokesfr TMR1L,@bptr : pokesfr TMR1H,@bptrinc .

Cheers, Alan.

 

[hippy]

I hope the PE gives ONLY a "Warning" and not the total "block" as occurs with other potentially "useful" commands such as a PULLUP on the SO and SI pins

At least for the short term it is likely to be a block as with other commands.

I don't know if it also occurs with POKESFRs

We will be checking other commands but so far it appears that only PEEKSFR is affected.

 

[cpedw]

I have just encountered this behaviour using PE6.1.0.
Peeksfr <location>,@bptrinc
increases bptr before and after the @bptrinc.

 

[AllyCat]

Hi,

Yes, unfortunately the bug appears to be in the interpreter (embedded in the PICaxe chips), so it can't be fixed by (realistic) changes to the Program Editor. BTW I'm almost reluctant to report bugs now, since the "fix" to the bug in readinternaltemp of PE5 has proved to create many more complications than the original bug.

Another SFR for which it is particularly annoying is the (Hardware) Serial Buffer (RCREG) as reported by Bill Wann in his "OT" comment at the very foot of post #13 in https://picaxeforum.co.uk/threads/is-hserin-really-this-slow.

I've also taken this opportunity to fix the "Code=Rich" (text) issue introduced by PE6 and the "new" forum software, in my posts above.

Cheers, Alan.