14M2 TABLE data

PhilHornby

Senior Member
I've recently been porting some code from a Picaxe 08M2 to a Picaxe 14M2, because I'd run out of memory (it's a WebServer implementation).

The intention was to make use of #SLOT 1 on the 14M2 to effectively double the amount of memory available (and get some more back because EEPROM doesn't overlap Program Space on the 14M2 like it does on the 08M2).

Then I remembered the TABLE command...

There's not a massive amount of documentation on it, so I did some experimenting. The Webserver is part of a larger project and gets its data from a nearby Picaxe 20X2, so I did some playing around with TABLE on that as well.

This is what I found:-

[highlight]Picaxe 20X2[/highlight]
  1. Using TABLE() data reduces the amount of code space available.
  2. If no TABLE() statement is present in the source file, any existing TABLE data is CLEARED from the microcontroller (unless the #No_table Directive is present). I.e. the same approach as EEPROM() data.

[highlight]Picaxe 14M2[/highlight]
  1. TABLE() data does NOT reduce the amount of code space available.
  2. If no TABLE() statement is present, any existing data in the microcontroller (if any) is RETAINED unchanged. (The Editor "CLEAR" function does NOT delete it either.)
  3. TABLE() data, if present in the source file, is ALWAYS loaded into the microcontroller - the #No_table directive is NOT supported.
  4. Each Slot has its OWN 512 bytes of TABLE data - so there is [highlight]1KByte in total[/highlight].

I can't see a whole lot of advantages in using TABLE data on the 20X2 - but the sudden discovery of an extra 1KByte of data on the 14M2 is a revelation. The fact that it survives an Editor "CLEAR" operation may be a good or a bad thing - I've not decided yet.

I wrote a little test program (attached) that demonstrates some of these effects (on the 14M2).

Code:
[COLOR=navy]#picaxe [/COLOR][COLOR=black]14m2[/COLOR]
[COLOR=navy]#no_data                [/COLOR][COLOR=green];not testing EEPROM. [/COLOR]
[COLOR=navy]#terminal 4800          [/COLOR][COLOR=green];Serial Terminal doesn't like all this data - may need restarting regularly :-(
[/COLOR]
[COLOR=navy]#slot 0
[/COLOR]
[COLOR=green]; Demonstration of 14M2 TABLE data

;Instructions:-

; 1. Ensure Statement above is set to #Slot 0, Uncomment Table 1 and Program Picaxe. Table 1 will be printed.
; 2. Set Statement above to #Slot 1, Comment out Table 1 again, Uncomment Table 2 and Program Picaxe. Table 2 will be printed.
; (NOTE: Slot 1 runs immediately after it has been programmed. Picaxe now contains Table 1 in Slot 0 and Table 2 in Slot 1.
;
; 3. Set Statement above to #Slot 0, Comment out Table 2 as well and Program Picaxe. Table 1 will be printed again.
; 4. Set Statement above to #Slot 1, and Program Picaxe. Table 2 will be printed.
;
; 5. Set Statement above to #Slot 0, uncomment 'RUN 1 and Program Picaxe. Both Table 1 + 2 will be printed.
;
; 6.Change Statement above to #Slot 1 and change 'RUN 1' to 'RUN 0' and Program Picaxe - both tables will printed ad infinitum.
; (Slot 0 prints Table 1 and 'chains' Slot 1. Slot 1 prints Table 2 and 'chains' Slot 0
;
; 7. Finally - CLEAR Picaxe with Editor. Comment out both tables. Reload program to both slots. Data is still there!


#rem
;
; Table 1 512 bytes. 
;
TABLE ("Now is the winter of our discontent, made glorious summer by this son of York.  ")
TABLE ("Now is the winter of our discontent, made glorious summer by this son of York.  ")
TABLE ("Now is the winter of our discontent, made glorious summer by this son of York.  ")
TABLE ("Now is the winter of our discontent, made glorious summer by this son of York.  ")
TABLE ("Now is the winter of our discontent, made glorious summer by this son of York.  ")
TABLE ("Now is the winter of our discontent, made glorious summer by this son of York.  ")
Table ("1234567890123456789012345678901")
#endrem

#rem
;
; Table 2 another 512 bytes.
;
TABLE ("There should be laughter after pain, there should be sunshine after rain, These ")
TABLE ("things have always been the same. Why worry now? Dire Straits, doncha know :-)  ")
TABLE ("There should be laughter after pain, there should be sunshine after rain, These ")
TABLE ("things have always been the same. Why worry now? Dire Straits, doncha know :-)  ")
TABLE ("There should be laughter after pain, there should be sunshine after rain, These ")
TABLE ("things have always been the same. Why worry now? Dire Straits, doncha know :-)  ")
Table ("1234567890123456789012345678901")
#endrem

      ;if W0 <> 512 then                              ;if we've been run before (tends to kill Serial Terminal!)
            [/COLOR][COLOR=blue]pause [/COLOR][COLOR=navy]2000                                [/COLOR][COLOR=green];wait for terminal (to start/recover!)
      ;endif

      [/COLOR][COLOR=blue]For [/COLOR][COLOR=purple]W0 [/COLOR][COLOR=darkcyan]= [/COLOR][COLOR=navy]0 [/COLOR][COLOR=blue]To [/COLOR][COLOR=navy]511 
            [/COLOR][COLOR=blue]Readtable [/COLOR][COLOR=purple]W0[/COLOR][COLOR=black],[/COLOR][COLOR=purple]b2                           [/COLOR][COLOR=green];get the byte from TABLE
            [/COLOR][COLOR=blue]Sertxd ([/COLOR][COLOR=purple]b2[/COLOR][COLOR=blue])                               [/COLOR][COLOR=green];and send it out of the serial port
      [/COLOR][COLOR=blue]Next[/COLOR]

[COLOR=green];     RUN 0                                           ;chain the 'other' slot.[/COLOR]
Warning: The demo program prints the contents of the TABLE data to the Serial Terminal. As observed in this thread PE6 Serial Terminal can consume VAST amounts of system resources. You may find you need to restart it frequently, and/or clear its buffer. It's much better to use something like Putty, but then you have to remember to close it before programming :(
 

Attachments

Last edited:

westaust55

Moderator
PICAXE TABLE memory

I can't see a whole lot of advantages in using TABLE data on the 20X2
Table memory uses the same type of memory as the program, i.e. flash memory. While not as fast as RAM, flash memory is faster to access than EEPROM memory, so advantageous for quicker access to data and sending a series of bytes out to say an LCD display.


With respect to the TABLE command, some of the information is available in the manuals or the On-Line Commands section of the website: http://www.picaxe.com/BASIC-Commands/Variables/table/
Description:
Specify values to be loaded to the internal lookup table when the program is downloaded.
M2 parts have 512 locations (0-511). These are separate to the 2048 bytes of program memory, so do not affect program length.
X1 and X2 parts have 256 locations (0-255). When table is used these reduce the overall program memory capacity of these parts (4096 - 256)

Applies To: 14M2, 20M2, 18M2+, X1 and X2 parts


The READTABLE command description also indicates:
Description:
When a data table is defined in a program code slot with the X2 parts, the data table is accessible only to the program within that slot. Each program slot using readtable commands should have its own 'table' defined.

If you look here:http://www.picaxe.com/What-is-PICAXE/PICAXE-Chip-Sizes/
you can see that the 20X2 has a single slot whereas the 28X2 and 40X2 have program memory 4 slots.

The second program slot for the M2 parts only became available with the release of the Programming Editor at V6. Note that PE V5 cannot access both program memory slots for M2 parts.

In that respect the manuals and on-line commands information could do with some update to reflect that the M2 parts also have a separate TABLE area for each program slot.

Nevertheless, a good summary and highlights some aspects not immediately obvious from a read through the current manuals and on-line command descriptions. Well done for documenting.
 

hippy

Technical Support
Staff member
We have updated the on-line command description for table within slots to reflect that some M2's now have multiple slots. Have put looking at related commands and what else can be improved on the list of things to do.
 

PhilHornby

Senior Member
Memory Speed

Table memory uses the same type of memory as the program, i.e. flash memory. While not as fast as RAM, flash memory is faster to access than EEPROM memory, so advantageous for quicker access to data
I'm sure you're right about the underlying PIC ... but the Picaxe firmware seems to negate the advantage.

I tried some timing tests - "READ" (ie EEPROM) vs "READTABLE" vs "LOOKUP". The attached program accesses 256 bytes of EEPROM, the first 256 bytes of TABLE data, and 64 bytes in a LOOKUP statement. In the case of the EEPROM and TABLE I had to slow the Picaxe down to 31KHz to get times that were meaningful on a stopwatch - both took 70 seconds. In the case of LOOKUP, the pro-rata'ed answer from 64 bytes was 600 seconds. I also induced a reproducible Picaxe RESET! (separate thread!).

Code:
[COLOR=navy]#picaxe [/COLOR][COLOR=black]20x2[/COLOR]
[COLOR=navy]#terminal 9600
#no_data
      [/COLOR][COLOR=blue]pause [/COLOR][COLOR=navy]2000
      [/COLOR][COLOR=blue]sertxd (cr[/COLOR][COLOR=black],[/COLOR][COLOR=blue]lf[/COLOR][COLOR=black],[/COLOR][COLOR=red]"EEPROM"[/COLOR][COLOR=blue])
      setfreq K31
      for [/COLOR][COLOR=purple]b0 [/COLOR][COLOR=darkcyan]= [/COLOR][COLOR=navy]0 [/COLOR][COLOR=blue]to [/COLOR][COLOR=navy]255
            [/COLOR][COLOR=blue]read [/COLOR][COLOR=purple]b0[/COLOR][COLOR=black],[/COLOR][COLOR=purple]b1
      [/COLOR][COLOR=blue]next [/COLOR][COLOR=purple]b0
      [/COLOR][COLOR=blue]setfreq M8 [/COLOR][COLOR=black]: [/COLOR][COLOR=blue]sertxd(cr[/COLOR][COLOR=black],[/COLOR][COLOR=blue]lf[/COLOR][COLOR=black],[/COLOR][COLOR=red]"FLASH"[/COLOR][COLOR=blue])
      setfreq K31
      for [/COLOR][COLOR=purple]b0 [/COLOR][COLOR=darkcyan]= [/COLOR][COLOR=navy]0 [/COLOR][COLOR=blue]to [/COLOR][COLOR=navy]255
            [/COLOR][COLOR=blue]readtable [/COLOR][COLOR=purple]b0[/COLOR][COLOR=black],[/COLOR][COLOR=purple]b1
      [/COLOR][COLOR=blue]next [/COLOR][COLOR=purple]b0
      [/COLOR][COLOR=blue]setfreq M8 [/COLOR][COLOR=black]: [/COLOR][COLOR=blue]sertxd(cr[/COLOR][COLOR=black],[/COLOR][COLOR=blue]lf[/COLOR][COLOR=black],[/COLOR][COLOR=red]"LOOKUP"[/COLOR][COLOR=blue])
      setfreq K31
      for [/COLOR][COLOR=purple]b0 [/COLOR][COLOR=darkcyan]= [/COLOR][COLOR=navy]0 [/COLOR][COLOR=blue]to [/COLOR][COLOR=navy]4
                  [/COLOR][COLOR=blue]lookup [/COLOR][COLOR=purple]b0[/COLOR][COLOR=black],[/COLOR][COLOR=blue]([/COLOR][COLOR=red]"xxxxxxxxxxxxxxxxxxxx"[/COLOR][COLOR=black], _
                       [/COLOR][COLOR=red]"xxxxxxxxxxxxxxxxxxxx"[/COLOR][COLOR=black], _
                       [/COLOR][COLOR=red]"xxxxxxxxxxxxxxxxxxxx"[/COLOR][COLOR=black], _
                       [/COLOR][COLOR=red]"xxxxZ"[/COLOR][COLOR=blue])[/COLOR][COLOR=black],[/COLOR][COLOR=purple]b1  [/COLOR][COLOR=green];64 OK
            
      [/COLOR][COLOR=blue]next [/COLOR][COLOR=purple]b0
      [/COLOR][COLOR=blue]setfreq M8 [/COLOR][COLOR=black]: [/COLOR][COLOR=blue]sertxd(cr[/COLOR][COLOR=black],[/COLOR][COLOR=blue]lf[/COLOR][COLOR=black],[/COLOR][COLOR=red]"END"[/COLOR][COLOR=blue])
      end[/COLOR]
 

PhilHornby

Senior Member
Documentation

We have updated the on-line command description for table within slots to reflect that some M2's now have multiple slots.
I don't tend to look at the online documentation - not least, because every download of Picaxe Editor installs the documentation set locally, in PDF format.

All this extra memory on the M2 series is worth a bit of a fanfare though - PE6 has doubled the capabilities of this range of devices!

What can/should/will be done about the 'missing' #No_TABLE command and the fact that the "CLEAR" function doesn't actually clear this particular data?
 

hippy

Technical Support
Staff member
What can/should/will be done about the 'missing' #No_TABLE command and the fact that the "CLEAR" function doesn't actually clear this particular data?
What do you think should be done, and what problems do you perceive there to be without either ?

I can't actually see any real problem. If you don't want the TABLE data to download, wrap it in a #IFDEF conditional or #REM it out.

The worst case scenario in not clearing out TABLE data is someone could download a program which does not contain TABLE data and read out the TABLE data previously downloaded. If the TABLE does not contain sensitive data there is unlikely to be much of a problem.
 

PhilHornby

Senior Member
What do you think should be done, and what problems do you perceive there to be without either ?
It's just an inconsistency across the range. You could argue that a "CLEAR" function of any description is unnecessary - as in, the next download overwrites everything anyway. To my mind, if you're going to have one, then it should clear everything.

I can't actually see any real problem. If you don't want the TABLE data to download, wrap it in a #IFDEF conditional or #REM it out.
That's what I've been doing. But again, it's an inconsistency; I don't have to do that for EEPROM. I don't have to do it for TABLE on an X2.

The worst case scenario in not clearing out TABLE data is someone could download a program which does not contain TABLE data and read out the TABLE data previously downloaded.
This is how I discovered I'd got two separate TABLE areas ;)
 
Top