NRF / BLE / low power

[Sebastien Lorquet]

Hello,

Just a noob question: does NuttX support developing a BLE peripheral on 
a NRF component, and if so, does it support low power modes so the 
peripheral could run for years on a battery? I've seen the nrf52 is a 
supported target.


I'm just looking to see if I can replace my home network sensor (which 
is based on usb powered ESP32 running nodemcu, connected via wifi/mqtt) 
by these BLE thingies. I've done some test with a pi pico and 
micropython, it works awesomely well, but I wonder how to do the same 
while saving as much power as possible, as should be with BLE.


Zigbee would also be possible I guess, but IIRC it's not as energy 
efficient as BLE?


I can get a nrf52840 dongle soon for testing. I will probably spin my 
own board with a ble, temperature sensor, and battery.


Thanks,

Sebastien

Re: [OT] Projects for GSoC 2024

[Alan C. Assis]

Hi Tomek,

Thank you for raising these good points and thank YF for suggesting it.

I also don't know much details about it, maybe I think at list on Linux we
have some other libs working between X11 and Wayland to make "legacy" code
work correctly.

I'm CC Nicolas Caramelli who recently added support to DirectFB2 (
https://github.com/directfb2/DirectFB2) on NuttX, maybe (or maybe not) he
could help us to get a better vision of it.

Another advantage when thinking about X11 port to NuttX is because
nanox/microwindows is an implementation that does exactly that.

Also keep in mind that what RT-Thread did was just add support to use
weston in the host, something NuttX has more than 3 years ago and works on
X11 and Wayland.

Their weston port (AFAIK) doesn't support any embedded board directly.

BR,

Alan

On Fri, Feb 2, 2024 at 1:35 AM Tomek CEDRO  wrote:

> On Fri, Feb 2, 2024 at 1:42 AM yfliu2008 wrote:
> > How about adding Wayland instead of X11? It seems RT-Thread can run
> weston now.
>
> * Wayland is basically a framebuffer.
> * What are advantages of Wayland over X11 here?
> * How would that support porting known libraries and applications to NuttX?
> * What would be estimated workload and result?
> * Would you like to port Wayland to NuttX?
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: FAT macro

[Alan C. Assis]

Hi Saurav,

Thank you for looking at our code base and planning to add Documentation,
that is really important!

NuttX has a long history but our Documentation is still lagging behind, so
your work will be very beneficial for our community.

I took a look at that macro you asked and seems it was wrote by Greg almost
16 years ago:

08d439fefbd (patacongo  2008-08-02 14:44:25 +  262) #define
DIRSEC_NDXMASK(f)   (((f)->fs_hwsectorsize - 1) >> 5)

BTW, why do you think it is wrong, could you please share your thoughts?

Best Regards,

Alan

On Fri, Feb 2, 2024 at 3:50 AM Saurav Pal  wrote:

> Hi,
>
> I was browsing through the source code of FAT implementation, trying to
> write some documentation, and I came across this macro
> .
>
> Since I'm new to the codebase, I wanted to know if this (especially
> DIRSEC_NDXMASK(fs)) is correct and I'm missing something or if it should
> have been DIRSEC_NDXMASK(f) (and I can raise an issue for it).
>
> Thanks and regards,
> Saurav
>

Re: NRF / BLE / low power

[raiden00pl]

The nrf52 port in NuttX has support for BLE using a closed-source
Softdevice controller
from Nordic (
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/README.html
).
This is a certified BLE stack so there should be no problems with it.
It worked with NuttX BLE Host and NimBLE BLE stack.

Regarding low energy - there is some PM logic, but I personally haven't had
a chance to test it. One day I would like to measure the power consumption
of
Nordic chips with NuttX. If something in the nrf PM logic doesn't work, it
should be
easy to fix it, Nordic peripherals are usually simple (until you have to
work
around bugs from errata).

> Zigbee would also be possible I guess, but IIRC it's not as energy
> efficient as BLE?

For now there is no IEEE802154 support for Nordic chips in NuttX.
I'm working on this in my spare time, but it'll take some time to make it
useful.

> I can get a nrf52840 dongle soon for testing. I will probably spin my
> own board with a ble, temperature sensor, and battery.

