Marlin: [2.0.x, RFC] Any interest in USB FlashDrive support?

[marcio-ao]

Hello all,

Is there any interest in USB FlashDrive support in upstream Marlin? I've recently asked the authors of the USB Host Shield Library 2.0 to update their license to the GPL v2 or later so that their work could be incorporated into Marlin. I've also gotten a proof-of-concept to function (this is marlin with the CLCD and USB Flash Drive prototypes):

At the moment, the code works, but could probably use some clean-up. Currently I implement USB by replacing the Sd2Card class with a shim class that forwards block-level requests to the USB Host Lib, but it probably makes a more sense to implement a generic block level device class in Marlin.

I guess a bigger question at this point is whether we want the code in upstream for the 2.0 release, or whether we should wait until a printer is released with the functionality. Today the only way to get the functionality is to cobble something together using a USB Host Shield and I'm not sure whether there would be anyone really interested in doing this.

Thoughts?

-- Marcio

[p3p]

A shim does sounds like the least invasive way of supporting other types of storage devices, for 2.0.x I've been looking at chan fatfs to give standard file IO functions, and then we can define as many types of storage devices as we want behind the API accessed with filename prefixes such as "sd0:filename.gcode" or "usb0:filename.gcode", this would also fix the problem of multiple sdcards, chan fatfs is very configurable for size, compatibility, or performance, I use it in the lpc1768 platform but I don't know how it would compare to the current classes yet.

[marcio-ao]

I've been looking at chan fatfs to give standard file IO functions

Seems promising. I was a little surprised (delighted) that the FAT routines in Marlin right now were able to read data of the USB flash drive. That meant I could use only a small portion of the USB host shield library.

[Grogyan]

Using a flash drive would be much more suited for 32bit controllers, as the (electronic) interfacing is more straight forward

[teemuatlut]

Implement the software first and let the enthusiasts implement it on their machines to test it out. I think there are plenty of us who choose to build our own machines instead of buying a more consumer focused product.

[marcio-ao]

Using a flash drive would be much more suited for 32bit controllers, as the (electronic) interfacing is more straight forward

@Grogyan: How so? Unless you are talking about a specific chip with USB-OTG support, I don't see how 32-bit would make a difference. Perhaps a 32-bit micro could be fast enough to make use of a bit-banged software-only USB implementation such as v-usb, while still having enough left over cycles to run a 3D printer, but someone would actually have to write the code for that, so it's kind of a long-shot.

Implement the software first and let the enthusiasts implement it on their machines to test it out. I think there are plenty of us who choose to build our own machines instead of buying a more consumer focused product.

@teemuatlut : I wonder if the RAMPs based printers be made to work by stacking on the USB Host Shield board. That would be a relatively low effort COTS solution.

-- Marcio

[teemuatlut]

There's also a smaller USB host shield that might work but it's 3.3V only.

[marcio-ao]

Closing this as the associated PR has already been merged.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.