Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USB device stack #3890

Closed
wants to merge 15 commits into from
Closed

USB device stack #3890

wants to merge 15 commits into from

Conversation

jfischer-no
Copy link
Contributor

USB Device stack implementation for RIOT.

Description:
It's all still WIP but it works. As it says in the title, it is a USB Device stack. It means that a RIOT board with this stack can communicate with the USB host.

For now, only the Kinetis Driver (8bef8ab) exists. It would be great if someone would add a different platform. Possibly the interface between driver and stack needs to be expanded.

Hardware Driver and Stack use few macros and need only few changes in Makefile. The Driver uses a "driver_init" macro to register at the stack, similar to module_init in Linux. It (dc8a7c9) still needs a little fine-tuning. And I hope you find it useful (I do not like the RIOTs autostart).

To be continued....

Supported and boards (SoCs):

  • Freescale Kinetis (tested with kw22d512 and k64f)
  • Boards pba-d-01 and frdm-k64f

How to test:

  • pba-d-01 : The board needs to be slightly modified, a bridge and a capacitor. Instructions follow. The board should be populated with the kw22d512
  • frdm-k64f should work without problems

Under test/usbdev (8db566c) is the appropriate Makefile. For testing you can either do
./dist/tools/pyterm/pyterm --port /dev/ttyACM1

Depends on #4114, #4163 and serves as an example for #4155

@jfischer-no jfischer-no added Platform: ARM Platform: This PR/issue effects ARM-based platforms State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: new feature The issue requests / The PR implemements a new feature for RIOT Area: drivers Area: Device drivers labels Sep 17, 2015
@jfischer-no jfischer-no self-assigned this Sep 17, 2015
@OlegHahm OlegHahm added this to the Release NEXT MAJOR milestone Sep 17, 2015
@OlegHahm
Copy link
Member

More good news today! Thanks!

@jfischer-no jfischer-no mentioned this pull request Sep 17, 2015
6 tasks
@jfischer-no jfischer-no added the Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR label Sep 23, 2015
@ks156
Copy link
Member

ks156 commented Oct 3, 2015

@jfischer-phytec-iot, nice to see your PR. Currently, a USB stack is a big lacks in RIOT imho.
I'm currently writing the support for NXP LPC11U34, a USB CortexM0 MCU. A usb stack would really be appreciable.
Once I've finished the implementations of the peripherals for this MCU, I'll try to implement your USB stack and see how it works.

@jnohlgard
Copy link
Member

@jfischer-phytec-iot

I do not like the RIOTs autostart

Could you elaborate on this? Perhaps it is possible to improve the autostart system?

@jfischer-no
Copy link
Contributor Author

@ks156 Well, when the time comes, I'll help you gladly.

@gebart I will separate the commit dc8a7c9 and explain my concept, it is similar to that in the Linux kernel.

@jfischer-no jfischer-no added the State: waiting for other PR State: The PR requires another PR to be merged first label Oct 27, 2015
@jfischer-no
Copy link
Contributor Author

Depends on #4163 and serves as an example for #4155

@jfischer-no
Copy link
Contributor Author

If someone wants to test it with the PhyNode Boards version 1426.0 or 1426.1, the following modifications must be performed:

  • two 0402 resistors (20Ohm ... 30Ohm) must be populated
  • 100 nF capacitor between pins PTE 18 (D14) and GND
  • connect PTE19 (D15) with VCC3V3

New 1426.2 Boards do not need this modifications.

The PhyWave module should be populated with MKW22D.
I have now tested it with gnrc_border_route example and it works mostly very good (a2a9440).
Over second USB connector (besides Phytec logo) runs the communication with the border router.

pl1426 0-usb-mod

@jfischer-no
Copy link
Contributor Author

I got usb working on samr21-xpro, this PR will be rebased and updated in the next days.

@kaspar030
Copy link
Contributor

nice! very looking forward...

@PeterKietzmann
Copy link
Member

This PR is WIP and I assume we won't make it until the release. Removing the Milstone now. Feel free to reset I was wrong in my assumption.

@PeterKietzmann PeterKietzmann modified the milestones: Release 2016.07, Release 2016.04 Mar 23, 2016
@kYc0o
Copy link
Contributor

kYc0o commented Jul 25, 2016

WIP -> postponed. And please rebase if possible.

@kYc0o kYc0o modified the milestones: Release 2016.10, Release 2016.07 Jul 25, 2016
@miri64
Copy link
Member

miri64 commented Oct 31, 2016

Postponed due to feature freeze.

@miri64 miri64 modified the milestones: Release 2017.01, Release 2016.10 Oct 31, 2016
@OlegHahm OlegHahm removed this from the Release 2017.01 milestone Jan 15, 2017
@OlegHahm
Copy link
Member

Let's remove the milestone until someone has time to pick it up again.

@antmerlino
Copy link
Contributor

@OlegHahm What is the status of this? How close was it to being done? Is anyone familiar with what has been completed already and could walk me through some of it?

I can't make any promises but depending on the level of work, I'd be interested in helping finish it. I would like to get a shell working over USB CDC ultimately.

@jfischer-no jfischer-no deleted the wip@usbdev branch January 23, 2017 09:17
@jfischer-no
Copy link
Contributor Author

Total outdated, update will come

@aabadie
Copy link
Contributor

aabadie commented Oct 8, 2017

@jfischer-phytec-iot, this PR is very interesting for some SAMD21 based boards (Arduino MKR, Adafruit Feather). In this comment above, you said that you could make it work on Samr21-xpro which kind of samd21 based. Is there any chance that you update your branch soon or give some notes on how you achieved this ? (We might consider reopening this PR I think)

@jfischer-no
Copy link
Contributor Author

@aabadie yes, I have tested it with samr21 board. I have to look again and squash so that it looks reasonable. Would you like to work on the usb device stack? I will unfortunately not have much time to help and I do not want that only the samr/d driver will be maintained, as it indicates in your message.

@dylad
Copy link
Member

dylad commented Oct 13, 2017

@jfischer-phytec-iot Your work is really interesting ! It would be great if you can reopen or share your branch. I'd would love to help RIOT to have a full USB support someday :)

@aabadie
Copy link
Contributor

aabadie commented Oct 14, 2017

@dylad, if you are interested in working on this, you can fetch the branch reference by the PR:

git fetch upstream pull/3890/head:wip@usbdev
git checkout wip@usbdev

@dylad
Copy link
Member

dylad commented Oct 15, 2017

Thanks for the tip @aabadie !

@jfischer-no
Copy link
Contributor Author

@dylad This PR can not be reopen, please pick wip@usbdev branch from my repository

@maribu
Copy link
Member

maribu commented Jun 4, 2020

This PR is still referred in the mulle board documentation. Is that reference still up to date?

@maribu
Copy link
Member

maribu commented May 1, 2024

This PR is still referred in the mulle board documentation. Is that reference still up to date?

Let's try to summon @bergzand, he might know.

@dylad
Copy link
Member

dylad commented May 6, 2024

This PR is no longer relevant regarding USB support for RIOT. I think it was added there as a "TODO" to add USB support later. I think you can remove it.
Sadly there is no periph_usbdev AFAIK for kinetis. But maybe tinyUSB could be use instead ?

@bergzand
Copy link
Member

bergzand commented May 6, 2024

Let's try to summon @bergzand, he might know.

I don't think this PR was on my radar while working on the USB stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR Platform: ARM Platform: This PR/issue effects ARM-based platforms State: waiting for other PR State: The PR requires another PR to be merged first State: WIP State: The PR is still work-in-progress and its code is not in its final presentable form yet Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.