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

Tue Sep 4 01:23:13 EDT 2007

On 9/3/07, Frieder Ferlemann <frieder.ferlemann at web.de> wrote:
>
> 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...)

this is ok..

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

ok :)

> 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?

this is not a problem  AFAik

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

this is *the*  problem,  because we have to be resuming even when we should
not, (and  even for a  short time) .. so we have to ensure what albert says

1. start with XO fully off
2. add battery and external power
3. let XO charge (do not boot)

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  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  of
suspend/resume or better opening  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.

Now for me  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,

so the next question is how we can program the kb3700/8051 to do the 1 wire
connection with the ds2657..?

Greetings,
>
> Frieder
>

-- 
Rafael Enrique Ortiz Guerrero
OLPC Colombia
http://wiki.laptop.org/go/OLPC_Colombia
rafael at laptop.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/openec/attachments/20070904/232c7bb9/attachment.htm 