ant elder wrote:
I'm not sure i agree about the sample, wont it be even more confusing
having
it use the old way? Maybe if there was something the sample was doing
that
required the complex SPI but while there isn't wont it just seem odd
to do
it an unnecessarily complicated way.
Do we even want this simpler SPI? If we do i think we should use it,
if we
don't we should scrap it now, which I'm fine with doing. Maybe it
would be
better to just move some of the simplifications to the existing SPI?
...ant
I'm still on the path that we were discussing earlier in [1], and I
thought we were pursuing:
- a simplified extension SPI layer, for simplified bindings and
implementations that don't need the power of the complete/advanced SPI
- on top of the more advanced SPI, not replacing or altering it
- clearly identified in separate packages
I don't think that having 2 samples for the 2 separate SPI layers is
confusing. We just released a 0.90 release with stable SPIs that we want
people to use, we should continue to have a sample illustrating how to
use these SPIs. If implementation-crud does not make good use of some of
the interesting SPI methods (like some of the start/stop methods) we
should just improve the sample and add a few print statements for
example indicating what could be done in these methods...
And we can have a different sample showing how you can use the
simplified extension SPI layer for a simpler implementation extension.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]