Working with Nordic dongle sucks. You have to connect the external JLink to
work
with it. The USB peripheral on Nordic chips is a nightmare and the current
support
in NuttX has a bug that I haven't had a chance to fix yet - so another
argument
to avoid dongle for now.
For development, I would recommend nrf52840-dk but it costs much more.

pt., 2 lut 2024 o 11:27 Sebastien Lorquet  napisał(a):

> Hello,
>
> Just a noob question: does NuttX support developing a BLE peripheral on
> a NRF component, and if so, does it support low power modes so the
> peripheral could run for years on a battery? I've seen the nrf52 is a
> supported target.
>
> I'm just looking to see if I can replace my home network sensor (which
> is based on usb powered ESP32 running nodemcu, connected via wifi/mqtt)
> by these BLE thingies. I've done some test with a pi pico and
> micropython, it works awesomely well, but I wonder how to do the same
> while saving as much power as possible, as should be with BLE.
>
> Zigbee would also be possible I guess, but IIRC it's not as energy
> efficient as BLE?
>
> I can get a nrf52840 dongle soon for testing. I will probably spin my
> own board with a ble, temperature sensor, and battery.
>
> Thanks,
>
> Sebastien
>
>

Re: NRF / BLE / low power

[Sebastien Lorquet]

Hi,

Thank you very much for your advice.

I can probably get a -DK. I'll have more questions once I get that board 
running.


Can the dongle be easily programmed as a BLE sniffer to debug the 
protocol? That would make it valuable.


ACK for the 802.15.4 part, thank you and best wishes for working this.

Sebastien


Le 02/02/2024 à 17:26, raiden00pl a écrit :

The nrf52 port in NuttX has support for BLE using a closed-source
Softdevice controller
from Nordic (
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/README.html
).
This is a certified BLE stack so there should be no problems with it.
It worked with NuttX BLE Host and NimBLE BLE stack.

Regarding low energy - there is some PM logic, but I personally haven't had
a chance to test it. One day I would like to measure the power consumption
of
Nordic chips with NuttX. If something in the nrf PM logic doesn't work, it
should be
easy to fix it, Nordic peripherals are usually simple (until you have to
work
around bugs from errata).


Zigbee would also be possible I guess, but IIRC it's not as energy
efficient as BLE?

For now there is no IEEE802154 support for Nordic chips in NuttX.
I'm working on this in my spare time, but it'll take some time to make it
useful.


I can get a nrf52840 dongle soon for testing. I will probably spin my
own board with a ble, temperature sensor, and battery.

Working with Nordic dongle sucks. You have to connect the external JLink to
work
with it. The USB peripheral on Nordic chips is a nightmare and the current
support
in NuttX has a bug that I haven't had a chance to fix yet - so another
argument
to avoid dongle for now.
For development, I would recommend nrf52840-dk but it costs much more.

pt., 2 lut 2024 o 11:27 Sebastien Lorquet  napisał(a):


Hello,

Just a noob question: does NuttX support developing a BLE peripheral on
a NRF component, and if so, does it support low power modes so the
peripheral could run for years on a battery? I've seen the nrf52 is a
supported target.

I'm just looking to see if I can replace my home network sensor (which
is based on usb powered ESP32 running nodemcu, connected via wifi/mqtt)
by these BLE thingies. I've done some test with a pi pico and
micropython, it works awesomely well, but I wonder how to do the same
while saving as much power as possible, as should be with BLE.

Zigbee would also be possible I guess, but IIRC it's not as energy
efficient as BLE?

I can get a nrf52840 dongle soon for testing. I will probably spin my
own board with a ble, temperature sensor, and battery.

Thanks,

Sebastien

Re: FAT macro

[Saurav Pal]

Hi Alan,

Thank you for looking at our code base and planning to add Documentation,
> that is really important!
>
> NuttX has a long history but our Documentation is still lagging behind, so
> your work will be very beneficial for our community.
>

I'll try my best to contribute some documentation for the various file
systems I look into, and I, in turn, hope they are informative, and more
importantly, correct, as I'm pretty new to the VFS layer of NuttX.


> BTW, why do you think it is wrong, could you please share your thoughts?
>

The problem according to me is on L264...where it's defined as:

#define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)

I can't seem to find anything defined as *fs *in the namespace at that
point (used in the fat_findsfnentry
function),
and I was wondering if it was a simple typo or a mistake on my part as it's
code that's quite old, which usually don't have such mistakes due to
extensive testing.

