-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDIO storage Read/write, M21, and print from media menu selectable access #25683
base: bugfix-2.1.x
Are you sure you want to change the base?
Conversation
|
@@ -543,10 +543,11 @@ | |||
#endif | |||
|
|||
#if DISABLED(USB_FLASH_DRIVE_SUPPORT) || BOTH(MULTI_VOLUME, VOLUME_SD_ONBOARD) | |||
#if ENABLED(SDSUPPORT) | |||
#define NEED_SD2CARD_SPI 1 | |||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The SDSUPPORT
option is used as the flag for any and all media types, not just SD Cards. If SDSUPPORT
is not enabled, none of the file access code (e.g., cardreader.cpp
) will be compiled in. So the code needs to be reworked a lot more if the intent is to make SDSUPPORT
only refer to SPI-based SD cards.
Since it is possible to have both onboard and external media drives, we would also need to rework the code to remove the assumption that there is only one SD card, either ONBOARD
, LCD
, or CUSTOM_CABLE
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could have SD_SPI_STORAGE
, SD_SDIO_STORAGE
, and USBFLASH_STORAGE
options underneath that requires SDSUPPORT
to be defined. I see that there are currently 3 media_driver_X
types implemented:
media_driver_usbFlash
(USB)media_driver_sdcard
(SPI)media_driver_sdiocard
(SDIO)
Even though the location of the SD slots may be onboard or on LCD to the user, the access method for the SD slots can vary between all three methods no matter where the slots physically are. There is a maximum of one SD slot connected for each media_driver_X
type, I think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current assumptions are probably a little constrained. As I've been working on separating out the LCD pins in another PR I've become better acquainted with the way that SD Card pins are allocated, either with or without an LCD controller. Here we have a number of different possibilities.
- Onboard SD Card drive with dedicated pins, sometimes but not always the native Hardware SPI.
- Onboard SD Card drive with SDIO, so the card can be released by Marlin and seen by the host PC over USB.
- I'm not sure whether SPI-based SD Cards can be shared in this way.
- No onboard SD Card drive, but the LCD has one, usually sharing SPI pins with the (SPI-based) LCD.
- No onboard SD Card drive, but an SD Card can be added. With native Hardware SPI or Software SPI.
- Onboard USB Flash Drive is rare, but I have a board or two with one. Presumably Hardware SPI.
- I'm not sure whether any board has SDIO Flash Drive, or if SDIO is a thing for Flash Drives.
- I'm not sure whether SPI or SDIO Flash Drives can be released and seen by the host PC over USB.
Right now pins files tend to follow the configuration of the original machine they came with, so if there is an LCD Controller with an SD Card drive, the pins file assumes that the presence of an LCD indicates the use of the SD Card drive on the LCD. Most pins files allow that to be overridden.
The "Custom Cable" option for SD Card drives is handled by very few pins files, and it could be better. If you define your own SPI pins (with SD_
prefix) and use CUSTOM_CABLE
then pins files should allow it, but the logic is not there.
There is a lot of overlap between the allocation of pins for the LCD and SD, so it might be good to tackle these two problems at the same time or in a similar manner. See #25650 for that little project, which is coming along slowly but steadily. There I'm trying to weed out assumptions about whether Software or Hardware SPI is used, but also trying to see if that can be based on the chosen pins. i.e., If the pins are not the standard SPI0, SPI1, etc., then we can assume Software-based SPI for that drive.
563a8a5
to
ec3a52c
Compare
ec3a52c
to
baf4fbe
Compare
I don't know of any boards that have a single SD slot that can be dual accessed over SPI and SDIO. Most newer boards I've seen have an onboard slot that is accessible by either SDIO or SPI and then the manufacturer or 3rd party has a LCD assembly that includes a second SD slot on the LCD assembly that is mounted somewhere more accessible to the user (like next to the LCD and encoder).
Currently, P0 and S are hard coded to
Yes, that's what I've noticed, I'm not sure what that achieves for the normal user since the menu would just mount the same media from before? |
Expanding I just tested When I set |
Try to fix CI error
It ensures that an |
I suggest that we defer to the board's definition of If there is a second SD Card drive installed, either on the LCD or elsewhere, that one will presumably be connected via SPI, and we can just call it the "External SD Card." If there is a USB Flash Drive installed, it should be accessible simply as "USB Drive." This way we are not assuming the user knows or cares whether the onboard SD card is SDIO or SPI. We should be able to assess that automatically based on the board / pins definition. When it comes to selecting one of the SD cards or the Flash drive, I suggest we allow the user to specify whatever order they prefer for Drive 0 (default), 1, 2, etc. The onboard SD Card will usually be the default, for setups that have the slot exposed on the side or front of the machine, while the external (LCD) SD Card will be the default on machines that are set up with that slot being more prominent, even though there may be an accessible SD Drive on the board. Of course, going forward we may see USB Flash Drive becoming more common as the default, in which case the LCD SD Card might be the secondary, and the onboard the tertiary or altogether inaccessible, depending on the machine. |
493e92f
to
f4160ec
Compare
Have a look at #25715 where I'm exhibiting a new concept for configuring drives that aims to simplify the user-level configuration of multiple volumes. It's not meant to compile successfully yet, but just to show how this PR might be continued. Most basically, the user should be able to simply specify what drives they have, and in what order. So… //#define SDSUPPORT
#if ENABLED(SDSUPPORT)
//#define DRIVE1_LOCATION ONBOARD
//#define DRIVE2_LOCATION LCD
//#define DRIVE3_LOCATION USBFD
#endif
|
I agree that the SDIO/SPI choice be hidden from the user. I see no value add I agree that the pins_YOUR_BOARD.h files definition of FYI on the hardware side. A board with an SDIO interface to the SD card can access the SD card either via the SDIO interface or using a SPI interface. The SPI option would probably be a software SPI. I'm not aware of a STM32 processor that has both SPI and SDIO mapping to the same pins. |
The concept for #25715 looks good. Please let me know when it is ready to test, my new btt octopus pro board has all 3 storage methods so it would be interesting to see how it works! |
c624e13
to
e6f1b07
Compare
9c65146
to
4f65466
Compare
c792921
to
37fb26b
Compare
37d77d6
to
aa44542
Compare
Description
Read and write ability for SDIO Cards. Add SDIO media support to
M21
. Add SDIO access in userPrint From Media
menu.Requirements
This requires the use of a board with an onboard SD slot accessible by SDIO (ex: BTT Octopus/Octopus Pro). If access to other storage media is desired at the same time,
#MULTI_VOLUME
should be enabledBenefits
Expose SDIO storage capability to hosts and users.
Many board bootloaders use the 'firmware.bin' method update firmware on startup. This firmware upgrade method often only works with the built in onboard SD slot which uses SDIO. When boards are installed in some printers it is difficult to access the onboard SD slot and repeated physical movement of the board in tight spaces leads to damage.
With SDIO access , the
firmware.bin
and gcode files can now be read and written to onboard SDIO storage through a host application withM21 O
,M28 filename
,M29
. Remote firmware upgrade will be possible on newer boards.SDIO can also be selected in
Print From Media
now as an option when#MULTI_VOLUME
is enabled.Configurations
BTT Octopus Pro Configuration_14apr23.zip
Related Issues
Implements and improves on issue #25197
#12782