[Openec] RFC: One-Wire-Filesystem (owfs) for charging battery on XO and openec, (long)

[Frieder Ferlemann]

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".