Teensy 3.x NATIVE USB HOST PREVIEW AVAILABLE

Status
Not open for further replies.

xxxajk

Well-known member
Yes fans, you've read that correctly
Those of you who have been waiting oh-so-long can now try out the next generation framework!
I just released this today for alpha testing.
if you have any MAJOR problems please report them on git hub.
DO NOT post requests for more drivers. These are being written in my spare time. All the drivers from 2.0 will be ported.

NOTE! To use the Teensy 3.0/3.1/LC in host mode, select "No USB" from the tools menu for USB Type.

Clone your copy here https://github.com/felis/UHS30 to play!

Good luck, and all the best!
--xxxajk
 
Last edited:
That's a very positive and welcome development!

Wondering though, has anyone else been able to get this to work? I hooked up a teensy3.1, feeding verified power to the Vin and Ground, and with a known-good OTG adapter cable to connect devices. Using Arduino-1.6.3 (Linux download link for 1.6.4 is broken), the current teensyduino distribution, and a current UHS30 checkout at c1eaa6a8b6f2c1eed14c48afa2874f6ef9b98d98.

The teensy's serial uart successfully prints out device descriptors when running the KINETIS_DEV_DESC example, but both my own code and the TEST_KINETIS_BULK seemingly fail to accomplish bulk transfers, with the latter's read attempts hanging with a known-good USB flash stick of 512 byte sector size. (I have not yet been able to try the UHS_FS_NEW_DEMO as it has a dependency on an apparently external RTC, but I'm willing to try stubbing that out)

I fully understand that this is alpha code but would be quite interested to know if there are any known "gotchas". For example, there is a note to set the teensy USB type to "none" (though this doesn't seem to matter). Should the clock speed be set to something other than 96 MHz optimized?

I've already been through a copy of the code adding a lot of logging, and as near as I can tell it the ISR is running and it does attempt to write bulk transfers, but I am doubting that they are seen by a peripheral. If I send a mass storage reset control request, that does seem to make the device go away for a while, so perhaps the failure is more confined to bulk transfers. Lacking a hardware USB analyzer, I'm toying with the idea of digging out a USB device project for another MCU board and modifying it to report over serial the raw contents of any bulk transfers it receives...

Thanks for publishing this library, even in experimental form, and for any ideas!
 
Last edited:
That's a very positive and welcome development!

Wondering though, has anyone else been able to get this to work? I hooked up a teensy3.1, feeding verified power to the Vin and Ground, and with a known-good OTG adapter cable to connect devices. Using Arduino-1.6.3 (Linux download link for 1.6.4 is broken), the current teensyduino distribution, and a current UHS30 checkout at c1eaa6a8b6f2c1eed14c48afa2874f6ef9b98d98.
1.6.3 should be fine and dandy.
You should also try adding on a powered HUB, in which case the USB transfer rates are slowed down a little bit, and you don't have to worry about power supply demands. This is the best way to run.
The teensy's serial uart successfully prints out device descriptors when running the KINETIS_DEV_DESC example, but both my own code and the TEST_KINETIS_BULK seemingly fail to accomplish bulk transfers, with the latter's read attempts hanging with a known-good USB flash stick of 512 byte sector size. (I have not yet been able to try the UHS_FS_NEW_DEMO as it has a dependency on an apparently external RTC, but I'm willing to try stubbing that out)
Some USB storage devices are finicky. Try another brand, and/or try adding a powered HUB which changes some of the transfer timings and solves any nagging power problems.

The RTC stuff is mandatory for the filesystem.
Don't worry, it supports the RTC on the teensy 3.1 out of the box, just add the RTC crystal on your Teensy 3.1.
The external RTC stuff is only for other MCU that lack an RTC, for example, ATMega2560.
I fully understand that this is alpha code but would be quite interested to know if there are any known "gotchas". For example, there is a note to set the teensy USB type to "none" (though this doesn't seem to matter). Should the clock speed be set to something other than 96 MHz optimized?
You really should set USB to None, and it does matter a lot. It may be why you are having some issues -- you may be getting conflicts.
All standard clock speeds are supported. Very low clock speeds can't be supported, and are not supported in device mode either because USB needs to have a certain minimum clock rate in order to operate at all. Overclocking hacks work too.
I've already been through a copy of the code adding a lot of logging, and as near as I can tell it the ISR is running and it does attempt to write bulk transfers, but I am doubting that they are seen by a peripheral. If I send a mass storage reset control request, that does seem to make the device go away for a while, so perhaps the failure is more confined to bulk transfers. Lacking a hardware USB analyzer, I'm toying with the idea of digging out a USB device project for another MCU board and modifying it to report over serial the raw contents of any bulk transfers it receives...

No need, since there is already error reporting facilities within the code.
These even work from within the ISRs, and heap is ISR safe-- meaning you can abuse this fact and use printf :)

Thanks for publishing this library, even in experimental form, and for any ideas!

You are most welcome!

Right now development is stalled because I am currently involved in a very demanding contract, and some of the others are busy with their education.
 
Awesome work Andrew!!

Oh how I need more hours in the day! So want to give this a try right now, but I've just barely getting caught up to the last 3 days of forum activity before I disappear for a few more days to hopefully fix the pin 33 problem once and for all.

I definitely want to look at this later in the week!!!
 
Thanx Paul, and yeah, I wish I had like 10 clones or some sort of way to have a parallel experience to do everything as well.
I need more than hours in a day, I need extra lifetimes. ;)
 
BTW, how does the LC assert host mode if there is no connection to pin 4 of the USB mini connector? I thought that had to be grounded for host mode to be enabled.
 
Pin 4 is used to tell which end is the supply for 5V. In USB 2.0 specifications. That is really all it does, and it is used to prevent both sides attempting to supply power. Technically you could eliminate the power line if both sides are self powered, and things would still work.
You can have the cable connected "wrong" where the device supplies the host with power, and HNP (Host Negotiation Protocol) decides which side is actually the host.
HNP is only partially dependent on the D+/- lines.

USB is actually a single host centered network, much like SCSI and IEEE488.

If a device is "dumb" and not OTG, then HNP fails and the fallback is the D+/- lines. Since the other side did not understand HNP, you assume the role of host. Pretty simple.

If both sides are "smart" (aka OTG) which side is actually the host depends on which side is requesting to be a host and which side is requesting to be a device.

Consider the following scenario: contact syncing two phones via USB OTG. One is a consumer, the other is a producer. These directly correspond to host and device.

I hope that this explains stuff in a way that is easy to consume without being too technical. If you want more dirty details, please consult the USB 2.0 (and later) specifications.
 
Will this code allow me to have the Teensy appear as a mass storage device when plugged into a computer?

I have added a 4Gbit SPI memory chip to my teensy, and I want users to be able to retrieve files off the Teensy by plugging it into their computer.

As far as I can tell, the only solution for this presently is to use uTasker, and I am not yet prepared to move out of the arduino ecosystem.
 
Last edited:
Will this code allow me to have the Teensy appear as a mass storage device when plugged into a computer?

No, it is host mode, not device mode.
I have added a 4Gbit SPI memory chip to my teensy, and I want users to be able to retrieve files off the Teensy by plugging it into their computer.

As far as I can tell, the only solution for this presently is to use uTasker, and I am not yet prepared to move out of the arduino ecosystem.
The None mode is there for the hacking, You'd have to write a mass storage device implementation.
 
I spoke to onehorse about his SPI flash boards, and he suggested that Mass Storage might be part of the next teensy firmware, and that Paul would have more information on this.
 
No need, since there is already error reporting facilities within the code.
These even work from within the ISRs, and heap is ISR safe-- meaning you can abuse this fact and use printf :)

First, many thanks for the reply and for your efforts in creating this library.

What I was finding was that the code thought things were okay, but something outside of its awareness wasn't working for the peripheral. At this point I think really attacking that problem would either require finding a hardware USB analyzer, making an instrumented peripheral that reports what it is seeing, or going through the code over and over until I understand it all in comparison with the programming manual.

I've actually now tried an entirely different, non-teensyduino codebase on the teensy hardware, based on a port of the mbed libraries, and that worked partially in getting a reply from the peripheral to its first operation, and continuing to get unsolicited responses thereafter, but subsequent commands were ignored. Interestingly the same application code worked for me both with KL25Z and STM32F4 backends in successfully operating the peripheral. I ultimately removed the PTC fuse from the teensy and replaced it with a 0 ohm shunt, so I'm satisfied it is not a power problem, especially as the result was substantially cleaner power routing than in my successful experiments on other boards.

I spent yesterday learning about oddities of the K20 family (splitting your ram evenly about 0x20000000 is, shall we say, novel) and trying to get something to function as enough of a CMSIS-DAP interface to bring up an MK20DX64 on my own board. It's definitely being a learning curve, but having USB host capability in a low end micro (ultimately right down to their 32-QFN M0's which would be the next project) is worth some adjustment.

