cpu/esp*: esp_now and esp_wifi cleanup by gschorcht · Pull Request #10929 · RIOT-OS/RIOT

gschorcht · 2019-02-02T14:02:06Z

Contribution description

This PR is a cleanup of modules esp_now and esp_wifi to get them working together, for example to realize a border router which connects an ESP-NOW based mesh network of ESP32 an ESP8266 nodes with an infrastructure mode WiFi network.

Testing procedure

Build a border router using project RIOT_ESP_NOW_WiFi_Border_Router and some ESP-NOW nodes. Follow the instructions in README.md.

Although the test could be performed on either ESP8266 nodes or ESP32 nodes only, a configuration is recommended in an ESP32 is used as border router and ESP8266s are used as ESP NOW nodes.
[Update] ~~However, if an ESP8266 is used as a boundary router, RPL must not be enabled due to its limited RAM.~~ After merging PR # 10981, the limited amount of RAM for ESP8266 should no longer be a problem.

Issues/PRs references

~~Since it cleans up esp_wifi for ESP32 as well as ESP8266, it depends on PR #9917.~~

gschorcht · 2019-04-12T08:50:50Z

@smlng The same as with PR #10883

MrKevinWeiss · 2019-06-13T12:29:02Z

release status ping, should I change the milestone?

gschorcht · 2019-06-17T07:13:23Z

@MrKevinWeiss I have to find some time to rebase it. I will try it in next days. And of course, someone would have to review it 😄

MrKevinWeiss · 2019-06-17T07:35:55Z

Great, when you do I will test and mercilessly bug @smlng for the review

MrKevinWeiss · 2019-06-25T16:51:23Z

I just want to see if murdock is happy. I can try testing soon.

MrKevinWeiss

Well I don't know what I did but I followed the testing procedure and was able to ping6 back and forth with a esp border router and node using rpl (with this PR). I don't know if that counts as tested, I think it was only with the esp_now though.

gschorcht · 2019-06-26T13:27:37Z

@MrKevinWeiss Most import is that both network interfaces esp_wifi and esp_now can be used simultaneously.

First, you should check on the border router whether it can connect to the configured WiFi AP.

[esp_wifi] associated with ssid whatever

Second, you should be able to ping another ESP-NOW node using network interface esp_now and any computer in your LAN using network interface esp_wifi at the same time.

I guess these both tests could also be done using examples/gnrc_networking

USEMODULE='esp_now esp_wifi' \
CFLAGS='-DESP_NOW_CHANNEL=<channel> -DESP_WIFI_SSID=\"<SSID>\" -DESP_WIFI_PASS=\"<passphrase>\"' \
make BOARD=... PORT=/dev/... flash

Please note, the channel used for ESP-NOW has to be the same as the channel used by your WiFi AP.

If you use the ESP-NOW to WiFi border router project and you configure a route to 2001:db8::/64 on your machine in the LAN using the link local unicast address of the WiFi interface of the border router, you should be able to ping the ESP-NOW nodes from your machine and vise versa.

MrKevinWeiss · 2019-06-28T12:38:50Z

ping @smlng I would have like this for the release.

smlng

LGTM code-wise, haven't tested myself but: @MrKevinWeiss if you're confident do the merge

MrKevinWeiss · 2019-06-28T12:55:16Z

OK. I will retest on Monday. If possible can you squash and fix the murdock errors?

gschorcht · 2019-06-29T12:15:38Z

@MrKevinWeiss I fixed the problems in TravisCI and Murdock but I didn't squash yet so that you are able to see how I had them to fix.

MrKevinWeiss · 2019-06-29T20:11:45Z

Many thanks. It is squash time!

kaspar030 · 2019-06-29T22:17:52Z

cpu/esp_common/include/cpu_conf.h

+
+#ifdef __cplusplus
+}
+#endif /* CPU_CONF_H */


(comment wrong)

gschorcht · 2019-07-30T13:49:00Z

@MrKevinWeiss I tested it again with two ESP32s in another environment where I had problems too as long as the LAN doesn't use global unicast addresses 2000::/3.

That is, as long as ESP32's WiFi interface and the machine in the LAN have only link local addresses fe80::/10, pinging the ESP-NOW network from LAN does not work. After setting the global unicast adresses by hand

ESP32: ifconfig 8 add unicast 2001:db9::1/64
LAN node: ip -6 addr add 2001:db9::2/64 dev eth0

pinging the ESP-NOW node behind the border router worked without problems. Of course, The route to 2001:db8::/64 has to be set ip -6 route add 2001:db8::/64 via 2001:db9::1 dev eth0.

Did you have global unicast addresses in your LAN?

MrKevinWeiss · 2019-07-30T15:34:38Z

