interfacing the pyboard to an esp8266-01

[katesfb]

Hi,
I have an esp8266 that i want to use to connect to local wifi. I was going to use the CC3000 breakout board, as a mycropython module exists (CC3K) however this board seems difficult to get a hold of, is not as good as/more expensive than the esp8266.

The version i have is the esp8266-01 - just has pin outs for connection to uart, spi etc

Does a module/library exist in micropython for the esp8266?

Is there any example code available to get me started?

Any help is much appreciated.

Cheers.

[SpotlightKid]

Does a module/library exist in micropython for the esp8266?

No, there is, to my knowledge, no module to use the esp8266 as a network adapter for a another micropython board.

It's theoretically possible, but we would either need to develop a special (C/C++) firmware for the ESP8266 for that or add I2C or SPI slave mode to the micropython esp8266 port, to implement such a firmware in micropython. Also, to make it easily reusable, we would need to implement a pyboard module that wraps communication with the esp8266 module and presents a socket-compatible interface to the rest of the Python code.

It is something I've been thinking about doing for a long time, but there are some road blocks that need to be eliminated first (e.g. the above mentioned SPI slave mode).


Chris

[pythoncoder]

I spent a considerable amount of time trying to do something along these lines last summer albeit with a more limited objective. My aim was to bring MQTT to the Pyboard via an ESP8266. I failed to produce anything worth publishing: the ESP8266 was not robust in the presence of WiFi dropouts or RF interference. On rare occasions umqtt would hang indefinitely disabling communication with the Pyboard.

I implemented a bit-banging serial protocol to communicate between the boards: slow but fast enough for typical MQTT applications. It used asynchronous code with the aim of enabling the Pyboard to run in a non-blocking fashion. This was where failure occurred: I never found a solution where the ESP8266 didn't (rarely) block for long periods. I think this would affect slave mode solutions too. The other obvious option for comms is the ESP's UART. I avoided this because of its usefulness for debugging.

It's something I'll revisit if the maintainers produce a fault tolerant version of umqtt based on uasyncio. Unless you get there first with a more general socket based solution