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
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
|X-10 module||11 bytes|
|Input port||9 bytes|
|Output port||5 bytes|
|Infrared signal||11 bytes|
|Scheduled event||11 bytes|
|Periodic event||6 bytes|
|Analog input||6 bytes|
|Custom light||7 bytes|
|Digital temperature sensor||8 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
- 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"'
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"'
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.