Hello,
I suggest people have a look at the RF interface that was rejected when
I suggested it.
Just to see if that could contribute something to the proposal.
There was ONE upper half driver with an unified ioctl interface for all
radio devices.
https://git.sr.ht/~f4grx/hn70ap/tree/main/item/board/src/genradio_ioctl.h
Lower half drivers could register with this driver through a device api.
https://git.sr.ht/~f4grx/hn70ap/tree/main/item/board/src/drv_genradio.h
The driver is incomplete but functional and I can donate it to the nuttx
project (update copyright notices as required).
https://git.sr.ht/~f4grx/hn70ap/tree/main/item/board/src/drv_genradio.c
I have used it with the si4463 using a wds canned config.
A modem calculator was a project but it's incomplete yet, and based on
reverse engineering, so IDK if that could be integrated.
Sebastien
On 14/03/2025 09:49, raiden00pl wrote:
I have doubts whether adding more kconfig options that basically do nothing
makes any sense.
NuttX configuration is already very complicated and making it even more
complicated seems
like a bad idea. We should describe the change well in the ReleaseNotes and
that should be
enough. It should be the responsibility of the developers to describe the
breaking change well
in the release notes, and it should be the responsibility of users
migrating to another version
to read the release notes.
pt., 14 mar 2025 o 00:47 Nathan Hartman <hartman.nat...@gmail.com>
napisał(a):
Hi all,
I like the fact that there has been a high level analysis here and an
effort to make things consistent across multiple types of communications.
Since the drivers mentioned are experimental, I agree that breaking changes
aren't breaking stabilized interfaces.
We should just be careful to mention this in the release notes because this
could create a long debugging session for someone.
Here's an idea: there could be a Kconfig that must be defined if using any
of these drivers. Some kind of
CONFIG_I_KNOW_ABOUT_THE_BREAKING_CHANGES_IN_THE_RF_DRIVERS. (That should
*not* be its name; I'm only writing it to illustrate my idea.) If this
Kconfig isn't present, #ifdef logic in the source code will deliberately
break the build with #error directive, and adjacent documentation in the
comments. This will ensure that nobody using the ioctl as it currently is
will have any head scratching and long debugging session. Thoughts?
Nathan
On Thu, Mar 13, 2025 at 4:50 PM Kevin Witteveen <kevinwit1...@gmail.com>
wrote:
Hi Nuttx,
This is a follow-up to GitHub issue #15856
<https://github.com/apache/nuttx/issues/15856> initiated by raiden00pl.
The
discussion there provides useful context for this proposal.
*--- Summary ---*
Currently, the IOCTL API for character-driven RF devices lacks a common
interface across different modulation technologies, such as LoRa, FSK,
and
OOK. As a result, driver-specific IOCTL commands are created even when
they
could be shared across multiple radios. This fragmentation makes
application portability more difficult to maintain.
*--- Impact ---*
This does require some changes to be made to 4 RF drivers.
- My SX126x (New, experimental)
- Raiden SX127x,
- Linguini RN2xx3 (New, experimental)
- nRF
The three of us—Raiden, Linguini, and I—support this idea and are already
involved in the development. Once implemented, this common API would make
it easier for IoT applications to run on NuttX with minimal
driver-specific
modifications, reducing maintenance overhead and eliminating redundant
implementations.
*--- Breaking ---*
This is considered a breaking change if the following IOCTL command may
be
changed:
WLIOC_SETTXPOWER takes an integer value for dB. This can be changed to
steps of 1/100 dB instead. Because the RN2xx3 and some radios can take
smaller values. (*Open for discussion)*
However, the RN2xx3 and SX126x drivers are marked experimental, so any
modifications to these are *not* considered breaking.
*--- Strategy ---*
1. Introduce new IOCTL commands without modifying legacy
implementations.
2. Gradually migrate existing drivers to the new API while testing and
documenting.
3. Remove legacy implementations
To avoid breaking changes, we could retain the legacy APIs if desired and
only remove the *experimental* ones.
*--- Proposal API header ---*
https://github.com/keever50/nuttx/blob/common_wireless_character_driver_API/include/nuttx/wireless/ioctl.h
I collaborated with Raiden and Linguini on defining these IOCTL commands.
Feedback and suggestions from the community would be greatly appreciated.
*--- Note about "Experimental" ---*
The SX126x and RN2xx3 drivers are marked as experimental, meaning users
are
explicitly warned that changes may occur in the near future. They were
labeled as such before being merged.
Looking forward to your thoughts!
Best regards,
Kevin (Keever50 on github)
