This is the mail archive of the ecos-patches@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tidy STM32 SPI driver


Bart Veer wrote:
> 
> For the chip select handling, if I understand the code correctly then
> currently the SPI driver is responsible for both setting up the GPIO
> pins and for driving them. There are other ways of handling this. One
> approach is for the platform HAL to set up all the pins early on
> during initialization, before the static constructors, on the theory
> that the platform HAL author knows what devices are attached to which
> pins. That saves having to do pin setup in each driver, so saves a bit
> more code.

Possibly, although the STM32E-EVAL board has a lot of flexibility in
terms of how it can be configured.  It would be quite difficult to
second-guess how a 'typical' developer would want to set it up.

> A more flexible approach is used in the coldfire HALs, see the mcf5272
> processor HAL's gpio.cdl and CYGHWR_HAL_M68K_MCF5272_BOARD_PINS in the
> m5272c3 platform HAL. That exposes all the pin settings to the
> configuration system, with the platform HAL providing default
> settings. The approach makes it possible to support boards with
> expansion connectors etc., where the platform HAL author does not
> necessarily know exactly what hardware will be used. It offers a lot
> of flexibility, and involves very little target-side code or data, but
> at the cost of significant programming effort.

If chip select setup is to be done in the HAL I suspect that something
like this would probably be required.  I'm not volunteering - I really
need to get cracking with my application!

> If pin setup can be left to the platform HAL then the SPI driver only
> needs to worry about driving the chip select pins. That can be
> handled by putting the pin id into the SPI device structure instead of
> the bus structure. That should save more code and data.

Now you come to mention it, the device structure is the most logical
place to put the chip select pin ID.  The only reason it's not there is
because of the requirement to set up the pin during initialisation.

Given that the CYG_DEVS_SPI_CORTEXM_STM32_DEVICE macro is already used
to hide all the bus attachment and type aliasing, it would also be
possible for that macro to automatically generate a static
initialisation function to set up the chip select pin.  That way there
is no need for the SPI bus data structure to hold any information about
chip selects and that configuration option can be discarded.

Chris.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]