I thought similarly to you when I wrote esp-link. Esp-link includes support for an attached uC to make outbound REST requests and to do pub/sub using MQTT. What I realized is that I then have to concoct a protocol over the serial wire for the attached uC to talk to esp-link and tell it what to do. So here comes SLIP and some RPC-like stuff on top.
Well, it's very easy and quick to come up with a shitty protocol and to write a shitty arduino or espruino library to show that it works on a sunny day. Creating a robust and efficient protocol to make esp-link do REST and MQTT (and do I hear someone clamoring for websockets?) and then writing robust libraries that have good error handling and such is an order of magnitude more work.
Plus now all this has added another level of failures: did the uC have a problem? or did esp-link have a problem? or did the protocol between them mess-up? Who gets to deal with "lost wifi connection" kind of stuff? Etc, etc.
It's when I faced theses questions that I thought: mhhh, maybe for 90%+ of what I do I can do it straight on the esp8266 and I'll be just fine.
And then there's the power stuff. It's already hard enough to run any wifi solution on battery for extended periods, adding more uC's is unlikely to help, I think.
So in the end you either bite the bullet and spend significant effort making two uC's dance or you spend a perhaps comparable effort using interrupts and threads to make your time critical stuff work on one uC. One big advantage of the emw3165 over the esp8266 is that we have full control over the FreeRTOS implementation and the various interrupt routines, and we have a much better processor and I/O devices to play with.
I have to admit that if I could build a system from scratch I'd put LwIP and TLS onto the BCM43362 and present a socket interface across the SDIO bus. Sadly that's not an option as far as I know.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I thought similarly to you when I wrote esp-link. Esp-link includes support for an attached uC to make outbound REST requests and to do pub/sub using MQTT. What I realized is that I then have to concoct a protocol over the serial wire for the attached uC to talk to esp-link and tell it what to do. So here comes SLIP and some RPC-like stuff on top.
Well, it's very easy and quick to come up with a shitty protocol and to write a shitty arduino or espruino library to show that it works on a sunny day. Creating a robust and efficient protocol to make esp-link do REST and MQTT (and do I hear someone clamoring for websockets?) and then writing robust libraries that have good error handling and such is an order of magnitude more work.
Plus now all this has added another level of failures: did the uC have a problem? or did esp-link have a problem? or did the protocol between them mess-up? Who gets to deal with "lost wifi connection" kind of stuff? Etc, etc.
It's when I faced theses questions that I thought: mhhh, maybe for 90%+ of what I do I can do it straight on the esp8266 and I'll be just fine.
And then there's the power stuff. It's already hard enough to run any wifi solution on battery for extended periods, adding more uC's is unlikely to help, I think.
So in the end you either bite the bullet and spend significant effort making two uC's dance or you spend a perhaps comparable effort using interrupts and threads to make your time critical stuff work on one uC. One big advantage of the emw3165 over the esp8266 is that we have full control over the FreeRTOS implementation and the various interrupt routines, and we have a much better processor and I/O devices to play with.
I have to admit that if I could build a system from scratch I'd put LwIP and TLS onto the BCM43362 and present a socket interface across the SDIO bus. Sadly that's not an option as far as I know.