Compression method to speed up CAN software download. (Or for low end processors in general)

From: Roberto Waltman (usenet_at_rwaltman.net)
Date: 10/31/04 

Date: Sun, 31 Oct 2004 16:05:20 -0500

I'm looking for advice on patent / royalty free compression /
decompression algorithms to use on low end microcontrollers.

This is the background:

I am currently written the specs for a CAN based control / monitor
protocol for a distributed telecom system. I'll be using the basic 0
to 8 bytes CAN packet format, not higher level protocols like CANOpen,
etc.

One of the system wide design constraints I need to follow, is that
all secondary processors, (there are many,) will download their
software from a master controller when they power up.

I originally specified a conservative 250 Kbit/sec CAN bus rate. I
just learned that some of the nodes in the CAN bus will use a
fault-tolerant transceiver that limits the bus speed to 125 Kbit/sec.
So all my time estimates are off...

This will not be a problem for the normal operation of the system once
everything is up and running, but may be very noticeable in longer
than tolerable delays from the moment the system powers up, until it
is fully operational.

I am now reworking things trying to speed up the SW download. One
thing I'll do is to use a different protocol for SW download to allow
using one or two bytes in the CAN message-id as additional data
payload.

Another thing I want to add, is to require that the SW image to be
downloaded should be compressed.

My question is, what compression method to use?

I have no control over the hardware of some of the nodes in the CAN
bus. (They are supplied by outside vendors.) They will have processors
vaguely ranging from high-end 8 biters to low-end 16 bit MCUs.

I am thinking of using the well known zip or bzip2 algorithms, but I
do not want to force our vendors to move to a higher power CPU,
include more memory in their designs, etc., just to support the
decompression algorithm.

Any other methods out there I should consider?

Thanks,

Roberto Waltman

[Please reply to the group. The
 reply-to address is invalid]

Relevant Pages