Best Regards,
Saurav

Re: NRF / BLE / low power

[raiden00pl]

> Can the dongle be easily programmed as a BLE sniffer to debug the
> protocol? That would make it valuable.

Nordic provides a lot of ready to use tools which are quite useful.
They also have a lot of useful code and documentation. They base their
ecosystem on Zephyr, but it's still useful.

BLE sniffer can be found here
https://www.nordicsemi.com/Products/Development-tools/nrf-sniffer-for-bluetooth-le/download
The dongle comes with factory-programmed Nordic's bootloader so it was
possible to flash fw using this method (and flash sniffer fw).
But Nordic messed up their tools a lot, so honestly I have no idea with
which bootloader version they ship the dongle now (and which tools are
compatible)

pt., 2 lut 2024 o 17:37 Sebastien Lorquet  napisał(a):

> Hi,
>
> Thank you very much for your advice.
>
> I can probably get a -DK. I'll have more questions once I get that board
> running.
>
> Can the dongle be easily programmed as a BLE sniffer to debug the
> protocol? That would make it valuable.
>
> ACK for the 802.15.4 part, thank you and best wishes for working this.
>
> Sebastien
>
>
> Le 02/02/2024 à 17:26, raiden00pl a écrit :
> > The nrf52 port in NuttX has support for BLE using a closed-source
> > Softdevice controller
> > from Nordic (
> >
> https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/README.html
> > ).
> > This is a certified BLE stack so there should be no problems with it.
> > It worked with NuttX BLE Host and NimBLE BLE stack.
> >
> > Regarding low energy - there is some PM logic, but I personally haven't
> had
> > a chance to test it. One day I would like to measure the power
> consumption
> > of
> > Nordic chips with NuttX. If something in the nrf PM logic doesn't work,
> it
> > should be
> > easy to fix it, Nordic peripherals are usually simple (until you have to
> > work
> > around bugs from errata).
> >
> >> Zigbee would also be possible I guess, but IIRC it's not as energy
> >> efficient as BLE?
> > For now there is no IEEE802154 support for Nordic chips in NuttX.
> > I'm working on this in my spare time, but it'll take some time to make it
> > useful.
> >
> >> I can get a nrf52840 dongle soon for testing. I will probably spin my
> >> own board with a ble, temperature sensor, and battery.
> > Working with Nordic dongle sucks. You have to connect the external JLink
> to
> > work
> > with it. The USB peripheral on Nordic chips is a nightmare and the
> current
> > support
> > in NuttX has a bug that I haven't had a chance to fix yet - so another
> > argument
> > to avoid dongle for now.
> > For development, I would recommend nrf52840-dk but it costs much more.
> >
> > pt., 2 lut 2024 o 11:27 Sebastien Lorquet 
> napisał(a):
> >
> >> Hello,
> >>
> >> Just a noob question: does NuttX support developing a BLE peripheral on
> >> a NRF component, and if so, does it support low power modes so the
> >> peripheral could run for years on a battery? I've seen the nrf52 is a
> >> supported target.
> >>
> >> I'm just looking to see if I can replace my home network sensor (which
> >> is based on usb powered ESP32 running nodemcu, connected via wifi/mqtt)
> >> by these BLE thingies. I've done some test with a pi pico and
> >> micropython, it works awesomely well, but I wonder how to do the same
> >> while saving as much power as possible, as should be with BLE.
> >>
> >> Zigbee would also be possible I guess, but IIRC it's not as energy
> >> efficient as BLE?
> >>
> >> I can get a nrf52840 dongle soon for testing. I will probably spin my
> >> own board with a ble, temperature sensor, and battery.
> >>
> >> Thanks,
> >>
> >> Sebastien
> >>
> >>
>

Re: FAT macro

[Lwazi Dube]

It is a typo. Please change to DIRSEC_NDXMASK(f)
There are no errors because fs is already available in every function that
"calls" DIRSEC_BYTENDX.

On Fri, 2 Feb 2024 at 11:55, Saurav Pal  wrote:

