Thanks for sharing.
I see that the project is bypassing the NuttX network stack and is using TCPIP
instead
CONFIG_MODULE_ETHIF=y
CONFIG_MODULE_TCPIP=y
I'm curious about the rationale for this, would you happen to know that Chao?
Yours sincerely,
Peter
-Original Message-
From: chao an
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.
Hence back then it was chosen to use kHz instead.
Yours sincerely,
Peter van der Perk
-Original Message
x27;s the case it should return -EBUSY.
Then the automatic ifup action that after SIOCSCANBITRATE that currently
happens should be removed.
The correct procedure to change bitrate would be then
1. ifdown the interface is it's up
2. Call SIOCSCANBITRATE
3. ifup the interface.
Yours sincerely,
After working in many codebases, I don't really have any preference for a style.
Except that the project should have an autoformatter such as clang-format or
astyle.
Unfortunely the current code style for NuttX is so exotic that no formatter
supports it well.
So, either an autoformatter should b
The main issue I was facing with clang-format was the indentation with NuttX
BreakBeforeBraces style see
https://github.com/llvm/llvm-project/issues/44188
Regards,
Peter
-Original Message-
From: Nathan Hartman
Sent: Monday, March 17, 2025 2:39 PM
To: dev@nuttx.apache.org
Subject: Re: [
HI Javier,
I'm on an older branch as well thus didn't have this issue yet.
But looking on the code it's reverting a regression.
Feel free to send in a PR I'll review it.
Yours sincerely,
Peter van der Perk
-Original Message-
From: Javier Casas Marin
Sent: Thursday
Hi Javier,
Good to hear.
If it working fine for you with the fix, feel free to send a PR into upstream
NuttX.
Yours sincerely,
Peter van der Perk
-Original Message-
From: Javier Casas Marin
Sent: Thursday, March 6, 2025 2:59 PM
To: dev@nuttx.apache.org
Subject: Re: socket CAN
g the code up would fix it.
Yours sincerely,
Peter van der Perk
-Original Message-
From: Javier Casas Marin
Sent: Wednesday, March 5, 2025 2:27 PM
To: dev@nuttx.apache.org
Subject: socket CAN timestamp missing
Hi Nuttxaddicts,
After configuring the CAN socket with SO_TIMESTAMP
There was a discussion when the kconfig GPL switch got introduced.
The libcanutils code from my perspective would be interpreted as BSD-3.
But it was decided otherwise
https://github.com/apache/nuttx-apps/pull/833#issuecomment-918875006
-Original Message-
From: Gregory Nutt
Sent: Thursd
nt of mailboxes and would even open the
possibility to use the DMA as well to transfer the CAN packets.
Yours sincerely,
Peter van der Perk
-Original Message-
From: Mårten Svanfeldt
Sent: Friday, March 3, 2023 9:48 AM
To: dev@nuttx.apache.org
Subject: Socketcan reordered packets and pa
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
Would this make sense or is there a better way to query the driver from network
stack?
Kind regards
Peter van der Perk
Hi Petro,
I understand having 2 upper separate layers for CAN isn't welcomed.
However I don't see any real particular gains for a generic can_ops_s
for both the SocketCAN and CAN Char driver.
For example SocketCAN net_driver_s interface uses the dev->d_buf
interface to transfer data and then in
Hi Peter,
NuttX has an SocketCAN interface as well. But currently only the Kinetis,
i.MXRT and S32K1 MCU use this interface for their CAN driver.
There's a porting guide to interface with SocketCAN driver as well
https://nuttx.apache.org/docs/latest/components/drivers/special/socketcan.html
htt
Hi Sathish,
Colleagues of mine, have worked on the BMS-772 (S32K144 + MC33772B) which also
runs NuttX.
To get the BCC working we've applied some patches that yet have to upstreamed
to NuttX.
But you can check out the source code here
https://github.com/NXPHoverGames/RDDRONE-BMS772
Furthermore t
port/xlocale/__nop_locale_mgmt.h:20:
first defined
here
arm-none-eabi-ld:
/home/peter/brickpoweredugv/nuttx/staging/libxx.a(ios.o): in function
`freelocale':
Thus my question is, is someone actively using libcxx with C++11 in
upstream NuttX and does it work well? Or do I have to use another
libc++ implementation
Yours sincerely,
Peter van der Perk
I've now got an approved account however it seems that the NuttX porting guide
page is a read-only html page. Can this page be converted to Confluence/Wiki
markup or is there a way for me to access this html file?
Yours sincerely,
Peter van der Perk
peter.vanderp...@nxp.com
-Ori
NuttX wiki Porting guide?
Yours sincerely,
Peter van der Perk
Hi Adam,
I've been trying to make a clang-format for NuttX however I did run in some
nasty bugs with clang-format.
Mostly the inconsistent spacing caused by preprocessor directives (#ifdef) etc.
I've filed a bug on the LLVM bugtracker
(https://bugs.llvm.org/show_bug.cgi?id=44843) unfortunely I d
apache.org/confluence/display/NUTTX/Integrating+with+Newlib)
however I'm getting errors that are not mentioned there. What would be the
required steps to make C++ work on NuttX with the gcc compiler and newlib
library?
Please find the compilation output below:
Regards,
Peter van der Perk
CXX:
>From ease-of-implementation perspective that would be the way to go. However
>this would mean that a CAN frame would go through the CAN driver -> Char
>driver -> VFS -> Socket -> user space. This would add unnecessary delay and
>jitter which would be certainly worse. Ideally I would implement i
Hardware|
+---+ +---+
Everything is still a WIP but I would like gather feedback and come up with an
architectural concept for the SocketCAN implementation.
Best regards,
Peter van der Perk
>I believe that both sides would be the same. Both would use BSD sockets,
>SocketCAN would be added to the network stacks, and the CAN drivers would be a
>network drivers.
>
>Your picture shows the existing implementation using character drivers.
>SocketCAN is intended to be integrated into the
Hardware|
+---+ +---+
(Note this is ASCII art use a monospace font to view correctly)
Everything is still a WIP but I would like gather feedback and come up with an
architectural concept for the SocketCAN implementation.
Best regards,
Peter van der Perk
24 matches
Mail list logo
