RE: [EXT] Re: Re: socket CAN timestamp missing

[Peter van der Perk]

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, March 6, 2025 5:25 PM
To: dev@nuttx.apache.org
Subject: Re: Re: socket CAN timestamp missing


Hi Peter,
I was thinking about that, the thing is that we are using Nuttx as a submodule 
in our system and we haven't updated it in a while so right now we are using a 
quite older version and I'm not able to test the fix in master. I can send a PR 
but I don't think it will be approved without the proper testing. WDYT?


Thanks

Javier Casas Marín
Geotab

Senior Embedded Systems Developer

Direct
Toll-free

Visit


+34 900 535 371
http://www.geotab.com/es

Twitter  | Facebook 
 | YouTube 
 | LinkedIn 



On Thu, Mar 6, 2025 at 3:24 PM Peter van der Perk 
wrote:

> 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 timestamp missing
>
> Caution: This is an external email. Please take care when clicking
> links or opening attachments. When in doubt, report the message using
> the 'Report this email' button
>
>
> Hi Peter,
>
> Thanks for answering. You are right, moving the timestamp generation
> back up fixes the issue and it makes more sense to have the code
> there, before branching the code flow, than having it duplicated in both 
> paths.
>
> Thanks!
>
> Javier Casas Marín
> Geotab
>
> Senior Embedded Systems Developer
>
> Direct
> Toll-free
>
> Visit
>
>
> +34 900 535 371
> http://www.g/
> eotab.com%2Fes&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7C23945522e0f
> 44c749ddf08dd5ccb709c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638
> 768751012827986%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
> 7C%7C&sdata=Pge79WK1%2BDR8gT89%2F3pYuidmabCKy5PdvruVsXdd3K0%3D&reserve
> d=0
>
> Twitter
>  tter.com%2Fgeotab&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7C23945522
> e0f44c749ddf08dd5ccb709c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C
> 638768751012839631%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%
> 7C%7C%7C&sdata=IundPq6DfqLT8WuzW5vUVdqQcCllEtW17pIpkplEFHk%3D&reserved
> =0> | Facebook <
> https://www/.
> facebook.com%2FGeotab&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7C2394
> 5522e0f44c749ddf08dd5ccb709c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C638768751012851628%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU
> sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C0%7C%7C%7C&sdata=POXP5B3LabUVJc00c1Oj6Y3Br%2Ft%2F15FITbSVSVEVyPA%3D&
> reserved=0> | YouTube <
> https://www/.
> youtube.com%2Fuser%2FMyGeotab&data=05%7C02%7Cpeter.vanderperk%40nxp.co
> m%7C23945522e0f44c749ddf08dd5ccb709c%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C638768751012864359%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=CpYLDUt9PJJvk%2FY9%2FBNrJz5vokkga4JKETUqCpZ
> 2tKg%3D&reserved=0> | LinkedIn <
> https://www/.
> linkedin.com%2Fcompany%2Fgeotab%2F&data=05%7C02%7Cpeter.vanderperk%40n
> xp.com%7C23945522e0f44c749ddf08dd5ccb709c%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C638768751012880738%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y%2F29kbwdXzNq5bAOwHxzRiGNuoNzB1KwhYCZ
> p8VlI8U%3D&reserved=0>
>
>
> On Wed, Mar 5, 2025 at 7:11 PM Peter van der Perk <
> peter.vanderp...@nxp.com>
> wrote:
>
> > Hi Javier,
> >
> > I think it's a regression from the IOB rewrite.
> >
> > The original implementation added the timestamp before calling
> > either devif_conn_event or can_data_event.
> >
> > https://gith/
> > ub.com%2Fapache%2Fnuttx%2Fblob%2F55d9e5f7af05e75ca62f57863b880d723aa
> > 83
> > c56%2Fnet%2Fcan%2Fcan_callback.c%23L123-136&data=05%7C02%7Cpeter.van
> > de
> > rperk%40nxp.com%7Cf104859d6a1a445d62a808dd5cb71af1%7C686ea1d3bc2b4c6
> > fa
> > 92cd99c5c301635%7C0%7C0%7C638768663693812678%7CUnknown%7CTWFpbGZsb3d
> > 8e
> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
> > WF
> > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rmMl%2BcVzdMZPrTpl1GcKUUfsz
> > m9
> > tDf1Oi1K%2FN%2F6kqF4%3D&reserved=0
> >
> > I think moving the code up would fix it.
> >
> > Yours sincerely,
> >
> > Peter van der Perk
> >
> > -Original Message-
> > From: Javier Casas Marin 
> 

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

