Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 6 of 6

Thread: Teensy 3.6 bare USB code

  1. #1
    Junior Member
    Join Date
    Jun 2015
    Posts
    9

    Teensy 3.6 bare USB code

    Hi all.

    Does anyone know if there's a bare metal version of the USB code kcuzner created for the Teensy 3.2? I want USB support for the Teensy 3.6 so I can start adding various
    endpoints. I've been looking at the Paul's core code and it's too complex to figure out what I need as a bare minimum (still looking at it).

    Thanks

  2. #2
    Moderator Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    4,346
    Arduino is bare metal... ;-)

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,711
    Quote Originally Posted by Icarus View Post
    Does anyone know if there's a bare metal version of the USB code kcuzner created for the Teensy 3.2?
    This is his code, right? Looks about as bare metal as you can get.

    https://github.com/kcuzner/teensy-os...ensy/src/usb.c

    I've been looking at the Paul's core code and it's too complex to figure out what I need as a bare minimum (still looking at it).
    The basic idea is the USB hardware responds to the tokens from the USB host by read/writing your buffers. You have give to the hardware your buffers in advance, via the BDT table. Then it gives you interrupts to tell you when it's used the buffers, and you have to give the hardware more buffers, and of course actually do something with ones it has finished using.

    If you're used to thinking of code as a reactionary model, where the hardware gives you an interrupt and then your code does the work of moving data, perhaps this model of setting up buffers in advance can seem complex. But this is the way modern high performance DMA-based peripherals work.

    Perhaps a bare minimum would use just two buffers per endpoint. Or maybe even just 1 buffer. The BDT is set up for ping-pong with 2 pointers, so 2 buffers might be simpler than 1.

    But the key to good USB performance is always having a buffer ready to receive data when the host sends the OUT token, or having a buffer filled with data ready to go when the host sends the IN token. USB host controllers tend to be quite bursty in their access, where (with bulk & control) you tend to be rewarded immediately with another IN or OUT token if you were ready for the last one, and then as soon as you don't have a buffer ready the hardware replies with a NAK token. The host controller usually moves on to other devices or enters a brief idle pause, so you *really* hurt performance if you're ever not ready. The host controller also spends a chunk of each frame servicing isochronous & interrupt endpoints. If your application is generating or consuming data quickly, the key to performance involves buffering up enough during those quiet times so you can always have buffers ready to go in the BDT slots during those times of rapid IN-ACK / OUT-ACK sequences.

    My USB code has quite a lot of work invested in achieving those performance goals. Maybe you'll manage something just as good with whatever "bare minimum" ends up looking like, but I'd put the odds performance will likely suffer.

  4. #4
    Junior Member
    Join Date
    Jun 2015
    Posts
    9
    Thanks Paul

    Really sorry for the mistake. I meant

    "Does anyone know if there's a bare metal version of the USB code kcuzner created for the Teensy 3.6?" not 3.6

    I'm looking at kcuzner's USB code now and thinking if it will be easy to port over to the Teensy 3.6. I guess the main work is dealing with the linker script.

    I'm not too bothered about performance. I just want to have some code small enough to study so I can play around on the Teensy 3.6.

    Regards!!

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    15,711
    The main issue is configuring the MPU to allow the USB DMA to access RAM.

    While not technically about the USB, Teensy 3.6 also has a different PLL, so you'll need to adapt the startup code. 180 MHz isn't an integer multiple of 24 MHz, so you'll also need to configure the USB to use the 48 MHz internal clock. Or just run at 168 MHz if you want to configure the USB clock the normal way.

    To use all of Teensy 3.6's much larger memory, you'll need the linker script. But if you use the one for Teensy 3.2, things should still work fine, just using only a subset of the memory.

  6. #6
    Junior Member
    Join Date
    Jun 2015
    Posts
    9
    Thanks for the help!

    I've managed to bring the code kcuzner created into for the Teensy 3.6 and created the various custom endpoints that I need for my project :-D.

    Regards

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •