Teensy 3.x NATIVE USB HOST PREVIEW AVAILABLE

Status
Not open for further replies.
yea, I can have the ID pin implemented. You are talking about pin 4 on the microUSB connector yes? Screen Shot 2016-08-28 at 6.35.13 PM.png

When you said implement a USB switch that changes the power on the VBUS line, do you mean the VUSB line on the teensy? I have a separate 1A 5v power supply on my device. Do you mean to say that I need to make sure I have enough power going out of the device? Or does it have something to do with the host mode capacitor on the Teensy quick ref card?
 
If you do not intend to power from the USB port at all, then use a MIC200xxx device, without the drainage resistor.
 
Screen Shot 2016-08-30 at 2.24.20 PM.png

Here is the schematic I am using for the OTG power switch. Any thoughts? I figure this will still allow me to power the teensy since the VUSB has the diode path back to my 3v3 LDO.

I am using a Micro-AB connector to ensure compatibility with OTG cables.

I was considering a pull down resistor to ensure it is disabled at startup, but I don't think it is necessary. Do you?

Once we get this working, I will do a full write up on how to get this to work for everyone!
Thank you for your help!
 
Andrew is absolutely right, the devil is in the details!

One of those thorny details is having a large capacitor for hotplug events. Without this, the sudden appearance of a USB device (with it's 10 uF capacitance) while power is applied to the port can drain away the charge on Teensy's capacitors. The momentary voltage drop can be severe enough to reboot Teensy.

The large capacitor creates another problem. When you turn on the host port's power, it needs to be charged up. Without current limiting, it can cause Teensy to have a voltage loss and reset.

That MIC94066 chip lacks the soft start circuit, so it's probably going to cause all sorts of trouble. Maybe? But if your 5V power supply is solid (not power from another USB host), maybe not an issue. Even if you switch to the MIC94068 version, whether the soft start prevents problems is a good question.

On Teensy 3.6, I used a TI part with current limiting. The sad reality is there's no perfect solution for all circumstances, especially the tough case were Teensy is powered through a lengthy USB cable from another USB host, and then you try to use its host port to power and hotplug other USB devices. I'm planning to write more detail about this as a lengthy update on Kickstarter. If only more hours in the day.....
 
For my device, the only reason I would need to power it via USB is when I am writing code and doing some local tests on it. It is a Eurorack Synth module, so in its natural state, it is connected to a 12v rail, and I get 5V from an LDO (off a 5.5v switched supply) that is capable of up to 1A. I think it should be able to handle the power up situation.


Paul, care to share your TI part selection so I may compare it to the MIC94066?
 
Is there any problem with having the 100 uF capacitor present when the device needs to be in device mode? I guess the danger there would be reverse and sucking too much current from the host and having it reset for some reason?
 
@PaulStoffregen: One of the switches has a slew rate built-in. So it can prevent in-rush problems, but read below as It isn't needed if you design correctly... :)

@tenkai: Paul is right when it comes to a stiff supply.

Personally, I would go with 5.25V, because you can lose a little bit of power going through the switch, in practice, 5V is close enough to get the job done.
Next, you don't place the capacitor on the vbus side, you should have it on the supply side as close as possible to the switch (VINA).
I find 10uF a touch short in capacity when in this configuration, and usually use 20uF-33uF tantalum, which also has a low ESR, meaning it will help keep noise out of the circuit too.
Organic electrolytic is also a good choice.
You should test both, since they have slightly different properties.

The pulldown resistor will be OK at 10K OHMs, possibly 100K will work too. 1K will work, but would waste power and generate more heat than 10K.
The ENA input should be from a digital pin.

I Make such circuits on a breadboard and play before committing it to copper.
Once you build a testing prototype, probe the output to see that you have the needed voltage, noise immunity, etc and tweak as needed.

HTH
 
Hey @ xxxajk thanks for the posts and sharing. I've received my two teenys3.6 and first thing I'm trying is your USB EHCI tests.
However, haven't used Teensy for some time, and eyeballing the code, I'm looking to find UHS_KINETIS_EHCI.h. i've searched the directories.
Here is the include
UHS_host.h
#include "UHS_KINETIS_EHCI/UHS_KINETIS_EHCI.h"

I was expecting it at
UHS30/libraries/UHS_host/UHS_KINETIS_EHCI/
but I don't see it. This is what, I see.
Capture.JPG

So sorry for the basic question .
Thanks.
 
Last edited:
Hey @ xxxajk thanks for the posts and sharing. I've received my two teenys3.6 and first thing I'm trying is your USB EHCI tests.
However, haven't used Teensy for some time, and eyeballing the code, I'm looking to find UHS_KINETIS_EHCI.h. i've searched the directories.
Here is the include
UHS_host.h
#include "UHS_KINETIS_EHCI/UHS_KINETIS_EHCI.h"

I was expecting it at
UHS30/libraries/UHS_host/UHS_KINETIS_EHCI/
but I don't see it. This is what, I see.
View attachment 8341

So sorry for the basic question .
Thanks.

Yeah, it is not present yet, or any examples.
I did not get to the point to send packets yet, however I can do speed detection, etc at this point.
The last two months have been crazy here work-wise. Even now I am manning the pick-n-place machine.
Do you think I should push the preliminary code and example even though it is not ready yet?
Note that the low/full speed connection _will_ work, the USB port that you upload to.
let me know if you need any info on getting that side working.
Let me know if I should post what I have so far to github, especially if you are interested in helping out.
 
Gosh ...... I guess you've posted results from the tests you've done ..... but.... with a pick-n-place running on Sunday, sounds like you have a hot customer delivery deadline .

I'll look over your code on the UHS_KINETIS_FS_HOST tomorrow, though my target is K66. I do have FRDM-K64 board which has the FS host broken out.
I have a Beagle USB12 analyzer, so if the _EHCI will negotiate down, I and connect.
I'm interested in the CDC_ACM mode to communicate with north bound modems ... particles Electron, photon, cell modems, 900Mhz, wifi etc and my project is an open source project. :)

So if you publish your code, and I can make it work, possibly knit in to your other code ... I could publish how I did it ... ... whatever you think ....
 
Gosh ...... I guess you've posted results from the tests you've done ..... but.... with a pick-n-place running on Sunday, sounds like you have a hot customer delivery deadline .
Not quite, I'm trying to get a free day off , like from now thru Tuesday, minus some circuit design stuff I have to go over with the fab... but that doesn't take all day.
I hope to be able to work on this a bit tonight. Let me know if you want to collaborate via Google hangouts. No I don't use any other services, SNR isn't good elsewhere.

I'll look over your code on the UHS_KINETIS_FS_HOST tomorrow, though my target is K66. I do have FRDM-K64 board which has the FS host broken out.
I have a Beagle USB12 analyzer, so if the _EHCI will negotiate down, I and connect.
I'm interested in the CDC_ACM mode to communicate with north bound modems ... particles Electron, photon, cell modems, 900Mhz, wifi etc and my project is an open source project. :)

So if you publish your code, and I can make it work, possibly knit in to your other code ... I could publish how I did it ... ... whatever you think ....

Full/low speed code isn't going to be much help I'm afraid. The SIE for it is totally different, the high speed silicon is EHCI.
IMHO Freescale REALLY messed up by using EHCI, because it is overly complex and designed pretty horribly, but then what else can be expected from Intel.
I'm sure that Freescale has to pay some sort of royalty too.
I've not found much in the hardware department that Intel has ever got totally right, and they always expect one to throw too much CPU at the goal, or totally lacking in features.
The only thing that Freescale did manage to get correct is having basically what amounts to a transaction translator built in. This does help a lot because then you don't have to write a second driver for OHCI.

If you think that is bad, on PC's for super speed, XHCI adds *another* driver on top of that! Totally dumb :)
All you really should need is something basic on the front-end, such as a hub or built in TT on the front end to take care of all the other fluff in hardware....
... BUT NOOOoooOOOooo.... Always the hard way.

The short of it is that it is a huge crap sandwich, and we all get to take a bite.

Anyway, let me know if you want to collaborate in real time on Google hangouts. You can locate me via github pretty easily for this.
 
IMHO Freescale REALLY messed up by using EHCI, because it is overly complex and designed pretty horribly, but then what else can be expected from Intel.
In return, if done right, (host) drivers for ?HCI are portable, assuming you have enough resources to run them in the first place. That is a big plus in the cost efficiency department, because you don't have to reinvent the wheel each time you move to a different SoC (family). For spare time projects this cost efficiency is less of an issue, in return messing with USB is a pain in the rear end, regardless. Seems to be the case for the HW engineers as well, because more often than not you will find something USB related in the chip errata :D
 
In return, if done right, (host) drivers for ?HCI are portable, assuming you have enough resources to run them in the first place. That is a big plus in the cost efficiency department, because you don't have to reinvent the wheel each time you move to a different SoC (family). For spare time projects this cost efficiency is less of an issue, in return messing with USB is a pain in the rear end, regardless. Seems to be the case for the HW engineers as well, because more often than not you will find something USB related in the chip errata :D

True for a __PC__. SoC? well, these chips are pretty close, yes, but I think of them more as MCU. SoC would be what is in a smartphone/tablet.
Anyway, I feel that Freescale should have just kept it simple and used the same SEI, added a couple registers for the super-speed stuff, and plopped a TT on it.
That way any changes would have been minimal.

Come to think of it, I have not seen an SEI that I could totally like yet, but the MAX3421E comes close, because it takes care of all the difficult details.
Unfortunately MAX3421E is SPI bus and full/low speed only though.

What my experience has always been is that most silicon designers do not consider the programmer at all. There are many cases where "WTF were they thinking" has been uttered by myself, and many others. Yes, I know it isn't exactly easy to design silicon either, however if you really think about it and consider a USB hub, you don't have to tell it how to send the packets, or at what speed. The TT's in the silicon do this for you. I don't see why you can't just spit packets out using DMA like the Kinetis SEI does. -- Note that the Kinetis SEI does some strange things too, and even it requires throttling, but it is no where near as stupidly set up as [UEX]HCI. This is dumb, and the MAX3421E proves these things have been solved in silicon, and any erratta isn't a show-stopper. EHCI is too RAM hungry as well. I would have been much happier with something designed with some built-in intelligence.

In any case, I believe EHCI is overkill on an MCU, but we're stuck with it.
Further discussion on the design choice Freescale made is moot. We have to just make it work, and I have dealt with worse designs. :cool:
 
Yes, I can do that, if you are willing to test it. Please note that currently only the low/full speed connector is supported. The upcoming board support for high-speed is in progress.

Please note that some devices do not follow the specification properly.
Most notable offender I have is an Arturia keyboard. It will drop keypresses during a mashup, and confuse the code. Breifly: it is supposed to buffer these, and it does not!

The AKAI and Yamaha keyboards I have _DO_ follow the spec.

Your success/failures will depend upon the device properly following the specification.

Keep watching the repository. I should be able to have something in about 2 weeks, after the dust settles here with work and whatnot.


Hi xxxajk,

I know you have been busy lately, but I have gotten my hardware to work properly! (I think). I have a board that has the ID pin implemented, with the schematic I had posted previously. I can connect various USB devices and not lose power on my teensy, and power them when I have the power circuit enabled.

You had mentioned that you would have something posted on Github for USB MIDI, but I diddnt see any commits that seemed relevant.

If you have some more breadcrumbs I can follow, I will follow them :D

Once I get this all to work, as I said I would be happy to do a write up and share it back to the community.

Thanks!
T
 
Yeah, been super busy. Right now I'm working on something, but I hope to have the rest of the evening free after this task is done.
 
I just wanted to take a moment and thank xxxajk for his work on this library.

I've been using USB_Host_Shield_2.0 for some time now on an Arduino Mega (to interface with a PS3 controller via bluetooth), and recently started to look at Teensy as an alternative (enhancement).

Looking forward to seeing future progress.
 
I just wanted to take a moment and thank xxxajk for his work on this library.

I've been using USB_Host_Shield_2.0 for some time now on an Arduino Mega (to interface with a PS3 controller via bluetooth), and recently started to look at Teensy as an alternative (enhancement).

Looking forward to seeing future progress.
UHS3 will be SO much better.
Currently the following are considered VERY stable:
  • Hub... not much here to break.
  • The mass storage driver and file system class that derives from it has been floating someplace in the ocean for something like a year or so, logging some kind of measurements. Have not heard of anything going wrong. No news is good news, I guess.
  • Not many people fully testing/using the serial drivers yet, but in my own tests they are stable. A recent quirk fix allows more FTDI devices to work too.

MIDI work is planned for tonight. Shouldn't be too hard as I have some code that someone kind-of started and failed, but it gives to me the overall picture of what the community wants for the API.
This kind of input is very important at this time. The API is not fully set in stone, and you do not have to follow the 2.0 behavior. If you wanted to do something in 2.0, and it was a real pain to do it, now you have the opportunity to voice that.
 
Getting going with UHS30 build

Well I got some help in being able to compile and download UHS30. Thankyou thankyou Andrew @xxxajk for your time. This took about 4 afternoons this week, to knit it all together.

What the following procedure does: Builds xxxajk UHS30 project, using a forked library, and facilitates downloading to Teensy36 (UsbHost HS is a k66 peripheral).

At this point UHS30 still looks like its in development - so this is for developers wanting to get into the nitty gritty.

xxxajk UHS30 project is built on linux for flexibility with links. The build uses a custom make and the Netbeans IDE. The make integrates with the Netbeans IDE, but the IDE may just be gravy ontop of the make, so this is the route I took. If you haven't got a linux machine - this isn't going to work for you. Windows10/bash beta is in the wings - but this assumes some linux standard make/arm-none-eabi-xx
My workstation environment - two screens - is a windows10, but I have an older machine that is repurposed as Ubuntu 16.04LTS - and for make environments it is soooo much more effective than Windows.

When adding new tools, I often seem to try different scenarios, until something works. The problem is then I don't have a clear view of the needed steps. So these are the following steps that I think will get you there - any mistakes are mine. Guru Andrew!!!! helped me in setting up the project, and had the depth of knowledge of linux which was sooo fantastic - I couldn't have got there with out that. Please post if you had to do anything different or see any assumptions I've missed on..

There are a number of sections to this - skip as appropriate - I started from the beginning as I haven't used Arduino for some time
a) Install Arduino on linux (Ubuntu 16.04LTS in my case)
b) Install Netbeans & configure for arduino arm
c) Setup UHS30
d) Build UHS30 and download to Teensy36
e) Teensy36 debugging