[Tomek CEDRO]

Okay here goes the PR with Guidelines update based on our votes, in
draft mode for now, I tired to make it as human friendly as possible,
unclear points are marked "TODO", discussion is now open :-)

https://github.com/apache/nuttx/pull/15950

Thanks :-)
Tomek



On Thu, Mar 6, 2025 at 7:39 PM Tomek CEDRO  wrote:
>
> Thank you Nathan, yes I will prepare Contribution Guidelines as
> promised, I am extremely overloaded recently sorry for the delay!!
> Tomek
>
> On Sun, Mar 2, 2025 at 5:04 PM Nathan Hartman  
> wrote:
> >
> > Hi all,
> >
> > A very *BIG* THANK YOU! to Tomek for driving this and doing the work
> > of running the votes and tallying the results!
> >
> > Also THANK YOU to everyone who has participated so far in the
> > discussions and voting.
> >
> > I guess the next steps will be to make any updates to the Contributing
> > Guidelines?
> >
> > Thanks again,
> > Nathan
> >
> > On Sat, Mar 1, 2025 at 9:05 AM Alan C. Assis  wrote:
> > >
> > > Thank Alin, but in the ROUND 2 was written in *separated PR*
> > >
> > > Yes, I think all commits should be separated into logic parts, depending 
> > > on
> > > which function is implemented.
> > >
> > > For example, a new generic driver shouldn't include arch/ and boards/ 
> > > files
> > > in the same commit, but a fix that involved arch/, boards/ and drivers/
> > > should be a single commit.
> > >
> > > This is why we cannot enforce developers to separate arch, drivers, 
> > > boards,
> > > etc all the time.
> > >
> > > BR,
> > >
> > > Alan
> > >
> > > On Sat, Mar 1, 2025 at 8:51 AM Alin Jerpelea  wrote:
> > >
> > > > Hi Alan,
> > > >
> > > > just for clarification
> > > >
> > > > Documentation should be part of the same PE but in a separate commit
> > > >
> > > > Best regards
> > > > Alin
> > > >
> > > > On Sat, 1 Mar 2025, 11:11 Alan C. Assis,  wrote:
> > > >
> > > > > Hi Tomek,
> > > > >
> > > > > Nice work! Kudos!
> > > > >
> > > > > About Documentation I voted +1 to have Documentation, but later I
> > > > realized
> > > > > it was required to be in a separate PR, which I don't agree with.
> > > > >
> > > > > When I contributor submit a new feature that doesn't have 
> > > > > Documentation I
> > > > > ask them to include it to avoid creating hidden feature (a nice
> > > > > functionality that nobody knows what is it used for and how to use 
> > > > > it, I
> > > > > have a nice example here:
> > > > >
> > > > >
> > > > https://acassis.wordpress.com/2024/07/02/how-a-supposed-malfunction-revealed-another-hidden-feature-of-nuttx/
> > > > > ).
> > > > >
> > > > > NuttX has many hidden features, this is something we need to fix, more
> > > > and
> > > > > better documentation will help newcomers to use the system.
> > > > >
> > > > > Even basic features like USERLEDS are missing documentation, people 
> > > > > spend
> > > > > days before they realize they need to include
> > > > > userled_lower_initialize("/dev/userleds") into bringup. There is no
> > > > > reference to it in our site:
> > > > >
> > > > >
> > > > https://nuttx.apache.org/docs/latest/search.html?q=userled_lower_initialize&check_keywords=yes&area=default
> > > > >
> > > > > The only reference to LEDs is the WS2812:
> > > > >
> > > > >
> > > > https://nuttx.apache.org/docs/latest/components/drivers/character/leds/index.html
> > > > >
> > > > > BR,
> > > > >
> > > > > Alan
> > > > >
> > > > > On Sat, Mar 1, 2025 at 4:00 AM Tomek CEDRO  wrote:
> > > > >
> > > > > > My thoughts and comments that I did not want to put as part of the
> > > > > > results message:
> > > > > >
> > > > > > It seems like this voting revealed two mindsets - one wants quick 
> > > > > > and
> > > > > > dirty experimental changes with low bar for acceptance that may be
> > > > > > streamed up from a single big organization that is probably paid for
> > > > > > the amount of changes or can simply allow to buy that much focus, as
> > > > > > opposed to more careful approach where self-compatibility and long
> > > > > > term maintenance are more important than quickly changing features
> > > > > > because of most probable personal and financial responsibility for
> > > > > > unexpected additional maintenance and maybe even damages (small
> > > > > > companies). This may look like Linux vs BSD, maybe more general 
> > > > > > terms
> > > > > > progressive vs conservative. NuttX was initially BSD, that aligned
> > > > > > with my mindset, and most part of the community seems quite
> > > > > > conservative that is opposing enforced changes.
> > > > > >
> > > > > > If we want to follow other moving-target projects that try to catch
> > > > > > some sort of rabbit all the time, just to gather some new community,
> > > > > > then we will loose existing community that was here all the time 
> > > > > > just
> > > > > > to avoid that rabbit. In that case no tools will be helpful or even
> > > > > > necessary because these will always prove only "current things" as
> > > > > > bleeding edge is in the mindset and you cannot ever fix "