Tested again with the additional CFLAGS += -DGNRC_NETIF_IPV6_ADDRS_NUMOF=4 and it still doesn't work.

All I want to do is ping the esp node from the esp border router when the esp border router is connected to wifi. If I enter the wrong wifi ssid I can ping the esp node and if the wifi ssid is correct it cannot ping.

gschorcht · 2019-07-30T15:50:50Z

@MrKevinWeiss Did you use the global unicast address 2001:db8:: or the link local address fe80:: for pinging the ESP-NOW node from the border router? In latter case, you would have to specify the interface that should be use for pinging.

gschorcht · 2019-07-30T16:59:27Z

@MrKevinWeiss I set up a completly new test environment which exactly corresponds to your test environment:

+-------+      +---------+     +-------+     +---------+
| Linux |------| WiFi AP |-----| ESP32 |-----|  ESP32  |
+-------+      +---------+     |  BR   |     | ESP-NOW |
                               +-------+     +---------+

On border router:

> ifconfig
Iface  7  HWaddr: 30:AE:A4:18:7A:3D 
          L2-PDU:249 MTU:1280  HL:64  RTR  
          RTR_ADV  6LO  Source address length: 6
          Link type: wireless
          inet6 addr: fe80::32ae:a4ff:fe18:7a3d  scope: local  VAL
          inet6 addr: 2001:db8::32ae:a4ff:fe18:7a3d  scope: global  VAL
          ...

Iface  8  HWaddr: 30:AE:A4:18:7A:3C  Link: up 
          L2-PDU:1500 MTU:1500  HL:64  RTR  
          Source address length: 6
          Link type: wireless
          inet6 addr: fe80::32ae:a4ff:fe18:7a3c  scope: local  VAL
          inet6 addr: fd22:5c78:9ead:8:32ae:a4ff:fe18:7a3c  scope: global  VAL
          inet6 addr: fd35:ed4d:6c92:0:32ae:a4ff:fe18:7a3c  scope: global  VAL
          ...

On ESP-NOW node:

> ifconfig
Iface  9  HWaddr: 30:AE:A4:41:60:F9 
          L2-PDU:249 MTU:1280  HL:64  RTR  
          RTR_ADV  6LO  Source address length: 6
          Link type: wireless
          inet6 addr: fe80::32ae:a4ff:fe41:60f9  scope: local  VAL
          inet6 addr: 2001:db8::32ae:a4ff:fe41:60f9  scope: global  VAL

Pinging border router from Linux:

$ ping6 fd22:5c78:9ead:8:32ae:a4ff:fe18:7a3c
PING fd22:5c78:9ead:8:32ae:a4ff:fe18:7a3c(fd22:5c78:9ead:8:32ae:a4ff:fe18:7a3c) 56 data bytes
64 bytes from fd22:5c78:9ead:8:32ae:a4ff:fe18:7a3c: icmp_seq=3 ttl=64 time=62.2 ms
64 bytes from fd22:5c78:9ead:8:32ae:a4ff:fe18:7a3c: icmp_seq=4 ttl=64 time=85.7 ms
64 bytes from fd22:5c78:9ead:8:32ae:a4ff:fe18:7a3c: icmp_seq=5 ttl=64 time=206 ms

Pinging ESP-NOW node from ESP32 border router:

> ping6 2001:db8::32ae:a4ff:fe41:60f9
12 bytes from 2001:db8::32ae:a4ff:fe41:60f9: icmp_seq=0 ttl=64 time=7.681 ms
12 bytes from 2001:db8::32ae:a4ff:fe41:60f9: icmp_seq=1 ttl=64 time=7.565 ms
12 bytes from 2001:db8::32ae:a4ff:fe41:60f9: icmp_seq=2 ttl=64 time=6.103 ms

> ping6 fe80::32ae:a4ff:fe41:60f9

--- fe80::32ae:a4ff:fe41:60f9 PING statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

> ping6 fe80::32ae:a4ff:fe41:60f9%7
12 bytes from fe80::32ae:a4ff:fe41:60f9: icmp_seq=0 ttl=64 time=7.452 ms
12 bytes from fe80::32ae:a4ff:fe41:60f9: icmp_seq=1 ttl=64 time=6.515 ms
12 bytes from fe80::32ae:a4ff:fe41:60f9: icmp_seq=2 ttl=64 time=6.069 ms

On Linux:

