[HELP] Using espnow on NuttX for espressif devices

[Laczen]

Description

Hi, I would like to use the espnow from expressif to communicate between different esp32 based nodes. Can this be done using the raw packets net interface or is it better to create a dedicated driver?

If the raw packets net interface would work, has anyone already done this or has a good example on how to do this?

If a dedicated driver would be a better approach, can this driver be created while still maintaining normal wifi operation (of course on the same wifi channel)?

Verification

• I have verified before submitting the report.

[acassis]

@tmedicci @eren-terzioglu please take a look ^

[tmedicci]

Hi @Laczen,

It is not on our roadmap. But if this is really important for your application and you decide to get hands on, open a dedicated branch so we can help with ideas and suggestions.

As a starting point for your reference, please consider ESP-IDF's release/v5.1 branch: if a feature is supported by this version, It'd be virtually possible to be adapted for NuttX.

[Laczen]

Hi @tmedicci thanks for your reply.

I think this would be a good addition for nuttx. From the ESP-IDF release/v5.1 branch it seems that espnow is supported and has its own library.

Do you think it is a good idea to add support for espnow in a similar way as cc1101 and nrf24l01 ?

[tmedicci]

Do you think it is a good idea to add support for espnow in a similar way as cc1101 and nrf24l01 ?

It would be the easiest approach, but I don't think it's the most appropriate...

In my opinion, I think it should be registered as a network device (possibly as a NET_LL_PKTRADIO). Can you take a look at this approach, please?

[Laczen]

In my opinion, I think it should be registered as a network device (possibly as a NET_LL_PKTRADIO). Can you take a look at this approach, please?

Thanks, I will have a look at this approach.

[Laczen]

Hi @tmedicci I have been studying the NET_LL_PKTRADIO (I am still new in NuttX).

I would think that to add espnow as a network device I should take a similar approach to the spirit_netdev.c (https://github.com/apache/nuttx/blob/master/drivers/wireless/spirit/drivers/spirit_netdev.c) and create a espnow_netdev.c. But where in the three should espnow_netdev.c be added?

Should espnow_netdev.c be added at the same location of esp_wifi_adapter.c ?

Thanks in advance.

[tmedicci]

Hi @Laczen,

Usually, NuttX drivers are split into a lower-half and upper-half, as described here. Network drivers, however, doesn't seem to follow the same path. If you check about spirit_netdev.c's spirit_netdev_initialize function is being called directly from the board-level (from nuttx/boards/arm/stm32l4/b-l475e-iot01a/src/stm32_spirit.c, for instance).

That being said, as ESPnow is specific for Espressif devices, I think you should implement it on nuttx/arch/xtensa/src/common/espressif (once it can be used by more Espressif's SocS) in a similar way it's done for Wi-Fi (check esp32s3_net_initialize function, for instance).

[Laczen]

Hi @tmedicci I have been looking at integrating this but this seems like a quite difficult job.

I am wondering if it would not be simpler/more generic to extend the raw packet interface for esp32 to allow sending vendor action frames using esp_wifi_80211_tx and to accept these vendor action frames in the raw packet interface in promiscuous mode.

[Laczen]

Hi @tmedicci the promiscuous mode also doesn't seem like a good idea as it would block the normal wifi operation mode.

So I was thinking about the following approach:

1. Integrate espnow transport in the wifi device,
2. Packets from espnow are differentiated from other net packets by assigning them to Ethertype 0x88B5 (Local experimental Ethertype),
3. Based upon the Ethertype packets are send from the tx packet queue using esp_now_send or esp_wifi_internal_tx,
4. Packets received from espnow are added to the receive packet queue as Ethertype 0x88B5,

I would start with only allowing broadcast packets. Do you think this would be an acceptable approach ?

[tmedicci]

Hi @tmedicci the promiscuous mode also doesn't seem like a good idea as it would block the normal wifi operation mode.

So I was thinking about the following approach:

1. Integrate espnow transport in the wifi device,
2. Packets from espnow are differentiated from other net packets by assigning them to Ethertype 0x88B5 (Local experimental Ethertype),
3. Based upon the Ethertype packets are send from the tx packet queue using esp_now_send or esp_wifi_internal_tx,
4. Packets received from espnow are added to the receive packet queue as Ethertype 0x88B5,

I would start with only allowing broadcast packets. Do you think this would be an acceptable approach ?

Hi @Laczen !

I'm sorry for the late response, I was on vacation...

Yes, I think it's an acceptable approach. We need to have something working to fully understand all the pros and cons and suggest improvements. Were you able to work on that since then?

[Laczen]

Hi @tmedicci the promiscuous mode also doesn't seem like a good idea as it would block the normal wifi operation mode.
So I was thinking about the following approach:

1. Integrate espnow transport in the wifi device,
2. Packets from espnow are differentiated from other net packets by assigning them to Ethertype 0x88B5 (Local experimental Ethertype),
3. Based upon the Ethertype packets are send from the tx packet queue using esp_now_send or esp_wifi_internal_tx,
4. Packets received from espnow are added to the receive packet queue as Ethertype 0x88B5,

I would start with only allowing broadcast packets. Do you think this would be an acceptable approach ?

Hi @Laczen !

I'm sorry for the late response, I was on vacation...

Yes, I think it's an acceptable approach. We need to have something working to fully understand all the pros and cons and suggest improvements. Were you able to work on that since then?

Hi @tmedicci no problem for the late reply, hope you had a nice vacation.

Since the post I have been reading and studying the pktradio code (the pktradio loopback device is a better startpoint than the spirit device). The approach I'm working on now is to use make a 6lowpan over espnow. The espnow packets will all be broadcasts with the first part of the packet being the destination address.

I am still learning about the pktmeta, iob, ... but I will get there. As soon as I have the first working code I will create a PR to allow feedback.

[Laczen]

@tmedicci I have been doing some further work and I can send some packets to the network. I'm using the broadcast address 0xff, 0xff, ... and esp_now_send() returns 0. However as the wifi is also up it seems that sending (even to the broadcast address) triggers the routine esp_wifi_tx_done_cb with ifidx=255. Is this expected ?

My code is in not yet in a state to create a PR :).

[tmedicci]

@tmedicci I have been doing some further work and I can send some packets to the network. I'm using the broadcast address 0xff, 0xff, ... and esp_now_send() returns 0. However as the wifi is also up it seems that sending (even to the broadcast address) triggers the routine esp_wifi_tx_done_cb with ifidx=255. Is this expected ?

My code is in not yet in a state to create a PR :).

Hi @Laczen . I don't know... I'm tagging the Wi-Fi internally to check about it.

I will let you know when I have some feedback on this ;)