RE: Re: socket CAN timestamp missing

[Peter van der Perk]

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 timestamp missing

Caution: This is an external email. Please take care when clicking links or 
opening attachments. When in doubt, report the message using the 'Report this 
email' button


Hi Peter,

Thanks for answering. You are right, moving the timestamp generation back up 
fixes the issue and it makes more sense to have the code there, before 
branching the code flow, than having it duplicated in both paths.

Thanks!

Javier Casas Marín
Geotab

Senior Embedded Systems Developer

Direct
Toll-free

Visit


+34 900 535 371
http://www.geotab.com/es

Twitter  | Facebook 
 | YouTube 
 | LinkedIn 



On Wed, Mar 5, 2025 at 7:11 PM Peter van der Perk 
wrote:

> Hi Javier,
>
> I think it's a regression from the IOB rewrite.
>
> The original implementation added the timestamp before calling either
> devif_conn_event or can_data_event.
>
> https://gith/
> ub.com%2Fapache%2Fnuttx%2Fblob%2F55d9e5f7af05e75ca62f57863b880d723aa83
> c56%2Fnet%2Fcan%2Fcan_callback.c%23L123-136&data=05%7C02%7Cpeter.vande
> rperk%40nxp.com%7Cf104859d6a1a445d62a808dd5cb71af1%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C638768663693812678%7CUnknown%7CTWFpbGZsb3d8e
> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
> pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rmMl%2BcVzdMZPrTpl1GcKUUfszm9
> tDf1Oi1K%2FN%2F6kqF4%3D&reserved=0
>
> I think moving 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, the application
> reading the socket is sometimes getting an empty timestamp in some
> situations. I've been debugging this issue and I this is what I found:
>
> There are two paths when receiving a CAN frame from the interrupt, if
> there is someone waiting for a frame, the can_recvfrom_eventhandler
> callback is called to deliver the frame to the application, otherwise
> the frame is stored in the read-ahead list.
>
> When there is no listener available the timestamp is generated in the
> can_callback function just before calling can_data_event to store the
> CAN frame in the read-ahead list. But, if there is a listener waiting,
> the can_recvfrom_eventhandler is called and the timestamp is not
> generated at all, so the recvmsg call in the application side returns an 
> empty timestamp.
>
> I think this is a bug. Why is the timestant not added in the explained
> case? Adding it in the can_recvfrom_newdata function solves the issue.
>
> Javier Casas Marín
> Geotab
>
> Senior Embedded Systems Developer
>
> Direct
> Toll-free
>
> Visit
>
>
> +34 900 535 371
> http://www.g/
> eotab.com%2Fes&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7Cf104859d6a1
> a445d62a808dd5cb71af1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638
> 768663693830272%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi
> IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
> 7C%7C&sdata=h2hUAcDskib8Ls0VEGXMTpYKCG%2B%2FAO24TAV5KhcHT5w%3D&reserve
> d=0
>
> Twitter
>  tter.com%2Fgeotab&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7Cf104859d
> 6a1a445d62a808dd5cb71af1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638768663693847889%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YKDNsDL62ZkxjJ%2FhSttjkxFxdghfZmqY4MNVXgFBzq4%3D&reserved=0>
>  | Facebook < https://www.facebook.com/Geotab> | YouTube < 
> https://www.youtube.com/user/MyGeotab> | LinkedIn < 
> https://www.linkedin.com/company/geotab/>
>

