Byte count varies more than expected

I'm working on a 28X1, with code up to around 3500 bytes. I seem to be getting some strange variation in the bytecount reported by the syntax checker. I'm only making slight code variations while I'm debugging but am seeing the bytecount vary by 100 bytes or more.

Using Editor 5.1.3

The 28X1 does some clever tricks with memory layout, giving 4096 bytes if you don't use TABLE or 3840 bytes plus 256 table bytes if you do.

It could be that you are extending the program into the table area and this could be the cause of whatever anomalies there are.

Adding a TABLE 0,("X&quot will force the table to be used, and that might stabilise the code size, show your program is encroaching into the table area, or may show up some other indicator as what's going on.

Thanks Hippy, I'll take a look at TABLE, I haven't got to reading up about that yet.

If you are using firmware A.0 (only) actual programs downloaded may be longer than syntax check reports if the software auto-corrects the code to workaround the A.0 'outpins' firmware issue. This correction only occurs at the final download stage.

Edited by - Technical on 02/07/2007 23:17:41

I'm using 5.1.4 Editor and A0 firmware.

Still showing discrepancy between syntax-check byte count and download byte count. Is this something I'm just going to have to live with?

As explained above, vA.0 firmware may always have a slightly longer download, depending on commands used. Later firmware versions do not.

Jeremy : I think you're having one of those &quot;not sinking in&quot; days we all have at times <img src="smile.gif" width=15 height=15 align=middle>

When syntax checking a 28X1 the compiler assumes the PICAXE will be an A.1 or greater version but doesn't check it is. The byte count is how big the program would be on A.1 and up.

When you actually download, the Programming Editor realises the PICAXE is A.0 and knows the code would not run as expected. There is a slight delay while the compiler is re-run and told it must re-compile for A.0 firmware. It applies the hotfixes necessary, creates a bigger program as a consequence, downloads that and reports how big it was.

So compiling ...<code><pre><font size=2 face='Courier'> #picaxe28x1
pin0 = 1 </font></pre></code> is &quot;5 bytes of 4096&quot; when syntax checked, but &quot;19 bytes of 4096&quot; when downloaded - An increase of 14 bytes. Other commands do not need hotfixes so the sizes would match in those cases.

The ideal solution would be if Rev-Ed added a View-&gt;Options checkbox to force compilation for the A.0 version.

There is a possible hack though, not fully tested nor guaranteed. In the <i>\Programming Editor\Compiler </i> directory ...<code><pre><font size=2 face='Courier'> REN axe28x1.exe axe28x1.old
COPY axe28x1_0.exe axe28x1.exe </font></pre></code> Syntax checking will then run the compiler for A.0 so the byte count will be correct and match that downloaded later.

Compiled tokens can still be downloaded to A.1 upwards and should run without problems, but they will include the hotfixes necessary for A.0 which are not needed for later versions.

Best to re-boot after the file renaming to flush any caching of .EXE files done by Windows.

Edited by - hippy on 16/07/2007 15:46:54

To Technical : There does seem to be a bug with 5.1.4 in standard configuration ( .EXE's as supplied ).

Compile &quot;pin0=1&quot; is &quot;5 bytes&quot; on syntax check &quot;19 bytes&quot; on download for A.0.

With multiple &quot;pin0=1&quot; commands, &quot;2728 bytes&quot; on syntax check, &quot;2729 bytes&quot; on download.

Suspect the compile for A.0 failed as code greater than 4096 but failure not detected prior to download.

Yes, it's taken a while to sink (got mental buffer overflow at the mo!) ...thanks for explaining. The bottom line seems to be that I need to get upgraded firmware to squeeze every drop out of a 28X1.

Edited by - jeremy leach on 16/07/2007 22:12:58