search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.61k stars 6.5k forks source link

Create a WebUSB subsys driver #12527

Open larsgk opened 5 years ago

larsgk commented 5 years ago

WebUSB enabled devices are able to communicate directly with web applications with browsers implementing the spec. Currently, there is a sample app (slightly outdated and static features) under /samples/subsys/usb/webusb

It would make sense to create a real subsys WebUSB 'driver' that can easily be included in projects that need WebUSB support. Often these will also have the need for other classes in parallel (resulting in a composite USB device description).

As a starting point, we can use the sample mentioned above with the following changes:

Also, it would be a good idea to involve Reilly Grant ( @reillyeon ) and Kenneth Christiansen ( @kenchris ) in the process.

larsgk commented 5 years ago

/cc @carlescufi

markus-becker-tridonic-com commented 4 years ago

I would really like to use WebUSB, possibly in combination with ACM and/or ECM. Would this use-case be possible with the current WebUSB sample or does the use-case require this issue to be tackled? Seems no-one is working on this currently, or?

larsgk commented 4 years ago

The sample also has some handshake issues on windows (it seems). I ran a workshop using the nRF52 Dongle and the Web USB stuff worked fine on Android, Linux and OSX - but not Windows even though it had the BOS and more in place that should make it PnP (I did a similar solution a few years ago using ARM Mbed, which works on all OSes -> https://github.com/empirikit )

markus-becker-tridonic-com commented 4 years ago

Ideally, I would like to have WebUSB combined with the shell: https://github.com/zephyrproject-rtos/zephyr/issues/20409, so that you would have the Zephyr shell available in a browser.

jfischer-no commented 4 years ago

WebUSB enabled devices are able to communicate directly with web applications with browsers implementing the spec. Currently, there is a sample app (slightly outdated and static features) under /samples/subsys/usb/webusb

It would make sense to create a real subsys WebUSB 'driver' that can easily be included in projects that need WebUSB support. Often these will also have the need for other classes in parallel (resulting in a composite USB device description).

No, I do not think there should be a "WebUSB 'driver'" and not in the subsys. Nothing prevents you to use other classes in your WebUSB application.

As a starting point, we can use the sample mentioned above with the following changes:

* [ ]   Functionality to change manufacturer and product string

What does it have to do with the sample? You can change PID and VID.

* [ ]  Functionality to change serial runtime, e.g. to assign unique IDs from hardware

Per default Serial Number will be obtained via HWINFO subsystem. Application can/should not change it after enumeration.

* [ ]  The possibility to merge with other interfaces (e.g. CDC & WebUSB)

We have support for composite configuration. Probably WebUSB sample needs some rework to show this.

* [ ]  License fix -> Apache2 (check with Intel?)

Where is this license issue? SPDX-License-Identifier: Apache-2.0

larsgk commented 4 years ago

@jfischer-phytec-iot - It's been a year since the issue was created. Some comments below:

WebUSB enabled devices are able to communicate directly with web applications with browsers implementing the spec. Currently, there is a sample app (slightly outdated and static features) under /samples/subsys/usb/webusb It would make sense to create a real subsys WebUSB 'driver' that can easily be included in projects that need WebUSB support. Often these will also have the need for other classes in parallel (resulting in a composite USB device description).

No, I do not think there should be a "WebUSB 'driver'" and not in the subsys. Nothing prevents you to use other classes in your WebUSB application.

I think it makes sense to at least have a common place for cross host OS compliance (Windows being the most difficult to get true PnP working) handshaking. That is the biggest pain when developing USB firmware for true PnP devices that are not part of the standard classes (HID, CDC, ...)

As a starting point, we can use the sample mentioned above with the following changes:

* [ ]   Functionality to change manufacturer and product string

What does it have to do with the sample? You can change PID and VID.

The strings are what appear to the OS in true PnP (not talking crippled windows *.inf files here ;)). At least a year ago, those were hard coded deep in the source.

* [ ]  Functionality to change serial runtime, e.g. to assign unique IDs from hardware

Per default Serial Number will be obtained via HWINFO subsystem. Application can/should not change it after enumeration.

Not changing after enumeration but being able to dynamically set based on e.g. chip ID before handshake.

* [ ]  The possibility to merge with other interfaces (e.g. CDC & WebUSB)

We have support for composite configuration. Probably WebUSB sample needs some rework to show this.

* [ ]  License fix -> Apache2 (check with Intel?)

Where is this license issue? SPDX-License-Identifier: Apache-2.0

AFAIK, A year ago it had some original Intel license on it (doesn't matter now)