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
Hey all,
Would someone be willing to share their experience with libcxx and their
toolchain? I've now caught up to the tip of master, which now downloads
and builds libcxx for me instead of using Alan's modified version. I am
facing an issue I've faced before, and would really love to properly
un
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
Here is an interesting application of Spresense and NuttX: Big Cat
Brother. See https://www.wildedge.info/
11 matches
Mail list logo
