1. Home
  2. Embedded Programming
  3. Compression method to speed up CAN software download. (Or for low end processors in general)

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

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]
Reply to
Roberto Waltman
Loading thread data ...

... snip ...

... snip ...

... snip ...

Get the "Data Compression Book", by Nelson Gailly. I believe the only troublesome patent is on LZW encoding, and I think it just ran out. LZSS and LZ77 are, I believe, trouble free. They have extremely simple expansion systems, so having that code in the destination will not hurt. All you need is a way to inject a boot system and run it. It can then capture a larger boot, which then loads the whole image compressed.

Look in the open source coding for gzip, zip, upx. Hunt on upx and info-zip. You can expect 2 or 3 times compression from these, especially if part of your load is preinitialized to zero variables. The hard work is compressing it. I got a 4x speedup for a similar application back around '88.

I believe there is a newsgroup in the comp hierarchy on compression. Also I suspect your easiest path is via UPX, which in turn is available on sourceforge (I think).

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
Reply to
CBFalconer

[SNIP]

How large are the S/W images you need to download, and do you expect many different nodes on the same bus?

Can you split the system up into multiple CAN busses to spread the load?

If the modules are to be supplied through external vendors, how do you expect the decompression part to be executed? Will you be working with those vendors to include your routines? Or will you use a bootstrap system to load your own 'decompression loader' before the real software comes in?

Rob

Reply to
Rob Turk

These statements are somewhat mutually exclusive ?

ZIP schemes will impact the resource of the nodes, and will require larger boot loaders.

Better would be to have a Checksum/Version handshake, and ONLY download the code that has changed. This could be Firstly on Whole SW, then on a BLOCK basis. You could then specify to your suppliers, that they follow simple Compile/LINK rules to keep stable code first.

You don't really want to download ALL code, on every power cycle, but download only when some version change is detected on the relevent node(s).

-jg

Reply to
Jim Granville

If there are many nodes with identical software and they power up at about the same, you could consider broadcasting the program to all nodes simultaneously. Divide the program into say 32-128 byte pages and when the first node requests a full download, send all pages and the first node will capture all pages. If other nodes are powered up during the data transfer, they can capture the end of the transmission and later request the missing pages. This way, the data may need to be transmitted 2-3 times even if there are a large number of identical nodes on the network.

At 125 kbit/s a frame is received about once every millisecond, so the node interrupt service routine must be able to handle the received frame within that time. If this is not possible, the page size should be limited so that the page fits into the FIFO (is SJA1000 style controller is used) or multiple capture registers are used with Intel style controllers, with a suitable message ID distribution within the page.

Paul

Reply to
Paul Keinanen

Take a look at minilzo

Mark

Roberto Waltman wrote:

Reply to
Mark Jones

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.