Documentation Requests/Feedback

[ESP_Sprite]

Sorry, I think you misunderstand as there's no SDR here. The S in SDR stands for software, implying there's software parsing the output of the ADCs. That's not true here, the ADCs/DACs are hardwired into a fixed WiFi/BT MAC; there's no software DSP'ing involved.

[chibill]

Thats very confusing mentions internal details about the DAC and ADC attached to the MACs if they weren't somehow relevant to using the Core.

[locustcox]

There really needs to be documentation of the esp32 file header. Where is the checksum stored? Where is the signature stored for image verification? What is the checksum algorithm?

We put out own image header into the esp32, and since we need to insert our image size into the image, we have to re-calculate the checksum so that the esp32 can validate the image. Which tools can we use to re-checksum the image after adding our size to our own internal file header? Are there image tools that we can use? Documenting things like that would be really useful.

[ESP_Sprite]

FWIW, the image files normally are generated with esptool.py; perhaps you can use/modify that for your use case. It also has the documentation for the image format: https://github.com/espressif/esptool/wi ... age-Format

[locustcox]

Thanks. I saw that link earlier, but it says "Note: Currently this document refers to ESP8266 only. ESP32 has some additional headers." Any idea when the esp32 specific headers might be added there?"

[locustcox]

Unrelated documentation request: Can you document how aps are sorted when esp_wifi_scan_start() is called? I work in an environment with a TON of wifi access points, and I'd like to only grab the top 10 ssids found sorted by rssi. However, it isn't documented how APs are sorted when esp_wifi_scan_get_ap_records() is called.

[Mr_Red]

I have two requests for the technical reference manual.

First, the doc of some Ethernet MAC registers seem incomplete. Specifically, in EMAC_EX_PHYINF_CONF_REG only EMAC_PHY_INTF_SEL is documented. In the code the other bits are defined / used (e.g. EMAC_EX_SBD_FLOWCTRL).

Second, Ethernet MAC registers addresses (10.9) are defined in the 0x6002xxxx range while the code refers to 0x3ff6xxxx range. After a little bit of search it seems 0x6000xxxx address is AHB and equivalent to 0x3ff4xxxx (found in low power section 30.4). It would be nice if this mapping would be described in the address mapping section (1.3.x). Also maybe use the 0x3ff6xxxx range for the summary to match other register summaries.

[Mr_Red]

I'm getting "Page does not exist yet" error when trying to access the following versions of IDF doc (from the drop-down menu or from the release notes):
https://docs.espressif.com/projects/esp ... 3.3-beta3/
https://docs.espressif.com/projects/esp-idf/en/v3.1.4/

[abqmichaelj]

This concerns <URL url="https://docs.espressif.com/projects/esp ... <LINK_TEXT text="https://docs.espressif.com/projects/esp ... index.html">https://docs.espressif.com/projects/esp ... TEXT></URL> and other Espressif programming documentation. In particular documentation for building on Macintosh macOS Mojave.

It would be good to document that the makefiles do not work if your put your code in a cloud-backed directories.

The problem is that apple puts cloud backed files and folders into a subdirectory of ~/Library/Mobile Documents/com~apple~CloudDocs. e.g., `/esp32 gets stored at ~/Library/Mobile Documents/com~apple~CloudDocs/esp32. Generic unix tools, including git and makefile, end up using these actual paths instead of the user intended paths. The make tool then stumbles when it runs across the space in "Mobile Documents."

The solution is to use the finder to create a directory (e.g., esp32) outside the cloud folder and then put your code there.

[maimariarti]

You need to re-write your entire technical reference manual for the esp32 and 8266.
As it stands, it is written in an unprofessional and cryptic ways.
Study the technical reference manuals from competition like MicroChip.
See how every little detail of every syb-system is explained, often with ASM code examples.
Also, see all the register explanations and block diagram of each module.
You can not expect to replace a good hardware manual with an API manual, and call it good!
You have a great SOC, but very bad documentation. Invest the money and outsource it to a good technical writing company.
Not the cheapest you come across.
For example, where are details about CAN controller on the ESP32?
It claims to have one, but nothing after that!