The Netbeans install for some reason really thrashed my disk and got stuck installing. Thanks for this tip from Andrew I added
noatime to /etc/fstab mount points ( info: wiki.archlinux.org fstab )
eg
/media/disk2 ext4 defaults, noatime 0 2

Also verify disk space before installing netbeans (211MB)
 
Last edited:
Install Arduino on linux/Ubuntu

somewhat of a repeat on pjrc.com/teensy/td_download must match installed arduino version
ubuntuhandbook.org/index.php/2015/11/install-arduino-ide-1-6-6-ubuntu

1) Download and extract Arduino
arduino.cc/en/Main/Software download linux installer (64bit for me)

cd ~/Downloads
#extract arduino-1.6.12 e
tar -xvf arduino-1.6.12-*.tar.xz
sudo mv arduino-1.6.12 /opt
cd /opt
# Create a link, future /opt/arduino-xxx upgrades result in only the link changing.
sudo ln -s arduino-1.6.12 Arduino #sudo as protected directory
ls -all
cd Arduino
sudo chmod +x install.sh
./install.sh # puts a short cut on the desktop

2) Install Linux udev rules
#Step into https://www.pjrc.com/teensy/49-teensy.rules - and highlight rules
#then paste in rules, or any other method your prefer to create /etc/udev/rules.d/49-teensy.rules
$sudo nano /etc/udev/rules.d/49-teensy.rules
exit and save nano
$ more /udev/rules.d/49-teensy.rules

