-
Notifications
You must be signed in to change notification settings - Fork 88
Add classic custom-board support and fix ESP32 build issues #508
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
base: main
Are you sure you want to change the base?
Add classic custom-board support and fix ESP32 build issues #508
Conversation
… workflow) builder/esp32: fix frozen manifest generation for external MCU-specific drivers (e.g. st7796, ft6x36, etc.) and *_api_gen_mpy.py files. .gitignore: update to exclude generated files and external libraries
| base_config.append(arg) | ||
| args.remove(arg) | ||
|
|
||
| elif arg.startswith("--"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Custom build arguments passed to make.py (e.g. --flash-size, --enable-uart) are not valid Make options.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no they are not, but when using a custom board those options should not be used in the build command and should instead be handled in the custom board. so when a user specifies a custom board and then uses those commands the commands are not parsed and get forwarded to makefile. What needs to be done is when a user uses a custom board and passes any arguments that should not be there an exception should be raised with a meaningful message about using those build command in combination with a custom bard.
|
|
||
|
|
||
| def build_sdkconfig(*args): | ||
| if custom_board_path is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This early return prevented inclusion of optional drivers (FROZEN_MANIFEST) and API generation (GEN_SCRIPT) when building for custom boards. It seems to be either an oversight or an unintended change. If this if custom_board_path is not None condition must be preserved, a flag could be added to differentiate the board type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intentional because everything done here is able to be done in the custom board files so it is not needed. The user needs to do this themselves in those board files.
|
the reason why using the custom board option pretty much stops all of the other command line parameters from working is because everything is able to be set using the files that are in a custom board. anything the build script does should be handled in the custom board and not via the command line options. This includes but it not limited to the partition sizes, espidf specific config options and manifest files. Adding a toml file to the custom board allows for generation of a more complete display and touch driver. the toml reader code writes a driver file that gets baked into the firmware where a single import of a file in the main.py file will get the display and the touch drivers up and running. |
|
|
||
|
|
||
| def build_sdkconfig(*args): | ||
| if custom_board_path is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intentional because everything done here is able to be done in the custom board files so it is not needed. The user needs to do this themselves in those board files.
| f'CONFIG_ESPTOOLPY_FLASH_SAMPLE_MODE_{itm}=n' | ||
| ) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unneeded change
| base_config.append(arg) | ||
| args.remove(arg) | ||
|
|
||
| elif arg.startswith("--"): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no they are not, but when using a custom board those options should not be used in the build command and should instead be handled in the custom board. so when a user specifies a custom board and then uses those commands the commands are not parsed and get forwarded to makefile. What needs to be done is when a user uses a custom board and passes any arguments that should not be there an exception should be raised with a meaningful message about using those build command in combination with a custom bard.
Adds a missing feature related to custom board handling and fixes ESP32 build issues.
1. Feature: classic custom-board support
make.pynow supports defining custom boards without a.tomlfile, using the same classic workflow as the generic boards provided in the upstream MicroPython repository.2. Fix: frozen manifest generation for external MCU-specific drivers
builder/esp32.pyincorrectly generated the frozen manifest, which prevented certain external MCU-specific drivers from being included (e.g.st7796,ft6x36, ...).Notes
python3 make.py esp32 --custom-board-path=../cannazor/lvgl_assets/ESP32_GENERIC_S3_N16R8/ --flash-size=16 --enable-uart-repl=y DISPLAY=st7796 INDEV=ft6x36 -j$(nproc)*_api_gen_mpy.pyfiles were not the root issue; they were only affected as a side effect..gitignoreto exclude generated files and external libraries.