So, while I'm no longer pursuing trying to do USB host stuff on the Teensy at this precise instant in time, I'd remain interested in the progress of it - always good to know of the options.

UPDATE: overcame some configuration and broken-trace issues and got home-made MK20DX64 board running, but unsurprisingly the mbed-derived USB host code does the exact same "almost but not quite" as it does running on the Teensy. Didn't try to port xxxajk's code to try. Sometime hopefully I'll figure out what is really going on with the K20 USB peripheral, but for now I" think I'm going to switch to making a smaller board for the MKL25Z's, since the build for the KL25Z freedom worked fine.
 
Last edited:
..... that Mass Storage might be part of the next teensy firmware....

MTP protocol is planned, but MSC is not. They're similar from an end user perspective, but the underlying protocol and implications for sharing of files between Teensy and the PC are very different.

At the rate things are going, MTP is certainly not going to make the next release. But it is planned....
 
First, many thanks for the reply and for your efforts in creating this library.

What I was finding was that the code thought things were okay, but something outside of its awareness wasn't working for the peripheral.

Please be aware that some devices expect to run only at high speed or super speed and not full or low speed.
This may be the reason your device fails, and why a hub can fix the problem because hubs have a transaction translator that can manage the speed differences.

I've used hubs on older PCs that only have full speed ports to enable use of high-speed devices, so it is a common problem.
Find an older PC and you will run into the same problem with using the device.
 
