teensy 3.6 as a usb mass storage proxy device

Status
Not open for further replies.
C

creitzel

Member
First, since this is my first post here, let me say hello to you all, and introduce my self. My name is Chris, and Ive been lurking around here for a while, researching the teensy, and the projects that you all have made with it. It seems to be a very impressive/capable device, and I really enjoy seeing everything you guys have been able to create with it. I am totally new to embedded programming, but I've got a couple decades of programming various platformss (android, windows, mac, linux, etc) in several languages (c, c++, pascal, delphi, etc), under my belt.

I am currently working on a car-puter project built on a raspberry pi 3.0 for my truck, and I just purchased a teensy 3.6 because it sounds like it will do what I want it to do. Which is, I want it to act as a USB mass storage device proxy, between my car stereo (which only understands how to talk to USB mass storage devices) and my raspberry pi which is going to be linked to a hard drive storing all of my media files. The basic idea is that when the car stereo tries to browse or stream a file from the teensy, I will proxy the request over to the pi, which will locate the appropriate file, and return it to the teensy to serve it up to the stereo.

I've been playing with my teensy 3.6 for a few days now, and have been able to successfully load various test programs, and examples onto it, using both Arduino, as well as c++ code, and a makefile.

It seems that the teensy should fit well into this role, from all of the reading that I've done on here. Unfortunately, it looks like a USB mass storage device isn't yet supported for the 3.6? As far as I can tell from the core code, there is a USB MTP device, but that seems to be a stubbed out empty implementation. I have been poking around in the code, and in the programmers reference for the MCU for the last couple of days, and I'm not quite understanding everything that is going on when setting up the usb devices.

I would greatly appreciate it, if you guys could a) let me know if I'm on the right track here, and the teensy can in fact do what I want it to do, and maybe b) give me a few tips/pointers in where to look, to get an understanding of what I will have to do to create a USB mass storage device object similar to the other usb objects in the core code, that I can then use to implement my proxy.

Thanks again for any help you guys can give me,

Chris
 
creitzel said:
I am currently working on a car-puter project built on a raspberry pi 3.0 for my truck, and I just purchased a teensy 3.6 because it sounds like it will do what I want it to do. Which is, I want it to act as a USB mass storage device proxy, between my car stereo (which only understands how to talk to USB mass storage devices) and my raspberry pi which is going to be linked to a hard drive storing all of my media files. The basic idea is that when the car stereo tries to browse or stream a file from the teensy, I will proxy the request over to the pi, which will locate the appropriate file, and return it to the teensy to serve it up to the stereo.
Click to expand...
You do realize that USB mass storage presents a disk image and not files, right?

Some car stereos support MTP, which would be file-based. But startup/indexing of the car stereo is going to be quite slow if you have a large number of files.
 
i suppose your android/iphone is not suffiecient enough you need music to pass through 2 microcontrollers before it hits your stereo, and expect that to work long time without issues?
 
tni said:
You do realize that USB mass storage presents a disk image and not files, right?

Some car stereos support MTP, which would be file-based.
Click to expand...

Actually, no, I didn't realize. This is my first project doing anything with the usb stack, and I've not yet gotten to reading the usb spec. It sounds like I should try and find a spec for my car stereo, and see what interfaces it is actually looking for, and read up on them in the usb spec.

I guess I was going under the assumption that there was a single standard that the stereos used, from what little I know of the usb spec, I was assuming that was a mass storage interface. I thought MTP was for digital cameras etc. I'm admittedly ignorant in this area, gonna have to educate myself I see. :)

But startup/indexing of the car stereo is going to be quite slow if you have a large number of files.
Click to expand...

Are you saying that it will be quite slow, due to me proxying the requests? or just going through the usb interfaces? I currently have a 250 GB laptop hard-drive in a usb enclosure (another reason I figured it was using a mass storage interface) plugged in, and it takes a couple seconds when the truck starts for it to start up, but then it seems to be fine. I know that I will be adding some slowdown to the process, by proxying, but are you saying that it will make it unusable?

Thanks for the comments/info. :)
 
tonton81 said:
i suppose your android/iphone is not suffiecient enough you need music to pass through 2 microcontrollers before it hits your stereo...
Click to expand...

I am planning on setting up the pi as a media server (among other things), so that my kids can pick and choose different media than what my wife and I are listening to, on trips and the like. Since I want to do that, and I also would like to not have to have my media collection stored on 2 drives, I figured this might be a good solution. My stereo can handle reading from a usb drive, and I figured I could just write some proxy code between something like the teensy, and my pi, and pull it off. As for passing through 2 micro-controllers, ideally, the media files would just be served up straight to the stereo. I don't want either the pi, or the teensy to process the files in any way, other than as a file server, so I figured this wouldn't add too much overhead.