Re: socket CAN timestamp missing

[Javier Casas Marin]

Hi Peter,

Thanks for answering. You are right, moving the timestamp generation back
up fixes the issue and it makes more sense to have the code there, before
branching the code flow, than having it duplicated in both paths.

Thanks!

Javier Casas Marín
Geotab

Senior Embedded Systems Developer

Direct
Toll-free

Visit


+34 900 535 371
www.geotab.com/es

Twitter  | Facebook
 | YouTube
 | LinkedIn



On Wed, Mar 5, 2025 at 7:11 PM Peter van der Perk 
wrote:

> Hi Javier,
>
> I think it's a regression from the IOB rewrite.
>
> The original implementation added the timestamp before calling either
> devif_conn_event or can_data_event.
>
> https://github.com/apache/nuttx/blob/55d9e5f7af05e75ca62f57863b880d723aa83c56/net/can/can_callback.c#L123-136
>
> I think moving 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, the application
> reading the socket is sometimes getting an empty timestamp in some
> situations. I've been debugging this issue and I this is what I found:
>
> There are two paths when receiving a CAN frame from the interrupt, if
> there is someone waiting for a frame, the can_recvfrom_eventhandler
> callback is called to deliver the frame to the application, otherwise the
> frame is stored in the read-ahead list.
>
> When there is no listener available the timestamp is generated in the
> can_callback function just before calling can_data_event to store the CAN
> frame in the read-ahead list. But, if there is a listener waiting, the
> can_recvfrom_eventhandler is called and the timestamp is not generated at
> all, so the recvmsg call in the application side returns an empty timestamp.
>
> I think this is a bug. Why is the timestant not added in the explained
> case? Adding it in the can_recvfrom_newdata function solves the issue.
>
> Javier Casas Marín
> Geotab
>
> Senior Embedded Systems Developer
>
> Direct
> Toll-free
>
> Visit
>
>
> +34 900 535 371
> http://www.geotab.com/es
>
> Twitter  | Facebook <
> https://www.facebook.com/Geotab> | YouTube <
> https://www.youtube.com/user/MyGeotab> | LinkedIn <
> https://www.linkedin.com/company/geotab/>
>

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

[Tomek CEDRO]

Thank you Nathan, yes I will prepare Contribution Guidelines as
promised, I am extremely overloaded recently sorry for the delay!!
Tomek

