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

From: Mark Jones (nntp-user_at_hackerjones.org)
Date: 11/02/04

  • Next message: CBFalconer: "Re: Warning on migrating to ATMega8515 - eeprom problem" 
    Date: Tue, 02 Nov 2004 02:50:19 GMT

    Take a look at minilzo

    Mark

    Roberto Waltman wrote:
    > 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]
    >

  • Next message: CBFalconer: "Re: Warning on migrating to ATMega8515 - eeprom problem"