[Openec] Patented NiMH charging algorithm

[Frieder Ferlemann]

Hi Albert,

Albert Cahalan schrieb:
> On 8/14/07, Richard A. Smith <richard at laptop.org> wrote:
> 
>> So if a LLNMH algorithm is to be produced it will probably have to be
>> reverse engineered from what ever we are allowed to release and from the
>> existing EC binary.

It's not certain that a reverse engineering approach
will necessarily turn out to give the best result.

If we accept a medium time scale (whatever that is)
for openec then modelling the chemistry and evaluating
near optimal charge algorithms for the XO would for example
be a very motivating factor for students doing their
diploma theses and their supervisors.

And with the experience there it is not unlikely that
quite a lot of "prior art" is dug out during this process,
so at least large parts will be unencumbered by patent claims.

After all it is deciding about adapting charge current based on
parameters like (t, I, V, R, T, and their respective histories).
It might turn out to be a subset of the problems that have been
encountered some ten years or some ten thousand years ago
when watering agriculture or nowadays when trying to
model/react on things that happen at stock exchanges.


> We could use an open source clone of IDA Pro. :-(
> That would make a wonderful mesh-shared activity BTW.
> (disassembly is most productive with people sitting
> next to each other discussing the code)
> 
> We can certainly manage with objdump and a script
> to add comments. (when you give a friendly label to
> an address, you want it to appear at all usage sites)

Maybe it's a good decision to decide not to look
at the code because a medium time scale allows to come
up with something at least on par?!


Technically the stuff to do it is there (except for the
collaborative part).
dd the first 64k of the OLPC image somewhere. cp the file
openec.ctl (within openec git repository) there too and rename it,
then run d52 over the binary and look at the .d52 file.
Adapt the .ctl file as you proceed.
I use d52 for my own code because d52 can add instruction
cycles (something which SDCC does not do) and because
it allows to see the relocated startup code without
further ado.


> I've seen it done for the CVS camcorder, which was
> running the same OS as the Marvell chip.
> 
> An EC emulator would be good to have. Maybe qemu could be
> hacked to have OLPC hardware, complete with separate threads
> for emulating the EC chip and Marvell chip.
> 
> A gcc port would be great. This isn't crazy; gcc does support
> some 8-bit stuff.

Not within a "medium" time scale:) I'm not sure the gcc folks
would like to carry around the quirks of the 8051 architecture
(designed some thirty years ago with overlapping memory spaces
and no efficient method to access data (let alone 32 bit data)
on the stack).
Other 8-bit architectures (avr/hc12/younameit) are fine.


If gcc decides to support mcs-51 then at least the first
steps of openec will show _very_ little resistance:
There is a file Makefile.gcc in the git repository which allows
to compile openec with gcc!

This means: At the moment you can compile and run and debug openec
on f.e. an i386 or Geode LX.
You only, ouch, only have to poke the volatile registers
to their respective values at the appropriate time
and invoke the interrupt functions when they'd would be
called by the 8051... likely too clumsy to be practical
but it could be done.

Greetings,

Frieder