[En-Nut-Discussion] node_cs definition in NUTSPINODE

[Ulrich Prinz]

I am not sure if that really solves the problems.

Ok, in emac we started to implement a cross weak linking. So the emac
code provides read and write to phy and the phy provides init and
status requests.
This is simple as regardless of emac or phy these functions are standarized.

With SPI building a standard is difficult as the IPs on the silicons
are sometimes totally different.
On AVR jou have no CS but have to use manual GPIO.
On ARM/Cortex every chip is different.
So on SAM7 you can use GPIO, you can use the shadow SPI so you have 4
dedicated and hardware supported CS lines or you can use 1 out of 16
without shadow if you set a decoder behind the 4 CS lines.
On STM32 you again have to use GPIO

Oh, now I see what you think of!

we provide some standarized functions in the main spi driver routine
and provide separate CS drivers. Dependant on the nutconf setting the
one or the others are linked.
I am not sure if that will work as the core spi handling might differ
and connect much closer to the CS handling than we expect.

Nevertheless we need to provide a cs setup that correspands to our termes.
What we have to keep in mind too ist that the SPI bus configuration is
highly device dependent. I mean the chip connected on the other end.
So setting up the bus is fairly only activating the SPI system,
provide clocks to it and select the right alternate pin setups.
The real setup is device dependent. So speed, mode, delays whatever is
a separate thing.

So Stm32SpiChipSelect()... May be we should provide something like this:

NutSpiRegister( SPI_BUS);
NutSpiAssignDevice( SOME_DEVICE, cs_port, cs_pin, spi_mode, spi_speed);

And SOME_DEVICE can be a device that we already provide, but it may be
an empty framework that provides a simple read and write functionality
too.
So one could either use this simple device to work with any SPI slave
that he likes in the application code or he might copy that framework
and add a new driver that provides more functionality.

All that looks more easy to me than
uint32_t spi_port = (NUTGPIO_PORTA << 8) | NUT_GPIO_PIN7;
int mode = SPI_MODE3;

NutSpiRegister( SPI_BUS, &spi_port);
_ioctl(SPI_BUS, SPI_SET_MODE, &mode);
mode = 100000;
_ioctl(SPI_BUS, SPI_SET_SPEED, &mode);
and now youre lost as you need to provide a device driver.

Ulrich

Am 26. Februar 2012 10:42 schrieb Uwe Bonnes
<bon at elektron.ikp.physik.tu-darmstadt.de>:
>>>>>> "Ulrich" == Ulrich Prinz <ulrich.prinz at googlemail.com> writes:
>
>    Ulrich> Hi Uwe, one could see it like this or like that...
>
>    Ulrich> The problem is that we have to find a compromize between the
>    Ulrich> different options a CPU provides.  On some we have GPIO-CS only,
>    Ulrich> on others we have fixed hardware CS and on the third we have not
>    Ulrich> only optional hardware-CS but diffferent modes of it too.
>
> Wouldn't a __weak__ linking definition of the NUTOS Stm32SpiChipSelect()
> function be a good compromise?
>
>
> --
> Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion