tmedicci commented on PR #11428: URL: https://github.com/apache/nuttx/pull/11428#issuecomment-2536365872
Hi @raiden00pl , I may have understood your concerns wrongly, but the current implementation is more like the _GOOD_ than the _BAD_. See, let's check `nuttx/boards/xtensa/esp32s3/common/src/esp32s3_board_rmt.c`s [`board_rmt_txinitialize`](https://github.com/apache/incubator-nuttx/blob/4ef01d98d526361b9348646dd1fd09f3faff88c0/boards/xtensa/esp32s3/common/src/esp32s3_board_rmt.c#L121). This function initializes both the generic RMT driver and the RMT-based WS2812 driver. Note that, the RMT peripheral is initialized by [`esp_rmt_tx_init`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L1964), which is arch-specific (lower-half). Although not implemented, calling `rmtchar_register` here to register the generic RMT driver is totally optional. `esp_ws2812_setup` uses the lower half initialized by `esp_rmt_tx_init`. Backing to [`esp_rmt_tx_init`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L1964): it calls [`esp_rmtinitialize`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L1859) which registers `priv->ops = &g_rmtops;` [here](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L1928). [`g_rmtops`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L399) registers the [`esp_rmt_read`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L1750) and [`esp_rmt_write`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt .c#L1812) to `struct rmt_ops_s`'s `read` and `write`. Both [`esp_rmt_read`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L1750) and [`esp_rmt_write`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L1812) are implemented by arch code (lower-half): this seems to be the "RMT_COMMON". [`esp_ws2812_setup`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_ws2812.c#L563) receives a structure of the RMT lower-half driver initialized by `esp_rmt_tx_init`. The registered `write` function for `struct ws2812_dev_s` is [`esp_write`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_ws2812.c#L431) (defined at `arch/xtensa/src/common/espressif/esp_ws2812.c`, i.e. a lower-half interface). This function end-up calling [`priv->rmt->ops->write()`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_ws2812.c#L510), which is the [`esp_rmt_write`](https://github.com/apache/incubator-nuttx/blob/8d50457dfc6f79f58487fb33c42407f115e94de6/arch/xtensa/src/common/espressif/esp_rmt.c#L1812) function of the lower-half driver (not the upper-half). As we used commonly-u sed names (read/write), this may have caused the confusion here. Also, please note that the `struct rmt_ops_s` (at [include/nuttx/rmt/rmt.h](https://github.com/apache/incubator-nuttx/blob/cd2fcf52520314bf375b4ffbf2ee527f53a0d23a/include/nuttx/rmt/rmt.h)) isn't part of the upper-half generic RMT driver ([nuttx/include/nuttx/rmt/rmtchar.h](https://github.com/apache/incubator-nuttx/blob/cd2fcf52520314bf375b4ffbf2ee527f53a0d23a/include/nuttx/rmt/rmtchar.h). I agree that the location of the `rmt.h` file could be understood like that (and should eventually be moved to the arch folder, although it is used by more than a arch) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
