New Debug Boards + Network Stack Hotness
about 6 years ago
– Sat, Dec 08, 2018 at 12:15:22 AM
Hey folks! We’ve been heads down working away on Meadow and we got our newly assembled debug boards back on Wednesday! I wanted to talk about those a little bit, and while I’m at it, I thought I would talk a little about how our networking stack works and some of the cool work we’ve been doing there.
First up, our debug boards. Here’s a shot of one of them after I soldered on our headers:
You’ll notice that there are female headers on there for GPIO; I find that unless I’m specifically plugging into a FeatherWing, female headers are much more friendly for use, as opposed to male headers on the bottom that plug into a breadboard.
By the way, here’s a shot comparing the debug and the final form factor of the board (both with the female headers on there):
I shipped these new boards off to the team around the world yesterday, so now the team will sit down and start validating the various corners of the hardware, specifically for this prototype; the Network hardware.
The last debug prototype didn’t expose a JTAG header for the ESP32 chip, which meant that we couldn’t flash and test it easily. Instead, we’ve been doing our network stack work on an ESP32 dev board. Now it’s time to bring a bunch of that stuff together though. Speaking of network stack...
Network Stack Hotness...
We’ve done some really cool architecture in our Network and comms stack that I think you’ll all dig. In this particular Meadow board, WiFi and Bluetooth functionality is provided by the ESP32 chip, because the STM32F7 has ethernet capabilities but no radio stuff. In future boards, we’ll swap out WiFI and Bluetooth for other gateway technologies like LTE or 5G, LoRaWan, ZWave, ZigBee, etc.
We therefore needed a flexible architecture in which we could swap out various gateway modems and support them with minimum effort as well as provide a seamless API, where you, as the developer don’t have to worry about how network capabilities are provided, but rather, they just work.
Basically, what we’ve done, is turned the ESP32 chip into a generic modem peripheral and written a serial comm protocol to talk to it from the STM32 chip (the STM32 and the ESP32 are connected via UART and SPI, more on the SPI stuff later).
This protocol works like this; when we talk to the ESP32, we send messages over that and have a header that describes what the message is for. For instance, it could be a WiFi message, a Bluetooth message, or any other configurable thing we want to communicate about. So if we need to enumerate WiFi networks, for instance, we send a “WiFi”-headered message to the ESP32 chip, telling it that’s what we want to do, and then it sends those back as it discovers them. When we do a data request to a web resource, we use the same basic pattern, effectively making the ESP32 chip a UART modem.
But there’s some additional magic there; in order to make this a seamless experience for the developer, once you configure your network device, be it telling the F7 to connect to a WiFi network, or in a future model, configuring LTE to connect, once that network gateway has been configured: network calls just work. So if you made used HttpWebRequest, or a System.Net socket call, they go over the configured network device seamlessly, no matter what that physical device is. You just have to configure it and forget it.
The way that we accomplished this, is by creating a network driver that plugs deep into the Mono/.Net stack in a place called the Platform Application Layer (PAL) that knows how to talk to our external modem, via our custom protocol.
The upshot of this is that in the future, we can easily add new gateways and all we have to do is add the appropriate configuration APIs, and then plug in a PAL driver that works for that device. Everybody wins!
Anyhow, if you made it through all this, I commend you. Stay tuned for more updates!
