I'm confused about the volume of SRAM

John Kauffman

I'm confused about the amount of SRAM on the SX28.
The SX28 datasheet specs the chip with " 136x8 bits SRAM " (page 3).
Out of curiosity I started adding variables to an empty program & assembling.

DEVICE· SX28, OSC4MHZ, TURBO, STACKX, OPTIONX
FREQ··· 4_000_000
'

---

Variables
var00·var·byte
var01·var·byte
var02·var·byte
var03·var·byte
...
PROGRAM Start
Start:
Main:
GOTO Main

Up to var18 there is no assembly problem.
When I add var19 I get an assembly error that "variable exceeded available RAM."
From the datasheet I predicted that I could declare 136 byte-size variables.
Can someone explain this? Thanks.

Bean

John,
The rest of the RAM is used for Arrays.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Did you know that 111,111,111 multiplied by 111,111,111 equals 12345678987654321 ?

www.iElectronicDesigns.com

·

John Kauffman

I used arrays in the past to make looping through values easier. Now I see that putting values in arrays also makes available an additional 108 bytes. This is great news, I had been fighting to squeeze my projects into only 19 variables.

I add to my program 12 arrays of 9 bytes each with no assembly problem.
varArr01 var byte(8)
varArr02 var byte(8)
varArr03 var byte(8)
...
varArr12 var byte(8)

But VarArr13 causes the VARIBAL EXCEEDED RAM error.

So I have:
19 single bytes = 19 bytes
12 arrays of 9 bytes each = 108 bytes
Total = 127 bytes
Datasheet says 136
Missing = 9 bytes

Not to be a stickler, but I'll learn something more about SX if I can figure out where the other 9 bytes are located. Is it conincedence that the 9 missing bytes would be one more array scoped to (8)? Am I counting my arrays wrong?

Code below.

'

---

Variables
var01 var byte
var02 var byte
var03 var byte
var04 var byte
var05 var byte
var06 var byte
var07 var byte
var08 var byte
var09 var byte
var10 var byte
var11 var byte
var12 var byte
var13 var byte
var14 var byte
var15 var byte
var16 var byte
var17 var byte
var18 var byte
var19 var byte
' var19 var byte ' #19 exceeds ram

varArr01 var byte(8) ' (8) = 9 bytes each
varArr02 var byte(8)
varArr03 var byte(8)
varArr04 var byte(8)
varArr05 var byte(8)
varArr06 var byte(8)
varArr07 var byte(8)
varArr08 var byte(8)
varArr09 var byte(8)
varArr10 var byte(8)
varArr11 var byte(8)
varArr12 var byte(8)
'varArr13 var byte(8) ' #13 exceeds ram

Zoot

There are a number of quasi-hidden registers in use if you are using SX/B -- the __PARAM vars all take up space, the __REMAINDER var, the "shadow" registers for pin directions and states, etc. The only way to free up the bit of extra ram is to program wholly in assembly.

In a technical sense, when you declare individual VARS, these go into the BANK 0 registers (some of which are already in use by the requirements of the chip and/or SX/B). When you declare "arrays" those go into BANK 1 ... BANK N where N is dependent on the chip (SX28 or SX48). You CAN set up individual vars in the "arrays" though, if you want, like this:

someArr VAR Byte(8)
someVar VAR someArr(0) ' alias to first element of someArr

So you can now use someVar like any other variable, although accessing may take up more code space (in assembly; you won't see it in SX/B) because of the way the FSR is used to access the higher banks of ram.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

John Bond

When are you allowed to use array variables as veriables and when can you not use them. I discovered last night that For...Next doesn't like array variables.

John Bond

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Bean

John,
You cannot use them as FOR...NEXT control variables. And you cannot use them as the index of another array.
Other than that, you should be able to use them anywhere else.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Did you know that 111,111,111 multiplied by 111,111,111 equals 12345678987654321 ?

www.iElectronicDesigns.com

·