; Hence back then it was chosen to use kHz instead.
> > >
> > > Yours sincerely,
> > >
> > > Peter van der Perk
> > >
> > > -Original Message-----
> > > From: Carlos Sanchez
> > > Sent: Wednesday, April 16, 2025 9:37 AM
> >
Hi Peter,
> can_ioctl_data_s is in a 32-bit union.
> https://github.com/apache/nuttx/blob/40c6af6dec0d769ac57f69e89709f9d6310ee0c6/include/net/if.h#L299
> Making it 64-bit would break that union.
Maybe I am missing something. AFAIU can_ioctl_data_s is already 64-bit
(it includes 4 uint16_t member
Hence back then it was chosen to use kHz instead.
> >
> > Yours sincerely,
> >
> > Peter van der Perk
> >
> > -Original Message-
> > From: Carlos Sanchez
> > Sent: Wednesday, April 16, 2025 9:37 AM
> > To: dev@nuttx.apache.org
> > Sub
ril 16, 2025 9:37 AM
> To: dev@nuttx.apache.org
> Subject: CAN ioctl units (WAS: socketcan ioctl(...SIOCSCANBITRATE...)
> brings the interface up)
>
>
> > > I was going to propose another global CAN change, removing the 1000
> > > factor from bitrate thus making bi
On Wed, Apr 16, 2025 at 3:37 PM Carlos Sanchez
wrote:
> > > I was going to propose another global CAN change, removing the 1000
> > > factor from bitrate thus making bitrate calls use units in Hz instead
> > > of kHz, so we can discuss that and (if agreed) I make the change on
> > > the same PR t
-
From: Carlos Sanchez
Sent: Wednesday, April 16, 2025 9:37 AM
To: dev@nuttx.apache.org
Subject: CAN ioctl units (WAS: socketcan ioctl(...SIOCSCANBITRATE...) brings
the interface up)
> > I was going to propose another global CAN change, removing the 1000
> > factor from bitrate thus ma
> > I was going to propose another global CAN change, removing the 1000
> > factor from bitrate thus making bitrate calls use units in Hz instead
> > of kHz, so we can discuss that and (if agreed) I make the change on
> > the same PR to avoid creating so a tiny one.
> What's the unit used on Linux
> > While testing this, I think I have discovered a small mistake on my
> > previous, Nuttx-side PR, which slipped by me and by revision: "ret"
> > might be used uninitialized now because I removed the assignment on
> > stm32_fdcan_sock:1976
> Yes, please make a PR to fix that!! When it's ready, p
On Wed, Apr 16, 2025 at 1:25 AM Carlos Sanchez
wrote:
> Related PR on the apps side, to make slcan work after the "bitrate no
> longer brings interface up" change:
> https://github.com/apache/nuttx-apps/pull/3059
>
> While testing this, I think I have discovered a small mistake on my
> previous,
On Tue, Apr 15, 2025 at 1:25 PM Carlos Sanchez
wrote:
> Related PR on the apps side, to make slcan work after the "bitrate no
> longer brings interface up" change:
> https://github.com/apache/nuttx-apps/pull/3059
>
> While testing this, I think I have discovered a small mistake on my
> previous,
Related PR on the apps side, to make slcan work after the "bitrate no
longer brings interface up" change:
https://github.com/apache/nuttx-apps/pull/3059
While testing this, I think I have discovered a small mistake on my
previous, Nuttx-side PR, which slipped by me and by revision: "ret"
might be
r van der Perk
>
> -Original Message-
> From: Carlos Sanchez
> Sent: Friday, April 11, 2025 12:16 PM
> To: dev@nuttx.apache.org
> Subject: socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up
>
>
> Hi devs,
>
> Short history: in all the existing socket
Peter van der Perk
-Original Message-
From: Carlos Sanchez
Sent: Friday, April 11, 2025 12:16 PM
To: dev@nuttx.apache.org
Subject: socketcan ioctl(...SIOCSCANBITRATE...) brings the interface up
Hi devs,
Short history: in all the existing socketcan drivers in Nuttx (imxrt, s32k3xx
Hi devs,
Short history: in all the existing socketcan drivers in Nuttx (imxrt,
s32k3xx, s32k1xx, stm32h7 and kinetis), the driver-specific
implementation of ioctl(...SIOCSCANBITRATE...) calls ifup at the end.
Is there a rationale / spec for this?
Long history:
In Linux, CAN bitrate is set with n
14 matches
Mail list logo