On Sun, Mar 2, 2025 at 5:04 PM Nathan Hartman  wrote:
>
> Hi all,
>
> A very *BIG* THANK YOU! to Tomek for driving this and doing the work
> of running the votes and tallying the results!
>
> Also THANK YOU to everyone who has participated so far in the
> discussions and voting.
>
> I guess the next steps will be to make any updates to the Contributing
> Guidelines?
>
> Thanks again,
> Nathan
>
> On Sat, Mar 1, 2025 at 9:05 AM Alan C. Assis  wrote:
> >
> > Thank Alin, but in the ROUND 2 was written in *separated PR*
> >
> > Yes, I think all commits should be separated into logic parts, depending on
> > which function is implemented.
> >
> > For example, a new generic driver shouldn't include arch/ and boards/ files
> > in the same commit, but a fix that involved arch/, boards/ and drivers/
> > should be a single commit.
> >
> > This is why we cannot enforce developers to separate arch, drivers, boards,
> > etc all the time.
> >
> > BR,
> >
> > Alan
> >
> > On Sat, Mar 1, 2025 at 8:51 AM Alin Jerpelea  wrote:
> >
> > > Hi Alan,
> > >
> > > just for clarification
> > >
> > > Documentation should be part of the same PE but in a separate commit
> > >
> > > Best regards
> > > Alin
> > >
> > > On Sat, 1 Mar 2025, 11:11 Alan C. Assis,  wrote:
> > >
> > > > Hi Tomek,
> > > >
> > > > Nice work! Kudos!
> > > >
> > > > About Documentation I voted +1 to have Documentation, but later I
> > > realized
> > > > it was required to be in a separate PR, which I don't agree with.
> > > >
> > > > When I contributor submit a new feature that doesn't have Documentation 
> > > > I
> > > > ask them to include it to avoid creating hidden feature (a nice
> > > > functionality that nobody knows what is it used for and how to use it, I
> > > > have a nice example here:
> > > >
> > > >
> > > https://acassis.wordpress.com/2024/07/02/how-a-supposed-malfunction-revealed-another-hidden-feature-of-nuttx/
> > > > ).
> > > >
> > > > NuttX has many hidden features, this is something we need to fix, more
> > > and
> > > > better documentation will help newcomers to use the system.
> > > >
> > > > Even basic features like USERLEDS are missing documentation, people 
> > > > spend
> > > > days before they realize they need to include
> > > > userled_lower_initialize("/dev/userleds") into bringup. There is no
> > > > reference to it in our site:
> > > >
> > > >
> > > https://nuttx.apache.org/docs/latest/search.html?q=userled_lower_initialize&check_keywords=yes&area=default
> > > >
> > > > The only reference to LEDs is the WS2812:
> > > >
> > > >
> > > https://nuttx.apache.org/docs/latest/components/drivers/character/leds/index.html
> > > >
> > > > BR,
> > > >
> > > > Alan
> > > >
> > > > On Sat, Mar 1, 2025 at 4:00 AM Tomek CEDRO  wrote:
> > > >
> > > > > My thoughts and comments that I did not want to put as part of the
> > > > > results message:
> > > > >
> > > > > It seems like this voting revealed two mindsets - one wants quick and
> > > > > dirty experimental changes with low bar for acceptance that may be
> > > > > streamed up from a single big organization that is probably paid for
> > > > > the amount of changes or can simply allow to buy that much focus, as
> > > > > opposed to more careful approach where self-compatibility and long
> > > > > term maintenance are more important than quickly changing features
> > > > > because of most probable personal and financial responsibility for
> > > > > unexpected additional maintenance and maybe even damages (small
> > > > > companies). This may look like Linux vs BSD, maybe more general terms
> > > > > progressive vs conservative. NuttX was initially BSD, that aligned
> > > > > with my mindset, and most part of the community seems quite
> > > > > conservative that is opposing enforced changes.
> > > > >
> > > > > If we want to follow other moving-target projects that try to catch
> > > > > some sort of rabbit all the time, just to gather some new community,
> > > > > then we will loose existing community that was here all the time just
> > > > > to avoid that rabbit. In that case no tools will be helpful or even
> > > > > necessary because these will always prove only "current things" as
> > > > > bleeding edge is in the mindset and you cannot ever fix "break by
> > > > > design". Those two worlds are exclusive.
> > > > >
> > > > > If we ever agree internally to a moving target approach, and have no
> > > > > commitment to self-compatibility and long term maintenance as the
> > > > > ultimate goal, then NuttX will become just like any other project that
> > > > > you will have to re-discover each time you use it after update, and
> > > > > there will be completely no difference which one to choose.
> > > > >
> > > > > I did my best to clarify things.
> > > > >
> > > > > Have a good weekend folks :-)
> > > > > Tomek
> > > > >
> > > > >
> > > > >
> > > > >
> > > >

Re: Re: socket CAN timestamp missing

[Javier Casas Marin]

Hi Peter,
I was thinking about that, the thing is that we are using Nuttx as a
submodule in our system and we haven't updated it in a while so right now
we are using a quite older version and I'm not able to test the fix in
master. I can send a PR but I don't think it will be approved without the
proper testing. WDYT?


Thanks

