Migrating to Version 2.6

[mikep]

I have migrated my native mode application to the new release. This is a non-trivial application with 6 tasks (including main).

First thing I found was that the code would no longer link. I specify the size of the stack for the main task and so the heap was now defaulting to 512 bytes. The remedy is to add the following line:

Code: Select all

Option HeapReserve 128

Out of 4K RAM I have 70 bytes left. I can tell this by using the following:

Code: Select all

Option HeapReserve 199

which fails with the message

Code: Select all

Error: statically allocated variables plus the specified main task stack size and the heap reserve (199) exceeds the available RAM (4096)

The code size grew from 19184 bytes to 19242 bytes. It would appear that this is due entirely to code changes with zxLib.

On investigation of the source code to see what had changed I noticed several cleanup items:
1. Double casts are removed (uint16_t)(uint16_t) becomes (uint16_t)
2. The order of generation has changed so that for example all static function declarations are first
3. Instead of declaring byte data for word and dword arrays, the proper type is used instead.

[dkinzer]

the heap was now defaulting to 512 bytes. The remedy is to add the following line:

Code: Select all

Option HeapReserve 128

The default heap reserve has always been 512 bytes; no change there. The difference is that in earlier compiler versions the heap reserve was not being taken into account when computing the aggregate RAM use. The upshot of this was that the RAM use of your application could actually be exceeding the available RAM and the compiler did not report it. The new version takes the heap reserve into account (whether it is the default or it is explicitly specified).

In your particular case, changing the amount of space reserved to 128 bytes may be appropriate while in other cases, it may not be. You can use System.HeapHeadRoom (after vigorous exercising of the application) to get an indication of how much heap space is being used. It is important to note that any native mode application that writes to Program Memory (via read/write ProgramMemory data items or otherwise) will require a heap that is large enough to allocate a temporary buffer that is used to perform the read-modify-write operation on Program Memory. The size of this buffer varies depending on the Flash page size of the underlying AVR device but it is typically 256 bytes.

[spamiam]

....It is important to note that any native mode application that writes to Program Memory (via read/write ProgramMemory data items or otherwise) will require a heap that is large enough to allocate a temporary buffer that is used to perform the read-modify-write operation on Program Memory. The size of this buffer varies depending on the Flash page size of the underlying AVR device but it is typically 256 bytes.

Sorrry for being off topic, somewhat....

As I recall, only code residing in the bootloader section can WRITE to flash (program memory), is that not correct?

If so, this is a very interesting side-effect of having some of the ZBasic native mode code (I suppose it would be considered the "kernel"?) living in the bootloader section. I always have been intrigued by the idea of self-modifying code, and this architecture appears to allow such a process.

At the very least, it can be used for simple self-updating, but being able to modify the actual program code allows for more subtle self-determined modifications, especially in a distributed processing network which allows some degree of parallel processing. Having said that, I have no idea of an actual application that would do such a thing, but I would love to think of one!

This is somewhat similar to the thread about EEPROM-based self-modifying code that was discussed about a year ago.

-Tony