[En-Nut-Discussion] node_cs definition in NUTSPINODE

Ulrich Prinz ulrich.prinz at googlemail.com
Fri Feb 24 11:09:48 CET 2012


Hi Uwe,

one could see it like this or like that...

The problem is that we have to find a compromize between the different
options a CPU provides.
On some we have GPIO-CS only, on others we have fixed hardware CS and
on the third we have not only optional hardware-CS but diffferent
modes of it too.

I think we have to keep the basic setup features inside qnutconf as
these decide the parts of the low level driver that are to be compiled
into the library.
Then we could make the registration function more Nut/OS standard
alike so we provide port and pin as an option instead of a 32bit value
that no one knows of how to provide.
But then we must add some traps, at least for the debug version of the
libraries:
If you use an AT91SAM and enable hardware-CS, we must trap a
registration to illegal port/pin combinations as only a few pins are
provided for CS by this chips.

I hope this is a good compromize.

Ulrich

Am 23. Februar 2012 11:27 schrieb Uwe Bonnes
<bon at elektron.ikp.physik.tu-darmstadt.de>:
>>>>>> "Ulrich" == Ulrich Prinz <ulrich.prinz at googlemail.com> writes:
>
>    Ulrich> Hi!
>    >>  was not a good idea. In practice you will configure Nut/OS for a
>    >> specific board once and never change it.
>
>    Ulrich> I fully agree :)
>
> I disagree:
>
> With adrino-like board or the STM32 discovery boards, you have ample pin
> headers and on a jumper board people would like to connect external SPI
> devices with their CS_N connected to some arbitray GPIO. But probably in
> that situation they don't like to do an extra branch of their NUTOS library.
>
> And with Jose's question for decoded chip selects even more requirements
> arise. What if the User could provide his own Stm32SpiChipSelect() function,
> perhaps by making the Stm32SpiChipSelect() definition in the library
> __weak__? And with an 32 bit argument to encode the GPIO Pin!
>
>    >>  Furthermore, Nut/OS doesn't currently allow to re-use a device. If
>    >> you got 4 DataFlash chips, you'll need devSpiAt45d0 to
>    >> devSpiAt45d3. Each SPI bus device has a fixed hardware chip select.
>    >>
>    Ulrich> Right, there must be one ICB per used ChipSelect even the SPI
>    Ulrich> bus itself is reused.
>
> Think also about the zillion of SPI devices where we don't have a NUTOS
> driver. Users should be able to use these devices too, even on the same SPI
> bus as e.g. devSpiAt45d0 with only a diffent CS.
>
> Bye
> --
> 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



More information about the En-Nut-Discussion mailing list