pbdrv/block_device: Implement async program load and save.

[laurensvalk]

Note: this is to be merged into master instead of the branch listed above.

---

This replaces the polling SPI implementation (deactivated in the
previous commit) with asynchronous DMA driven SPI transfers.
This fixes motors going out of sync when starting programs.

Fixes pybricks/support#599
Fixes pybricks/support#679

This also avoids touching file systems used by other known firmwares,
so that Pybricks can operate entirely stand alone. This reduces
the complexity of firmware installation and troubleshooting, because
there are no dependencies on prior firmwares or hub state.

It also lays the groundwork for saving and storing program data on
Powered Up hubs, but this isn't fully implemented in order to preserve
compatibility with Pybricks Code and the existing tutorial videos.
This restores the ability to run the program appended to the firmware,
which was temporarily removed in the previous commit.

This also frees up about 7K of build size on Prime Hub.

To keep the diff easier to go through, I have not yet done the following, but this should be done before merging:

• Remove littlefs submodule
• Remove pb_flash.{c,h}
• Remove flash related calls from pybricks.experimental.

Other things to consider and test:

• Check maximum SPI read via DMA in one go. The flash chip supports reading the whole flash, but we may need to break up reads in smaller steps if the DMA has upper limits.
• See if we can generalize the w25qxx driver beyond just two devices.
• Go through other notes in Improved program download, multi-file projects, and persistent storage on Powered Up hubs #106 relevant to this part

[dlech]

What happens if we lose power during a write operation? Do we want to have some sort of hash to validate the data when we read it back to detect this? (this hash could also be used to avoid redownload of the same program later). Another option could be to write the "file" data first and the metadata last (at the end of the block?) so that the metadata will only be written if everything else was successfully written.

If pbio_task was in better shape, it would be a good fit for the block read/write functions, so maybe add a TODO/REVIST comment to that effect?

[dlech]

The flash chip supports reading the whole flash, but we may need to break up reads in smaller steps if the DMA has upper limits.

The DMA NDT registers are 16-bit so 65535 bytes is probably the limit.

[laurensvalk]

What happens if we lose power during a write operation? Do we want to have some sort of hash to validate the data when we read it back to detect this? (this hash could also be used to avoid redownload of the same program later). Another option could be to write the "file" data first and the metadata last (at the end of the block?) so that the metadata will only be written if everything else was successfully written.

Yes - there is an existing TODO for this in program_load. There was even an entry to prepare for it in the data map in the original PR, but it was removed to keep the changes smaller.

By doing it in program_load, we can keep the block drivers generic while using the same checks on the powered up hubs too. The hash to avoid redownloading fits right in there as well, good idea.

If pbio_task was in better shape, it would be a good fit for the block read/write functions, so maybe add a TODO/REVIST comment to that effect?

Several PRs back it started out that way, but the implementation with protothreads turned out to be simpler and more effective for now.

[dlech]

See if we can generalize the w25qxx driver beyond just two devices.

I wouldn't spend time doing this since we don't actually have a use for it.

[laurensvalk]

Thanks for the review! I’ll try getting this fixed and merged tomorrow.