wp/Marlin-2-0-x-Anycubic-i3-MEGA-S
1
0
Fork 0
Code Issues 28 Pull Requests 2 Actions Packages Projects Releases 30 Wiki Activity

Merge upstream changes from Marlin 2.1.2.5

Browse Source
This commit is contained in:
Stefan Kalscheuer
2024-11-23 13:43:26 +01:00
parent c41a85354a
commit c8ff13654b
376 changed files with 4922 additions and 3840 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/ConfigEmbedding.md
View File

@@ -3,7 +3,7 @@
Starting with version 2.0.9.3, Marlin can automatically extract the configuration used to generate the firmware and store it in the firmware binary. This is enabled by defining `CONFIGURATION_EMBEDDING` in `Configuration_adv.h`.
## How it's done
At the start of the PlatformIO build process, we create an embedded configuration by extracting all active options from the Configuration files and writing them out as JSON to `marlin_config.json`, which also includes specific build information (like the git revision, the build date, and some version information. The JSON file is then compressed in a ZIP archive called `.pio/build/mc.zip` which is converted into a C array and stored in a C++ file called `mc.h` which is included in the build.
At the start of the PlatformIO build process, we create an embedded configuration by extracting all active options from the Configuration files and writing them out as JSON to `marlin_config.json`, which also includes specific build information (like the git revision, the build date, and some version information). The JSON file is then compressed in a ZIP archive called `.pio/build/mc.zip` which is converted into a C array and stored in a C++ file called `mc.h` which is included in the build.
## Extracting configurations from a Marlin binary
To get the configuration out of a binary firmware, you'll need a non-write-protected SD card inserted into the printer while running the firmware.

14
docs/Maintenance.md Normal file
View File

@@ -0,0 +1,14 @@
# Marlin Code Maintenance
In addition to the general work of fixing bugs, supporting new hardware, developing new features, and refining existing features we have to also maintain supporting files that change in tandem with the codebase. Some of this maintenance can be done as part of CI, and we may even generate commits to the development branch using periodic checks whenever any auto-generated files need to be regenerated. (See `bump-date.yml` for one example.)
## Configuration Tasks
- Add CI build tests and Unit Testing to catch future breaking changes.
- Periodically run `buildroot/bin/build_all_examples` to make sure configs and code are buildable.
- Periodically run `buildroot/share/scripts/makeBaseConfigs.py` to generate new base configurations.
## Documentation Tasks
- For any G-code command changes update G-code pages and the RepRap wiki G-code page.
- For a new feature or changes to an existing feature update Configuration page and any articles about the feature.