<br><br><div><span class="gmail_quote">On 9/3/07, <b class="gmail_sendername">Frieder Ferlemann</b> &lt;<a href="mailto:frieder.ferlemann@web.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">frieder.ferlemann@web.de
</a>&gt; 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 Rafael,<br><br>Rafael Enrique Ortiz Guerrero schrieb:<br>&gt;&gt; Temperature, Current, accumulated Current, EEPROM data, etc.<br>&gt;&gt; could be accessed by reading/writing text files<br>&gt;&gt; <a href="http://owfs.sourceforge.net/shell_hints.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://owfs.sourceforge.net/shell_hints.html</a><br>&gt;<br>&gt;<br>&gt;&nbsp;&nbsp;how to do this with the actual XO system?<br><br>Well currently the EC is not supported as hardware<br>adapter for owfs. Changing this would mean<br>

writing/changing a linux driver.<br>Not too easy.<br>Accessing the data on an external battery would<br>be much more straightforward. One way would be:<br>(soldering the 4 diode, 1 resistor solution here:<br><a href="http://owfs.sourceforge.net/adapters.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://owfs.sourceforge.net/adapters.html</a> , connect<br>this to an USB to Serialadapter, install owfs on<br>the XO or on a plain Linux PC) and, well, there<br>you are.<br>You can then try out accessing/reacting on the
<br>
data from the external battery.<br>(and later if the owfs were implemented for the<br>EC you&#39;d only have to use a different directory name...)</blockquote><div><br>this is ok..<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

&gt; ..could be a nice way to see whats inside the actual ds2756 EEPROM..i dont<br>&gt; know if that breaks any rule, but the data in there is the actual base of<br><br>Please don&#39;t test.</blockquote><div><br>ok :) <br>

</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; the so called charging algorithm.<br><br>Well that idea is part of the patent mentioned over here:
<br><a href="http://lists.laptop.org/pipermail/openec/2007-August/000064.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://lists.laptop.org/pipermail/openec/2007-August/000064.html</a><br>
<br><br>&gt; 2) how would it be used within XO<br>&gt;&gt; =================================
<br>&gt;&gt; A task in linux user space would periodically (and/or on<br>&gt;&gt; notification) read the data from the appropriate files<br>&gt;&gt; and based on that give directions to the EC.<br>&gt;&gt; These directions would tell the EC what to do now and
<br>&gt;&gt; what to do next.<br>&gt;&gt;<br>&gt;&gt; The charging algorithms will basically react on entities like:<br>&gt;&gt; (t, I, V, R, T, I*t, dV/dt, dT/dt).<br>&gt;&gt; So if one of these entities leaves a specified intervall the
<br>&gt;&gt; EC would &quot;know&quot; what to do next (without having to know a<br>&gt;&gt; bigger view) and then notify the host that it needs<br>&gt;&gt; updated directions.<br>&gt;&gt;<br>&gt;&gt; By checking f.e. entity t (time) the EC would react
<br>&gt;&gt; as a dumb timebased charger, monitoring dV/dt would allow<br>&gt;&gt; for a charge end due to voltage drop (not that this is intended),<br>&gt;&gt; T or dT/dt would allow for charge end due to temperature<br>

&gt;&gt; or temperature rise (not that this is intended),<br>&gt;&gt; V would allow for charge end due to end voltage reached...<br>&gt;&gt;<br>&gt;&gt; Note the above mentioned modes are not meant to be the<br>&gt;&gt; charging modes, just the direction given to the EC
<br>&gt;&gt; so it can react autonomously for the next few seconds<br>&gt;&gt; or tens of seconds.<br>&gt;&gt;<br>&gt;&gt; There should be no hard real time requirements on the<br>&gt;&gt; linux user space code.<br>&gt;<br>

&gt;<br>&gt;<br>&gt;<br>&gt;&gt; Nice approach, the only problem is that we will lose the actual power<br>&gt;&gt; management advantages of the EC. because for doing so we have to tell the<br>&gt;&gt; CPU to be wake up..my understanding of the ec is that it can work even with
<br>&gt;&gt; a the CPU is idle (richard or joel can correct me if im wrong)&nbsp;&nbsp; so we will<br>&gt;&gt; become more CPU dependent and thus more power consuming.<br><br>If we consider Low Current Charging mode to have around 400mA
<br>charging current and the EC during most of the charging would<br>require one CPU intervention (just using some boguous numbers<br>of say 100ms duration and 5W) every 60 seconds,<br><br>then the battery would have got 400mA * 60s * 6V = 144 Joule
<br>while the XO consumed 0.5 Joule.<br>Would that be a problem?</blockquote><div><br>this is not a problem&nbsp; AFAik <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Does resuming the XO (while in low current charging mode)<br>change the current into/out the battery?<br>(might be a problem)</blockquote><div><br>this is *the*&nbsp; problem,&nbsp; because we have to be resuming even when we should not, (and&nbsp; even for a&nbsp; short time) .. so we have to ensure what albert says
<br><br>1. start with XO fully off<br>2. add battery and external power<br>3. let XO charge (do not boot)<br><br>As a work around we should use frieders implementation, and for doing that (in my point of view) we will need to learn a way to hack ohm&nbsp; for doing it in a manner that does not need a complete boot of the system, like for example use some button for beginning the process of charging, like the current implementation of the porwer button that does the function&nbsp; of suspend/resume or better opening&nbsp; the lid..(so the charging process takes place in suspend), but anyway im not an expert in ohm and how is it working in the XO. 
<br><br>Now for me&nbsp; the best solution (although more complex) for me will be making measurements of the battery through ofws, and then putting this data in the rought one wire algorithm,<br><br>so the next question is how we can program the kb3700/8051 to do the 1 wire connection with the ds2657..?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Greetings,<br><br>Frieder<br></blockquote></div><br><br clear="all"><br>-- <br>Rafael Enrique Ortiz Guerrero <br>OLPC Colombia<br><a href="http://wiki.laptop.org/go/OLPC_Colombia" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://wiki.laptop.org/go/OLPC_Colombia</a>
<br><a href="mailto:rafael@laptop.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rafael@laptop.org</a>