Make Teensy act like a USB file system?
- Thread starter kdharbert
- Start date
- Status
defragster
Senior Member+
What Teensy? Look for MSC threads?
wwatson
Well-known member
You are correct. It is still work in progress but is still usable. There are several branches I have made the latest being MSC-non-blocking. So far I have used it with uSDFS which uses FatFs. All of these are functional but not necessarily complete or optimized because of my programming skills
But they do function I am still learning c++ and am trying to keep up with programming wizards on this forum. The latest version can use asynchronous access to reads and writes of a USB host mass storage device but needs a multitasking type of file system to work. Right now it is just doing direct sector reads/writes (destructive).I have just now got MSC working with SdFat-beta using the latest version of @Paul's SD, SdFat-beta libraries.
This is still WIP.
More to come
wwatson
Well-known member
I think what you are looking for is MTP. Here is what you probably want. https://forum.pjrc.com/threads/43050-MTP-Responder-Contribution It turns the Teensy into an MTP drive. My libraries at this time are meant for the USB Host port on the T3.6, T4.0 and T4.1.
KurtE
Senior Member+
I just updated my fork of it from the main sources: https://github.com/WMXZ-EU/MTP_t4 last update was 9 days ago...
And compiled the mtp-test program for a T4.1. And it builds for me. Note: I am running Arduino 1.9.13, with the latest beta Teensyduino (actually maybe a little beyond that). And as you will tell you, you need to change your USB type to be the MTP experimental.
And compiled the mtp-test program for a T4.1. And it builds for me. Note: I am running Arduino 1.9.13, with the latest beta Teensyduino (actually maybe a little beyond that). And as you will tell you, you need to change your USB type to be the MTP experimental.
Thanks for the details. I'm hoping there might be an alternate route:
Is there any chance there is a such a thing as a 'USB mux' library out there? There are interrupts on all the digital pins, so its not hard to attach a secondary USB connector between the Teensy and the PC and mirror the pins through to the SD card. When the SD is being written, the PC will briefly lose control. The files will be written at regular intervals, so the script on the PC can time the reads to avoid collisions. It seems Teensy could also fake a heartbeat signal back to the PC so the device doesn't unload in the OS.
Would this be able to work? Anything like this exist?
Is there any chance there is a such a thing as a 'USB mux' library out there? There are interrupts on all the digital pins, so its not hard to attach a secondary USB connector between the Teensy and the PC and mirror the pins through to the SD card. When the SD is being written, the PC will briefly lose control. The files will be written at regular intervals, so the script on the PC can time the reads to avoid collisions. It seems Teensy could also fake a heartbeat signal back to the PC so the device doesn't unload in the OS.
Would this be able to work? Anything like this exist?
PaulStoffregen
Well-known member
No, that can't work. USB doesn't work on ordinary GPIO pins with interrupts. SD cards and USB are completely different protocols. The details of each protocol are far too complex to explain in a forum message. Please trust when I say there is absolutely no hope to "mirror the pins through" to give your PC access to the SD card.
PaulStoffregen
Well-known member
I can barely even understand your question. Are you somehow suggesting that USB and SD protocols would no longer be completely different and utterly incompatible with each other if an additional add-in card (whatever that is?) were used instead of the "on-board card" (the Teensy pins?) This question just doesn't even make any sense to me, though I'll admit I'm not clear on exactly what sort of hardware you have in mind by these vague phrases?
What I can do is point you to the sources to actually learn some details about these protocols.
Here is the USB 2.0 spec. While it is a huge 600 page document (and those 600 pages are only the beginning, MSC bulk-only and SCSI are on top of this), you can at least learn the essential concepts of USB from chapter 4, which is only about a dozen pretty easy to read pages.
https://www.pjrc.com/teensy/beta/usb20.pdf
And here is the basic SD spec.
http://users.ece.utexas.edu/~valvano/EE345M/SD_Physical_Layer_Spec.pdf
I know "SD card readers" which plug into USB ports are cheap commodity items these days. It's easy to take them for granted. But inside those chips is an incredible amount of complexity to implement USB, to emulate a SCSI host controller over the MSC protocol, and also implement the complex protocol to access the SD card. It's so much more than some wires. Each protocol is incredibly complex. Things only "just work" because an incredible amount of design work went into making the chip inside those cheap products.
What I can do is point you to the sources to actually learn some details about these protocols.
Here is the USB 2.0 spec. While it is a huge 600 page document (and those 600 pages are only the beginning, MSC bulk-only and SCSI are on top of this), you can at least learn the essential concepts of USB from chapter 4, which is only about a dozen pretty easy to read pages.
https://www.pjrc.com/teensy/beta/usb20.pdf
And here is the basic SD spec.
http://users.ece.utexas.edu/~valvano/EE345M/SD_Physical_Layer_Spec.pdf
I know "SD card readers" which plug into USB ports are cheap commodity items these days. It's easy to take them for granted. But inside those chips is an incredible amount of complexity to implement USB, to emulate a SCSI host controller over the MSC protocol, and also implement the complex protocol to access the SD card. It's so much more than some wires. Each protocol is incredibly complex. Things only "just work" because an incredible amount of design work went into making the chip inside those cheap products.
Thanks for the second response. It looks like my original goal got lost. I have a camera library that writes files to the onboard SD card (or any other) and the PC can read those files when the SD card is inserted into a USB port. The goal is to time slice access to an SD card between the Teensy and PC via a secondary USB connection to the PC since it appears MTP functions are WIP.
My reasoning is that if I used an SD unit that was not the onboard one, I could use an external MUX IC to select between the Teensy and the PC having access. In this config, the original protocol usage would already be sufficient to get the job done, and I don't have to go into depth on protocols. Unless I'm missing something, this at a minimum should work.
From there, I figured perhaps Teensy's pins could be configured as pass-throughs to save the need for the extra MUX...and if that works, perhaps they can be configured to pass through to the onboard SD card as well...which saves another external component as well. I'd need logic converters, but its much neater. This would of course revolve around being able to blindly ferry USB traffic from pin to pin WITHOUT foreknowledge of protocols. It seems the core message here is that foreknowledge IS required. Just in case someone outsmarted how do to this, I figured I'd ask.
My reasoning is that if I used an SD unit that was not the onboard one, I could use an external MUX IC to select between the Teensy and the PC having access. In this config, the original protocol usage would already be sufficient to get the job done, and I don't have to go into depth on protocols. Unless I'm missing something, this at a minimum should work.
From there, I figured perhaps Teensy's pins could be configured as pass-throughs to save the need for the extra MUX...and if that works, perhaps they can be configured to pass through to the onboard SD card as well...which saves another external component as well. I'd need logic converters, but its much neater. This would of course revolve around being able to blindly ferry USB traffic from pin to pin WITHOUT foreknowledge of protocols. It seems the core message here is that foreknowledge IS required. Just in case someone outsmarted how do to this, I figured I'd ask.
isaacjacobson
Well-known member
I am trying to accomplish the same thing. It's been driving me crazy.
Adafruit's TinyUSB Arduino library is about as close as I've seen to this becoming a possibility.
Here's a demo of it in action: https://www.youtube.com/watch?v=0bWba0PU4-g
Unfortunately, given my limited knowledge I hit a dead end in trying to find out how to make the Arduino TinyUSB library work with Teensy. It's not impossible, as the original TinyUSB library already supports Teensy. But the TinyUSB Arduino library is does not support Teensy boards yet.
Here's a forum I started here trying to figure it out: https://forum.pjrc.com/threads/60646-Adafruit-s-TinyUSB-with-Teensy-4-0?highlight=tinyusb
Here's a thread from TinyUSB's Github regarding what needs to be done to make it work: https://github.com/adafruit/Adafruit_TinyUSB_Arduino/issues/63
Adafruit's TinyUSB Arduino library is about as close as I've seen to this becoming a possibility.
Here's a demo of it in action: https://www.youtube.com/watch?v=0bWba0PU4-g
Unfortunately, given my limited knowledge I hit a dead end in trying to find out how to make the Arduino TinyUSB library work with Teensy. It's not impossible, as the original TinyUSB library already supports Teensy. But the TinyUSB Arduino library is does not support Teensy boards yet.
Here's a forum I started here trying to figure it out: https://forum.pjrc.com/threads/60646-Adafruit-s-TinyUSB-with-Teensy-4-0?highlight=tinyusb
Here's a thread from TinyUSB's Github regarding what needs to be done to make it work: https://github.com/adafruit/Adafruit_TinyUSB_Arduino/issues/63
- Status