3) Run Teensyduino
Teensyduino must be compatible/match the installed arduino version which currently is Arduino 1.6.12 - the Teensyduino does do the checking to ensure there is a compatible version - very nice.
The Teensyduino 1.31 Beta is needed for Arduino 1.6.12 and referenced here
pjrc.com/teensy/td_download.html
and as of 2016Oct7th download it here
forum.pjrc.com/threads/37204-Teensyduino-1-31-Beta-1-Available
# Monitor where it goes, most likely ~/Downloads
cd ~/Downloads
chmod +x TeensyduinoInstall.linux64
./TeensyduinoInstall.linux64 # don't use sudo as it will go in as onwer root

# At some point I also added to dial out
sudo usermod -aG dialout <loginname>

Connect the Teensy36/35 microUSB to Ubuntu USB Host A
To start double click on "Arduino IDE" then set Tools->Board : "Teensy 3.6"

I verified by doing a modified blinky, and saving it in my library which came out here
~/Arduino/Blinky161005/Blinky161005.ino
and downloading to Teensy36 and verify its working .
 
Last edited:
Download & Setup UHS30

This section assumes you want to operate on a fork of UHS30 - you can make adjustments as needed below.
The UHS30 project requires Andrew's Arduino_Make - I put it with my other git
cd ~/git
git clone git@github.com:felis/xxxajk_Arduino_Make.git
cd ~/Arduino
ln -s ~/git/xxxajk_Arduino_Make Arduino_Make

Login to github.com
Go to https://github.com/felis/UHS30 and fork the project into your account

Now setup directories/links as
ArduinoNetbeansLinks.png
mkdir ~/NetBeansProject

cd ~/NetBeansProject
mkdir UHS_30_MASTER
cd UHS_30_MASTER
git clone git@github.com:felis/UHS30.git
cd UHS30
# init the submodules RTClib
git submodule update --init --recursive

#now do the same for the fork
mkdir UHS_30_FORK
cd UHS_30_FORK
git clone git@github.com:<yourAcc>/UHS30.git

cd UHS30
git submodule update --init --recursive

#Choose one module to use for the netbeans and thereby also Arduino IDE as well
ln -s ~/NetBeansProjects/UHS_30_FORK/UHS30 UHS30

cd ~/Arduino/libraries
ln -s ~/NetBeansProjects/UHS30/libraries/UHS_host UHS_host
ln -s ~/NetBeansProjects/UHS30/libraries/dyn_SWI dyn_SWI
ln -s ~/NetBeansProjects/UHS30/libraries/UHS_FS UHS_FS
ln -s ~/NetBeansProjects/UHS30/libraries/RTClib RTClib
 
Last edited:
Status
Not open for further replies.
Back
Top