> Hi Alan,
>
> Thank you for looking at our code base and planning to add Documentation,
> > that is really important!
> >
> > NuttX has a long history but our Documentation is still lagging behind,
> so
> > your work will be very beneficial for our community.
> >
>
> I'll try my best to contribute some documentation for the various file
> systems I look into, and I, in turn, hope they are informative, and more
> importantly, correct, as I'm pretty new to the VFS layer of NuttX.
>
>
> > BTW, why do you think it is wrong, could you please share your thoughts?
> >
>
> The problem according to me is on L264...where it's defined as:
>
> #define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)
>
> I can't seem to find anything defined as *fs *in the namespace at that
> point (used in the fat_findsfnentry
>  >function),
> and I was wondering if it was a simple typo or a mistake on my part as it's
> code that's quite old, which usually don't have such mistakes due to
> extensive testing.
>
> Best Regards,
> Saurav
>

Re: FAT macro

[Saurav Pal]

Hi,

Thanks for the confirmation and an explanation as to why it works even as
it is!

Regards,
Saurav

On Fri, 2 Feb, 2024, 22:35 Lwazi Dube,  wrote:

> It is a typo. Please change to DIRSEC_NDXMASK(f)
> There are no errors because fs is already available in every function that
> "calls" DIRSEC_BYTENDX.
>
> On Fri, 2 Feb 2024 at 11:55, Saurav Pal  wrote:
>
> > Hi Alan,
> >
> > Thank you for looking at our code base and planning to add Documentation,
> > > that is really important!
> > >
> > > NuttX has a long history but our Documentation is still lagging behind,
> > so
> > > your work will be very beneficial for our community.
> > >
> >
> > I'll try my best to contribute some documentation for the various file
> > systems I look into, and I, in turn, hope they are informative, and more
> > importantly, correct, as I'm pretty new to the VFS layer of NuttX.
> >
> >
> > > BTW, why do you think it is wrong, could you please share your
> thoughts?
> > >
> >
> > The problem according to me is on L264...where it's defined as:
> >
> > #define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)
> >
> > I can't seem to find anything defined as *fs *in the namespace at that
> > point (used in the fat_findsfnentry
> > <
> https://github.com/apache/nuttx/blob/master/fs/fat/fs_fat32dirent.c#L1137
> > >function),
> > and I was wondering if it was a simple typo or a mistake on my part as
> it's
> > code that's quite old, which usually don't have such mistakes due to
> > extensive testing.
> >
> > Best Regards,
> > Saurav
> >
>

Re: [OT] Projects for GSoC 2024

[Tomek CEDRO]

I have played with Wayland on FreeBSD and its NOT compatible with X11.
Its something >>>new<<<, a constantly fancy pancy moving target. Also
it is not network friendly (no client-server architecture) you need to
use VNC and this sux because of latency. I even tried to port some
stuff to Wayland@FBSD (i.e. Enlightenment WM) but I failed there is
too much Linux hardcoded stuff. So I still use Xorg myself :-) :-)

I can understand minimal port of Xorg it has strong merit to port
existing applications to NuttX. We even have display server - client
examples!

FB + LVGL is enough for us at that level and quite equivalent :-)

Over Wayland I would prefer to see native SDL implementation on NuttX
but that is another story :-)

We could think of Wayland on NuttX when it gets stable and mature
enough on a desktop.. and there would be good reason to invest time
into that work :-)

My 12 cents :D

Have a good weekend folks :-)
Tomek

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

On Fri, Feb 2, 2024 at 3:53 PM Alan C. Assis  wrote:
>
> Hi Tomek,
>
> Thank you for raising these good points and thank YF for suggesting it.
>
> I also don't know much details about it, maybe I think at list on Linux we
> have some other libs working between X11 and Wayland to make "legacy" code
> work correctly.
>
> I'm CC Nicolas Caramelli who recently added support to DirectFB2 (
> https://github.com/directfb2/DirectFB2) on NuttX, maybe (or maybe not) he
> could help us to get a better vision of it.
>
> Another advantage when thinking about X11 port to NuttX is because
> nanox/microwindows is an implementation that does exactly that.
>
> Also keep in mind that what RT-Thread did was just add support to use
> weston in the host, something NuttX has more than 3 years ago and works on
> X11 and Wayland.
>
> Their weston port (AFAIK) doesn't support any embedded board directly.
>
> BR,
>
> Alan
>
> On Fri, Feb 2, 2024 at 1:35 AM Tomek CEDRO  wrote:
>
> > On Fri, Feb 2, 2024 at 1:42 AM yfliu2008 wrote:
> > > How about adding Wayland instead of X11? It seems RT-Thread can run
> > weston now.
> >
> > * Wayland is basically a framebuffer.
> > * What are advantages of Wayland over X11 here?
> > * How would that support porting known libraries and applications to NuttX?
> > * What would be estimated workload and result?
> > * Would you like to port Wayland to NuttX?
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >

