-
Notifications
You must be signed in to change notification settings - Fork 7.4k
Espressif: ESP32: board target terminology is incompatible with guidelines #90807
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
Comments
I think there is a misconception. There are Espressif boards (like DevkitC), modules (like Wroom) and chips (like ESP32-D0WD-V3). Then:
"Economic considerations aside", you DO can buy Espressif chips (and not modules). It is just not convenient for the majority of users. PTAL: https://products.espressif.com/#/product-selector?names= |
I am well aware of that. My issue is that the current board target naming does not respect Zephyr board target terminology, by using the SoC series name (ex: esp32s3) instead of the SoC name (the question of what ESP32 part is considered a Zephyr SoC, is it the ESP32 'module' or the 'chip', can be discussed later). |
This is exactly the point. What you are suggesting as SOC name is actually a module configuration. This is not right either. ESP32-S3 is actually an SOC Part number, and we can move from 'config_esp32s3_series' to 'config_esp32s3' with very questionable gains. FWIW, other ESP32-S3 SOC names would be the ones from this list here. While I also agree that we need to add the actual SOCs to this, and I also agree that we could use 'board variants' for devkits with different module configurations, I also noted users getting things done with overlays for both cases. Considering our main goal is enabling users to get things done, overlay as a workaround is good enough. |
I will introduce variants for the devkitc-esp32s3 board, already tested & it works great for rapidly & easily switching between the different Flash/RAM sizes. |
Well, it is open source, contribution is always welcome! Just remember to only add variations that are actually sold by Espressif. There are many DevkitC clones/based/copies that have slightly different set-ups and shouldn't be a DevkitC variant. For example, some feature an LED, some have different module, etc. These are usually rejected if placed under Espressif. FWIW, a while ago, we had to do a taskforce effort to organize the boards and take all 'non-Espressif' boards that were posing as Espressif's to their respective manufacturer folder, when one could be found. |
Uh oh!
There was an error while loading. Please reload this page.
Describe the bug
When looking at https://docs.zephyrproject.org/latest/boards/espressif/esp32s3_devkitc/doc/index.html, the board target to build for is indicated as
esp32s3_devkitc/esp32s3/procpu
, butesp32s3
is the SoC series (as it is clear fromzephyr/soc/espressif/esp32s3/Kconfig
Line 4 in 11c543e
Many of ESP32 DevkitC boards come with different SoCs that differ in xSPI PSRAM & Flash sizes as indicated for ESP32-S3-DevKitC for example https://docs.espressif.com/projects/esp-dev-kits/en/latest/esp32s3/esp32-s3-devkitc-1/user_guide.html#ordering-information. So to target the ESP32S3 DevkitC board variant with a different SPI Flash/PSRAM sizes than the one hard-coded (
zephyr/boards/espressif/esp32s3_devkitc/Kconfig.esp32s3_devkitc
Line 5 in 11c543e
zephyr/boards/espressif/esp32s3_devkitc/esp32s3_devkitc_procpu.dts
Line 8 in 11c543e
esp32s3_devkitc/esp32s3_wroom_n16r8/procpu
for example.Regression
Steps to reproduce
N/A
Relevant log output
Impact
Annoyance – major irritation; significant impact on usability.
Environment
Additional Context
N/A
The text was updated successfully, but these errors were encountered: