Nick Garnett wrote:
Andrew Lunn <and...@lunn.ch> writes:
There has been comments that Rutgers code has too many layers. Rutger
aims to allow as much code reuse between drivers as possible, which i
think is good. Simon commented that he thinks Ross's design may result
in a lot of code stuck in HALs where it is hard to reuse without copy
paste. However Ross argued that he thinks that making code reusable is
going to be hard, there is too many different configurations of chips
and controllers, etc.
With only one supported platform on Ross's code and two with Rutgers,
i think it is too early to tell the truth. However, im generally in
favour of layers.
Just a few quick words about layering...
We have to be very careful in eCos not to over-do the abstractions.
eCos is still an embedded operating system and not a full-featured
general purpose OS. As such we must take care not to compromise code
size and performance. There are some areas in eCos already where we
have more layers than we strictly need, and performance has
suffered. Many of the target processors are relatively slow, without
caches or much fast memory and every extra call and indirection can
cost a lot of cycles.
In my NAND package, there are indirect calls to the device-specific code
of the controller. I followed the examples in the eCos documentation,
where serial line, Ethernet etc all use this approach. Per NAND page
that is written (typically 2KB or 4KB) there are a few indirect calls.
My unsubstantiated intuition is that the data transfers would dominate
performance compared to a few indirections. There are also a few
indirect calls in the chip module, but these are used at initialization
time only. Still, this indirection is only needed for heterogeneous
controllers.
Besides the layering issue, there is another thing that I would like to
point out. My NAND package has support for 3 types of NAND chip:
small-page (the old type), 'regular' large-page (that's what you buy
today), ONFI (I think this still has to hit the market). Small-page has
its own instruction set, and has interrogation protocol worth
mentioning. 'regular' and ONFI largely share the instruction set but
differ completely in the interrogation protocol.
For a specific build, it would be not hard at all to compile only the
support for the type of chip that is actually used, and to /not/ compile
command implementations and interrogation for the other types.
This same observation would hold for the ECC routines, and, as I
mentioned in an earlier email, for the code that hides away controller
or chip heterogeneity.
Rutger
