[Tinyos-devel] Re: look at this
Gaurav Mathur
gmathur at cs.umass.edu
Thu Aug 10 08:34:57 PDT 2006
Given our experience with building a storage system for both NAND and
NOR flash memories, I think we are mostly in-sync with the consensus
that this discussion has reached -- HIL should take advantage of
chip-specific features to optimize the performance of the
implementation, and HAL should offer chip-specific features to a
developer. It is also a good idea to add a platform and chip independent
access abstraction (possibly a simple page-offset based interface) at
the HIL, as this would be helpful for people wanting direct access to
the flash, without going through the HIL storage abstractions.
A couple of comments:
* Most of the discussion centered around optimizing the performance of
the HIL, and it is quite clear that a chip-specific implementation would
perform better than a generic one. It would be good to have some
measurements between a chip-specific and a generic implementation of the
same storage abstraction to determine the level of performance degradation.
* One of the points brought up was that having a chip-specific HIL
introduces a hurdle for anyone introducing a new storage chip;
implementing and supporting the entire HIL for a new platform is
definitely not trivial. It might be a good idea to have a "generic"
version of the HIL in TinyOS, which focuses on portability rather than
performance. This would provide a good intermediate platform before a
chip-specific HIL is released, and would also satisfy those who value
portability over performance.
While designing our storage system (Capsule
<http://www.cs.umass.edu/%7Egmathur/publications/mathur-sensys06.pdf>),
we looked at some aspects of how NAND and NOR flashes can use the same
interface and here is a summary of some of our observations.
There are a number of differences between NAND and NOR flash memories.
1. The ability to set 1 bits to 0 on NOR flash even though that location
might have been "written over" -- not supported by NAND flash
2. Writing a very large number of times to a NOR page in comparison to
NAND flash (typically 1-5 writes to a page are allowed), which mandates
writing to the flash in larger buffer sizes
3. A lot of the larger page sized NAND flash memories (hold true for
most new high-capacity chips) mandate that pages within an erase block
can be written to only sequentially.
Our approach while building the Capsule storage system was to use an
abstraction that exposes only the common features between all classes of
flash memories (going against the conclusion reached in this
discussion). Since NANDs are so much more constrained than the NOR, the
flash abstraction layer used only NAND features. For instance, the
metadata per page (8 bytes on the Mica2 NOR, 16 bytes on the NAND flash
that we used) is not exposed at all, and therefore not exploited by
Capsule. The downside to this was that certain optimizations that are
possible for the NOR cannot be used for it. The upside is that Capsule
works for both the NAND (our custom board) and NOR (Telos/Mica2)
flashes. In fact, the NOR port of Capsule after it had been built for
the NAND flash was quite trivial.
We are currently looking at exploiting some flash-specific properties
which would probably require a less generic interface, (similar to what
David Gay and Jonathan have pointed out) possibly a generic one for NOR
and another for NAND.
- Gaurav
>>> *From: *Philip Levis <pal at cs.stanford.edu <mailto:pal at cs.stanford.edu>>
>>> *Date: *July 26, 2006 6:20:00 PM EDT
>>> *To: *David Moss <dmm at rincon.com <mailto:dmm at rincon.com>>
>>> *Cc: *"'David Gay'" <dgay42 at gmail.com <mailto:dgay42 at gmail.com>>,
>>> "'Ramesh Govindan'" <ramesh at usc.edu <mailto:ramesh at usc.edu>>,
>>> tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, "'Joe Polastre'"
>>> <joe at polastre.com <mailto:joe at polastre.com>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> On Jul 26, 2006, at 11:11 AM, David Moss wrote:
>>>
>>>>
>>>> As a developer who's using this technology, time is one of my
>>>> team's most
>>>> valuable resources. If my team has to spend twice the amount of time
>>>> testing and developing code just to get it to run on two different
>>>> platforms, then that's not worth it. The fact that David Gay and
>>>> Johnathan
>>>> are both writing the same end functionality doesn't seem worth it to me
>>>> because their time is equally valuable. Trying to get people to adopt
>>>> hardware-dependant technology is much more difficult than getting
>>>> people to
>>>> adopt hardware-independent technology. If we eventually have 50
>>>> different
>>>> flash types, who's going to write and test all that code for the basic
>>>> storage implementations? Not me, and not my team. Time to erase is one
>>>> thing, but time to market is another. An increase in nitty gritty
>>>> bit-banging performance is usually not worth a delay in getting to
>>>> a robust
>>>> and finished product.
>>>>
>>>> Having optional platform-dependent and -independent interfaces is
>>>> probably
>>>> the best route to meet everyone's needs. If you want your app to work
>>>> everywhere, use the platform-independent interfaces. If you want
>>>> your app
>>>> to take full advantage of extra features on a specific chip, then
>>>> use the
>>>> implementation tailored to that hardware. Full documentation should be
>>>> provided on how these interfaces work, how to use them, and what to
>>>> expect.
>>>
>>> That sounds right to me. The most important thing is that every
>>> chip/platform meets the HIL, which must truly be independent of the
>>> underlying technology. The HAL is a way to enable developers to
>>> optimize more if need be. IIRC, none of the TEPs mandate that an
>>> implementation MUST have a HAL; instead, they mandate the HIL. For
>>> example, you can meet TEP 103 without having a HAL; it only provides
>>> some statements on what a HAL SHOULD look like.
>>>
>>> (Reading the TEP a bit more carefully, it seems that it lacks the
>>> MUST statements for the three HILs. David G., Jonathan, I assume
>>> this is an oversight?)
>>>
>>> Phil
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"Jonathan Hui" <jwhui at cs.berkeley.edu
>>> <mailto:jwhui at cs.berkeley.edu>>
>>> *Date: *July 26, 2006 3:24:44 PM EDT
>>> *To: *"David Moss" <dmm at rincon.com <mailto:dmm at rincon.com>>
>>> *Cc: *David Gay <dgay42 at gmail.com <mailto:dgay42 at gmail.com>>, Joe
>>> Polastre <joe at polastre.com <mailto:joe at polastre.com>>,
>>> tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> On 7/26/06, David Moss <dmm at rincon.com <mailto:dmm at rincon.com>> wrote:
>>>> As a developer who's using this technology, time is one of my
>>>> team's most
>>>> valuable resources. If my team has to spend twice the amount of time
>>>> testing and developing code just to get it to run on two different
>>>> platforms, then that's not worth it. The fact that David Gay and
>>>> Johnathan
>>>> are both writing the same end functionality doesn't seem worth it to me
>>>> because their time is equally valuable. Trying to get people to adopt
>>>> hardware-dependant technology is much more difficult than getting
>>>> people to
>>>> adopt hardware-independent technology. If we eventually have 50
>>>> different
>>>> flash types, who's going to write and test all that code for the basic
>>>> storage implementations? Not me, and not my team. Time to erase is one
>>>> thing, but time to market is another. An increase in nitty gritty
>>>> bit-banging performance is usually not worth a delay in getting to
>>>> a robust
>>>> and finished product.
>>>
>>> Depends what your end goals are. If you're trying maximize the
>>> performance a chip can give you while minimizing resource consumption,
>>> then having a separate implementation per chip is desireable. Note
>>> that you can do this while still providing a chip-independent
>>> interface. We have had the luxury of using "fat" nodes since they are
>>> what Crossbow, Moteiv, etc. provides. When cost is an issue, you might
>>> want to spend the extra time to do the chip-dependent optimization
>>> that still provides a chip-independent interface so that your app
>>> still works.
>>>
>>>> Having optional platform-dependent and -independent interfaces is
>>>> probably
>>>> the best route to meet everyone's needs. If you want your app to work
>>>> everywhere, use the platform-independent interfaces. If you want
>>>> your app
>>>> to take full advantage of extra features on a specific chip, then
>>>> use the
>>>> implementation tailored to that hardware. Full documentation should be
>>>> provided on how these interfaces work, how to use them, and what to
>>>> expect.
>>>
>>> Don't get me wrong, I think application portability is important. It
>>> really depends where you draw the "app" line. If most developers just
>>> want a logging abstraction, then that's what they'll use and they
>>> could care less if there's a common or different implementation for
>>> each chip. You are different in that Blackbook is your "app" (the
>>> product you're providing).
>>>
>>> To support your concerns, we should look further into what the changes
>>> should be. I'd be in favor of modifying the BlockStorage interfaces
>>> since that seems pretty close to what you need (read/write/erase) and
>>> add the erase unit gets. Then change commit() to sync() which commits
>>> to stable storage. No need to differentiate between sync() and flush()
>>> here. How does that sound?
>>>
>>>> I guess what it comes down to is, I can jump in a hybrid or a
>>>> ferrari and
>>>> expect them to behave the same when I push the pedals, without
>>>> having to
>>>> reconfigure myself, the car, or know how their engines differ.
>>>
>>> Just don't slam the gas pedal in a ferrari and expect to stay on the
>>> road ;-)
>>>
>>> --
>>> Jonathan W. Hui
>>> jwhui at cs.berkeley.edu <mailto:jwhui at cs.berkeley.edu>
>>> http://www.cs.berkeley.edu/~jwhui/
>>> <http://www.cs.berkeley.edu/%7Ejwhui/>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *Philip Levis <pal at cs.stanford.edu <mailto:pal at cs.stanford.edu>>
>>> *Date: *July 26, 2006 3:24:47 PM EDT
>>> *To: *miguel erazo <erazo_miguel at yahoo.com
>>> <mailto:erazo_miguel at yahoo.com>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>
>>> *Subject: **Re: [Tinyos-devel] Parse error in AM.h *
>>>
>>> On Jul 26, 2006, at 12:18 PM, miguel erazo wrote:
>>>
>>>> I am trying to use the component GenericComm to send packets to
>>>> UART. However, everytime I add such component I get the following
>>>> error:
>>>>
>>>> c:/tinyos/cygwin/tinyos-1.x/tos/types/AM.h:51: parse error before
>>>> '0xffff'
>>>>
>>>>
>>>> Could someone help me please?
>>>>
>>>> Thank you!
>>>>
>>>
>>> Please send questions to tinyos-help.
>>>
>>> Phil
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"David Moss" <dmm at rincon.com <mailto:dmm at rincon.com>>
>>> *Date: *July 26, 2006 2:11:43 PM EDT
>>> *To: *<tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>>
>>> *Cc: *"'David Gay'" <dgay42 at gmail.com <mailto:dgay42 at gmail.com>>,
>>> "'Joe Polastre'" <joe at polastre.com <mailto:joe at polastre.com>>,
>>> "'Ramesh Govindan'" <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **RE: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> I agree as well.
>>>
>>> I see that a lot of progress has been made in this area from 1.x -> 2.x
>>> including the compile time volume management, that's excellent. And
>>> I did
>>> confuse the HAL/HIL, but my cross-platform compatibility argument
>>> remains,
>>> and it is a difference in philosophy as Johnathan pointed out.
>>>
>>> As a developer who's using this technology, time is one of my team's
>>> most
>>> valuable resources. If my team has to spend twice the amount of time
>>> testing and developing code just to get it to run on two different
>>> platforms, then that's not worth it. The fact that David Gay and
>>> Johnathan
>>> are both writing the same end functionality doesn't seem worth it to me
>>> because their time is equally valuable. Trying to get people to adopt
>>> hardware-dependant technology is much more difficult than getting
>>> people to
>>> adopt hardware-independent technology. If we eventually have 50
>>> different
>>> flash types, who's going to write and test all that code for the basic
>>> storage implementations? Not me, and not my team. Time to erase is one
>>> thing, but time to market is another. An increase in nitty gritty
>>> bit-banging performance is usually not worth a delay in getting to a
>>> robust
>>> and finished product.
>>>
>>> Having optional platform-dependent and -independent interfaces is
>>> probably
>>> the best route to meet everyone's needs. If you want your app to work
>>> everywhere, use the platform-independent interfaces. If you want
>>> your app
>>> to take full advantage of extra features on a specific chip, then
>>> use the
>>> implementation tailored to that hardware. Full documentation should be
>>> provided on how these interfaces work, how to use them, and what to
>>> expect.
>>>
>>> I guess what it comes down to is, I can jump in a hybrid or a
>>> ferrari and
>>> expect them to behave the same when I push the pedals, without having to
>>> reconfigure myself, the car, or know how their engines differ.
>>>
>>> -David
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: joe.polastre at gmail.com [mailto:joe.polastre at gmail.com] On
>>> Behalf Of
>>> Joe Polastre
>>> Sent: Wednesday, July 26, 2006 10:45 AM
>>> To: handzisk at tkn.tu-berlin.de <mailto:handzisk at tkn.tu-berlin.de>
>>> Cc: Jonathan Hui; David Moss; tinyos-devel at millennium.berkeley.edu
>>> <mailto:tinyos-devel at millennium.berkeley.edu>; Ramesh
>>> Govindan
>>> Subject: Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th
>>>
>>>
>>>> I think that this is the best way forward. Let's see what is
>>>> missing from
>>>> the current HIL interfaces that prevent David to implement his
>>> abstraction.
>>>> If the shortcomings can be addressed with simple changes of the
>>>> existing
>>> HIL
>>>> interfaces, than this is the best way. If not, we should consider
>>> including
>>>> David's abstraction as a new HIL interface.
>>>
>>> 100% agreed.
>>>
>>> -Joe
>>>
>>>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"Vlado Handziski" <handzisk at tkn.tu-berlin.de
>>> <mailto:handzisk at tkn.tu-berlin.de>>
>>> *Date: *July 26, 2006 1:55:31 PM EDT
>>> *To: *"Joe Polastre" <joe at polastre.com <mailto:joe at polastre.com>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> On 7/26/06, *Joe Polastre* <joe at polastre.com
>>> <mailto:joe at polastre.com>> wrote:
>>>
>>> > I think that this is the best way forward. Let's see what is
>>> missing from
>>> > the current HIL interfaces that prevent David to implement his
>>> abstraction.
>>> > If the shortcomings can be addressed with simple changes of
>>> the existing HIL
>>> > interfaces, than this is the best way. If not, we should
>>> consider including
>>> > David's abstraction as a new HIL interface.
>>>
>>> 100% agreed.
>>>
>>>
>>> Just to be clear, I meant to add David's abstraction in _addition_
>>> to the existing ones, which are quite useful when one does not need
>>> all the complexity of Blackbook.
>>>
>>> Vlado
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"Joe Polastre" <joe at polastre.com <mailto:joe at polastre.com>>
>>> *Date: *July 26, 2006 1:44:46 PM EDT
>>> *To: *handzisk at tkn.tu-berlin.de <mailto:handzisk at tkn.tu-berlin.de>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>>> I think that this is the best way forward. Let's see what is
>>>> missing from
>>>> the current HIL interfaces that prevent David to implement his
>>>> abstraction.
>>>> If the shortcomings can be addressed with simple changes of the
>>>> existing HIL
>>>> interfaces, than this is the best way. If not, we should consider
>>>> including
>>>> David's abstraction as a new HIL interface.
>>>
>>> 100% agreed.
>>>
>>> -Joe
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"Vlado Handziski" <vlado.handziski at gmail.com
>>> <mailto:vlado.handziski at gmail.com>>
>>> *Date: *July 26, 2006 1:30:02 PM EDT
>>> *To: *"Jonathan Hui" <jwhui at cs.berkeley.edu
>>> <mailto:jwhui at cs.berkeley.edu>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>, Joe Polastre
>>> <joe at polastre.com <mailto:joe at polastre.com>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>> *Reply-To: *handzisk at tkn.tu-berlin.de <mailto:handzisk at tkn.tu-berlin.de>
>>>
>>>
>>> I am replying to Jonathan, but this is a general comment to all
>>> participants in the thread.
>>>
>>> On 7/26/06, *Jonathan Hui* < jwhui at cs.berkeley.edu
>>> <mailto:jwhui at cs.berkeley.edu>> wrote:
>>>
>>> On 7/25/06, Joe Polastre <joe at polastre.com
>>> <mailto:joe at polastre.com>> wrote:
>>> > David Moss makes a great point--By using get() functions
>>> combined with
>>> > the lowest common denominator, you can build Block/Config/Log
>>> above
>>> > it. If you go back and re-read the Flexible Hardware Abstraction
>>> > paper, it clearly articulates that you should use HAL
>>> interfaces for
>>> > optimal performance. For optimal hardware independence, you
>>> should
>>> > use HIL interfaces.
>>>
>>> Joe, I guess you and I differ in philosophy here. David Gay's and my
>>> goal was to not only provide hardware independence but not
>>> sacrafice a
>>> huge amount of performance in doing it. If you consider the design
>>> difference between the AT45DB and STM25P implementations, they are
>>> significant and for good reasons. More on this below.
>>>
>>>
>>> I am not sure what the disagreement is actually about. I think we
>>> all agree that the chips _are_ different and the respective HALs
>>> should represents the "best abstractions" for this particular chip,
>>> exporting the full capabilities of the hardware. The HALs should not
>>> compromise this, not even if the goal is more simple/common HIL
>>> implementation. This is completely independent from the question if
>>> the current flash HILs interfaces are the best cross-chip
>>> abstraction for implementing a filing system like Blackbook. I think
>>> David Moss confused either HAL and HIL in his original mail or the
>>> difference between a HIL interface and HIL implementation. I think
>>> that the HAA is quite clear on this.
>>>
>>>
>>> > Jonathan's comments when taken in the context of the original
>>> paper
>>> > are in conflict--The goal of the HIL is not performance but
>>> > interoperability. As such, the interface that provides the
>>> greatest
>>> > interoperability should be used at the HIL. The interfaces that
>>> > provide the greatest performance should be used at the
>>> HAL. David
>>> > Moss has made an excellent case that the current HIL
>>> interfaces are
>>> > unsuitable for building file systems in a platform independent
>>> manner.
>>> > With this feedback, I believe it is worthwhile to revisit why
>>> > Config/Block/Log are the appropriate cross-platform HIL
>>> interfaces.
>>>
>>> Sure, so we decided to take a compromise. The HILs proposed in
>>> TEP103
>>> are implemented using the proposed HALs. David Gay and I, as chip
>>> developers, decided to provide chip-specific implementations of HILs
>>> that are most likely to have higher performance than a common
>>> implementation across both.
>>>
>>>
>>> Again I think that we need to separate this discussion in two parts:
>>> 1. Are the selected HALs for the specific chips the best
>>> abstractions providing full access to the HW capabilities? and 2.
>>> What kind of HIL interfaces we think are the best for implementing
>>> chip/platform independent WSN applications using permanent external
>>> storage.
>>>
>>> The implementation of the HIL components that transform between the
>>> chip-specific HALs and the wanted HIL interface is not constrained
>>> in any way by the HAA. In some cases, when the HALs are very
>>> similar, we can achieve a common HIL component implementation (by
>>> pulling info from the lower layers using "get" as David said) thas
>>> sits on a very thin glue over the HAL components.
>>> But this is not a general requirement and is not explicitly required
>>> by the HAA. Let's take a hypothetical example where the selected HIL
>>> interface is very close to the HAL interface of one of the chips
>>> (the "best" or the "newest" one) and is quite different from the
>>> HALs of the other "older" chips. It is clear that the developer of
>>> the driver for the "best" chip will like to have a dedicated HIL
>>> component implementation that will be very thin. The driver
>>> developers for the "older" chips will have to invest more effort to
>>> implement in software all the functions required by the HIL
>>> interface that are not provided by the particular chip hardware and
>>> are not exported by its HAL.
>>>
>>> David Moss' real point is he'd like to see another HIL live
>>> along side
>>> the proposed Config/Block/Log offerings. I never said
>>> Config/Block/Log
>>> are the *only* cross-platform HIL interfaces, they are just the
>>> first
>>> three that we proposed. You can implement David Moss' proposed
>>> HIL on
>>> top of the current HALs and Blackbook would use that. In his case,
>>> he's willing to suffer the performance hit of sitting on top of an
>>> HIL.
>>>
>>>
>>> Exactly. This is a discussion about HILs and should not be confused
>>> with the HALs.
>>>
>>> The difference between Blackbook and Config/Block/Log is that it
>>> is a
>>> much more general storage system and requires much more code to
>>> maintain. So it's natural that David Moss would like to implement it
>>> on top of an HIL. In reality, his proposed HIL is pretty similar to
>>> the BlockStorage interface, and maybe some small tweaks to it would
>>> satisfy his requests. It seemed like only a few things were
>>> getting in
>>> his way, some of which have already been fixed.
>>>
>>>
>>>
>>> I think that this is the best way forward. Let's see what is missing
>>> from the current HIL interfaces that prevent David to implement his
>>> abstraction. If the shortcomings can be addressed with simple
>>> changes of the existing HIL interfaces, than this is the best way.
>>> If not, we should consider including David's abstraction as a new
>>> HIL interface.
>>>
>>> Vlado
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"David Gay" <dgay42 at gmail.com <mailto:dgay42 at gmail.com>>
>>> *Date: *July 26, 2006 3:53:44 AM EDT
>>> *To: *"Philip Levis" <pal at cs.stanford.edu <mailto:pal at cs.stanford.edu>>
>>> *Cc: *"tinyos-2. 0" <tinyos-2.0wg at mail.millennium.berkeley.edu
>>> <mailto:tinyos-2.0wg at mail.millennium.berkeley.edu>>, TinyOS-Devel
>>> list <tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>>
>>> *Subject: **[Tinyos-devel] Re: [Tinyos-2.0wg] Meeting: July 26
>>> (content within, please read)*
>>>
>>> On 7/26/06, Philip Levis <pal at cs.stanford.edu
>>> <mailto:pal at cs.stanford.edu>> wrote:
>>>> 2. These storage abstractions are not the lowest common denominator
>>>> when it
>>>> comes to an interface for flash.
>>>> The most direct, abstract interfaces to any flash chip are:
>>>> * read(addr, *buf, len);
>>>> * write(addr, *buf, len);
>>>> * erase(eraseUnitIndex);
>>>> * crc(addr, len);
>>>> * flush();
>>>
>>> I don't have time for an in-depth discussion now, but I will give the
>>> basic reasons we didn't provide an interface like the one above
>>>
>>> - the interface above needs to come with a fairly significant set of
>>> restrictions on writes to actually be portable, at least if you care
>>> about wear-levelling issues or NAND flash. Two obvious options:
>>> (1) the length must be a multiple of the write unit (1 byte for
>>> most NOR flashes, 256+ bytes for most NAND flashes)
>>> (2) we assume flashes with large write units have a write
>>> buffers, and require that between calls to flush, multiple writes must
>>> refer to non-overlapping addresses within a write unit (this can be
>>> generalised to a known number of buffers)
>>>
>>> - the interface above doesn't tell us much about failure modes (we can
>>> maybe assume that writes to a write unit fail? what about any
>>> ordering guarantees in the presence of buffering?) - without this,
>>> there is no writing of any failure-tolerant storage solution
>>>
>>> - you need sync as well as flush
>>>
>>> - this doesn't expose useful properties of various flashes,e.g.:
>>> - the extra 8 bytes/page of an at45db flash
>>> - the ability to bypass the buffers in an at45db flash (for reads
>>> only, IIRC)
>>> - the ability to rewrite bytes in some NOR flashes, as long as you
>>> only push 1 bits to 0
>>> - bad-block information in a NAND flash
>>>
>>> So, two obvious conclusions at least:
>>> - you need a HAL-like layer below the interface proposed above which
>>> exposes the interesting behaviours of each chip
>>> - it's probably possible to provide a "least common denominator"
>>> interface to flash similar to the one above; but this won't let you
>>> take full advantage of each chip's capabilities (as an example of
>>> this, consider the fairly different ways in which LogStorage is
>>> implemented for the stm25p and the at45db - the problem isn't so much
>>> normal behaviour but fault-tolerance)
>>>
>>> My suggestion would be (and I think this is similar to what Jonathan
>>> is proposing) to fully specify such a "portable" flash interface, and
>>> propose it as an additional HIL abstraction for volumes. But making
>>> that the only HIL, and forcing things like Block/Config/Log on top of
>>> that seems a mistake to me (especially as I don't think that this HIL
>>> interface is well enough defined yet).
>>>
>>> Note also that there may well be a middle point: common interfaces to
>>> each kind of flash (e.g., NorFlash and NandFlash interfaces).
>>>
>>> Btw, re the at45db BlockStorage comments:
>>> - The at45db implementation implements the behaviour specified by
>>> the HIL.
>>> - There is no hidden address range unavailable to the application (it
>>> would be pretty useless if there was).
>>> - The metadata/crc stored on the first page is in an unused portion of
>>> that page (the extra 8 bytes).
>>> - The fact that erasing a BlockStorage only physically erases the
>>> first page is not a problem, as BlockStorage.erase() does not mean
>>> "physically erase the volume", it means "logically erase the block".
>>> Erasing the metadata is sufficient to erase the block.
>>>
>>> David Gay
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"Jonathan Hui" <jwhui at cs.berkeley.edu
>>> <mailto:jwhui at cs.berkeley.edu>>
>>> *Date: *July 25, 2006 11:14:38 PM EDT
>>> *To: *"Joe Polastre" <joe at polastre.com <mailto:joe at polastre.com>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> On 7/25/06, Joe Polastre <joe at polastre.com
>>> <mailto:joe at polastre.com>> wrote:
>>>> David Moss makes a great point--By using get() functions combined with
>>>> the lowest common denominator, you can build Block/Config/Log above
>>>> it. If you go back and re-read the Flexible Hardware Abstraction
>>>> paper, it clearly articulates that you should use HAL interfaces for
>>>> optimal performance. For optimal hardware independence, you should
>>>> use HIL interfaces.
>>>
>>> Joe, I guess you and I differ in philosophy here. David Gay's and my
>>> goal was to not only provide hardware independence but not sacrafice a
>>> huge amount of performance in doing it. If you consider the design
>>> difference between the AT45DB and STM25P implementations, they are
>>> significant and for good reasons. More on this below.
>>>
>>>> Jonathan's comments when taken in the context of the original paper
>>>> are in conflict--The goal of the HIL is not performance but
>>>> interoperability. As such, the interface that provides the greatest
>>>> interoperability should be used at the HIL. The interfaces that
>>>> provide the greatest performance should be used at the HAL. David
>>>> Moss has made an excellent case that the current HIL interfaces are
>>>> unsuitable for building file systems in a platform independent manner.
>>>> With this feedback, I believe it is worthwhile to revisit why
>>>> Config/Block/Log are the appropriate cross-platform HIL interfaces.
>>>
>>> Sure, so we decided to take a compromise. The HILs proposed in TEP103
>>> are implemented using the proposed HALs. David Gay and I, as chip
>>> developers, decided to provide chip-specific implementations of HILs
>>> that are most likely to have higher performance than a common
>>> implementation across both.
>>>
>>> David Moss' real point is he'd like to see another HIL live along side
>>> the proposed Config/Block/Log offerings. I never said Config/Block/Log
>>> are the *only* cross-platform HIL interfaces, they are just the first
>>> three that we proposed. You can implement David Moss' proposed HIL on
>>> top of the current HALs and Blackbook would use that. In his case,
>>> he's willing to suffer the performance hit of sitting on top of an
>>> HIL.
>>>
>>> The difference between Blackbook and Config/Block/Log is that it is a
>>> much more general storage system and requires much more code to
>>> maintain. So it's natural that David Moss would like to implement it
>>> on top of an HIL. In reality, his proposed HIL is pretty similar to
>>> the BlockStorage interface, and maybe some small tweaks to it would
>>> satisfy his requests. It seemed like only a few things were getting in
>>> his way, some of which have already been fixed.
>>>
>>> --
>>> Jonathan W. Hui
>>> jwhui at cs.berkeley.edu <mailto:jwhui at cs.berkeley.edu>
>>> http://www.cs.berkeley.edu/~jwhui/
>>> <http://www.cs.berkeley.edu/%7Ejwhui/>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"Joe Polastre" <joe at polastre.com <mailto:joe at polastre.com>>
>>> *Date: *July 25, 2006 9:17:21 PM EDT
>>> *To: *"Philip Levis" <pal at cs.stanford.edu <mailto:pal at cs.stanford.edu>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>>> Unfortunately, that leaves a typical developer in a bit of a bind: if
>>>> the only choices are HAL (optimal performance) or HIL (optimal
>>>> independence), then there is no middle ground with tradeoffs. The
>>>> paper -- and TEP 2 -- certainly don't take so strong a stance. In
>>>> fact, the HAA paper proposes Log, Config, and Block! E.g.:
>>>
>>> The point of my email was as follows: The HIL is allowed to sacrifice
>>> performance in the interest of independence. Independence is achieved
>>> through "typical hardware services required in a WSN application."
>>>
>>> If David's HIL proposal leads to more interfaces above a common
>>> "narrow waist" than the current Conflig/Log/Block, then I firmly
>>> believe it is the correct choice for an HIL layer and it provides the
>>> interface for typical hardware services required for a WSN
>>> application.
>>>
>>>> The HAA paper proposed them....
>>>
>>> Yes, they also proposed the wrong Timer and ADC interfaces too, which
>>> have changed with more experience. I think this is a clear case where
>>> additional experience can lead to a better design.
>>>
>>> As of the writing of the paper, no one had been able to get a file
>>> system working in a cross-platform implementation. David Moss, afaik,
>>> is the only such individual to achieve this feat.
>>>
>>> -Joe
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *Philip Levis <pal at cs.stanford.edu <mailto:pal at cs.stanford.edu>>
>>> *Date: *July 25, 2006 9:10:56 PM EDT
>>> *To: *Joe Polastre <joe at polastre.com <mailto:joe at polastre.com>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> On Jul 25, 2006, at 5:47 PM, Joe Polastre wrote:
>>>
>>>>
>>>> David Moss makes a great point--By using get() functions combined with
>>>> the lowest common denominator, you can build Block/Config/Log above
>>>> it. If you go back and re-read the Flexible Hardware Abstraction
>>>> paper, it clearly articulates that you should use HAL interfaces for
>>>> optimal performance. For optimal hardware independence, you should
>>>> use HIL interfaces.
>>>
>>> Unfortunately, that leaves a typical developer in a bit of a bind:
>>> if the only choices are HAL (optimal performance) or HIL (optimal
>>> independence), then there is no middle ground with tradeoffs. The
>>> paper -- and TEP 2 -- certainly don't take so strong a stance. In
>>> fact, the HAA paper proposes Log, Config, and Block! E.g.:
>>>
>>> "The API ''contract'' should reflect the typical hardware services
>>> that are required in a WSN application."
>>>
>>> "The platform-independent HIL interfaces represent a compromise
>>> between the capabilities of the currently supported platforms."
>>>
>>> There's also discussion of versioning HIL interfaces, as well as
>>> branching them -- providing more than one option at the HIL level.
>>>
>>>>
>>>> Jonathan's comments when taken in the context of the original paper
>>>> are in conflict--The goal of the HIL is not performance but
>>>> interoperability. As such, the interface that provides the greatest
>>>> interoperability should be used at the HIL. The interfaces that
>>>> provide the greatest performance should be used at the HAL. David
>>>> Moss has made an excellent case that the current HIL interfaces are
>>>> unsuitable for building file systems in a platform independent manner.
>>>> With this feedback, I believe it is worthwhile to revisit why
>>>> Config/Block/Log are the appropriate cross-platform HIL interfaces.
>>>
>>> The HAA paper proposed them....
>>>
>>> Phil
>>>
>>>
>>>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *Philip Levis <pal at cs.stanford.edu <mailto:pal at cs.stanford.edu>>
>>> *Date: *July 25, 2006 9:03:21 PM EDT
>>> *To: *David Moss <dmm at rincon.com <mailto:dmm at rincon.com>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, "'Ramesh Govindan'"
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> On Jul 25, 2006, at 2:14 PM, David Moss wrote:
>>>
>>>>
>>>> SUMMARY
>>>> * The HAL is broken as is and needs to be thought out some more to
>>>> provide
>>>> one set of basic flash interfaces that works on each flash type with no
>>>> behavior inconsistencies. Abstracting flash by providing direct access
>>>> through a common interface with predictable behavior is the key.
>>>> Volume
>>>> abstractions can further be provided on top of that, but should not
>>>> be the
>>>> basic means of accessing flash.
>>>>
>>>> * Above the HAL layer, the HIL should not be chip dependant. If
>>>> the HAL is
>>>> designed and built correctly (it's the Abstraction Layer after
>>>> all), the
>>>> implementation layer should be written once, used everywhere. The
>>>> AT45DB
>>>> should look like a smaller M25P80 from the application standpoint.
>>>> Chip
>>>> Dependant HIL == Chip Dependant Application. And that breaks the
>>>> model for
>>>> TinyOS.
>>>
>>> I could be mistaken, but my understanding is that the current HILs
>>> are completely chip independent. You mentioned that you tried using
>>> earlier implementations. Do the current ones still have the same issues?
>>>
>>>
>>>>
>>>> * The LogStorage looks great - provided the user defining volumes and
>>>> software knows that a circular log can't be implemented in less
>>>> than 2 erase
>>>> units.
>>>>
>>>> * The ConfigStorage component should stop looking like the BlockStorage
>>>> component by getting rid of addresses in the arguments, taking a
>>>> load off
>>>> the application layer. If multiple structs are to be stored in
>>>> ConfigStorage, key-value look ups should be considered as a simple,
>>>> alternative implementation.
>>>>
>>>> * BlockStorage looks just like the basic flash interfaces previously
>>>> described, but with some data verifying functionality. This
>>>> functionality
>>>> should be well documented, and its implementation and behavior
>>>> should be
>>>> identical on any flash chip to allow an application to port to any
>>>> platform.
>>>> It would be nice to be able to find where the next writable address is
>>>> located.
>>>>
>>>> * The address ranges an application is able to read/write should be
>>>> enforced
>>>> - i.e. to prevent the app from using BlockStorage to overwrite an
>>>> area where
>>>> the CRC's are kept.
>>>>
>>>> * Remove the confusing web of typedef's that translate back into basic
>>>> variable types.
>>>>
>>>> * Remove the differences and references to commit, sync, and
>>>> flush. Choose
>>>> one. They all basically mean the same thing.
>>>>
>>>> * Keep in mind that it's easy to define a volume simply as the size
>>>> of a
>>>> sector, and enforce full volume-sized erases when you go to erase
>>>> something.
>>>> This would help make flash access more chip-independent by removing the
>>>> erase unit size inconsistencies.
>>>>
>>>
>>>
>>> There are all useful, concrete comments. Having them in summary is
>>> great.
>>>
>>> Phil
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"Joe Polastre" <joe at polastre.com <mailto:joe at polastre.com>>
>>> *Date: *July 25, 2006 8:47:52 PM EDT
>>> *To: *"Jonathan Hui" <jwhui at cs.berkeley.edu
>>> <mailto:jwhui at cs.berkeley.edu>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>>> While I'm sure that it's possible to write Blackbook such that its
>>>> implementation is chip independent, I feel that making it chip
>>>> dependent would allow you to utilize chip-specific features and
>>>> increase performance considerably. Blackbook can still provide the
>>>> same interfaces on top. Sure, it will require you to maintain a
>>>> version for each flash chip, but that is the tradeoff. I guess I'm
>>>> more inclined to strive for greater performance when operating on
>>>> already resource constrained devices.
>>>
>>> My two cents:
>>>
>>> I think it is a mistake to encourage multiple implementations per
>>> chip. It is a tremendously painful experience writing TinyOS code,
>>> and encourage users to write addtional code per chip only extends
>>> development time.
>>>
>>> David Moss makes a great point--By using get() functions combined with
>>> the lowest common denominator, you can build Block/Config/Log above
>>> it. If you go back and re-read the Flexible Hardware Abstraction
>>> paper, it clearly articulates that you should use HAL interfaces for
>>> optimal performance. For optimal hardware independence, you should
>>> use HIL interfaces.
>>>
>>> Jonathan's comments when taken in the context of the original paper
>>> are in conflict--The goal of the HIL is not performance but
>>> interoperability. As such, the interface that provides the greatest
>>> interoperability should be used at the HIL. The interfaces that
>>> provide the greatest performance should be used at the HAL. David
>>> Moss has made an excellent case that the current HIL interfaces are
>>> unsuitable for building file systems in a platform independent manner.
>>> With this feedback, I believe it is worthwhile to revisit why
>>> Config/Block/Log are the appropriate cross-platform HIL interfaces.
>>>
>>> -Joe
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"Jonathan Hui" <jwhui at cs.berkeley.edu
>>> <mailto:jwhui at cs.berkeley.edu>>
>>> *Date: *July 25, 2006 6:41:31 PM EDT
>>> *To: *"David Moss" <dmm at rincon.com <mailto:dmm at rincon.com>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>, Ramesh Govindan
>>> <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Subject: **Re: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> Thanks for all the comments/feedback. I've inlined my comments to give
>>> you a better idea of why we went down the path that we did.
>>>
>>> On 7/25/06, David Moss <dmm at rincon.com <mailto:dmm at rincon.com>> wrote:
>>>> 1. There are considerable differences in software behavior across
>>>> different
>>>> flash types.
>>>> Yes, the AT45DB and the STM25P and every other flash type is inherently
>>>> different, but that shouldn't prevent us from being able to write
>>>> interfaces
>>>> and implementations that allow a single application to run on both
>>>> a mica2
>>>> and a tmote without having to rewrite the app for each flash type.
>>>> Correct
>>>> me if I'm wrong, but the BlockWrite on the AT45DB uses the first
>>>> page of
>>>> flash to store meta/CRC information - so this first page is off
>>>> limits to my
>>>> app and not well documented. Also, only the first page is
>>>> erasable. On the
>>>> STM25P, however, the last page of each sector is used for volume
>>>> information, and no CRC's are stored like the AT45DB
>>>> implementation. So now
>>>> my app can't write to the last page of each sector either.
>>>> Therefore, in
>>>> order to write an application that uses BlockRead/BlockWrite, I
>>>> have to know
>>>> a lot of detail about the intricate behavioral differences between
>>>> the two
>>>> implementations. If I wrote an app for a mica2 that uses the
>>>> BlockRead/BlockWrite interface and now want that app to work as is on a
>>>> tmote, forget about it. The reason for this is....
>>>
>>> Actually, we addressed this issue indirectly in the latest tinyos-2.x
>>> implementations. The volume tables are generated at compile time, so
>>> there is no need for them to be stored on the flash chip itself.
>>>
>>>> 2. These storage abstractions are not the lowest common denominator
>>>> when it
>>>> comes to an interface for flash.
>>>> The most direct, abstract interfaces to any flash chip are:
>>>> * read(addr, *buf, len);
>>>> * write(addr, *buf, len);
>>>> * erase(eraseUnitIndex);
>>>> * crc(addr, len);
>>>> * flush();
>>>>
>>>> All other flash abstractions can sit on top of these five commands,
>>>> and they
>>>> should be implemented without any behavioral differences for all flash
>>>> types. The concept of volumes would exist above this level as well.
>>>> BlockStorage looks like it attempted to fulfill this type of general
>>>> interface, but verify() and commit() got in the way. If I want to ever
>>>> interact directly with flash I should be able to access this HAL
>>>> interface
>>>> for all flash types and let my app do its thing - without having to
>>>> worry
>>>> about where CRC's and volume information are being kept and what
>>>> areas of
>>>> flash are off limits for each flash type.
>>>
>>> One behavioral difference you'll never be able to match between flash
>>> chips is the erase time. The STM25P takes significantly longer to
>>> erase a sector than the AT45DB does to erase a page. Also, you will
>>> loose efficiency if you try to unify the HAL. For example, the AT45DB
>>> implementation utilizes the metadata section of each page, while the
>>> STM25P has no luxury. So methods for supporting fault tolerance,
>>> improving seek performance, etc. would best be implemented above the
>>> HAL layer where better knowledge of the data and its storage semantics
>>> are known.
>>>
>>>> I completely disagree with the statement "Flash families with a
>>>> common HPL
>>>> SHOULD have a common HAL." Instead, this should read "All flash types
>>>> SHOULD have a common interface to the HAL with parallel underlying
>>>> behavior." If all flash types don't have a common hardware abstraction
>>>> interface with similar, expected behaviors, then the abstraction is
>>>> undeniably broken - there is no abstraction.
>>>
>>> This is nearly impossible unless you want to sacrifice efficiency at
>>> the HAL layer. One example is the AT45DB's 264 byte pages/erase size
>>> vs the STM25P 256 byte pages/64K erase size. What does an address
>>> mean? What page does it map to? Should address X always map to the
>>> same page, meaning the extra 8 bytes per page on the AT45DB are
>>> unaddressable?
>>>
>>> Another nice feature about the AT45DB compared to the STM25P is that
>>> it allows you to write the same byte over and over again without first
>>> have to do an erase. This feature alone would cause me to use
>>> different mechanisms on the AT45DB than the STM25P.
>>>
>>>> BlockStorage, ConfigStorage, LogStorage, custom file systems, and
>>>> any other
>>>> flash component implementation can sit nicely on top of this type
>>>> of HAL
>>>> interface without having to rewrite each storage implementation for
>>>> each
>>>> flash type. Preventing each storage implementation from being
>>>> rewritten for
>>>> each flash type saves both the implementers and the end-user
>>>> developers time
>>>> and headaches.
>>>
>>> In many cases, its best to have different implementations for Block,
>>> Config, and Log. There already are very different implementations
>>> between the AT45DB and STM25P because of their performance and feature
>>> differences. For Logs, the AT45DB keeps information in the metadata
>>> section of each page to indicate where the end of the log is. For
>>> Config storage, the STM25P implementation uses a log-based approach,
>>> while config storage does not and simply swaps between two areas of
>>> flash since erase/write cycles are small and quick. Clearly, a
>>> log-based approach on the AT45DB would have been less efficient and
>>> require more resources.
>>>
>>>> Let's talk about flash differences. The AT45DB041's erase size is
>>>> at the
>>>> page level, with varying sector sizes in sectors 0-2, and similar
>>>> sector
>>>> sizes in sectors 3-5. ST's M25P80 has erase sizes at the sector
>>>> level, with
>>>> similar sector sizes throughout. The AT45DB has RAM buffers, the
>>>> M25P80
>>>> does not. The AT45DB has the ability to do a read-modify-write
>>>> operation
>>>> because of the RAM buffers, while the M25P80 does not. The
>>>> difference in
>>>> behavior between these two flash chips usually kills anyone's
>>>> ability to
>>>> think that a common, behavior neutral abstraction can be formed
>>>> between the
>>>> two chips. But it can. The FlashBridge interface and
>>>> implementations I
>>>> wrote (/contrib/rincon/apps/flashbridge) proves this by providing the
>>>> interfaces described above with neutral behavior. Although I had
>>>> to change
>>>> the minimum erase unit on the AT45DB flash to the size of a sector
>>>> in my
>>>> implementation (because I didn't care about small erase sizes), it's
>>>> possible to compile an app that uses FlashBridge onto both mica's and
>>>> tmote's without modifications to the application layer.
>>>
>>> Your approach is definitely one approach. We also feel that its
>>> possible to provide a common abstraction for both the AT45DB and the
>>> STM25P. However, we felt that it is better provided at a higher layer
>>> (Block/Log/Config) rather than at the HAL layer for the reasons I gave
>>> above.
>>>
>>>> In order to adjust for the difference in erase sizes and make for a
>>>> better
>>>> abstraction, the solution is to provide a second interface for flash
>>>> properties that allows an application to adjust itself based on the
>>>> flash
>>>> erase sizes - similar, in a way, to how the Packet interface allows
>>>> higher
>>>> layers in an application to adjust themselves according to what's
>>>> underneath. The Logger component, for example, would be able to
>>>> access this
>>>> flash properties interface for the STM25P80 and know it needs at
>>>> least 2
>>>> erase units (2 sectors = 0x20000 bytes) to be able to implement a
>>>> circular
>>>> log. Similarly, it could look at the flash properties interface
>>>> for the
>>>> AT45DB and know it needs at least 2 erase units (2 pages = 0x200
>>>> bytes) to
>>>> be able to implement a circular log. Because it would have access
>>>> to the
>>>> properties of the flash, the application knows exactly which
>>>> addresses are
>>>> on erase unit boundaries, and respond accordingly without writing
>>>> data to an
>>>> area where it may be lost on the next erase. In my Blackbook file
>>>> system,
>>>> the set of properties I needed to correctly handle each flash type
>>>> turned
>>>> out to be: page length, erase unit length, total erase units - and
>>>> could
>>>> calculate the number of pages/erase unit. This was used by the
>>>> file system
>>>> to know where to locate boundaries and place data so it wouldn't
>>>> get cut in
>>>> half from an erase. So maybe it needs to be thought out a little
>>>> more, but
>>>> start out with a basic flash properties interface would look like:
>>>>
>>>> * getEraseUnitLength();
>>>> * getPageLength();
>>>> * getTotalEraseUnits();
>>>> * getPagesPerEraseUnit();
>>>> * etc.
>>>> As far as the RAM buffer differences in the flash types - flush()
>>>> should
>>>> store what's in the RAM to flash on the AT45DB, and flush() should
>>>> not do
>>>> anything on the M25P80. When the application needs to ensure data is
>>>> written to flash, calling flush() on either flash type guarantees
>>>> your data
>>>> is on flash.
>>>>
>>>> NAND flash would be able to implement this type of interface and
>>>> hide the
>>>> bad block management functionality within - still providing a common,
>>>> behavior neutral HAL interface.
>>>
>>> This is definitely an interesting approach. Erase sizes are not the
>>> only thing to be concerned about, but erase latencies are also very
>>> important. I would argue that implementations specific to each chip
>>> can and should provide much better performance since it can take into
>>> account the full features of each chip. This is what an HAL is
>>> designed to do and is by no means intended to be uniform across
>>> different chips.
>>>
>>> Futhermore, you mentioned ways to adapt between the two chips by
>>> having run-time knowledge of the erase size and how to deal with flash
>>> buffers. What if you're trying to support a different flash chip that
>>> provides a different set of features? Should you add another interface
>>> that is stubbed out on the AT45DB and STM25P? I'd argue if you're
>>> trying to do that, then you're effectively trying to write different
>>> implementations for different flash chips already but limiting
>>> yourself to it's full features. You've already limited yourself to
>>> explicitly managing the AT45DB's RAM buffers. What if you wanted to
>>> use a MRU policy rather than LRU? What if you want to prefetch data?
>>> You can't do that in your proposed interfaces.
>>>
>>>> 3. Implementation problems and application layer demands...
>>>> BlockStorage and ConfigStorage both have very similar interfaces
>>>> that allow
>>>> you to read and write seemingly arbitrary addresses on flash. If
>>>> you've
>>>
>>> The interfaces are similar, but have very different semantics. One
>>> provides fault-tolerance and the other doesn't.
>>>
>>>> written something to flash and reboot the mote, it appears as
>>>> though the
>>>> application layer has to take care of finding the next write
>>>> location on
>>>> flash. It would be nice if, at least in ConfigStorage, you didn't
>>>> have to
>>>> worry about finding and writing to the correct location - or worry
>>>> about any
>>>> address for that matter. Addresses should be dealt with internally by
>>>> ConfigStorage interface - not in the application layer.
>>>>
>>>> For reference and to plant a seed, the Blackbook file system's
>>>> equivalent to
>>>> ConfigStorage is the Dictionary, which allows your application to write
>>>> key-value pairs to flash. The keys are uint32_t, and the values are
>>>> arbitrary lengths. Of course, this was on a file system, so Dictionary
>>>> files were actually being written - but the same concept could
>>>> apply here.
>>>> This was a very sleek way to store and retrieve information: for
>>>> example,
>>>> if you have a struct that contains the security settings of your
>>>> application
>>>> and want it to be reloaded from flash on boot, just save the struct
>>>> in an
>>>> open Dictionary file, providing a corresponding look up key. No
>>>> need to
>>>> worry about what address it's being written to in flash, whether or
>>>> not it's
>>>> valid, or how to retrieve it. On the next reboot, just open up the
>>>> Dictionary file and tell it to retrieve the value from the given
>>>> key, and
>>>> your struct in RAM is automatically loaded with the latest
>>>> information if it
>>>> exists. Managing configuration data can't get much easier than
>>>> that from an
>>>> application standpoint. Multiple key-value pairs are allowed, and
>>>> Dictionary files in Blackbook are also circular: you can write to
>>>> the file
>>>> infinitely and it should never run out of space, only erasing sectors
>>>> ("volumes") once the entire flash is filled.
>>>>
>>>> On the implementation side of these storage components, random typedefs
>>>> should be done away with. It's time consuming to sift through .h files
>>>> looking for the definition of "storage_addr_t" and "storage_len_t"
>>>> and other
>>>> such typedefs. Both implementations have the same issues, like
>>>> "storage_addr_t" maps to "stm25p_addr_t" in one .h file which maps to
>>>> "uint32_t" in a separate .h file, and similarly "storage_len_t" maps to
>>>> "stm25p_len_t" which maps to "uint32_t". And "storage_cookie_t" is
>>>> just a
>>>> "uint32_t" as well. So why not just do away with all of these and
>>>> simply
>>>> use "uint32_t" in the first place, saving everybody some trouble?
>>>> Typedef's
>>>> are useful for structs - but not useful for giving a basic variable
>>>> type
>>>> several different names.
>>>>
>>>>
>>>> SUMMARY
>>>> * The HAL is broken as is and needs to be thought out some more to
>>>> provide
>>>> one set of basic flash interfaces that works on each flash type with no
>>>> behavior inconsistencies. Abstracting flash by providing direct access
>>>> through a common interface with predictable behavior is the key.
>>>> Volume
>>>> abstractions can further be provided on top of that, but should not
>>>> be the
>>>> basic means of accessing flash.
>>>
>>> I guess we differ in where the HIL abstraction should be. You are
>>> arguing that it be below BlockStorage/LogStorage/ConfigStorage. I
>>> would argue that that is too low level if you want efficient
>>> implementations for especially Log and Config.
>>>
>>>> * Above the HAL layer, the HIL should not be chip dependant. If
>>>> the HAL is
>>>> designed and built correctly (it's the Abstraction Layer after
>>>> all), the
>>>> implementation layer should be written once, used everywhere. The
>>>> AT45DB
>>>> should look like a smaller M25P80 from the application standpoint.
>>>> Chip
>>>> Dependant HIL == Chip Dependant Application. And that breaks the
>>>> model for
>>>> TinyOS.
>>>
>>> I think this is where part of the confusion lies. The 'A' in 'HAL'
>>> actually stands for Adaptation. I suggest you take a look at TEP2:
>>> http://www.tinyos.net/tinyos-2.x/doc/html/tep2.html for a better
>>> explanation of the HAA. While the HIL abstraction is chip independent,
>>> by no means does the implementation of the HIL have to be chip
>>> independent.
>>>
>>>> * The LogStorage looks great - provided the user defining volumes and
>>>> software knows that a circular log can't be implemented in less
>>>> than 2 erase
>>>> units.
>>>
>>> A circular log can easily be implemented on a single AT45DB page. The
>>> fact that it requires 2 erase units is chip dependent.
>>>
>>>> * The ConfigStorage component should stop looking like the BlockStorage
>>>> component by getting rid of addresses in the arguments, taking a
>>>> load off
>>>> the application layer. If multiple structs are to be stored in
>>>> ConfigStorage, key-value look ups should be considered as a simple,
>>>> alternative implementation.
>>>
>>> Key-value lookups are interesting but do require additional overhead.
>>>
>>>> * BlockStorage looks just like the basic flash interfaces previously
>>>> described, but with some data verifying functionality. This
>>>> functionality
>>>> should be well documented, and its implementation and behavior
>>>> should be
>>>> identical on any flash chip to allow an application to port to any
>>>> platform.
>>>> It would be nice to be able to find where the next writable address is
>>>> located.
>>>
>>> We do not plan to strive for "identical" performance between chips as
>>> this is not possible when considering timing differences alone.
>>>
>>>> * The address ranges an application is able to read/write should be
>>>> enforced
>>>> - i.e. to prevent the app from using BlockStorage to overwrite an
>>>> area where
>>>> the CRC's are kept.
>>>>
>>>> * Remove the confusing web of typedef's that translate back into basic
>>>> variable types.
>>>>
>>>> * Remove the differences and references to commit, sync, and
>>>> flush. Choose
>>>> one. They all basically mean the same thing.
>>>
>>> They don't really mean the same thing. BlockWrite.commit() means you
>>> shouldn't write any more data until the next erase. A LogWrite.sync()
>>> really means to make all recently written log data persistent, but you
>>> can continue appending if you wish.
>>>
>>>> * Keep in mind that it's easy to define a volume simply as the size
>>>> of a
>>>> sector, and enforce full volume-sized erases when you go to erase
>>>> something.
>>>> This would help make flash access more chip-independent by removing the
>>>> erase unit size inconsistencies.
>>>
>>> I haven't look much into Blackbook, but it does satisfy a different
>>> set of requirements by allowing key-value pairs. Though it probably
>>> uses more resources than the current ConfigStorage implementations do
>>> (correct me if I'm wrong).
>>>
>>> We certainly do not mean for BlockStorage/LogStorage/ConfigStorage to
>>> be the only HIL for storage chips. I would love to see additional HILs
>>> added to that list, including (possibly) a more general file system.
>>> While I'm sure that it's possible to write Blackbook such that its
>>> implementation is chip independent, I feel that making it chip
>>> dependent would allow you to utilize chip-specific features and
>>> increase performance considerably. Blackbook can still provide the
>>> same interfaces on top. Sure, it will require you to maintain a
>>> version for each flash chip, but that is the tradeoff. I guess I'm
>>> more inclined to strive for greater performance when operating on
>>> already resource constrained devices.
>>>
>>> --
>>> Jonathan W. Hui
>>> jwhui at cs.berkeley.edu <mailto:jwhui at cs.berkeley.edu>
>>> http://www.cs.berkeley.edu/~jwhui/
>>> <http://www.cs.berkeley.edu/%7Ejwhui/>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>> Begin forwarded message:
>>
>>> *From: *"David Moss" <dmm at rincon.com <mailto:dmm at rincon.com>>
>>> *Date: *July 25, 2006 5:14:47 PM EDT
>>> *To: *"'Ramesh Govindan'" <ramesh at usc.edu <mailto:ramesh at usc.edu>>
>>> *Cc: *tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>
>>> *Subject: **RE: [Tinyos-devel] Request for comments on TEP 103, due
>>> August 10th*
>>>
>>> My team's deployment applications rely heavily on the use of flash for
>>> permanent data storage. In fact, the use of flash makes or breaks our
>>> ability to meet product requirements.
>>>
>>> First, the permanent data storage solutions described in TEP 103 are
>>> good
>>> ideas. Having the ability to partition the flash and use different
>>> volumes
>>> for different purposes is great. Being able to log data linearly or
>>> circularly, store configuration data as well as large objects of data is
>>> what people need for useable, deployable systems.
>>>
>>> I attempted to use the lib/Flash components (BlockStorage) early on
>>> to meet
>>> our storage requirements, but ended up writing my own interfaces to
>>> flash
>>> because BlockStorage was found not to be the best general solution.
>>> We had
>>> to start with rewriting a basic flash interface all the way up to a full
>>> blown cross-platform compatible file system - kind of a pain, when all I
>>> wanted to do is write the application.
>>>
>>> There were three aspects of the storage solution that prevented us from
>>> using it in deployment applications. These are described below,
>>> each with a
>>> small book that follows, detailing the issues. A summary can be
>>> found at
>>> the end. I wrote a lot because I think that having a robust permanent
>>> storage solution is absolutely necessary for TinyOS.
>>>
>>>
>>>
>>> 1. There are considerable differences in software behavior across
>>> different
>>> flash types.
>>> Yes, the AT45DB and the STM25P and every other flash type is inherently
>>> different, but that shouldn't prevent us from being able to write
>>> interfaces
>>> and implementations that allow a single application to run on both a
>>> mica2
>>> and a tmote without having to rewrite the app for each flash type.
>>> Correct
>>> me if I'm wrong, but the BlockWrite on the AT45DB uses the first page of
>>> flash to store meta/CRC information - so this first page is off
>>> limits to my
>>> app and not well documented. Also, only the first page is erasable.
>>> On the
>>> STM25P, however, the last page of each sector is used for volume
>>> information, and no CRC's are stored like the AT45DB implementation.
>>> So now
>>> my app can't write to the last page of each sector either.
>>> Therefore, in
>>> order to write an application that uses BlockRead/BlockWrite, I have
>>> to know
>>> a lot of detail about the intricate behavioral differences between
>>> the two
>>> implementations. If I wrote an app for a mica2 that uses the
>>> BlockRead/BlockWrite interface and now want that app to work as is on a
>>> tmote, forget about it. The reason for this is....
>>>
>>>
>>>
>>> 2. These storage abstractions are not the lowest common denominator
>>> when it
>>> comes to an interface for flash.
>>> The most direct, abstract interfaces to any flash chip are:
>>> * read(addr, *buf, len);
>>> * write(addr, *buf, len);
>>> * erase(eraseUnitIndex);
>>> * crc(addr, len);
>>> * flush();
>>>
>>> All other flash abstractions can sit on top of these five commands,
>>> and they
>>> should be implemented without any behavioral differences for all flash
>>> types. The concept of volumes would exist above this level as well.
>>> BlockStorage looks like it attempted to fulfill this type of general
>>> interface, but verify() and commit() got in the way. If I want to ever
>>> interact directly with flash I should be able to access this HAL
>>> interface
>>> for all flash types and let my app do its thing - without having to
>>> worry
>>> about where CRC's and volume information are being kept and what
>>> areas of
>>> flash are off limits for each flash type.
>>>
>>> I completely disagree with the statement "Flash families with a
>>> common HPL
>>> SHOULD have a common HAL." Instead, this should read "All flash types
>>> SHOULD have a common interface to the HAL with parallel underlying
>>> behavior." If all flash types don't have a common hardware abstraction
>>> interface with similar, expected behaviors, then the abstraction is
>>> undeniably broken - there is no abstraction.
>>>
>>> BlockStorage, ConfigStorage, LogStorage, custom file systems, and
>>> any other
>>> flash component implementation can sit nicely on top of this type of HAL
>>> interface without having to rewrite each storage implementation for each
>>> flash type. Preventing each storage implementation from being
>>> rewritten for
>>> each flash type saves both the implementers and the end-user
>>> developers time
>>> and headaches.
>>>
>>> Let's talk about flash differences. The AT45DB041's erase size is at the
>>> page level, with varying sector sizes in sectors 0-2, and similar sector
>>> sizes in sectors 3-5. ST's M25P80 has erase sizes at the sector
>>> level, with
>>> similar sector sizes throughout. The AT45DB has RAM buffers, the M25P80
>>> does not. The AT45DB has the ability to do a read-modify-write
>>> operation
>>> because of the RAM buffers, while the M25P80 does not. The
>>> difference in
>>> behavior between these two flash chips usually kills anyone's ability to
>>> think that a common, behavior neutral abstraction can be formed
>>> between the
>>> two chips. But it can. The FlashBridge interface and implementations I
>>> wrote (/contrib/rincon/apps/flashbridge) proves this by providing the
>>> interfaces described above with neutral behavior. Although I had to
>>> change
>>> the minimum erase unit on the AT45DB flash to the size of a sector in my
>>> implementation (because I didn't care about small erase sizes), it's
>>> possible to compile an app that uses FlashBridge onto both mica's and
>>> tmote's without modifications to the application layer.
>>>
>>> In order to adjust for the difference in erase sizes and make for a
>>> better
>>> abstraction, the solution is to provide a second interface for flash
>>> properties that allows an application to adjust itself based on the
>>> flash
>>> erase sizes - similar, in a way, to how the Packet interface allows
>>> higher
>>> layers in an application to adjust themselves according to what's
>>> underneath. The Logger component, for example, would be able to
>>> access this
>>> flash properties interface for the STM25P80 and know it needs at least 2
>>> erase units (2 sectors = 0x20000 bytes) to be able to implement a
>>> circular
>>> log. Similarly, it could look at the flash properties interface for the
>>> AT45DB and know it needs at least 2 erase units (2 pages = 0x200
>>> bytes) to
>>> be able to implement a circular log. Because it would have access
>>> to the
>>> properties of the flash, the application knows exactly which
>>> addresses are
>>> on erase unit boundaries, and respond accordingly without writing
>>> data to an
>>> area where it may be lost on the next erase. In my Blackbook file
>>> system,
>>> the set of properties I needed to correctly handle each flash type
>>> turned
>>> out to be: page length, erase unit length, total erase units - and could
>>> calculate the number of pages/erase unit. This was used by the file
>>> system
>>> to know where to locate boundaries and place data so it wouldn't get
>>> cut in
>>> half from an erase. So maybe it needs to be thought out a little
>>> more, but
>>> start out with a basic flash properties interface would look like:
>>>
>>> * getEraseUnitLength();
>>> * getPageLength();
>>> * getTotalEraseUnits();
>>> * getPagesPerEraseUnit();
>>> * etc.
>>> As far as the RAM buffer differences in the flash types - flush() should
>>> store what's in the RAM to flash on the AT45DB, and flush() should
>>> not do
>>> anything on the M25P80. When the application needs to ensure data is
>>> written to flash, calling flush() on either flash type guarantees
>>> your data
>>> is on flash.
>>>
>>> NAND flash would be able to implement this type of interface and
>>> hide the
>>> bad block management functionality within - still providing a common,
>>> behavior neutral HAL interface.
>>>
>>>
>>>
>>> 3. Implementation problems and application layer demands...
>>> BlockStorage and ConfigStorage both have very similar interfaces
>>> that allow
>>> you to read and write seemingly arbitrary addresses on flash. If you've
>>> written something to flash and reboot the mote, it appears as though the
>>> application layer has to take care of finding the next write location on
>>> flash. It would be nice if, at least in ConfigStorage, you didn't
>>> have to
>>> worry about finding and writing to the correct location - or worry
>>> about any
>>> address for that matter. Addresses should be dealt with internally by
>>> ConfigStorage interface - not in the application layer.
>>>
>>> For reference and to plant a seed, the Blackbook file system's
>>> equivalent to
>>> ConfigStorage is the Dictionary, which allows your application to write
>>> key-value pairs to flash. The keys are uint32_t, and the values are
>>> arbitrary lengths. Of course, this was on a file system, so Dictionary
>>> files were actually being written - but the same concept could apply
>>> here.
>>> This was a very sleek way to store and retrieve information: for
>>> example,
>>> if you have a struct that contains the security settings of your
>>> application
>>> and want it to be reloaded from flash on boot, just save the struct
>>> in an
>>> open Dictionary file, providing a corresponding look up key. No need to
>>> worry about what address it's being written to in flash, whether or
>>> not it's
>>> valid, or how to retrieve it. On the next reboot, just open up the
>>> Dictionary file and tell it to retrieve the value from the given
>>> key, and
>>> your struct in RAM is automatically loaded with the latest
>>> information if it
>>> exists. Managing configuration data can't get much easier than that
>>> from an
>>> application standpoint. Multiple key-value pairs are allowed, and
>>> Dictionary files in Blackbook are also circular: you can write to
>>> the file
>>> infinitely and it should never run out of space, only erasing sectors
>>> ("volumes") once the entire flash is filled.
>>>
>>> On the implementation side of these storage components, random typedefs
>>> should be done away with. It's time consuming to sift through .h files
>>> looking for the definition of "storage_addr_t" and "storage_len_t"
>>> and other
>>> such typedefs. Both implementations have the same issues, like
>>> "storage_addr_t" maps to "stm25p_addr_t" in one .h file which maps to
>>> "uint32_t" in a separate .h file, and similarly "storage_len_t" maps to
>>> "stm25p_len_t" which maps to "uint32_t". And "storage_cookie_t" is
>>> just a
>>> "uint32_t" as well. So why not just do away with all of these and
>>> simply
>>> use "uint32_t" in the first place, saving everybody some trouble?
>>> Typedef's
>>> are useful for structs - but not useful for giving a basic variable type
>>> several different names.
>>>
>>>
>>>
>>> SUMMARY
>>> * The HAL is broken as is and needs to be thought out some more to
>>> provide
>>> one set of basic flash interfaces that works on each flash type with no
>>> behavior inconsistencies. Abstracting flash by providing direct access
>>> through a common interface with predictable behavior is the key. Volume
>>> abstractions can further be provided on top of that, but should not
>>> be the
>>> basic means of accessing flash.
>>>
>>> * Above the HAL layer, the HIL should not be chip dependant. If the
>>> HAL is
>>> designed and built correctly (it's the Abstraction Layer after all), the
>>> implementation layer should be written once, used everywhere. The
>>> AT45DB
>>> should look like a smaller M25P80 from the application standpoint. Chip
>>> Dependant HIL == Chip Dependant Application. And that breaks the
>>> model for
>>> TinyOS.
>>>
>>> * The LogStorage looks great - provided the user defining volumes and
>>> software knows that a circular log can't be implemented in less than
>>> 2 erase
>>> units.
>>>
>>> * The ConfigStorage component should stop looking like the BlockStorage
>>> component by getting rid of addresses in the arguments, taking a
>>> load off
>>> the application layer. If multiple structs are to be stored in
>>> ConfigStorage, key-value look ups should be considered as a simple,
>>> alternative implementation.
>>>
>>> * BlockStorage looks just like the basic flash interfaces previously
>>> described, but with some data verifying functionality. This
>>> functionality
>>> should be well documented, and its implementation and behavior should be
>>> identical on any flash chip to allow an application to port to any
>>> platform.
>>> It would be nice to be able to find where the next writable address is
>>> located.
>>>
>>> * The address ranges an application is able to read/write should be
>>> enforced
>>> - i.e. to prevent the app from using BlockStorage to overwrite an
>>> area where
>>> the CRC's are kept.
>>>
>>> * Remove the confusing web of typedef's that translate back into basic
>>> variable types.
>>>
>>> * Remove the differences and references to commit, sync, and flush.
>>> Choose
>>> one. They all basically mean the same thing.
>>>
>>> * Keep in mind that it's easy to define a volume simply as the size of a
>>> sector, and enforce full volume-sized erases when you go to erase
>>> something.
>>> This would help make flash access more chip-independent by removing the
>>> erase unit size inconsistencies.
>>>
>>>
>>> Hope my comments were useful, and keep in mind I'm only trying to help.
>>> -David
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: tinyos-devel-bounces at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU>
>>> [mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of
>>> Ramesh
>>> Govindan
>>> Sent: Friday, July 21, 2006 8:34 AM
>>> To: tinyos-help at Millennium.Berkeley.EDU
>>> <mailto:tinyos-help at Millennium.Berkeley.EDU>
>>> Cc: tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:tinyos-devel at Millennium.Berkeley.EDU>
>>> Subject: [Tinyos-devel] Request for comments on TEP 103, due August 10th
>>>
>>>
>>> Hi folks,
>>>
>>> TEP 103 is ready to move from draft to final. As part of this process,
>>> I'd like to invite those of you who might have comments about this
>>> TEP, available at:
>>>
>>> http://www.tinyos.net/tinyos-2.x/doc/html/tep103.html
>>>
>>> to send them to me before *August 10th*. I will collate the comments,
>>> discuss the required revisions with the authors, and shepherd the TEP
>>> to final.
>>>
>>> Please let me know if you have any questions.
>>>
>>> Regards.
>>> --
>>> Ramesh
>>> http://cs.usc.edu/~ramesh/ <http://cs.usc.edu/%7Eramesh/>
>>>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>> Tinyos-devel at Millennium.Berkeley.EDU
>>> <mailto:Tinyos-devel at Millennium.Berkeley.EDU>
>>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>
>>>
>>> _______________________________________________
>>> Tinyos-devel mailing list
>>>