Optimizing memory use

First a couple of things about the inner workings of the controller must be known to be able to determine which savings may help the situation and which have no useful effect. The controller has two memory banks. One bank is used for loaded object names, learned infrared signals, the thermostat schedule and the TV event log. The other bank is used for pretty much everything else. This includes among other things object tables, action code, RAM video screens, custom TV menu system, text storage buffer, serial port buffers, sunrise and sunset data, and all kinds of settings. The data log will use available space from both banks.

The description above should make clear that when you are running out of space for action code (the most common space problem), it doesn't help to reduce the number of object names you load into the controller or turn learned infrared signals into standard infrared signals. That information is stored in a different memory bank which can't be used for action code.

For some purposes the Homevision controller works with memory segments of 256 bytes. The most interesting examples related to memory optimization are the object tables. Even if an object table only needs a few bytes of a segment, the whole segment is reserved for that object table.

Below is a table listing the sizes of object table entries for each type of object:

Since the action code space is usualy the first thing to become scarce, here are a few suggestions on what can be done to fit more actions in the limited amount of memory available:

HomeVisionXL memory optimization

The CSI Homevision software always reserves space for the maximum number of objects of each type. HomeVisionXL has an "Optimize memory use" setting on the "Advanced" tab of the Software preferences screen (default on) that will make sure only as many segments as needed to fit the defined objects are taken.

Unused objects

As described above, HomeVisionXL will reserve space for all defined objects. So if you have unused objects in your object tables, they take up space. Using the HomeVisionXL Reorder tool these objects can be moved to the end of the object table after which they can be deleted.

Using scheduled- and periodic events as macros

When you run out of macros it is possible to use disabled scheduled events and periodic events for the same purpose. When doing that, periodic events take less space than scheduled events. For example 30 scheduled events used as macros will use 2 segments, while 30 periodic events only need 1 segment.

Object table sizes

Even though HomeVisionXL uses the minimum number of segments needed to store each object table, sometimes this still turns out less than optimal. So it may be useful to calculate the sizes of the object tables by hand and change some things to save some memory. For example: Your schedule has 90 macros and 15 scheduled events. Using the object entry size table you can calculate that the macro object table needs 3 segments and the scheduled event table requires 1 segment. However, if you would use 5 disabled scheduled events as macros, the scheduled event table still fits in 1 segment, while the macro table can now fit in 2 segments. This saves 256 bytes.

Determining code size

On many occasions there are several ways to write code that achieve the same results. You can use the experimental action editor to figure out if either method uses less memory space. Just enter each version into the editor in turn and save it. The current action size value will then indicate exactly how many bytes of memory will be used by that action. Note that each action has two bytes of overhead.

Repeated serial strings

Most commands are only 3 or 4 bytes long. Serial strings are relatively expensive because they use 1 byte per character in addition to the 3 bytes for the command. So try to avoid duplicating serial strings of more than a few characters. For example, don't use:

If
   Flag #25 (Door) is set
Then
   Serial port 1 (Main serial port): Transmit string 'tts string "The door is open"'
Else
   Serial port 1 (Main serial port): Transmit string 'tts string "The door is closed"'
End If

But instead use:

Serial port 1 (Main serial port): Transmit string 'tts string "The door is '
If
   Flag #25 (Door) is set
Then
   Serial port 1 (Main serial port): Transmit string 'open"'
Else
   Serial port 1 (Main serial port): Transmit string 'closed"'
End If

That saves 21 bytes. You can make macros for strings that you use frequently throughout your schedule.

Note: Don't fall into the trap of moving the closing double quote into a separate Transmit string command after the if-then-else. That will actualy increase the size of the code by 2 bytes.

Transmit Carriage return and Line feed

The "Transmit Carriage return and Line feed" command takes 3 bytes. If you put this command directly behind a "Transmit ASCII string" command, it will save 1 byte to include the cariage return and line feed in the ASCII string (press Shift-Enter in the "Enter Text" box). While 1 byte may not sound like a lot, if you have many "Transmit Carriage return and Line feed" commands it still adds up.

X-10 objects

If you don't use any X-10, switch off the "Enable X-10 function" option on the Functions tab of the Controller Settings. That will save 2816 bytes.

RAM video screens

Each RAM video screen uses 264 bytes. So every RAM video screen you can do without will save 264 bytes. If you don't use RAM video screens at all, be sure to switch off the "Enable RAM video screens" option on the Video tab of the Controller Settings screen, otherwise space is reserved for at least one RAM video screen.

Custom TV menu system

The Custom TV menu system uses 480 bytes + 294 bytes per screen. Switch it off on the Video tab of the Controller Settings screen if you are pressed for space and don't need the custom TV menu system.

Lookup tables

Each lookup table takes 256 bytes of memory. So if you only need to translate a few values it may be cheaper memory-wise to handle that in a couple of if-then commands.