espnow missing some functions to get going

[TrueBrain]

Initially I wanted to make a PR for this, but before I do it might be better to check if I am overlooking something.

While trying out ESPNow, I noticed a few missing pieces:

• There is no helper function to get the MAC address to use for ESPNow. Of course esp-idf-sys has it, but that is less nice. Currently I did: esp!(esp_wifi_get_mac(wifi_mode_t_WIFI_MODE_NULL, &mut mac as *mut c_types::c_uchar))?;. I think a nice helper function either in espnow or in wifi would greatly help the next guy trying out ESPNow.
• I couldn't find a function that does an esp_wifi_start() in STA, without actually connecting to an AP. set_configuration does a lot more than is needed for ESPNow. For now I settled on:

        esp!(esp_wifi_set_mode(wifi_mode_t_WIFI_MODE_STA))?;
        esp!(esp_wifi_start())?;

But here too it might be useful to have a simple wrapper function.

Am I overlooking something, or would it be fine if I make a PR to wrap both in a nice little function? I was thinking of putting the first one in espnow, as there are several MAC addresses assigned to an ESP, but only one works with ESPNow. The second I guess belongs in wifi, so something like start_sta() or something?

Tnx :)

[MabezDev]

I'm not too familiar with how espnow works (I'll do some reading), but PR's would be most welcome!

[ivmarkov]

• I couldn't find a function that does an esp_wifi_start() in STA, without actually connecting to an AP. set_configuration does a lot more than is needed for ESPNow. For now I settled on:

        esp!(esp_wifi_set_mode(wifi_mode_t_WIFI_MODE_STA))?;
        esp!(esp_wifi_start())?;

In the latest esp-idf-svc (the master branch) it will be possible to start the Wifi stack without doing a connection. :)

I'll think about the mac stuff. If we expose it in Wifi, we need to in Eth as well.

[ivmarkov]

I've now added get/set_mac pair of functions to WifiDriver and EspWifi which should address the remaining open bits in this issue. Getting/setting MAC for Eth is much more involved, so I've postponed implementing a symmetrical API there.