Hello,
I have a MMECH08 hooked up to my ESP32S3 and I have already got all the examples in mm-iot-esp32 working perfectly fine.
The question I have is most of these examples seem to be using the MorseMicros implementation of iPerf, I can’t find a good example/documentation that explains how I can actually glue the MM6108 to the network stack to be able to use the existing esp-idf API for the rest of the application.
I keep seeing comments like this all over the code:
/**
Receive callback. This is invoked when a packet is received, which is typically passed to the network stack.
*/
and tracing these functions lead to a header file with minimal explanation., which makes it difficult to follow. Documentation seems to be mostly empty for these areas as well.
I would appreciate any guidance, pointers on this. I believe maybe adding an example that utilizes esp_http_client for example or really anything past the esp-idf’s built in network stack would help all the users.
1. Examples utilizing some of the Espressif examples
As it so happens I have been working on exactly this recently in my spare time . I’ve put my current state of the art up on github for you to have a look at. I currently have two examples
A http webserver that you can hit to view an image captured by a camera attached to the esp32
A mqtt client that will publish and image taken by a camera attached to the esp32
It’s still early days but I think it should give you a good starting point for integrating HaLow into other examples in the esp-idf. Any feedback or additions would be more than welcome.
2. How can you glue the MM6108 to the network stack
I think a good starting point to understanding this is to take a look at this comment Documentation SPI Command Set MM6108-MF08651-US - #8 by matt . In that comment you can see the ‘LWIP Shim’ is the glue that allows the network interface to talk to the MM6108. The code for this can be found here for the mm-iot-esp32 repo. An important thing to keep in mind is this is just the data-path (i.e. Ethernet frames) and does not cover WLAN control API (connect, disconnect), they are all handled separately through the mmwlan API.
So effectively there is going to be a call to transmit date and a call the receive data. In the case of mm-iot-esp32-2.6.4 these are (glossing over details like packet allocation and link status):
/**
* Transmit the given packet. The packet must start with an 802.3 header, which will be
* translated into an 802.11 header by this function.
....
*/
enum mmwlan_status mmwlan_tx_pkt(struct mmpkt *pkt, const struct mmwlan_tx_metadata *metadata);
and
/**
* Receive data packet callback function.
*
* @param header Buffer containing the 802.3 header for this packet.
* @param header_len Length of the @p header.
* @param payload Packet payload (excluding header).
* @param payload_len Length of @p payload.
* @param arg Opaque argument that was given when the callback was registered.
*/
typedef void (*mmwlan_rx_cb_t)(uint8_t *header, unsigned header_len,
uint8_t *payload, unsigned payload_len,
void *arg);
/**
* Register a receive callback.
*
* @note Only one receive callback may be registered. Further registration will overwrite the
* previously registered callback.
*
* @note Only a single receive callback may be registered at a time.
*
* @param callback The callback to register (@c NULL to unregister).
* @param arg Opaque argument to be passed to the callback.
*
* @return @ref MMWLAN_SUCCESS on success, else an appropriate error code.
*/
enum mmwlan_status mmwlan_register_rx_cb(mmwlan_rx_cb_t callback, void *arg);
Hi Rob,
Thank you very much for getting back to me and sharing this nice repo!
I had done some studying and interestingly enough I had gotten to the same conclusion as you did, mmiot seems to be tapping directly to LWIP and it should be really integrated with esp_netif instead. I will try to do this and see how far I get (famous last word?)
One challenge I have is during the test phase we are using esp32-s3 (coincidentally it’s esp32 XIAO!), but for the final product we are planning to use ESP32-P4, however seems like morselib is all assembled files for extensa lx7 only! Is it possible to get the actual source so we can modify and recompile for RISCV with an NDA?
We don’t currently provide the actual source. However, it is something that is being worked on. Unfortunately, I don’t have a concrete date to give you for it though.
Thanks @Rob
I noticed everytime my board boots up, it has a random mac address. Can you provides insight as to where the mac is comming from? is it randomly generated?
Currently the driver will attempt to read the MAC burnt into the OTP of the MM6108, if there isn’t one it will fall back to a randomly generated one. If you are using a module I believe it will have the MAC burnt already (I’m not 100% on this fact).
The other option is to provide one based on something unique in the host MCU. I.e. for the STM based platforms there is an option to derive one based on the UID (number burnt by STM during manufacturing from memory).
Uhuh!
Perfect.
When I was using the MMECH08 V2 Shim, it seems like the Mac was in fact burned into an OTP.
I’m now using a MM6108-MF08651-US Module I bought off of Mouser, even thought it’s the same exact part number from MMECH08, it does not have it burned into OTP.
Thank you for pointing me to the ‘mmhal_read_mac_addr’ function, I had found that but since I can’t see the underlying code inside the object files, I just wanted to make sure I’m at the correct place. I’m now just setting it to ESP32’s STA mac and things are fine and dandy!
@guru69, would you mind sending through a photo of the sticker on the top of the MM6108-MF08651-US module? That way we can chase up the history of the module internally.
More over, are there any updates on the source for MM-IOT libraries? We are designing our Prototype with ESP32-P4, however we haven’t been able to move things forward ont he FIrmware Side due to lack of source code.
. I’ve put my current state of the art up on github for you to have a look at. I currently have two examples