Javier Casas Marín
Geotab

Senior Embedded Systems Developer

Direct
Toll-free

Visit


+34 900 535 371
www.geotab.com/es

Twitter  | Facebook
 | YouTube
 | LinkedIn



On Thu, Mar 6, 2025 at 3:24 PM Peter van der Perk 
wrote:

> 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 timestamp missing
>
> Caution: This is an external email. Please take care when clicking links
> or opening attachments. When in doubt, report the message using the 'Report
> this email' button
>
>
> Hi Peter,
>
> Thanks for answering. You are right, moving the timestamp generation back
> up fixes the issue and it makes more sense to have the code there, before
> branching the code flow, than having it duplicated in both paths.
>
> Thanks!
>
> Javier Casas Marín
> Geotab
>
> Senior Embedded Systems Developer
>
> Direct
> Toll-free
>
> Visit
>
>
> +34 900 535 371
> http://www.geotab.com/es
>
> Twitter  | Facebook <
> https://www.facebook.com/Geotab> | YouTube <
> https://www.youtube.com/user/MyGeotab> | LinkedIn <
> https://www.linkedin.com/company/geotab/>
>
>
> On Wed, Mar 5, 2025 at 7:11 PM Peter van der Perk <
> peter.vanderp...@nxp.com>
> wrote:
>
> > Hi Javier,
> >
> > I think it's a regression from the IOB rewrite.
> >
> > The original implementation added the timestamp before calling either
> > devif_conn_event or can_data_event.
> >
> > https://gith/
> > ub.com%2Fapache%2Fnuttx%2Fblob%2F55d9e5f7af05e75ca62f57863b880d723aa83
> > c56%2Fnet%2Fcan%2Fcan_callback.c%23L123-136&data=05%7C02%7Cpeter.vande
> > rperk%40nxp.com%7Cf104859d6a1a445d62a808dd5cb71af1%7C686ea1d3bc2b4c6fa
> > 92cd99c5c301635%7C0%7C0%7C638768663693812678%7CUnknown%7CTWFpbGZsb3d8e
> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF
> > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rmMl%2BcVzdMZPrTpl1GcKUUfszm9
> > tDf1Oi1K%2FN%2F6kqF4%3D&reserved=0
> >
> > I think moving 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, the application
> > reading the socket is sometimes getting an empty timestamp in some
> > situations. I've been debugging this issue and I this is what I found:
> >
> > There are two paths when receiving a CAN frame from the interrupt, if
> > there is someone waiting for a frame, the can_recvfrom_eventhandler
> > callback is called to deliver the frame to the application, otherwise
> > the frame is stored in the read-ahead list.
> >
> > When there is no listener available the timestamp is generated in the
> > can_callback function just before calling can_data_event to store the
> > CAN frame in the read-ahead list. But, if there is a listener waiting,
> > the can_recvfrom_eventhandler is called and the timestamp is not
> > generated at all, so the recvmsg call in the application side returns an
> empty timestamp.
> >
> > I think this is a bug. Why is the timestant not added in the explained
> > case? Adding it in the can_recvfrom_newdata function solves the issue.
> >
> > Javier Casas Marín
> > Geotab
> >
> > Senior Embedded Systems Developer
> >
> > Direct
> > Toll-free
> >
> > Visit
> >
> >
> > +34 900 535 371
> > http://www.g/
> > eotab.com%2Fes&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7Cf104859d6a1
> > a445d62a808dd5cb71af1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638
> > 768663693830272%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi
> > IwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%
> > 7C%7C&sdata=h2hUAcDskib8Ls0VEGXMTpYKCG%2B%2FAO24TAV5KhcHT5w%3D&reserve
> > d=0
> >
> > Twitter
> >  > tter.com%2Fgeotab&data=05%7C02%7Cpeter.vanderperk%40nxp.com%7Cf104859d
> >
> 6a1a445d62a808dd5cb71af1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638768663693847889%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YKDNsDL62ZkxjJ%2FhSttjkxFxdghfZmqY4MNVXgFBzq4%3D&reserved=0>
> | Facebook < https://www.facebook.com/Geotab> | YouTube <
> https://www.youtube.com/user/My