Repository navigation
Conversation
|
RAM / Flash usage vs. base commit
See RAM/flash optimization guide for techniques to reduce usage. |
|
Test firmware build ready — commit Download firmware for PR #12130 251 targets built. Find your board's
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An SD card on SPI runs at
BUS_SPEED_STANDARDonce it is initialised: 10.5 MHz on F4, 6.75 MHz on F7, 6.25 to 7.5 on H7 and 9 on AT32, although the comment next to it says "full speed clock (<25MHz)" and an SD card in default speed mode takes up to 25 MHz. It has been so since before the SD driver was split in 2018.The driver sends each 512-byte sector in 128-byte chunks with a blocking SPI transfer from
afatfs_poll(), so the CPU waits for every chunk. These are estimates from the clock alone, not measurements: on F7 a chunk takes about 150 us at 6.75 MHz, and logging at 1 kHz (60 to 100 KB/s) means 470 to 780 chunks a second, roughly 7 to 12% of the CPU, each chunk delaying whatever task is due next.This sets
SDCARD_BUS_SPEEDtoBUS_SPEED_FAST: 21 MHz on F4, 13.5 on F7, 12.5 to 15 on H7 (by chip revision) and 18 on AT32, all under 25 MHz. That halves the clock time per chunk; the byte-by-byte transfer adds the same overhead as before, so the real gain is somewhat less. On F7 and H7, #12061 also removes the idle time between bytes, so with it the gain is larger.Only when the card has its SPI bus to itself. The bus keeps the last speed set, and the other drivers set theirs once, at init: the MAX7456, for one, would then run at the card's speed. So if any other device is registered on the card's bus, the card stays at the standard speed as today. That is the case on ALIENFLIGHTNGF7, ATOMRCF405MINI, BLUEJAYF4 and FISHDRONEF4 (a flash chip) and on SPEEDYBEEF405V3 and BLUEBERRYF435WING_SD (the OSD).
After an error the driver resets the card and identifies it again; that now goes back to the standard speed first, as it always ran.
Testing
Not tested on hardware: none of the boards I have puts the SD card on SPI. If you have one where the card has its own bus (for example MATEKF405SE, MATEKF722, SPEEDYBEEF405WING, SPEEDYBEEF405V4, SPEEDYBEEF7V3, GEPRC_TAKER_H743 or IFLIGHT_BLITZ_F7_PRO), I'd like to know whether the card still mounts and logs without errors with this, and if you can,
taskswith the blackbox running, before and after.Built for MATEKF405SE, MATEKF722, MATEKF722SE, SPEEDYBEEF405WING, SPEEDYBEEF7V3, GEPRC_TAKER_H743, KAKUTEF7, KAKUTEF7HDV, KAKUTEH7, SPEEDYBEEF405V3 and BLUEBERRYF435WING_SD: flash -120 to +316 B (MATEKF722SE 98.56%), ITCM unchanged on KAKUTEF7 and KAKUTEF7HDV. Unit tests pass.