Scratchpad memory

julianE

Senior Member
I usually use EEPROM memory to store array values but decided to give the scratchpad a whirl. I use memory locations starting at 28 up to 128 and just do a for next loop to see what's in the locations, i run the loop before my program begins and every location has a zero in it, then, it hits my program and lets say i write to location 56, my number is there when i do a for next loop but i also see values in other locations that i did not write to. My question, is the interpreter also using the scratchpad memory . the locations where i see values i did not write are like 3 bytes in a row starting at location 78 but it varies.
I can work around the issues, in the past I used an external eeprom on a clock module. It's not an urgent issue just would like to add to my understanding of the scratchpad. BTW, i've been running tests on a 14M2 and 08M2.
thanks in advance.
 

steliosm

Senior Member
Hi Jullian.

This is not scratchpad memory, this is normal user memory (RAM) and the interpreter is not using it for internal tasks. Are you seeing this on the emulator or on the actual chip? How are you accessing those memory locations?
 

inglewoodpete

Senior Member
The M2-series chips do not have scratchpad memory. Refer to Manual 2 - "Commands" and look for Scratchpad (about page 15). You need to use ptr, Put and Get to access the scratchpad.

And, of course, the scratchpad is volatile so data is lost when power is removed.
 

WhiteSpace

Well-known member
Hi @julianE, I'm not sure what you are seeing - if you're using an 08M2 and a 14M2, it must be something other than scratchpad. If it's any help in understanding scratchpad, I use it like this on 28X2s:

So far I have used it to store the character bytes for SSD1306 displays. The first step is to put the bytes into scratchpad:

Rich (BB code):
put 130, 0x40, 0x00, 0x00, 0x00, 0x00; .  
put 140, 0x00, 0x14, 0x00, 0x00, 0x00; :
put 150, 0x7C, 0x12, 0x11, 0x12, 0x7C ;A

put 160, 0x3E, 0x51, 0x49, 0x45, 0x3E ;0
put 170, 0x00, 0x42, 0x7F, 0x40, 0x00 ;1
I generally start a new "put" command for each character - others seem to put all the bytes as a single large block, but I prefer to be able to see what I'm doing more easily. The code above is a bit wasteful, because I'm using 10 byte spaces in scratchpad to store 5 bytes. Scratchpad bytes on the 28X2 run from 0 to 1023.

Then when I want to display the characters, I call them up like this (displaying motor feedback current values):

Rich (BB code):
row = 7
      col = 78
      gosub SetPosition;

            let b37 = 0

            do
            lookup b37, ("R", ":", RCurrentUnits, ".", RCurrentTenths, RCurrentHundredths,"A"), b36 ;takes the 3 digits of DummyCurrent and feeds them in succession to b36
            ;which points to the right place in scratchpad
      
            gosub DisplayCharacter
            inc b37
            loop while b37 <= 6
      endif
and then:

Rich (BB code):
DisplayCharacter: ; this is a universal piece of code to write all characters.  It doesn't set the starting position for them - that is done by the code that refers to here
       ; SerTXD ("GoneSub Display", CR, LF)      
      If b36 = "i" then 
            ptr = 100
            elseif b36 = "L" then ptr = 110
            elseif b36 = " " then ptr = 120
            elseif b36 = "." then ptr = 130
            elseif b36 = ":" then ptr = 140
            elseif b36 = "A" then ptr = 150
            elseif b36 = "0" then ptr = 160
            elseif b36 = "1" then ptr = 170
            elseif b36 = "2" then ptr = 180
           
[I've cut some "elseifs" here because of the character limit]    
      endif

      hi2cout (0x40, @ptrinc, @ptrinc, @ptrinc, @ptrinc, @ptrinc,0x00) ; 
      
      if b36 = "." or b36 = "," then
            col = col + 3; smaller space for short characters full stop and comma
            
                  else
      col = col + 6 ;then move to the next character space, 6 columns further on
      endif
      
      gosub SetPosition

return
The byte b36 then takes the characters from the lookup table and points to the right set of bytes in scratchpad. So if b36 is currently "A" (for Amps), it points to 150 in the scratchpad ("then ptr = 150"). The hi2cout command displays the first byte contained in the scratchpad pointer @ptrinc, which is 0x7C, which in turn corresponds to a set of on and off dots on the display. The @ part of @ptrinc means that it contains the value of position 150, whereas ptr on its own just points to the position 150. The inc part of @ptrinc then moves the pointer on to position 151 in the scratchpad, which is 0x12, and so on. The 5 @ptrincs within the brackets point to the 5 bytes that make up the character.

It took me a while to get my head round scratchpad, and it still catches me out, but the manual has a good explanation.

I hope this helps.
 

julianE

Senior Member
Thank you everyone for all your suggestions, odds are that I misunderstood the manual.
Here is my code stripped down to the basics, I receive 2 bytes from the receiver and am trying to store them array style.
First byte is the identifier and second byte is the data.

Code:
#picaxe 14M2

pause 1000
'print initial locations 28 to 128
for bptr=28 to 128
sertxd (#bptr, "= ", #@bptr,cr,lf)
next bptr

'receive data from rf module
main:
sertxd ("listening...",cr,lf)
Serin c.0, n1200,("ABC"),b7,B8
sertxd (#b7,"   ",#b8,cr,lf)

if b7<28 then main 'only collecting above 27

bptr=b7      'setting pointer
@bptr=b8     'saving at pointer location

'print location info
for bptr=28 to 128
sertxd (#bptr, "= ", #@bptr,cr,lf)
next bptr

goto main
Well, I can't replicate the problem with a pared down program.
I was going to cancel my post but might as well find out what I'm writing to if not the scratchpad. Probably just regular RAM as Steliosm states.
I am testing this on a real chip not the emulator.

all the best.
 

lbenson

Senior Member
might as well find out what I'm writing to if not the scratchpad. Probably just regular RAM as Steliosm states.
You're writing with @bptr=b8, so there's no "probably" about it--you're writing to RAM. You're checking for b7 < 28, but not for b7>128, so it's possible that you're writing somewhere other than where you intend (above 128--the 14M2 has 512 bytes of RAM; since you're loading bptr with a byte variable, you can't be writing above 255).

Is your larger program still ending up with values other than what you expect between address 28 and address 128? If so, you might post that program.
 

julianE

Senior Member
Thank you lbenson. Is it safe for me to write to those RAM locations, I read that locations bellow 28 are the variables written by the interpreter hence why I'm avoiding them. My larger program is very messy and I'm confident I can get it working by breaking into smaller pieces. Appreciate all the help.
 

lbenson

Senior Member
Yes--safe to write RAM addresses 28 through 511 (bptr is a word variable). Below 28 are the variables b0 through b27 (at RAM locations 0 through 27).

You can still read and write to these ram locations with bptr, but you're doing well to avoid them because you can easily mess things up in ways that can be very confusing to unravel. You're not in danger with what you are doing, but be aware that if incremented too far bptr will wrap around from address 511 to address 0 and start overwriting what is there.
 
Top