Access sd card via usb?

Status
Not open for further replies.

MMESSITER

Active member
Hi
Does anybody know how to read and write files on the sd card of a Teensy 4.1 via the USB port?
That would avoid a user needing to open a case and physically remove the card!

Thanks if you know how!

Malcolm Messiter
 
In a post on this thread: https://forum.pjrc.com/threads/6626...er-data-to-from-Teensy-4-0-4-1-and-Windows-10

I gave examples of python scripts and a Teensy 4.1 sketch that transferred data to and from the PC over the USB link. This could be expanded to handle transfers to and from the Teensy SD card. The implementation of a decent user interface on the PC is the hard part.

Sometime in the next few months, I expect the Media Transfer Protocol (MTP) will attain a level of maturity that will warrant its inclusion as a standard part of Teensyduino. Some smart programers are working on the MTP code and it is getting more capable. However, IMHO, the efforts to make MTP work for many different storage devices are standing in the way of a workable solution for the SD card---which I feel will be the storage system of choice for 99.5% of the users.

With some mods to the Teensy 3.6 or 4.1 core files, MTP is very useful now so long as you stick with the SD card root directory and don't need the event mechanism. There's even a brute force workaround that will update the MTP database without events. Note that I have only used MTP on Win10 computers---there may be issues with Linux or MacOS that have motivated some of the more recent efforts.
 
Thanks - I’ll try that!

If you stick with microSD cards (as I do it) the actual MTP_t4 https://github.com/WMXZ-EU/MTP_t4 is a reasonable solution.
Obviously feel free to follow the MTP responder thread or wait until Paul includes MTP to Teensyduino

Thank you! I’ll try that. Today. Indeed I need only a simple solution. A few small files in the root directory. These are “.MOD” files - which in my house define the parameters for different model helicopters in my home-designed radio control transmitter. I wanted to find a convenient method for backing up these files to a computer and thence to another transmitter.

Thank again.

Malcolm
 
I tried that link - the two examples won’t compile without lots of errors so I guess I must have missed something. What might that have been?
 
I tried that link - the two examples won’t compile without lots of errors so I guess I must have missed something. What might that have been?

what type of errors?
did you follow the instructions on the readme file?
what USB-type did you choose?
 
I think I should have installed one or two things first - I will try again.
I was preoccupied today because I took out a large model helicopter to a field, and for the first time ever, I flew it, controlled by my own home made radio control!! I was very excited as the radio system worked perfectly. I flew for maybe 30 minutes with zero issues!
 
If you stick with microSD cards (as I do it) the actual MTP_t4 https://github.com/WMXZ-EU/MTP_t4 is a reasonable solution.
Obviously feel free to follow the MTP responder thread or wait until Paul includes MTP to Teensyduino

I took a quick look at the GitHub repository and I will probably try implementing it later today. A few things still bother me:

1. The endpoint definitions are different between the T3 and T4 cores in usb_desc.h:

in the T4 Code:
Code:
#define ENDPOINT2_CONFIG	ENDPOINT_RECEIVE_UNUSED + ENDPOINT_TRANSMIT_INTERRUPT
 #define ENDPOINT3_CONFIG	ENDPOINT_RECEIVE_BULK + ENDPOINT_TRANSMIT_BULK

in the T3 Code:
Code:
#define MTP_INTERFACE         2 // MTP Disk
  #define MTP_TX_ENDPOINT       4
  #define MTP_TX_SIZE           64
  #define MTP_RX_ENDPOINT       5
  #define MTP_RX_SIZE           64
  #define MTP_EVENT_ENDPOINT    6
  #define MTP_EVENT_SIZE        32
  #define MTP_EVENT_INTERVAL    10
  #define ENDPOINT1_CONFIG      ENDPOINT_TRANSMIT_ONLY
  #define ENDPOINT2_CONFIG      ENDPOINT_RECEIVE_ONLY
  #define ENDPOINT3_CONFIG      ENDPOINT_TRANSMIT_ONLY
  #define ENDPOINT4_CONFIG      ENDPOINT_TRANSMIT_ONLY
  #define ENDPOINT5_CONFIG      ENDPOINT_RECEIVE_ONLY
  #define ENDPOINT6_CONFIG      ENDPOINT_TRANSMIT_ONLY

For the T4, one endpoint is used for both receive and transmit, while on the T3 side, there are separate endpoints for receive and transmit. Also, the defines for
the endpoints are different and depend on earlier #defines which are different. I wonder if it would be possible to set up both the T3 and T4 to use the same endpoint definitions---adjusting the earlier #defines as required. I ran across these issues a few days ago when I wanted to port the T4 version of MTP to the T3. I found that simply cutting the T4 defines and pasting into the T3 usb_desc.h required a lot of adjustments.

Another thing that would be nice---but I haven't figured out how to do it: Is there a way to add the new MTP descriptors to usb_desc.h without actually editing the file? I'm thinking of something like a "soft include" in usb_desc.h that would add the source from an external file if the file is present, but not cause the build to fail if the file is not present. It seems like it should be possible, but I have little experience with makefiles as I've relied on RADs like Arduino, C++ Builder, and IAR Embedded Workbench to handle the makefile generation for me. @luni proposed a similar solution in a post back in November:
Code:
#pragma once

#if __has_include("userConfig.h")
    #include "userConfig.h"
#else
    #include "defaultConfig.h"
#endif


Another point: I've seen references to "boards.local.txt" as a way to add to capabilities enumerated in "boards.txt". Is that capability defined and discussed somewhere?
 
@mborgerson
the endpoint definition are somewhat modelled after the other devices.
Anyhow, T3 and T4 have different USB implementations therefore there will be different descriptors.
There was some years ago a discussion on adding new devices more easily, but no conclusive solution was found.
Maybe Paul remembers better.
From time to time, I look into using a different USB stack, but I'm not sure it is worth the effort, as the actual system is working for me.
There is a comment by FrankB that some defines are not good for Linux, but I'm using Windows only and have no difficulties.
 
I agree - perhaps just at the moment the effort and complexity exceed the result value. I might await a simpler solution which I gather is on the way. Meanwhile I plan to perfect my comprehensive radio control system which is looking really robust and useful - especially after today’s helicopter flights. I plan to release the source code and .stl files as soon as it’s stable enough. Probably now. I’ve been adding more and more features - and this may well continue!
 
Status
Not open for further replies.
Back
Top