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

Sun Sep 2 09:17:14 EDT 2007

Hi all.

Some newbie questions
>
>
> 1) what is OWFS?
> ================
> The One-Wire-Filesystem allows to access data on 1-wire devices
> as if they were a file within a directory.
>
> http://sf.net/projects/owfs
>
> The ds2756 is already listed here, so parts are already in place:
> http://www.owfs.org/index.php?page=standard-devices
>
> 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?

..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
the so called charging algorithm.

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

Yes this is true..but see the discussion above.

5) what does it empower people to do
> ====================================
> Well you could run the charging code on _any_ linux system which
> there is one-wire-filesystem support for.
>
> The adapter can be as simple as an RS232 connector and a
> few diodes/resistors or be an off-the-shelf USB to One-Wire adapter.
>
> One example: If you to develop/evaluate a charging algorithm
> and want to do so in a larger scale, you could implement the
> algorithm on a linux PC, connect a few resistors/transistors
> controlling charge/discharge current to the parallel port
> of the PC and give it a go.
> You can evaluate on _several_ cells (and eventually several
> algorithms, or different load profiles) at a time.
> (This could be a nice subject for several diploma theses).
>
> Each cell would have its own ds2576 connected to it so you
> would need _much_ less XO battery packs:)
>
>
> Another example: Also (probably not a good idea) of course
> the XO or the school-server itself could be controlling
> the gang charger as well...
>
>
Really cool!!

-- 
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/20070902/916962da/attachment.htm 