$ sudo ip -6 route add 2001:db8::/64 via fd22:5c78:9ead:8:32ae:a4ff:fe18:7a3c
$ ping6 2001:db8::32ae:a4ff:fe41:60f9
PING 2001:db8::32ae:a4ff:fe41:60f9(2001:db8::32ae:a4ff:fe41:60f9) 56 data bytes
64 bytes from 2001:db8::32ae:a4ff:fe41:60f9: icmp_seq=1 ttl=63 time=35.9 ms
64 bytes from 2001:db8::32ae:a4ff:fe41:60f9: icmp_seq=2 ttl=63 time=41.5 ms
64 bytes from 2001:db8::32ae:a4ff:fe41:60f9: icmp_seq=3 ttl=63 time=63.4 ms

So the environment looks exactly like yours. I can ping the ESP-NOW node with connected WiFi interface either using its global unicast address 2001:db8::32ae:a4ff:fe41:60f9 or its link local address when specifying the interface fe80::32ae:a4ff:fe41:60f9%7.

After setting the route on the Linux machine to 2001:db8::/64, I can also ping the ESP-NOW node directly from my Linux machine.

Sorry, when I'm nerving a bit, but could you double check whether you have tried in exactly this way., please. There is no reason why it should not work in your environment.

Update: No matter whether RPL is activated on BR or not. RPL is not required for direct links between the border router and the ESP-NOW node.

MrKevinWeiss · 2019-07-30T17:26:08Z

I know, I am sorry that I cannot get it but I really would like for anyone else to test to confirm.
@smlng @MichelRottleuthner @leandrolanzieri
Anyone try this out. I just cannot ack the testing if it isn't working for me.

Downsized numbers of dynamic send and receive buffers.

gschorcht · 2019-07-31T11:55:10Z

Rebased

MichelRottleuthner · 2019-07-31T15:32:00Z

I tested with the freshly rebased version and the following setup: PC<->WiFiAP<->ESPbr<->ESPnow

Both ESPs used gnrc_networking, programed as follows:
ESPbr:

USEMODULE='esp_now esp_wifi' \
CFLAGS='-DGNRC_IPV6_NIB_CONF_SLAAC=1 -DGNRC_NETIF_IPV6_ADDRS_NUMOF=4 -DESP_NOW_CHANNEL=11 -DESP_WIFI_SSID=\"somessid\" -DESP_WIFI_PASS=\"somepw\"' \
make BOARD=esp32-wroom-32 PORT=/dev/ttyUSB0 all flash term

ESPnow:

USEMODULE='esp_now' CFLAGS='-DESP_NOW_CHANNEL=11' make all flash term BOARD=esp32-wroom-32 PORT=/dev/ttyUSB1

Notes:
GNRC_NETIF_IPV6_ADDRS_NUMOF=4 was added because the ESPbr already needs to store two addresses it gets from the WiFiAP plus its own LLA.
Without GNRC_IPV6_NIB_CONF_SLAAC=1 all the addresses on ESPbr's esp_wifi interface were marked as tentative so pinging other hosts from ESPbr didn't work.

Setup of the nodes:
ESPnow: nothing

ESPbr:

ifconfig 9 add 2001:db8::1
rpl init 9
rpl root 1 2001:db8::1

PC:

*connect to same WiFiAP as ESPbr*
ip -6 route add 2001:db8::/64 via <global_IPv6_addr_of_ESPbr> dev <wireless_interface>

Using that setup everything worked: I could ping every host from every other host in the setup.

I found one (unrelated?) problem where I left the ESPbr in this setup running without using it and after around 40 minutes it printed the following message before the shell stopped responding to input:
W (1422385) [ wifi]: no timer handle. Though, I didn't manage to reproduce it yet.

Nonetheless I can confirm that this PR indeed enabled using esp_now and esp_wifi on the same node, so I will add the tested label.

MichelRottleuthner · 2019-07-31T15:34:32Z

I'll leave merging to @MrKevinWeiss or @smlng as I didn't have the slightest look at the code ;)

gschorcht · 2019-07-31T15:43:00Z

@MichelRottleuthner Many thanks for testing it . Theses are really good news. I'm really happy that someone else than me could get it working 🚀

The problem you saw might have the same reason as the problem I described in issue #11941. I'm already investigating it and it seems that it is caused to be caused by using mutexes in WiFi interface callbacks within interrupt context. I have already changed it in a test version which seems to be working stable, also with multiheap enabled.

My setup was bad

MrKevinWeiss · 2019-08-01T07:55:15Z

Many thanks @MichelRottleuthner now that we confirmed it was my setup I am happy to merge it. Also the documentation seems good.

gschorcht · 2019-08-01T07:57:39Z

Thank you all for your support and your patience 😄

gschorcht added Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation Platform: ESP Platform: This PR/issue effects ESP-based platforms Area: cpu Area: CPU/MCU ports labels Feb 17, 2019

gschorcht mentioned this pull request Feb 17, 2019

cpu/esp8266: esp-now network device support #9917

Merged