I don't currently use my android phone to serve media to my stereo, as it has to be played on the phone, and forwarded to the stereo via bluetooth, which means I lose my steering wheel controls, and in dash player functionality.

...and expect that to work long time without issues?
Click to expand...

I have no expectations whatsoever here. I'm new to all of this technology, but at a high level, it seemed like it should be doable. That said, it also sounded like a cool project to play with, and I love to tinker with this kind of stutff, so I figured I'd give it a go. Quite frankly, even if I never get it working to my satisfaction, I'll have at least learned quite a bit about usb, and the teensy in the process, right? :)

Are there specific problems that you are foreseeing with this idea? If so, I would love to hear them.

Thanks for you input :)
 
so using teensy basically as a "usb drive" you couldn't just pop a usb drive in the Pi instead? It makes no sense to use a teensy as a usb drive if the Pi will just feed it to the stereo, you might as well just plug a usb drive in the Pi and work on your passthru there
 
tonton81 said:
so using teensy basically as a "usb drive" you couldn't just pop a usb drive in the Pi instead? It makes no sense to use a teensy as a usb drive if the Pi will just feed it to the stereo, you might as well just plug a usb drive in the Pi and work on your passthru there
Click to expand...
That doesn't work. Pi 3 is only a USB host, it can't do device mode. The stereo is the USB host.

\\

Android can act as MTP device. You should test that with your stereo, if it works reasonably well. You can expect MTP to be a lot slower than your USB hard drive (which acts as USB mass storage), even without proxying.

The Teensy MTP that was linked is using the USB 1.1 port, it's limited to 1MB/s.

How do you want to connect the Pi 3 to Teensy? Using the second Teensy USB port would be a major effort. Paul has some early support for it in host mode, but AFAIK there is nothing so far to support device mode (since the Pi has to be host). (The 2 Teensy USB controllers have completely different programming models.)
 
tonton81 said:
so using teensy basically as a "usb drive" you couldn't just pop a usb drive in the Pi instead? It makes no sense to use a teensy as a usb drive if the Pi will just feed it to the stereo, you might as well just plug a usb drive in the Pi and work on your passthru there
Click to expand...

The Pi won't just feed it to the stereo, I wish I could set it up that way, it would be simpler for sure. I'm using the Raspberry Pi 3b, it has a single usb stack on it, supporting a 4 port onboard hub. All 4 of the ports are running in host mode only (unless you rebuild the kernel of the os, to make them device mode, in which case all 4 would be running in device mode). I need those ports (running in host mode) for other parts of the project (one of which I am plugging a usb hard drive into, to store my media on., and 2 more to support some video capture hardware for my reverse cameras).

I'm not actually wanting to use the teensy as a usb drive. I want it to act as a usb drive proxy. I want the teensy to present a usb drive interface to the stereo (so that it thinks it is talking to a usb drive), and I want to write software on the teensy, to use the GPIO pins to communicate to the raspberry pi, the requests coming from the stereo, and have the Pi communicate to the usb hard drive plugged into it, and serve up the data to the teensy through the GPIO, and then have the teensy return it to the stereo. If all that makes sense.
 
tni said:
Android can act as MTP device. You should test that with your stereo, if it works reasonably well. You can expect MTP to be a lot slower than your USB hard drive (which acts as USB mass storage), even without proxying.

The Teensy MTP that was linked is using the USB 1.1 port, it's limited to 1MB/s.
Click to expand...

Ah, I didn't think about android running MTP mode, but you're right, it can. I'll have to plug a device into that port in the truck, and see if it can deal with it. That would let me know whether the MTP example that was posted will work or not.

How do you want to connect the Pi 3 to Teensy? Using the second Teensy USB port would be a major effort. Paul has some early support for it in host mode, but AFAIK there is nothing so far to support device mode (since the Pi has to be host). (The 2 Teensy USB controllers have completely different programming models.)
Click to expand...

I was planning on writing a proprietary byte wide interface through the GPIO on both devices. I thought if I used one of the bit wide interfaces (I2C, or SPI UART, etc) that are available on both sides, that it would add too much of a slow down. I've got like 20 some pins open on the Pi's GPIO side, and basically all of them open on the teensy side, so I've got pins to burn lol.

Heading out to see if the truck can connect to an old android phone using MTP mode! :)
 
