That's exactly what I need: an example to follow. I'll check it
Thanks, Alan
Grr
El vie, 8 ene 2021 a las 13:10, Alan Carvalho de Assis ()
escribió:
> On 1/8/21, Abdelatif Guettouche wrote:
> >> The biggest issue I see is that drivers are hard coding the CS reference
> >> like the MCP2515 whic
On 1/8/21, Abdelatif Guettouche wrote:
>> The biggest issue I see is that drivers are hard coding the CS reference
>> like the MCP2515 which always uses SPIDEV_CANBUS(0), this should be
>> passed
>> in to the initialization of all SPI devices and owned by the private
>> device
>> structure not har
Some drivers do do that. They accept a "devno" argument in their init
> function and then pass it with the SPI calls.
>
If *every* driver *must* do that, problem solved
>
>
> On Fri, Jan 8, 2021 at 7:41 PM Brennan Ashton
> wrote:
> >
> > On Fri, Jan 8, 2021, 10:35 AM Abdelatif Guettouche <
> >
> The biggest issue I see is that drivers are hard coding the CS reference
> like the MCP2515 which always uses SPIDEV_CANBUS(0), this should be passed
> in to the initialization of all SPI devices and owned by the private device
> structure not hard coded. I could even see the argument for this be
On Fri, Jan 8, 2021, 10:35 AM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:
> > One problem was I didn't understand current CS definition. I thought
> > #define GPIO_MCP2515_CS (GPIO_OUTPUT|GPIO_CNF_OUTPP|GPIO_MODE_50MHz|\
> >GPIO_OUTPUT_SET|GPIO_PORT
> One problem was I didn't understand current CS definition. I thought
> #define GPIO_MCP2515_CS (GPIO_OUTPUT|GPIO_CNF_OUTPP|GPIO_MODE_50MHz|\
>GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4)
> created a bitmask named GPIO_MCP2515_CS but no, it creates an ASCII string
> that do
Thank you for the response
Hi,
> some of the points you mention about drivers being tied to board logic and
> the fact that initialization is "hard coded" is something I once tried to
> improve
> when I worked on "device tree" support (discussion at
> https://github.com/apache/incubator-nuttx/issu
Hi,
some of the points you mention about drivers being tied to board logic and
the fact that initialization is "hard coded" is something I once tried to
improve
when I worked on "device tree" support (discussion at
https://github.com/apache/incubator-nuttx/issues/1020). However as this was
quite
This is board and arch specific and cannot be more generalized than that.
> They will have different requirements for pullups, speed, etc. The define
> should also start with BOARD_ but some use GPIO_. This is the case
> for all PINs including UART, GPIO, SPI, USB, etc...
>
I mean after that arc
On Thu, Jan 7, 2021 at 9:51 PM Grr wrote:
>
> It is abstracted, for example see this file.
>
> >
> > https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140
> >
>
> You mean GPIO_MCP2515_CS? I don't quite understa
It is abstracted, for example see this file.
>
> https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140
>
You mean GPIO_MCP2515_CS? I don't quite understand its definition
#define GPIO_MCP2515_CS (GPIO_OUTPUT
On Thu, Jan 7, 2021 at 8:20 PM Grr wrote:
>
> I've been working towards creating a unified (character or SocketCAN)
> driver model for SPI CAN controller MCP2515 and I found out that SPI_*
> macro family allow platform-neutral SPI device control but there's one
> thing I cannot find:
>
> Is it pos
I've been working towards creating a unified (character or SocketCAN)
driver model for SPI CAN controller MCP2515 and I found out that SPI_*
macro family allow platform-neutral SPI device control but there's one
thing I cannot find:
Is it possible to abstract chip select (CS) definition and usage
13 matches
Mail list logo
