M2 table command slows program download?

[RonHackett]

I have been playing around with using the table command to store string data for outputting to an LCD, and I have found that it greatly increases the program download time on 14M2 and 20M2 processors, but not on the 20X2. At first I thought that it was because I was using a fairly large amount of "table" storage, but I get similar results with the following simple test program. It takes more than 50 seconds to download the test program to a 14M2 or 20M2 processor. If I comment out the table command, the download takes only 10 seconds. With a 20X2, the download takes about 10 seconds whether the table command is included or not.

table 0,("?")
do
  pause 10
loop

So, I'm wondering if anyone else has experienced this, and whether anything can be done to speed up M2 program downloads that include table commands.

Thanks... Ron

 

[hippy]

This is the nature of the beast. The M2 is different from the X2, has a different internal memory layout and requires a different download mechanism which does unfortunately take longer.

It's not usually much of a problem for the target audience of the M2 but where it is there are some possibilities ...

If using the AXE027 reduce the device latency in Device Manager

Switch to using an X2

Download as normal, then for subsequent downloads comment out the TABLE commands ( #REM ... #ENDREM is the easy option ); downloads will be faster and Table data should remain intact. You can checksum the table or just check the first byte(s) to help ensure it is.

#NO_TABLE is not supported for the 20M2 but I have an idea for that which I'll raise here which may improve things.

 

[RonHackett]

Hippy - thanks for clarifying what was going on. I'm also using TABLECOPY so that I can use BPTR and @BPTR to process the table contents, so I just tried switching from TABLE to DATA, and then copying the data to the storage area with the following loop:

for bptr = 32 to 95
  read bptr, @bptr
next bptr

That speeds up the program download, and then adding #NO_DATA speeds it up even more. (Of course, it also reduces the program size considerably.) Since I can use the same approach with an 08M2, I think I'll stick with that.

Thanks again for the usual fast and clear response to a problem!

Ron

 

[hippy]

so I just tried switching from TABLE to DATA

I meant to suggest that as an option then forgot - too early on a Saturday morning ! Glad you figured it out for yourself, and apologies for having to do so, but at least you get the deserved credit for working it out.

 

[RonHackett]

I really appreciate the fact that your outstanding support is even available early on a Saturday Morning. Thanks again for your help!

 

[Armp]

I'm still confused on the differences between DATA and TABLE.
I need to preload ~200 bytes into a 20M2, which should I use? And why...

 

[hippy]

I'm still confused on the differences between DATA and TABLE.

TABLE is pre-loaded read-only data

DATA is pre-loaded readable and writeable data.

I need to preload ~200 bytes into a 20M2, which should I use? And why...

If your program needs to update the pre-loaded data then you will have to use DATA.

If you only read the pre-loaded data you can use TABLE or DATA but, as noted, using TABLE on an M2 will mean a slower download than when using DATA.

 

[Armp]

TABLE is pre-loaded read-only data

DATA is pre-loaded readable and writeable data.

Thanks Hippy - I missed that somehow...

 

[Armp]

I thought I saw that 512 byte 'table' space was separate from program space? But a test in sim says:

table 0,("Hello World") uses 19 bytes of program memory

eeprom 0,("Hello World") uses 0 bytes

 

[Technical]

Table on M2 parts is downloaded as 'part' of the program memory, which is why it is read only. However it has no effect on the length of your program, as it is a 'separate' reserved 'table storage area' of the program memory, so not part of the normal 'program storage area' of the program memory.

 

[Armp]

That's what I understood... so is PE giving the wrong answer? Or am I not quite awake yet

This is the result of repeating the table statement a dozen times, no other statements:

View attachment 10010

 

[Technical]

Yes, the msg is a bit misleading, we'll look at making it clearer. It has used those bytes, but they are not part of the 2048 'program area'.

 

[PADJ]

#NO_TABLE is not supported for the 20M2 but I have an idea for that which I'll raise here which may improve things.

Any progress?

 

[hippy]

@ PADJ : I guess whatever I was thinking turned out not to be practical. I honestly cannot remember what I was thinking back then.