Re: FAT macro

[Alan C. Assis]

Hi Saurav,

I think you found a BUG!

Please report it at https://github.com/apache/nuttx/issues to keep a track
of it and when you we submit a PR it could be closed automatically (since
you link it at your PR).

In fact looking both macros the f to fs mistake becomes clear:

#define DIRSEC_NDXMASK(f)   (((f)->fs_hwsectorsize - 1) >> 5)

#define DIRSEC_BYTENDX(f,i) (((i) & DIRSEC_NDXMASK(fs)) << 5)

I'm curious to know what this mistake could cause to VFAT on NuttX?

Why haven't we seen any side effects in products using NuttX with VFAT?

Best Regards,

Alan

On Fri, Feb 2, 2024 at 1:55 PM Saurav Pal  wrote:

> Hi Alan,
>
> Thank you for looking at our code base and planning to add Documentation,
> > that is really important!
> >
> > NuttX has a long history but our Documentation is still lagging behind,
> so
> > your work will be very beneficial for our community.
> >
>
> I'll try my best to contribute some documentation for the various file
> systems I look into, and I, in turn, hope they are informative, and more
> importantly, correct, as I'm pretty new to the VFS layer of NuttX.
>
>
> > BTW, why do you think it is wrong, could you please share your thoughts?
> >
>
> The problem according to me is on L264...where it's defined as:
>
> #define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)
>
> I can't seem to find anything defined as *fs *in the namespace at that
> point (used in the fat_findsfnentry
>  >function),
> and I was wondering if it was a simple typo or a mistake on my part as it's
> code that's quite old, which usually don't have such mistakes due to
> extensive testing.
>
> Best Regards,
> Saurav
>

Re: FAT macro

[Saurav Pal]

Hi Alan,

Yeah I'll add an issue in the repo, and put a PR for fixing this. A quick
question...is there any standard on commit names, or should I just use my
own like "FIX: VFAT macro Issue#123"?

About why side effects have not been seen...like Lwazi explained,
macro DIRSEC_BYTENDX(f,
i) is always used as DIRSEC_BYTENDX(fs, inode), and so, in its expansion,
DIRSEC_NDXMASK(f) should become DIRSEC_NDXMASK(fs), and that weirdly
coincides with what the typo is, and so, it weirdly works how it was
intended to and does not give any errors.

Since it is a macro, even language servers (as far as the ones I know) do
not visually show their "unused parameters" warning like in the case proper
functions.

Regards,
Saurav

On Sat, Feb 3, 2024 at 1:11 AM Alan C. Assis  wrote:

> Hi Saurav,
>
> I think you found a BUG!
>
> Please report it at https://github.com/apache/nuttx/issues to keep a track
> of it and when you we submit a PR it could be closed automatically (since
> you link it at your PR).
>
> In fact looking both macros the f to fs mistake becomes clear:
>
> #define DIRSEC_NDXMASK(f)   (((f)->fs_hwsectorsize - 1) >> 5)
>
> #define DIRSEC_BYTENDX(f,i) (((i) & DIRSEC_NDXMASK(fs)) << 5)
>
> I'm curious to know what this mistake could cause to VFAT on NuttX?
>
> Why haven't we seen any side effects in products using NuttX with VFAT?
>
> Best Regards,
>
> Alan
>
> On Fri, Feb 2, 2024 at 1:55 PM Saurav Pal  wrote:
>
> > Hi Alan,
> >
> > Thank you for looking at our code base and planning to add Documentation,
> > > that is really important!
> > >
> > > NuttX has a long history but our Documentation is still lagging behind,
> > so
> > > your work will be very beneficial for our community.
> > >
> >
> > I'll try my best to contribute some documentation for the various file
> > systems I look into, and I, in turn, hope they are informative, and more
> > importantly, correct, as I'm pretty new to the VFS layer of NuttX.
> >
> >
> > > BTW, why do you think it is wrong, could you please share your
> thoughts?
> > >
> >
> > The problem according to me is on L264...where it's defined as:
> >
> > #define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)
> >
> > I can't seem to find anything defined as *fs *in the namespace at that
> > point (used in the fat_findsfnentry
> > <
> https://github.com/apache/nuttx/blob/master/fs/fat/fs_fat32dirent.c#L1137
> > >function),
> > and I was wondering if it was a simple typo or a mistake on my part as
> it's
> > code that's quite old, which usually don't have such mistakes due to
> > extensive testing.
> >
> > Best Regards,
> > Saurav
> >
>

