Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: support for WiFi on the ESP32-C3 #2138

Closed
wants to merge 15 commits into from
Closed

WIP: support for WiFi on the ESP32-C3 #2138

wants to merge 15 commits into from

Conversation

aykevl
Copy link
Member

@aykevl aykevl commented Sep 24, 2021

This is an experimental branch. It's not complete. See tinygo-org/drivers#320.

I plan on cleaning up some commits from here to submit separately, to hopefully make reviewing easier. See #2135 and #2136 for example.

This is simple: just add the required header file. But this commit also
adds a simple test to make sure it remains supported.
This is just a first step. It's not complete, but it gets some real
world C code to parse.

This signature, from the ESP-IDF:

    esp_err_t esp_wifi_get_mac(wifi_interface_t ifx, uint8_t mac[6]);

Was previously converted to something like this (pseudocode):

    C.esp_err_t esp_wifi_get_mac(ifx C.wifi_interface_t, mac [6]uint8)

But this is not correct. C array parameters will decay. The array is
passed by reference instead of by value. Instead, this would be the
correct signature:

    C.esp_err_t esp_wifi_get_mac(ifx C.wifi_interface_t, mac *uint8)

So that it can be called like this (using CGo):

    var mac [6]byte
    errCode := C.esp_wifi_get_mac(C.ESP_IF_WIFI_AP, &mac[0])

This stores the result in the 6-element array mac.
This adds support for specifying linker scripts in LDFLAGS. I looked a
bit into whether it allows arbitrary code execution but I couldn't find
any sign of that.
This is necessary to support the WiFi binary blobs from Espressif.
This is normally provided by the libc, but in our case it makes more
sense to define it in the runtime (just like malloc).
You can now debug the ESP32-C3 from the TinyGo command line, like this:

    tinygo flash -target=esp32c3 examples/serial
    tinygo gdb -target=esp32c3 examples/serial

It's important to flash before running `tinygo gdb`, because loading a
new firmware from GDB has not yet been implemented.

Probably the easiest way to connect to the ESP32-C3 is by using the
built-in JTAG connection. See:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-guides/jtag-debugging/configure-builtin-jtag.html

You will need to make sure that the `openocd` command in your $PATH is
the one from Espressif. Otherwise GDB will hang. You can debug this by
supplying the -ocd-output flag:

    $ tinygo gdb -target=esp32c3 -ocd-output examples/serial
    Open On-Chip Debugger 0.10.0
    openocd: Licensed under GNU GPL v2
    openocd: For bug reports, read
    openocd: 	http://openocd.org/doc/doxygen/bugs.html
    openocd: embedded:startup.tcl:60: Error: Can't find interface/esp_usb_jtag.cfg
    openocd: in procedure 'script'
    openocd: at file "embedded:startup.tcl", line 60

Make sure to configure OpenOCD correctly, until you get the correct
version (that includes the string "esp32"):

    $ openocd --version
    Open On-Chip Debugger  v0.10.0-esp32-20210721 (2021-07-21-13:33)
    Licensed under GNU GPL v2
    For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html

If you are on Linux, you may also get the following error:

    $ tinygo gdb -target=esp32c3 -ocd-output examples/serial
    Open On-Chip Debugger  v0.10.0-esp32-20210721 (2021-07-21-13:33)
    openocd: Licensed under GNU GPL v2
    openocd: For bug reports, read
    openocd: 	http://openocd.org/doc/doxygen/bugs.html
    openocd: Info : only one transport option; autoselect 'jtag'
    openocd: adapter speed: 40000 kHz
    openocd:
    openocd: Warn : Transport "jtag" was already selected
    openocd: Info : Listening on port 6666 for tcl connections
    openocd: Info : Listening on port 4444 for telnet connections
    openocd: Error: libusb_open() failed with LIBUSB_ERROR_ACCESS
    openocd: Error: esp_usb_jtag: could not find or open device!

The error LIBUSB_ERROR_ACCESS means that there is a permission error.
You can fix this by creating the following file:

    $ cat /etc/udev/rules.d/50-esp.rules
    # ESP32-C3
    SUBSYSTEMS=="usb", ATTRS{idVendor}=="303a", ATTRS{idProduct}=="1001", MODE="0666"

For more details, see:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-guides/jtag-debugging/index.html
This simply calls runtime.alloc, because the memory will be
zero-initialized anyway.
@aykevl aykevl force-pushed the espnet branch 3 times, most recently from 33d2847 to 6b15965 Compare September 27, 2021 15:28
This should behave the same but is compatible with the ESP32-C3 which
lacks the MIE CSR (but does have the MSTATUS CSR).
This is necessary to support the ESP32-C3, which lacks the A (atomic)
extension and thus requires these 32-bit atomic operations.
With this commit, flashing ./testdata/atomic.go to the ESP32-C3 works
correctly and produces the expected output on the serial console.
This is only supported for RV32 at the moment. RV64 can be added at a
later time.
This is especially useful if we ever want to support the ESP-IDF.

Currently implemented:

  - xTaskGetCurrentTaskHandle
  - xSemaphoreCreateRecursiveMutex
  - xSemaphoreDelete
  - xSemaphoreTakeRecursive
  - xSemaphoreGiveRecursive
@aykevl aykevl force-pushed the espnet branch 3 times, most recently from 3fecf31 to 853df1f Compare September 29, 2021 00:22
This commit implements:

  * xTaskCreate
  * vTaskDelay
  * xSemaphoreCreateCounting (partially)
  * xSemaphoreTake
  * xSemaphoreGive
  * xQueueCreate
  * vQueueDelete
  * xQueueReceive
  * xQueueSend
  * uxQueueMessagesWaiting
@Dorbmon
Copy link

Dorbmon commented May 8, 2022

Is this pull request still active?

@aykevl
Copy link
Member Author

aykevl commented Jan 27, 2024

Everything except for FreeRTOS compatibility has been merged already, so let's close this. I don't plan on implementing wifi/BLE support by implementing these FreeRTOS shims so that part can be dropped.

Also see: tinygo-org/drivers#650

@aykevl aykevl closed this Jan 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants