[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


Hi frieder,

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).
>
>
> http://dev.laptop.org/git?p=projects/openec;a=commitdiff;h=53ca1c7bcc9dbfe7c945b36219df02227ed6ebd3
>
> Would that make sense?
>
> Greetings,
> Frieder
>
>
>
>
> 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
> http://lists.laptop.org/listinfo/openec
>



-- 
Rafael Enrique Ortiz Guerrero
One Laptop Per Child
rafael at laptop.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/openec/attachments/20071008/ed570a4d/attachment.htm 


More information about the Openec mailing list