Re: FAT macro

[Alan C. Assis]

Hi Saurav,

You can follow the steps here:
https://nuttx.apache.org/docs/latest/contributing/index.html

After running the checkpatch.sh and confirming everything is fine, you can
create a commit.

Basically your commit should be like this:

--
fs/vfat: Fix typo in the macro DIRSEC_BYTENDX

Some comments explaining what the commit is supposed to do!

Signed-off-by: Saurav Pal 
--

Best Regards,

Alan

On Fri, Feb 2, 2024 at 5:14 PM Saurav Pal  wrote:

> Hi Alan,
>
> Yeah I'll add an issue in the repo, and put a PR for fixing this. A quick
> question...is there any standard on commit names, or should I just use my
> own like "FIX: VFAT macro Issue#123"?
>
> About why side effects have not been seen...like Lwazi explained,
> macro DIRSEC_BYTENDX(f,
> i) is always used as DIRSEC_BYTENDX(fs, inode), and so, in its expansion,
> DIRSEC_NDXMASK(f) should become DIRSEC_NDXMASK(fs), and that weirdly
> coincides with what the typo is, and so, it weirdly works how it was
> intended to and does not give any errors.
>
> Since it is a macro, even language servers (as far as the ones I know) do
> not visually show their "unused parameters" warning like in the case proper
> functions.
>
> Regards,
> Saurav
>
> On Sat, Feb 3, 2024 at 1:11 AM Alan C. Assis  wrote:
>
> > Hi Saurav,
> >
> > I think you found a BUG!
> >
> > Please report it at https://github.com/apache/nuttx/issues to keep a
> track
> > of it and when you we submit a PR it could be closed automatically (since
> > you link it at your PR).
> >
> > In fact looking both macros the f to fs mistake becomes clear:
> >
> > #define DIRSEC_NDXMASK(f)   (((f)->fs_hwsectorsize - 1) >> 5)
> >
> > #define DIRSEC_BYTENDX(f,i) (((i) & DIRSEC_NDXMASK(fs)) << 5)
> >
> > I'm curious to know what this mistake could cause to VFAT on NuttX?
> >
> > Why haven't we seen any side effects in products using NuttX with VFAT?
> >
> > Best Regards,
> >
> > Alan
> >
> > On Fri, Feb 2, 2024 at 1:55 PM Saurav Pal  wrote:
> >
> > > Hi Alan,
> > >
> > > Thank you for looking at our code base and planning to add
> Documentation,
> > > > that is really important!
> > > >
> > > > NuttX has a long history but our Documentation is still lagging
> behind,
> > > so
> > > > your work will be very beneficial for our community.
> > > >
> > >
> > > I'll try my best to contribute some documentation for the various file
> > > systems I look into, and I, in turn, hope they are informative, and
> more
> > > importantly, correct, as I'm pretty new to the VFS layer of NuttX.
> > >
> > >
> > > > BTW, why do you think it is wrong, could you please share your
> > thoughts?
> > > >
> > >
> > > The problem according to me is on L264...where it's defined as:
> > >
> > > #define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)
> > >
> > > I can't seem to find anything defined as *fs *in the namespace at that
> > > point (used in the fat_findsfnentry
> > > <
> >
> https://github.com/apache/nuttx/blob/master/fs/fat/fs_fat32dirent.c#L1137
> > > >function),
> > > and I was wondering if it was a simple typo or a mistake on my part as
> > it's
> > > code that's quite old, which usually don't have such mistakes due to
> > > extensive testing.
> > >
> > > Best Regards,
> > > Saurav
> > >
> >
>