gschorcht added this to the Release 2019.04 milestone Mar 3, 2019

gschorcht mentioned this pull request Mar 5, 2019

cpu/esp8266: complete reimplementation based on ESP8266 RTOS SDK #11108

Merged

20 tasks

gschorcht mentioned this pull request Apr 12, 2019

cpu/esp*: Xtensa vendor code moved to esp_common #10883

Merged

gschorcht requested a review from smlng April 12, 2019 08:50

miri64 modified the milestones: Release 2019.04, Release 2019.07 May 7, 2019

MrKevinWeiss self-requested a review June 17, 2019 07:34

gschorcht force-pushed the esp_now_wifi_cleanup branch 2 times, most recently from 2591165 to 6d0651e Compare June 24, 2019 12:52

MrKevinWeiss added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jun 25, 2019

MrKevinWeiss reviewed Jun 25, 2019

View reviewed changes

smlng approved these changes Jun 28, 2019

View reviewed changes

kaspar030 reviewed Jun 29, 2019

View reviewed changes

gschorcht added 9 commits July 31, 2019 13:53

cpu/esp32: esp_wifi compile configuration tuned

1492f00

Downsized numbers of dynamic send and receive buffers.

cpu/esp*: shorter netdev task names

f34a1a3

cpu/esp_common: cleanup of compile time config

9db62bd

cpu/esp_common: add/fix comments and messages

8f0f8f5

cpu/esp_common: set WiFi config storage type

636c084

cpu/esp32: cleanup comments/messages in esp_wifi

9981d2b

cpu/esp32: set WiFi config storage type

96a9949

cpu/esp_common: doc fixes

760168e

cpu/esp*: changes to use esp_wifi and esp_now

97bb337

gschorcht force-pushed the esp_now_wifi_cleanup branch from a8fe593 to 97bb337 Compare July 31, 2019 11:54

MichelRottleuthner added the Reviewed: 3-testing The PR was tested according to the maintainer guidelines label Jul 31, 2019

MrKevinWeiss added the Reviewed: 5-documentation The documentation details of the PR were reviewed according to the maintainer guidelines label Aug 1, 2019

MrKevinWeiss merged commit 2be1323 into RIOT-OS:master Aug 1, 2019

MrKevinWeiss approved these changes Aug 1, 2019

View reviewed changes

gschorcht deleted the esp_now_wifi_cleanup branch August 1, 2019 07:57

gschorcht mentioned this pull request Aug 1, 2019

cpu/esp32: critcial section handling changed in FreeRTOS adaptation layer #11947

Merged

gschorcht restored the esp_now_wifi_cleanup branch September 18, 2019 16:15

gschorcht deleted the esp_now_wifi_cleanup branch September 18, 2019 16:52

Conversation

gschorcht commented Feb 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution description

Testing procedure

Issues/PRs references

Uh oh!

gschorcht commented Apr 12, 2019

Uh oh!

MrKevinWeiss commented Jun 13, 2019

Uh oh!

gschorcht commented Jun 17, 2019

Uh oh!

MrKevinWeiss commented Jun 17, 2019

Uh oh!

MrKevinWeiss commented Jun 25, 2019

Uh oh!

MrKevinWeiss left a comment

Choose a reason for hiding this comment

Uh oh!

gschorcht commented Jun 26, 2019

Uh oh!

MrKevinWeiss commented Jun 28, 2019

Uh oh!

smlng left a comment

Choose a reason for hiding this comment

Uh oh!

MrKevinWeiss commented Jun 28, 2019

Uh oh!

gschorcht commented Jun 29, 2019

Uh oh!

MrKevinWeiss commented Jun 29, 2019

Uh oh!

kaspar030 Jun 29, 2019

Choose a reason for hiding this comment

Uh oh!

gschorcht Jun 30, 2019

Choose a reason for hiding this comment

Uh oh!

gschorcht commented Jul 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MrKevinWeiss commented Jul 30, 2019

Uh oh!

gschorcht commented Jul 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gschorcht commented Jul 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MrKevinWeiss commented Jul 30, 2019

Uh oh!

gschorcht commented Jul 31, 2019

Uh oh!

MichelRottleuthner commented Jul 31, 2019

Uh oh!

MichelRottleuthner commented Jul 31, 2019

Uh oh!

gschorcht commented Jul 31, 2019

Uh oh!

MrKevinWeiss commented Aug 1, 2019

Uh oh!

gschorcht commented Aug 1, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

gschorcht commented Feb 2, 2019 •

edited

Loading

gschorcht commented Jul 30, 2019 •

edited

Loading

gschorcht commented Jul 30, 2019 •

edited

Loading

gschorcht commented Jul 30, 2019 •

edited

Loading