Automate managing of STM32CubeMX + PlatformIO projects
Big refactoring release with a couple new features.
.ioc config inspection feature – such files can now be parsed and analyzed by stm32pio:
board_build.stm32cube.custom_config_header PlatformIO option (#26)platformio.ini file after patchingStm32pio class:
instance_options in constructorfrom_subprocess=True flag can now be used directly, without extra argumentLogPipe now accumulates data only when explicitly said to, also the algorithm is more efficientinspect_ioc feature for generate, pio_init, patch and new commandspython instead of python3
try...except in __main__.py
Mostly a maintenance release. It focuses mainly on GUI codebase reorganization and structuring, also fixes some old GUI bugs and modernizes a build process.
__main__.py
.ioc filemodule_logger messageQApplicaion subclass (causes segfaults)Qt.quit() can now be used safelyplant_multiple_fixtures.py script - auto-create a bunch of identical projects for manual testingPyPA/build package for building both wheel and source distributionssetup.py is not needed anymorelast_error config file parameter (currently CLI-only) (+ corresponding test)-c/--with-build)clean() method, tests)git clean as a removal toolclean() method doesn't look for the determined .ioc file but does it by itself which can cause some unwanted behavior (potential data loss)setup.cfg: specify supported PySide2 versionsetup.cfg: PyPA parsing issuesProjectID parameter for the initialized signal to get rid of the annoying Shiboken overflow error.ioc file, PlatformIO versions (both for local and CI builds)state.py modulelogging.py moduleconfig.py module)lib.py -> project.py modulesettings module (none_options)_cubemx_execute_script() method)generate_code() function__str__() implementation, just print(project.config), that's all)util.configparser_to_dict() function (ConfigParser is already conforms with mapping protocol)settings.py (yes_options/no_options)settings.py
f"{STAGE_PATH.name}.ioc" occurrences in teststest_clean() to unit testsgo_to_this option for the addListItem method (instead invoke on the list model)addListItem methodHello! Long time no see!
stm32pio Python namespace
version.py file with a value stored in itnucleo_f031k6 project + real-life f103 and so on)pyproject.toml, declarative setup.cfg, PEP-517 and so on. However in the middle of the development process it became evident that such a workflow is still early and not so common and there are simply not enough tools to implement it gracefully (e.g. no official tool to build both dist source tarball and wheel)patch command. With this function now all meaningful (for end-user) methods of the Stm32pio class are mapped by CLI commands and match corresponding buttons from the GUI version so the similar workflow can be applied:
stm32pio init
stm32pio generate
platformio project init
stm32pio patch
platformio run
initialized signal to ProjectListItem
project.lastActionSucceed property to fix some visual behavior (bold borders remains after an error)Stm32pio constructor (this should be done outside)settings.py a strings that we looked for to determine successful CubeMX code generationplatformio project init command, use verbose versions of CLI argumentsAgain, add some bugs, fix new features fix some bugs, add new features. Changes:
examples folder (currently, only an embedding one (updated and moved from the wiki page))docs folder with some useful internal descriptions (currently, only a logging schematic (with sources))ProjectListItem.fromStartup propertyconfig to QMLsubTest (also should_log_error_...)TypeError: Cannot read property 'actionRunning' of null (deconstruction order) (on project deletion only)DelegateModel to store state in the ListView delegate)typing annotationstry...except
goToProject signal instead of duplicateFound
Settings in a separate thread using QThreadPool and saveInSettings() methodProjectsList.each_project_is_duplicate_of generatorstate handlingstm32pio.app.setup_logging(), should_setup_logging argument fo stm32pio.app.setup_main(). This also fixes annoying logging errors on testing because the loggers interfere with each otherstm32pio.util.ProjectLoggerAdapter() subclass as an individual logger for every projectstm32pio.util.log_current_exception()
log_record_factory substitutionstm32pio.util.Verbosity entity (enum). Acts like an additional degree of freedom for the logging setupstm32pio.util.DispatchingFormatter
BuffersDispatchingHandler() classplatformio_ini_is_patched a property instead of functionBug-fix 🐞:
GUI version is out of beta! :tada: Obviously there is still a work to do but the app now is more usable and also has many new features:
extras option to install the GUI version via piptry...catch
ProjectListItem members: _from_startup flag, _current_action string with corresponding properties and signalstyping annotationsSettings which will be called on the value change.ioc file instead of the directory. Check that .ioc is a non-empty text filestm32pio-gui -> stm32pio_gui
state and state.current_stage both for back- and frontend to reduce IO operationsProjectActionWorker -> Worker (as it is used for the variety of tasks) and some of its internalsSettings prefix as an argument for the constructormain() function, less global variablesfrom __future__ import annotations statementsThis release mainly focusing on the core library features that have been put aside by the time of the GUI version development.
-q/--quiet option for the clean CLI command. The command now by default warns the user about the content deletionstm32pio/app.py)--start-editor option value using shlex.quote()
platformio.ini to establish its correctness when checking for project states (ProjectStage.PIO_INITIALIZED, ProjectStage.PATCHED)configparser interpolation but there is no need in it). The backwards compatibility with the old-style config format has been preserved though those projects still will be non-portable unless you manually edit a config.ioc and app versions mismatch and so on), and just shows a dialogplatformio_ini_config Stm32pio instance property returning current platformio.ini parsed ConfigParser value. Used in some internal routines such as correctness determination and doesn't have to be used by the library userLogPipe now returns "remote control" LogPipeRC - small utility class holding the writable stream and the reference to the string accumulating all incoming messages. It can be accessed later, in the end of the context manager, to store and analyze all the outputpio_build() execution were suppressedplatformio package imports and dependencies) (the reason is crushes when the pio is not isolated in a separated subprocess). Use PlatformIO JSON format output to get and filter boardsrequired=False from argparse commands as it is a default (and even recommended) value anywayStm32pio arguments onto 2 categories: project parameters and instance options and use dictionaries for them. First one has now the same form as the project config configparser.ConfigParser and merging into the default and file settings on the project creation. Instance options are more related to the programmatic instance itself and contains currently 2 options - logger and save_on_destruction
append() instead of insert() to modify sys.path
raise FileNotFoundError(file) instead of raise FileNotFoundError("file FILE was not found")). Use pathlib.Path().resolve(strict=True) where appropriate to shorten the codeEnum represents a single stage of the project (e.g. "code generated" or "project built") while the special dictionary unfolds the full information about the project i.e. combination of all stages (True/False). Implemented in 2 classes - ProjectStage and ProjectState, though the Stm32pio.state property is intended to be a user's getter. Both classes have human-readable string representationsstatus CLI commandutil.py module (yes, now the name matches the functionality it provides)logging.Logger objects are now individual unique attributes of every Stm32pio instance so it is possible to distinguish which project is actually produced a message (not so useful for a current CLI version but for other applications, including GUI, is). LogPipe context manager is used to redirect subprocess output to the logging module. DispatchingFormatter allows to specify different logging' formatters depending on the origin of the log record. Substituted LogRecordFactory handles custom flags to .log() functions familyplatformio package is added as a requirement and is used for retrieving the boards names (util.py -> get_platformio_boards()). Expected to become the replacement for all PlatformIO CLI calls.ioc file versionConfig subclass and move its save() method back to the main Stm32pio class. This change serves 2 goals: ensures consistency in the possible operations list (i.e. init, generate, etc.) and makes possible to register the function at the object destruction stage via weakref.finilize()
_resolve_board() method as it is not needed anymore_load_config_file() -> _load_config() (hide implementation details)logger.isEnabledFor() instead of manually comparing logging levelsproject_path -> path
app.main() function versus subprocess.run()
(mostly) bug-fixing release
generate_code() doesn't destroy the temp folder after executionsubTest context managerspio_build() => build() methodsettings.py the width of the field in the log format string