dap_vendor: Buffer MSD_Write packets into 512-byte blocks. #1093
Conversation
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
microbit-carlos
force-pushed
the
feature/dap-msd-buffer
branch
from
e2482f4 to
15d3016
Compare
microbit-carlos
commented
Feb 3, 2025
To send to the file streamer blocks of size matching the VFS sector size, which is expected for some stream formats like Universal Hex Blocks.
microbit-carlos
force-pushed
the
feature/dap-msd-buffer
branch
from
15d3016 to
eba229a
Compare
|
When combining this PR + out of order PR + UF2, it fails building some ports due to insufficient Force pushed, diff can be seen in: |
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.
Currently flashing a Universal Hex in "segments" or "blocks" format via WebUSB does not work.
This PR sends to the file streamer blocks of the same size as the VFS sector size, which is what
vfs_managerdoes and some stream formats expect, like Universal Hex and in the future UF2.This could have been implemented inside
file_streaminstead, but this way it mirrors what the MSC side is doing, buffering the 64 byte packets into 512-byte sectors before passing it tovfs_manager, which then sends it tofile_stream.One constrain is that DAPLink doesn't know when the last DAP.js
ID_DAP_MSD_Writepacket is sent, so we need to flush whatever is left in the buffer onID_DAP_MSD_Close. So the "close" response could contain an error writing the last buffer.There is also a memory hit, as the buffer takes 512 bytes of RAM. We could reuse the
usb_bufferfromvfs_manager.c(which is passed tousbd_msc.c, so that's where the 64-byte MSC packets are buffer into VFS sectors), not if you prefer to keep them separated. To be fair, using WebUSB flashing + MSD drag&drop at the same time will fail anyway, so probably wouldn't need to worry much about having two different components accessing the same buffer.