On Wed, 2004-06-16 at 18:01, Greger Cronquist wrote:
> Hi again,
>
> This issue solved itself rather annoyingly since we use flash memory in
> our newer devices (which had slipped my mind). So we must erase the
> memory first and then load.
Last time I played with flash, you could erase a block
Hi again,
This issue solved itself rather annoyingly since we use flash memory in
our newer devices (which had slipped my mind). So we must erase the
memory first and then load.
Cheers, Greger
Donovan Baarda wrote:
G'day,
From: "Greger Cronquist" <[EMAIL PROTECTED]>
[...]
compiled binaries ar
G'day,
From: "Greger Cronquist" <[EMAIL PROTECTED]>
[...]
> >compiled binaries are often very different for only minor source
> >changes. It would be worth analysing your data to see if there are more
[...]
> Is that really true---that the binaries differ that much? Isn't that
> mostly due to relo
Donovan Baarda wrote:
The algorithm sacrifices CPU to minimise data transfer when updating it.
For it to be worth it, you must already have similar data that needs
updating, and data transfer must be expensive relative to CPU.
Often with embedded systems you are loading programs from scratch, so
th
On Tue, 2004-06-01 at 17:44, Greger Cronquist wrote:
> Hi,
>
> Has anyone considered using the rsync algorithm for loading programs on
> embedded platforms? I.e. with low cpu power (say, 16-25 MHz ARM7) and
> low memory requirements (programs are < 128 KB, and the rsync algorithm
I've been doi
Hi,
Has anyone considered using the rsync algorithm for loading programs on
embedded platforms? I.e. with low cpu power (say, 16-25 MHz ARM7) and
low memory requirements (programs are < 128 KB, and the rsync algorithm
must use little ROM and RAM). Or is it just not worth the effort?
I guess you
