tinygo
tinygo copied to clipboard
tinygo-org
ESP8266 WiFi support
The docs (https://tinygo.org/microcontrollers/esp8266/) list that the ESP8266 WiFi feature is not supported by TinyGo.
Imo having this support is crucial for this board to make sense. What needs to be done so this can happen?
Just wanted to comment and say how grateful I am for the tinygo project. I am truly terrible at c++, and I don’t like writing It, but I resonate with go. I’m really excited to do a project with an ESP chip and tinygo.
WiFi support would is HUGE. If I’m capable I’d be happy to help make it happen. But a major +1 to this request.
It looks like theoretically you could use one esp8266 to control / use wifi over another esp8266 (over UART). The first esp8266 would use this driver to talk to the second esp8266 with the AT firmware (listed on driver's README).
Because I really want to write go on the esp8266, and because they are cheaper than something like the arduino nano 33 IoT, I may actually do this. I'll post code if I do. Then I can always swap it out when tinygo supports the esp8266 wifi.
Imo having this support is crucial for this board to make sense. What needs to be done so this can happen?
Yes, I totally agree. One of the first things is probably to get compiler-rt and picolibc to compile. They do appear to compile in the latest version of the Xtensa fork (Espressif pushed some bug fixes) but when testing the chip (at least the ESP32, didn't test the ESP8266 yet) the chip seems to hang. Debugging this would be much easier with a proper debugger. I've ordered a FT2232 board to act as a JTAG debugger, so I should be able to see what's going on in a few weeks.
Also, for networking to work we'll also need:
- interrupt support
- a network goroutine/task (probably)
In other words, it'll require some low-level development. If you would like to dive deep, you're very welcome to help out :)
Update: compiler-rt and picolibc are now available. But many things are left to do.
@aykevl I've looked into this a few weeks ago. I've also compiled compiler-rt and picolibc without problems. One problem I ran into was that by the looks of it, at least the ESP32, does not have the ability to run without the RTOS. As far as I understand the current tinygo implementation does not leverage any of the RTOS based SDK. I've looked into options to link against some sort of libraries as possible with the non RTOS version of the ESP8266 development kit but did not succeed. And I found that Espressif discontinued the non RTOS based SDK for the ESP8266 as well. It receives some sort of bugfix update but the users are encouraged to use the RTOS based SDK.
If this is the right observation, are you aware of this situation and maybe have some ideas to overcome this?
One problem I ran into was that by the looks of it, at least the ESP32, does not have the ability to run without the RTOS.
I think we can use the TinyGo scheduler as the RTOS, but I haven't looked into this yet. Using FreeRTOS in TinyGo would be very complicated.
Thats the point, embedding FreeRTOS into TinyGo is not the right path to enter. Espressif supplies some kind of libraries at https://github.com/espressif/esp32-wifi-lib/tree/master/esp32. On my first look this libraries also depend on FreeRTOS and their SDK. I was hoping to find some low level APIs, within the libraries, which allows interacting with the wifi system.
IMHO I would like to reuse as most network logic from the standard library of go as possible. But it looks like Espressif is not willing to support such setups. Is TinyGo currently running on a single core in ESP32 setup?
Looks like at least for the ESP32 there is an option to get full access to the coprocessor. https://github.com/espressif/esp-idf/blob/master/components/freertos/Kconfig#L4
It appears that RIOT has managed to run its RTOS on the ESP8266, with WiFi support: https://doc.riot-os.org/group__cpu__esp8266.html
I think we should look into how they do it.
Thanks for the reference! I was not ware of the existence of riot. I've looked into micropython and low.js. Micropython uses the FreeRTOS from Espressif and low.js has the part about ESP32 not opensource.
I just watched this Hackaday talk by Uri Shaked (@urish) that may be a way in for the development of an open source driver: https://hackaday.com/2021/12/30/remoticon-2021-uri-shaked-reverses-the-esp32-wifi/
I also watched that talk and was inspired to have another look into this. Maybe I find some time to dig into the internals again.
Thanks for bringing this up again.
Writing here since there haven't been any comments since April, this would be great to have. It is one of the last steps before I can dump cpp for my esp development project
Hi, what is the current status of this issue? Is there any update on here?
Is this something that would benefit from additional eyes? I love go and these chips, and would love to see their full stack implemented here.
Worth noting rust is having similar experimental headway
https://github.com/esp-rs/esp-wifi
This uses the WiFi drivers from a fork of espressif drivers
@panbanda ooh that looks really interesting! Thank you for sharing! That should certainly be useful.
I really do hope someone implements this within like the next 2 years, it would be incredibly useful
I really do hope someone implements this within like the next 2 years, it would be incredibly useful
You could always give it a go.
Would it be possible to link the c-code for wifi or i2c into a go-project instead of writing it from scratch?
That's how Rust did it, directly references the ESP c code. The tinygo maintainers have voiced not wanting to go this route.
On Sat, May 20, 2023, 3:09 PM Kortenbach @.***> wrote:
Would it be possible to link the c-code for wifi or i2c into a go-project instead of writing it from scratch?
— Reply to this email directly, view it on GitHub https://github.com/tinygo-org/tinygo/issues/1427#issuecomment-1555986945, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQONNLN7HV55HZ4KQZ4KKLXHEQILANCNFSM4SHC7O4A . You are receiving this because you commented.Message ID: @.***>
Oke, that seems odd. I wonder why that is... Would that also mean that you can't use all the c-libraries that exist for different sensors?
You can use whatever CGo code you can get to work for you. That does not mean it will necessarily become part of the one the official repos.
We're mostly interested in open source, and in pure TinyGo implementations, but there are plenty of places you can find CGo in use in various TinyGo packages.
Sensors that are tied to a specific hardware architecture are not too interesting in general for that exact reason the TinyGo drivers repo contains 90+ sensors etc that work on pretty much any architecture.
Regarding the ESP32 wifi support, someone could be contributing a PR to add this to the drivers repo and we'd certainly look at it.
In the meantime please see https://github.com/tinygo-org/tinygo/pull/2138 and https://github.com/tinygo-org/drivers/pull/320
Oke, that seems odd. I wonder why that is... Would that also mean that you can't use all the c-libraries that exist for different sensors?
The ESP8266 is basically dead. Yes, it's still being used in the wild but as far as I can see it can be replaced with ESP32-series chips in almost every case (in particular, the ESP32-C3 for low-cost applications) and Espressif does not appear to continue developing it. Also, as far as I know, the ESP-IDF does not support the ESP8266 so there is that.
When it comes to the newer chips (especially the newer RISC-V ESP32-series chips), the proper way to add WiFi support is by using esp32-wifi-lib, which are basically the binary blobs and headers needed for WiFi and BT extracted from the ESP-IDF. This is what is now also used by the Rust people.
Actually there are two ways Rust supports WiFi on the ESP32-series chips:
- Using the ESP-IDF, treating it like a regular operating system.
- As a baremetal system using esp32-wifi-lib for WiFi support (mentioned above).
While the first option is possible, it would mean replacing most of the TinyGo runtime with an ESP-IDF version. That is a massive maintenance burden that I'm not willing to take up. It's easy to say "just use the ESP-IDF", it's a whole different story to have to maintain the mess that is called ESP-IDF (and associated support burden). The second option is my preferred route. It fits much more cleanly in TinyGo, in fact it is somewhat similar to the Nordic SoftDevices that we use for Bluetooth on the nrf chips (which is also a binary blob). So far, nobody has actually made it work so if you want to do that, there is your chance to contribute something that will be useful to many people (but disclaimer: only do this if you're familiar with C, the ESP32-series chips, TinyGo, and the RISC-V architecture).
Thanks you for your explanation Ayke. I think it will help people that are capable enough, to pick this up and get it working. A small nudge in the right direction.
The ESP8266 is basically dead. Yes, it's still being used in the wild but as far as I can see it can be replaced with ESP32-series chips in almost every case (in particular, the ESP32-C3 for low-cost applications) and Espressif does not appear to continue developing it. Also, as far as I know, the ESP-IDF does not support the ESP8266 so there is that.
Just a few clarifications:
- Espressif has a 12-year commitment, and for the esp8266 it means that it will be supported (however good I don't know) until Jan, 1st 2026, see: https://www.espressif.com/en/products/longevity-commitment
- In the ESP-IDF README it says: "Espressif SoCs released before 2016 (ESP8266 and ESP8285) are supported by RTOS SDK instead."
How useful would it be to make the effort to support esp8266 wifi now in TinyGo? That I don't know :sweat_smile:
