[Openec] RFC: One-Wire-Filesystem (owfs) for charging battery on XO and openec, (long)
Rafael Enrique Ortiz Guerrero
dirakx at gmail.com
Mon Oct 8 10:43:27 EDT 2007
For me is a really good idea, but i dont know if the charging algorithm for
the NIMH is an issue anymore, because afaik these batteries are not going
to be deployed and the LIFe batteries have a really easy charging algorithm,
something like a voltage threshold..but anyway the scheduler feature is a
very good way of collecting data, for both kinds of batteries .
On 10/7/07, Frieder Ferlemann <frieder.ferlemann at web.de> wrote:
> Hi all,
> I just added the files charge_sched.c and charge_sched.h which would
> implement kind of a scheduler as mentioned in section 2) and 3)
> in the RFC (posted 20070902).
> Would that make sense?
> Please take my excuses for top-posting:
> > 2) how would it be used within XO
> > =================================
> > A task in linux user space would periodically (and/or on
> > notification) read the data from the appropriate files
> > and based on that give directions to the EC.
> > These directions would tell the EC what to do now and
> > what to do next.
> > The charging algorithms will basically react on entities like:
> > (t, I, V, R, T, I*t, dV/dt, dT/dt).
> > So if one of these entities leaves a specified intervall the
> > EC would "know" what to do next (without having to know a
> > bigger view) and then notify the host that it needs
> > updated directions.
> > By checking f.e. entity t (time) the EC would react
> > as a dumb timebased charger, monitoring dV/dt would allow
> > for a charge end due to voltage drop (not that this is intended),
> > T or dT/dt would allow for charge end due to temperature
> > or temperature rise (not that this is intended),
> > V would allow for charge end due to end voltage reached...
> > Note the above mentioned modes are not meant to be the
> > charging modes, just the direction given to the EC
> > so it can react autonomously for the next few seconds
> > or tens of seconds.
> > There should be no hard real time requirements on the
> > linux user space code.
> > 3) why having charging algorithms within the EC itself might
> > not be the best approach
> > ============================================================
> > The resources within the EC are pretty low (RAM is 128 byte
> > idata memory, 2kByte xdata memory).
> > While one can it is not really a good idea to have floating
> > point operations on the EC. (Linux kernel does not either)
> > The 2kByte do not allow an elaborated charging algorithm
> > to use a longer history.
> > If charging algorithms change/improve or as new batteries
> > or new battery types are used this would mean updating the
> > EC code. (Of course updating can be done but the scheme
> > proposed under 2) would not need this)
> > There might be patent implications with the proprietary
> > charging algorithm (Goldpeak seems to want to patent it
> > but who knows whether the algorithm itself is not covered
> > by another patent). If the charging algorithm resides
> > in linux user space it can be exchanged quickly.
> > It would f.e. be no fun to change an algorithm on the EC
> > that has been converted from floating point to integer
> > arithmetic for another algorithm. Linux user space code
> > on the other hand could be a "quickly moving target".
> Openec mailing list
> Openec at lists.laptop.org
Rafael Enrique Ortiz Guerrero
One Laptop Per Child
rafael at laptop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openec