This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: SPI infrastructure
>>>>> "jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
jifl> Bart Veer wrote:
>> +cdl_package CYGPKG_IO_SPI {
>> + display "Generic SPI support"
>> + requires CYGPKG_INFRA CYGPKG_HAL
>> + hardware
jifl> "hardware" not in ecos.db? Probably isn't wanted in any
jifl> case.
In this respect CYGPKG_IO_SPI is like CYGPKG_IO_PCI. Depending on what
devices are attached to the SPI bus, on some targets CYGPKG_IO_SPI
must be part of the target definition or the target won't be fully
functional. Hence it has must be a hardware package. If the
application does not use any of the SPI devices then this is harmless,
the package and driver interface have been designed such that
selective linking will remove everything SPI-related. I'll fix ecos.db
Index: ecos.db
===================================================================
RCS file: /cvs/ecos/ecos/packages/ecos.db,v
retrieving revision 1.128
diff -u -r1.128 ecos.db
--- ecos.db 24 Aug 2004 17:31:17 -0000 1.128
+++ ecos.db 24 Aug 2004 21:13:37 -0000
@@ -2007,6 +2007,7 @@
alias { "Generic SPI support" spi io_spi spi_io }
directory io/spi
script spi.cdl
+ hardware
description "
The generic SPI package provides an API for accessing devices
attached to an SPI bus. It also provides support for writing
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
...
}
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.
jifl> It's interesting on reading this patch that most of it is
jifl> documentation :-). Probably the right way round for DD
jifl> infrastructure for a change!
Correct, exported APIs should be fully documented. The SPI device
drivers need rather less documentation and somewhat more code.
>> --- /dev/null 1 Jan 1970 00:00:00 -0000
>> +++ io/spi/current/include/spi.h 24 Aug 2004 17:26:27 -0000
jifl> [snip]
>> +// All devices should be in a per-bus table
>> +#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.
>> +
>> +#define CYG_SPI_DEVICE_ON_BUS(_which_) CYG_HAL_TABLE_ENTRY( spibus_ ## _which_)
>> +
>> +// Keys for use with the get_config() and set_config() operations.
>> +#define CYG_IO_GET_CONFIG_SPI_CLOCKRATE 0x00000800
>> +#define CYG_IO_SET_CONFIG_SPI_CLOCKRATE 0x00000880
>> +
>> +// The simple I/O operations.
>> +externC void cyg_spi_transfer(cyg_spi_device*, cyg_bool, cyg_uint32, const cyg_uint8*, cyg_uint8*);
>> +externC void cyg_spi_tick(cyg_spi_device*, cyg_bool, cyg_uint32);
>> +externC int cyg_spi_get_config(cyg_spi_device*, cyg_uint32, void*, cyg_uint32*);
>> +externC int cyg_spi_set_config(cyg_spi_device*, cyg_uint32, const void*, cyg_uint32*);
>> +
>> +// Support for more complicated transactions.
>> +externC void cyg_spi_transaction_begin(cyg_spi_device*);
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.
Bart
--
Bart Veer eCos Configuration Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts