common: add firmware update page - #7981
Conversation
|
(the numbers were me throwing darts, please suggest alternatives + justifications :-) ) |
| | 4.8 | 4.2 | | ||
| +--------------+--------------------------+ | ||
| | 4.7 | 4.2 | | ||
| +--------------+--------------------------+ | ||
| | 4.6 | 4.1 | | ||
| +--------------+--------------------------+ |
There was a problem hiding this comment.
4.8(latest)
have to reformat table, this is what a user sees in firmware server
| Baro Thrust Compensation <common_baro_thrust_compensation> | ||
| Boat mode <boat-mode> | ||
| Bootloader Update <common-bootloader-update> | ||
| Firmware Update <common-firmware-update> |
There was a problem hiding this comment.
I would not put it on this page..rather additional-information.rst...
There was a problem hiding this comment.
I would not put it on this page..rather additional-information.rst...
Done
cba9833 to
a722fdb
Compare
| | 4.8(latest) | 4.2 | | ||
| +--------------+--------------------------+ | ||
| | 4.7 | 4.2 | | ||
| +--------------+--------------------------+ | ||
| | 4.6 | 4.1 | |
There was a problem hiding this comment.
Sub skipped 4.2, 4.3, 4.4, and 4.6, so should probably have 4.1 -> 4.5 and 4.5 -> 4.7/4.8.
If that's not valid for the other firmware variants then we could differentiate with some site filtering.
There was a problem hiding this comment.
I don't know whether it makes sense for this to be vehicle-specific.
In the linked PR, for example, I'm trying to remove some old conversion code. The version that was introduced and the version it's leaving aren't changing there.
We should add a note about Sub's missing versions, somehow, I guess? So a Sub user wanting to go from 4.1 to 4.8 would go via 4.5 not 4.6. (the table above is specifies the maximum jumps, not the suggested or actual jumps)
There was a problem hiding this comment.
Oh, just to emphasise - I opened this PR with "I made these numbers up". If there's general agreement that we want this then I'll try to come up with some real numbers.
@rmackay9 has previous suggested that a strict 3-version rule is the way to go. So you could go 4.5->4.8 but not 4.4->4.8 - but you could go 4.5->4.7->4.8
|
I'll leave it to @Hwurzburg re whether we need a new page but here are some other pages that users might think are related:
|
|
I think we should move the "Parameter Migration" section to the, "Loading Firmware" page |
really just here to hold the table at the end showing what versions we support moving to and from
a722fdb to
2da3e3f
Compare
|
I asked Claude to flesh out the table for me: |
|
Henry and I chatted. We noted that there were several sections missing from one page but were present on another. @Hwurzburg is going to make a common page to hold some of this stuff (inc. references to the custom build server IIUC) |
|
Per @rmackay9's suggestion above, the "Parameter Migration" section (prose + version table) is now carried in #8002, which collapses the two "Loading Firmware" sidebar entries into a single That does leave the section in two places: No files overlap between the two PRs, so they won't conflict in git either way. |
The setup sidebar carried two separate "Loading Firmware" entries, one for boards that already have an ArduPilot compatible bootloader and one for boards that do not, forcing the reader to decide which page applied before either page explained how to tell. Both pages also carried their own copies of the firmware download instructions and the beta/developer version descriptions. Add a single "Loading Firmware" page as the sidebar entry, structured as: 1. Download the Firmware - firmware server navigation, which file type each loading method needs (.apj / _with_bl.hex / .abin / .bin), and Stable, Beta, Latest Developer and Custom Builds subsections. 2. Loading the Firmware - how to tell whether the autopilot has an ArduPilot compatible bootloader, from the board's provenance and from a USB/Device Manager test, then links to the two loading pages. 3. Testing that it Worked. 4. Additional Information - Parameter Conversion, Loading Firmware via SD Card, and Firmware Feature Limitations with the custom build server. The Parameter Conversion section takes the "Parameter Migration" text and its version migration table from ArduPilot#7981, as suggested by rmackay9 there; the wording and the table are peterbarker's. Retitle the two loading pages to say which case they cover, and reduce them to just the loading procedure, with the download, beta/developer, SD card, feature limitation and testing content now on the parent page. Both keep their existing anchors so the many board pages that link straight to them are unaffected. Drop the Zadig and Betaflight Configurator alternate DFU method, leaving STM32CubeProgrammer as the single documented path, and remove the two images it used. The external flash/SSBL section stays, as those boards cannot be loaded with STM32CubeProgrammer at all. Point the cross-references that previously offered the reader a choice between the two pages at the new page instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The setup sidebar carried two separate "Loading Firmware" entries, one for boards that already have an ArduPilot compatible bootloader and one for boards that do not, forcing the reader to decide which page applied before either page explained how to tell. Both pages also carried their own copies of the firmware download instructions and the beta/developer version descriptions. Add a single "Loading Firmware" page as the sidebar entry, ordered as the reader actually proceeds rather than as a table of contents: 1. Connect the Autopilot to the Computer - plug in over USB, without holding DFU/BOOT, so that the board comes up as it normally would. 2. Check What is Already on the Autopilot - the board's provenance, then how to read the USB device name on Windows, Linux and macOS, and what each result means. 3. Load the Firmware - branch to the ground station page or to the DFU page. 4. Test that it Worked. Reference material that interrupted that flow - firmware server navigation, the Stable, Beta, Latest Developer and Custom Builds descriptions, Parameter Conversion, Loading Firmware via SD Card, and Firmware Feature Limitations - moves to an Additional Information section below it, and the local contents block is dropped. A ground station downloads Stable firmware by itself, so only the DFU path and the non-Stable builds need the download instructions at all. The per-OS detection instructions identify the board by its own USB product string rather than by the manufacturer, since 53 of the 464 hwdefs set their own USB_STRING_MANUFACTURER, and note that the bootloader appends -BL or -Secure-BL-v10 to that name, though not every board changes it. The Parameter Conversion section takes the "Parameter Migration" text and its version migration table from ArduPilot#7981, as suggested by rmackay9 there; the wording and the table are peterbarker's. Retitle the two loading pages to say which case they cover, and reduce them to just the loading procedure, with the download, beta/developer, SD card, feature limitation and testing content now on the parent page. Both keep their existing anchors so the many board pages that link straight to them are unaffected. The ground station page also drops its own "Connect autopilot to computer" section, which is now step 1 of the parent page. Drop the Zadig and Betaflight Configurator alternate DFU method, leaving STM32CubeProgrammer as the single documented path, and remove the two images it used. The external flash/SSBL section stays, as those boards cannot be loaded with STM32CubeProgrammer at all. Point the cross-references that previously offered the reader a choice between the two pages at the new page instead. Co-authored-by: Peter Barker <pb-gh@barker.dropbear.id.au> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
really just here to hold the table at the end showing what versions we support moving to and from