Please be aware that some devices expect to run only at high speed or super speed and not full or low speed.
This may be the reason your device fails, and why a hub can fix the problem because hubs have a transaction translator that can manage the speed differences.

I wish it were that simple - but given that I've now run the peripheral directly using both STM32F4 and KL25Z chips neither of which support USB high speed (some of the ST parts could, but only with a helper chip that wasn't present), I know that it is fine with USB full speed. And I now it's not the board, as I had the same experience on both commercial and handmade boards, with the working KL25Z board being very similar to the running, but not quite communicating handmade K20 one that gets the same partial result as the Teensy does.

Sometime it would be interesting to sit down with the K20 and KL25 programming manuals and do a side by side comparison of the USB engines... but for the moment I'm content to use the other chip families.
 
Have you tried a hub though? Please try it.
If a hub fixes the problem, then I'll know to slow things down even if there is no hub involved.
I do a few tricks that currently may place the speeds out-of-spec for timing unless a hub is present.
Although I have not had any problems with my devices, it doesn't mean other devices will fall apart.
 
All of the support from the 2.0 library is getting ported, and in some cases, rewritten to make more sense. This would include HID.
There is a lot to think about when rewriting parts that have multiple paths, such as HID.
The problem I am working out is that HID can sometimes be on bluetooth on USB.
As you can imagine, this can make things complicated, especially when you want tight code that can be reused.
 
I know this is probably the last place a noob should stick their head in but I'm too excited by developments.
I plan to use this library with the PTP library to talk to my Canon EOS.
Do you have a nice picture of how to do the wiring so I don't blow up my teesny, 5dIII, computer and everything else up?
Don't worry I'll be hooking up my 450d first .....
I notice from previous discussions that I shouldn't use the 150uF capacitor. I have some USB female type A
http://www.ebay.com.au/itm/USB-Type-A-female-Converter-Module-Breakout-Charging-Charger-Board-5V-Power-/321718227389?hash=item4ae7e691bd:g:b4AAAOSwNSxVI6Mx
sockets waiting. Or I have to use a OTG cable ?
I have been using the MegaADK and the Due that I have quiet well with the 7D that I have.
Doesn't mean I understand most of it though.
 
The only thing that is supported at this time is mass storage. PTP is a planned feature, though.
Considering my busy schedule, I unfortunately can not hint on a timeline at this point.
 
The only thing that is supported at this time is mass storage. PTP is a planned feature, though.
Considering my busy schedule, I unfortunately can not hint on a timeline at this point.

I still have the Mega ADK to play with till its ready :)
 
Hmmm... not working (Teensy 3.2).

Is there no Tutorial?! USB Host is important... and no Tutorial?

How I can see the Serial Monitor without connected USB, because its USB Host?


I mean... why the autor can not do a simple USB Host check .ino? A logic test so that everyone can check whether USB Host is working... and then play around with this basic start.

I don't understand it, really.


Is it so hard to write a short .ino for the Arduino UNO with "Serial.write()" and a short USB Host .ino for the Teensy 3.x to receive the USB signal from the UNO?

I don't know the lines I need... and I can not test the USB Host, because I understand nothing what the UHS30 lines are doing... there is no help, only not helping examples.
 
Last edited:
Status
Not open for further replies.
Back
Top