Re: FAT macro

[Saurav Pal]

Hi,

Thanks for the tip! I've created an issue and a PR, now waiting for a
review.

Regards,
Saurav

On Sat, Feb 3, 2024 at 1:57 AM Alan C. Assis  wrote:

> Hi Saurav,
>
> You can follow the steps here:
> https://nuttx.apache.org/docs/latest/contributing/index.html
>
> After running the checkpatch.sh and confirming everything is fine, you can
> create a commit.
>
> Basically your commit should be like this:
>
>
> --
> fs/vfat: Fix typo in the macro DIRSEC_BYTENDX
>
> Some comments explaining what the commit is supposed to do!
>
> Signed-off-by: Saurav Pal 
>
> --
>
> Best Regards,
>
> Alan
>
> On Fri, Feb 2, 2024 at 5:14 PM Saurav Pal  wrote:
>
> > Hi Alan,
> >
> > Yeah I'll add an issue in the repo, and put a PR for fixing this. A quick
> > question...is there any standard on commit names, or should I just use my
> > own like "FIX: VFAT macro Issue#123"?
> >
> > About why side effects have not been seen...like Lwazi explained,
> > macro DIRSEC_BYTENDX(f,
> > i) is always used as DIRSEC_BYTENDX(fs, inode), and so, in its expansion,
> > DIRSEC_NDXMASK(f) should become DIRSEC_NDXMASK(fs), and that weirdly
> > coincides with what the typo is, and so, it weirdly works how it was
> > intended to and does not give any errors.
> >
> > Since it is a macro, even language servers (as far as the ones I know) do
> > not visually show their "unused parameters" warning like in the case
> proper
> > functions.
> >
> > Regards,
> > Saurav
> >
> > On Sat, Feb 3, 2024 at 1:11 AM Alan C. Assis  wrote:
> >
> > > Hi Saurav,
> > >
> > > I think you found a BUG!
> > >
> > > Please report it at https://github.com/apache/nuttx/issues to keep a
> > track
> > > of it and when you we submit a PR it could be closed automatically
> (since
> > > you link it at your PR).
> > >
> > > In fact looking both macros the f to fs mistake becomes clear:
> > >
> > > #define DIRSEC_NDXMASK(f)   (((f)->fs_hwsectorsize - 1) >> 5)
> > >
> > > #define DIRSEC_BYTENDX(f,i) (((i) & DIRSEC_NDXMASK(fs)) << 5)
> > >
> > > I'm curious to know what this mistake could cause to VFAT on NuttX?
> > >
> > > Why haven't we seen any side effects in products using NuttX with VFAT?
> > >
> > > Best Regards,
> > >
> > > Alan
> > >
> > > On Fri, Feb 2, 2024 at 1:55 PM Saurav Pal 
> wrote:
> > >
> > > > Hi Alan,
> > > >
> > > > Thank you for looking at our code base and planning to add
> > Documentation,
> > > > > that is really important!
> > > > >
> > > > > NuttX has a long history but our Documentation is still lagging
> > behind,
> > > > so
> > > > > your work will be very beneficial for our community.
> > > > >
> > > >
> > > > I'll try my best to contribute some documentation for the various
> file
> > > > systems I look into, and I, in turn, hope they are informative, and
> > more
> > > > importantly, correct, as I'm pretty new to the VFS layer of NuttX.
> > > >
> > > >
> > > > > BTW, why do you think it is wrong, could you please share your
> > > thoughts?
> > > > >
> > > >
> > > > The problem according to me is on L264...where it's defined as:
> > > >
> > > > #define DIRSEC_BYTENDX(*f*,i) (((i) & DIRSEC_NDXMASK(*fs*)) << 5)
> > > >
> > > > I can't seem to find anything defined as *fs *in the namespace at
> that
> > > > point (used in the fat_findsfnentry
> > > > <
> > >
> >
> https://github.com/apache/nuttx/blob/master/fs/fat/fs_fat32dirent.c#L1137
> > > > >function),
> > > > and I was wondering if it was a simple typo or a mistake on my part
> as
> > > it's
> > > > code that's quite old, which usually don't have such mistakes due to
> > > > extensive testing.
> > > >
> > > > Best Regards,
> > > > Saurav
> > > >
> > >
> >
>