tni said:
Android can act as MTP device. You should test that with your stereo...
Click to expand...

Ok, just did a quick test with an android phone running in MTP mode, with 2 albums on it (roughly 17 mp3s). It worked, the stereo was able to read the phone, and make sense out of the media files on it, so it must support both MTP and mass storage devices.

That said, it was significantly slower than using my usb hard drive.

Loading the usb hard drive, when the truck first starts, takes about 5-10 seconds max, usually around 3-5, and then browsing between songs (using shuffle across all the rock albums lets say) takes about half a second to get to the next song (I believe the stereo is caching a song list on it or something, no way it could be browsing the entire drive that fast, for every song switch).

The MTP connection took around 50 seconds to load initially (granted it's browsing the entire contents of my phone's internal memory, so that may be faster with the teensy, if it is just publishing music folders), and it took around 2 seconds to switch songs.

I have no idea what transfer rate is being used by the phone, it is fairly recent hardware though (samsung galaxy s6 edge), so it should have the ability to do usb 2.0. Not exactly sure how to go about testing it either. I'd definitely like the end result to be a bit faster than what I saw with the phone, though, if I can get it.

Is the 1MB/s limit, a limit of MTP, or was it a design choice of that project to use the 1.1 port? Is the mass storage interface inherently faster than MTP? Or is it just the fact that it is using the 1.1 port vs a 2.0 port, and if I were to use a 2.0 port, I would see similar speeds with either interface?

Thanks a ton for all the help so far :)
 
who ever said an android/iphone transfar was high speed? it's not. If you start your truck with a SSD, it should be way faster, and since it's for vvehicle use, you SHOULD be using SSD, NOT HDD.
 
creitzel said:
Is the 1MB/s limit, a limit of MTP, or was it a design choice of that project to use the 1.1 port?
Click to expand...
USB 2 would work fine. But the Teensy USB 2 port is very different and more difficult to work with (EHCI interface).
Is the mass storage interface inherently faster than MTP?
Click to expand...
With MTP, you can expect a lot of request/response roundtrips as it enumerates the files. With USB mass storage, if there is decent caching, there will be a lot less roundtrips - asynchronous read-ahead and the directory disk blocks will also cover multiple files.
Or is it just the fact that it is using the 1.1 port vs a 2.0 port, and if I were to use a 2.0 port, I would see similar speeds with either interface?
Click to expand...
Your phone is most certainly using USB 2.
 
tonton81 said:
who ever said an android/iphone transfar was high speed? it's not.
Click to expand...

Not sure who said that, I'm sure I didn't. I stated I didn't know what transfer rate I was getting out of the phone.

If you start your truck with a SSD, it should be way faster, and since it's for vvehicle use, you SHOULD be using SSD, NOT HDD.
Click to expand...

I imagine an SSD drive would be quite a bit faster than the hard drive I am a currently using, for sure. Frankly, I don't see the point in spending another $100 on a SSD drive, when I have a spare laptop hard drive laying around, and I can get a usb enclosure for it for $15. Not to mention that a 250GB SSD was around $250-$300 when I first put the drive in the truck. It's been working in my truck for a few years now, with absolutely no problems at all.

All that said, just using a SSD drive doesn't get me to where I want to be with this project, I still don't want to have to have 2 copies of my entire media library on 2 different devices in my truck. Like I said before, if this ends up not being possible with the teensy, I'll just drop the stereo interface portion of my project, chalk it up to a learning experience with a cool little device, and move on.
 
the difference is in -20 temps a hdd will not be able to spin up and you wont have music
also the vibration of the roads is not ideal for harddrives they have sensitive heads that are easy to fail in time, SSD should be used for this type of project
 
I'm going to take a stab at using that example project to set my teensy up as a MTP device, toss an SD card in it, load it up with a portion, or all of my media library, and see how that performs in the truck. I think that will give me a good baseline of the kind of performance I can expect if I go that route.

even if that proves to be slower than my current setup, it might be acceptable performance, and I can then try to write a backend interface to the pi, and see how the whole chain performs.

if MTP is too slow, it sounds like, from what you are saying, I'll have to basically start at the chip level, and implement my own usb 2.0 driver, and then the mass storage interface on top of that. Sounds like quite a bit of coding. I might just do it, this is a hobby project after all, and if I'm not coding on this, I'll be coding on something else. Might as well learn as much as possible lol. :)
 
the difference is in -20 temps a hdd will not be able to spin up and you wont have music
also the vibration of the roads is not ideal for harddrives they have sensitive heads that are easy to fail in time, SSD should be used for this type of project
Click to expand...

