Hi frieder,<br><br>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 .
<br><br><div><span class="gmail_quote">On 10/7/07, <b class="gmail_sendername">Frieder Ferlemann</b> <<a href="mailto:frieder.ferlemann@web.de">frieder.ferlemann@web.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br><br>I just added the files charge_sched.c and charge_sched.h which would<br>implement kind of a scheduler as mentioned in section 2) and 3)<br>in the RFC (posted 20070902).<br><br><a href="http://dev.laptop.org/git?p=projects/openec;a=commitdiff;h=53ca1c7bcc9dbfe7c945b36219df02227ed6ebd3">
http://dev.laptop.org/git?p=projects/openec;a=commitdiff;h=53ca1c7bcc9dbfe7c945b36219df02227ed6ebd3</a><br><br>Would that make sense?<br><br>Greetings,<br>Frieder<br><br><br><br><br>Please take my excuses for top-posting:
<br><br><br>> 2) how would it be used within XO<br>> =================================<br>> A task in linux user space would periodically (and/or on<br>> notification) read the data from the appropriate files<br>
> and based on that give directions to the EC.<br>> These directions would tell the EC what to do now and<br>> what to do next.<br>><br>> The charging algorithms will basically react on entities like:<br>> (t, I, V, R, T, I*t, dV/dt, dT/dt).
<br>> So if one of these entities leaves a specified intervall the<br>> EC would "know" what to do next (without having to know a<br>> bigger view) and then notify the host that it needs<br>> updated directions.
<br>><br>> By checking f.e. entity t (time) the EC would react<br>> as a dumb timebased charger, monitoring dV/dt would allow<br>> for a charge end due to voltage drop (not that this is intended),<br>> T or dT/dt would allow for charge end due to temperature
<br>> or temperature rise (not that this is intended),<br>> V would allow for charge end due to end voltage reached...<br>><br>> Note the above mentioned modes are not meant to be the<br>> charging modes, just the direction given to the EC
<br>> so it can react autonomously for the next few seconds<br>> or tens of seconds.<br>><br>> There should be no hard real time requirements on the<br>> linux user space code.<br>><br>><br>> 3) why having charging algorithms within the EC itself might
<br>> not be the best approach<br>> ============================================================<br>> The resources within the EC are pretty low (RAM is 128 byte<br>> idata memory, 2kByte xdata memory).<br>
> While one can it is not really a good idea to have floating<br>> point operations on the EC. (Linux kernel does not either)<br>> The 2kByte do not allow an elaborated charging algorithm<br>> to use a longer history.
<br>><br>> If charging algorithms change/improve or as new batteries<br>> or new battery types are used this would mean updating the<br>> EC code. (Of course updating can be done but the scheme<br>> proposed under 2) would not need this)
<br>><br>> There might be patent implications with the proprietary<br>> charging algorithm (Goldpeak seems to want to patent it<br>> but who knows whether the algorithm itself is not covered<br>> by another patent). If the charging algorithm resides
<br>> in linux user space it can be exchanged quickly.<br>> It would f.e. be no fun to change an algorithm on the EC<br>> that has been converted from floating point to integer<br>> arithmetic for another algorithm. Linux user space code
<br>> on the other hand could be a "quickly moving target".<br>_______________________________________________<br>Openec mailing list<br><a href="mailto:Openec@lists.laptop.org">Openec@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/openec">http://lists.laptop.org/listinfo/openec</a><br></blockquote></div><br><br clear="all"><br>-- <br>Rafael Enrique Ortiz Guerrero <br>One Laptop Per Child<br><a href="mailto:rafael@laptop.org">
rafael@laptop.org</a>