Optimizing memory use

When the HomeVision schedule gets too big to fit in the available memory of the controller, there may be a few things that can be done to use the memory more efficiently.

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:

Object typeSize
X-10 module11 bytes
Flag4 bytes
Variable4 bytes
Timer10 bytes
Input port9 bytes
Output port5 bytes
Infrared signal11 bytes
Macro6 bytes
Scheduled event11 bytes
Periodic event6 bytes
Analog input6 bytes
Custom light7 bytes
Digital temperature sensor8 bytes

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:
   Flag #25 (Door) is set
   Serial port 1 (Main serial port): Transmit string 'tts string "The door is open"'
   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 '
   Flag #25 (Door) is set
   Serial port 1 (Main serial port): Transmit string 'open"'
   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.
Last modified: 20 May 2010, 15:10 CEST