This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: SPI infrastructure
Bart Veer wrote:
jifl> The title is generic SPI support, but here's a poser, and
jifl> something we're inconsistent with... should SPI hardware
jifl> drivers have CYGPKG_IO_SPI as a parent? That way related
jifl> functionality is kept together rather than distributed. in
jifl> lots of top level packages.
Yes, for example:
cdl_package CYGPKG_DEVS_SPI_MCF52xx_QSPI {
parent CYGPKG_IO_SPI
...
}
Just checking... in that case perhaps it should be named just "SPI support"
instead of "Generic SPI support"
For other subsystems there have been inconsistencies - not entirely
surprising, the CDL way of managing code was new to all of us. Next
time we make a major release we should consider cleaning up this sort
of thing.
:-)
>> Index: io/spi/current/doc/spi.sgml
>> ===================================================================
>> RCS file: io/spi/current/doc/spi.sgml
>> diff -N io/spi/current/doc/spi.sgml
>> --- /dev/null 1 Jan 1970 00:00:00 -0000
>> +++ io/spi/current/doc/spi.sgml 24 Aug 2004 17:26:27 -0000
>> @@ -0,0 +1,711 @@
>> +<!-- DOCTYPE part PUBLIC "-//OASIS//DTD DocBook V3.1//EN" -->
jifl> Add to doc/sgml/doclist ?
Probably, but I have not rebuilt the global docs recently so am not
sure what the preferred versions of the sgml tools are.
You don't need to verify it, but it should go there so it isn't missed when
someone rebuilds the docs.
>> +#define CYG_SPI_DEFINE_BUS_TABLE(_type_, _which_) \
>> + CYG_HAL_TABLE_BEGIN(cyg_spi_bus_ ## _which_ ## _devs, spibus_ ## _which_); \
>> + CYG_HAL_TABLE_END(cyg_spi_bus_ ## _which_ ## _devs_end, spibus_ ## _which_); \
>> + extern _type_ cyg_spi_bus_## _which_ ## _devs[], cyg_spi_bus_## _which_ ## _devs_end
jifl> externC? (or better: __externC)
No need. This is data, not functions, so there are no problems with C
vs. C++ linkage.
Ah, I read it too quickly.
jifl> Is it not possible the underlying bus implementation may
jifl> want to return an error? Ditto the others that return void.
I did think about this but could not see any way in which an SPI
transfer can fail. The bus hardware is very straightforward. Even if
the addressed device has gone completely dead the SPI transfer will
still appear to succeed, you just get a stream of 0xff bytes. Any
error handling has to be handled at a higher level by code that knows
about the expected responses from the device(s) attached to the SPI
bus.
If you've thought about it then okay.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine