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

[Frieder Ferlemann]

Hi Rafael,

Rafael Enrique Ortiz Guerrero schrieb:
>> Temperature, Current, accumulated Current, EEPROM data, etc.
>> could be accessed by reading/writing text files
>> http://owfs.sourceforge.net/shell_hints.html
> 
> 
>  how to do this with the actual XO system?

Well currently the EC is not supported as hardware
adapter for owfs. Changing this would mean
writing/changing a linux driver.
Not too easy.
Accessing the data on an external battery would
be much more straightforward. One way would be:
(soldering the 4 diode, 1 resistor solution here:
http://owfs.sourceforge.net/adapters.html , connect
this to an USB to Serialadapter, install owfs on
the XO or on a plain Linux PC) and, well, there
you are.
You can then try out accessing/reacting on the
data from the external battery.
(and later if the owfs were implemented for the
EC you'd only have to use a different directory name...)


> ..could be a nice way to see whats inside the actual ds2756 EEPROM..i dont
> know if that breaks any rule, but the data in there is the actual base of

Please don't test.

> the so called charging algorithm.

Well that idea is part of the patent mentioned over here:
http://lists.laptop.org/pipermail/openec/2007-August/000064.html


> 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.
> 
> 
> 
> 
>> Nice approach, the only problem is that we will lose the actual power
>> management advantages of the EC. because for doing so we have to tell the
>> CPU to be wake up..my understanding of the ec is that it can work even with
>> a the CPU is idle (richard or joel can correct me if im wrong)   so we will
>> become more CPU dependent and thus more power consuming.

If we consider Low Current Charging mode to have around 400mA
charging current and the EC during most of the charging would
require one CPU intervention (just using some boguous numbers
of say 100ms duration and 5W) every 60 seconds,

then the battery would have got 400mA * 60s * 6V = 144 Joule
while the XO consumed 0.5 Joule.
Would that be a problem?

Does resuming the XO (while in low current charging mode)
change the current into/out the battery?
(might be a problem)

Greetings,

Frieder