I'm not arguing that a hard-drive should be used for this type of project, rather than an SSD, at all. I understand that my truck is not the ideal environment for a hard drive to be running in.

I'm simply stating, that
A.) I had the hard-drive laying around, doing nothing.
B.) I have a complete backup of the data on the hard drive on my network in the house. So if it is lost, no biggie.
C.) I've got a family to feed, and at the time that I decided to use it, spending $15 on a usb enclosure was way better than $250+ for an equivalent amount of storage space on an SSD.

That said, I live in Michigan, and we do occasionally experience temps in the 0 to -10 range throughout the winter, and I've never had a problem with the drive spinning up. Even when it is that cold outside, it's always a few degrees warmer in my truck cab.

if and when the hard drive finally dies on me, you can bet that I'll probably be replacing it with an SSD (they've come down quite a bit in cost since I first put a drive in the truck). And I'll count myself as having saved some money for however many years I get out of this old piece of hardware pulled from a dead laptop.
 
Po Ting said:
hello, I remember a project, that could turn a teensy 3.2 into a ~190Kb USB mass storage device? with chip its own flash.

I didn't really dig into it, so poor in coding.
but i guess the project might help you?
Click to expand...

Thanks for the link, I'll check that out.

I've currently been trying to get the MTP example posted earlier in the thread to work with my car stereo. I've been able to get it up and running, and my computer seems to be able to read it, and interact with it, but the stereo refuses to go beyond it's initial "Loading USB" phase, which means it is getting hung up somewhere. I have created a log file on the sd card, but so far the info I'm dumping in there seems to be the same for both the computer, and the stereo. Not quite sure where to go from here with it.

I was just thinking of maybe putting down the MTP stuff, and trying to do a mass storage device on my own, so your post is very timely. :)

Thanks again.
 
creitzel said:
Thanks for the link, I'll check that out.

I've currently been trying to get the MTP example posted earlier in the thread to work with my car stereo. I've been able to get it up and running, and my computer seems to be able to read it, and interact with it, but the stereo refuses to go beyond it's initial "Loading USB" phase, which means it is getting hung up somewhere. I have created a log file on the sd card, but so far the info I'm dumping in there seems to be the same for both the computer, and the stereo. Not quite sure where to go from here with it.

I was just thinking of maybe putting down the MTP stuff, and trying to do a mass storage device on my own, so your post is very timely. :)

Thanks again.
Click to expand...

You are welcome,
I once tried to build a USB interface that could access file with SPI- micro SD and then found that project ,
now I think the MTP library would met my previous use.
but sure USB mass storage is much faster, I'll stick to your updates ;)
 
bmuessig said:
The easiest solution is to take a big SD card and a Raspberry Pi Zero, which can act as a USB mass storage device.
Click to expand...

I agree, that would probably be the easiest way to implement this part of the project. That said, I also need wifi support for other parts of my project (like a media server for my kids, and a way to transmit camera video to my android tablet), and I wouldn't be able to run the pi-zero in both host and device mode for USB, so that I can have it act as a wifi hotspot, and run as a mass storage device for the stereo.

I looked at uTasker as recommended earlier, and was working with the author to get something going, but was running into a couple of issues there. So I have now purchased a FRDM-K66F development board, and I'm in the process of writing my own solution, using that. I want to use the high speed USB port, so I'm probably going to build a little daughter board with a USB connector on it (I need some other functionality for my pi as well, so the daughter board is necessary), and then plug the teensy into that, and write the software using NXP's sdk and tools.
 
creitzel said:
I agree, that would probably be the easiest way to implement this part of the project. That said, I also need wifi support for other parts of my project (like a media server for my kids, and a way to transmit camera video to my android tablet), and I wouldn't be able to run the pi-zero in both host and device mode for USB, so that I can have it act as a wifi hotspot, and run as a mass storage device for the stereo.

I looked at uTasker as recommended earlier, and was working with the author to get something going, but was running into a couple of issues there. So I have now purchased a FRDM-K66F development board, and I'm in the process of writing my own solution, using that. I want to use the high speed USB port, so I'm probably going to build a little daughter board with a USB connector on it (I need some other functionality for my pi as well, so the daughter board is necessary), and then plug the teensy into that, and write the software using NXP's sdk and tools.
Click to expand...

Well there is the new Raspberry Pi Zero W which has builtin WiFi. This might be exactly what you need ;)
https://www.raspberrypi.org/products/pi-zero-w/
 
Status
Not open for further replies.
Back
Top