The PR which solved the interaction between main thread and error
generation: https://github.com/apache/nuttx/pull/8060
This affects the stm32 CAN driver, actually. I mentioned s32x_error()
because we have ported the error generation code to the s32k1xx CAN driver,
because we needed that. The driv
ee if you can enough
> throughput.
>
> Yours sincerely,
>
> Peter van der Perk
>
> -Original Message-
> From: raiden00pl
> Sent: Wednesday, January 4, 2023 10:01 AM
> To: dev@nuttx.apache.org
> Subject: Re: d_len/d_buf arbitration for s32k1xx_flexcan
>
Hi Peter,
> It seems that calling can_input directly from IRQ got broken since the IOB
> rewrite.
> Before can_input only used dev->d_appdata, but now can_input overwrites
> the dev->d_buf pointer as well.
>
> https://github.com/apache/nuttx/blob/779a610ca3ba495640b49d6c36bce89784955e0d/net/can/c
ersion of NuttX, or try to
schedule the workqueue for can_input and see if you can enough throughput.
Yours sincerely,
Peter van der Perk
-Original Message-
From: raiden00pl
Sent: Wednesday, January 4, 2023 10:01 AM
To: dev@nuttx.apache.org
Subject: Re: d_len/d_buf arbitration for s32k1x
Related issue: https://github.com/apache/nuttx/issues/5142.
Not using a work queue to handle CAN RX is basically wrong. Unfortunately
all NXP SocketCAN drivers are affected.
wt., 3 sty 2023 o 19:38 Xiang Xiao napisał(a):
> Sorry, "you must do..." may confuse you. What I mean is the CAN driver.
Sorry, "you must do..." may confuse you. What I mean is the CAN driver.
On Wed, Jan 4, 2023 at 2:30 AM Carlos Sanchez
wrote:
> Hi Xiang,
>
> Please note what I describe is not caused by my code using multiple
> threads, but is happening on Nuttx upstream. My code is single threaded,
> but s32k
Hi Xiang,
Please note what I describe is not caused by my code using multiple
threads, but is happening on Nuttx upstream. My code is single threaded,
but s32k1xx_flexcan driver (and several other Socket CAN drivers as they
all seem to be derived from the same code base) does some things on the
th
Since tx/rx share the same d_len/d_buf, you must do send/recv in one and
only thread(either by system work thread or driver dedicated thread) to
avoid the race condition you describe below.
On Wed, Jan 4, 2023 at 1:45 AM Carlos Sanchez
wrote:
> Hi all,
>
> I am observing an extrange behavior: un
Hi all,
I am observing an extrange behavior: under heavy-error CAN TX scenario (no
acks so TX fails always), usually after the second call to write() my
writes fail. This is expected as s32k1xx_flexcan has two TX mailboxes and
from my understanding of the code there is no other buffering (on this
