obdev / v-usb Goto Github PK

Is anyone interested in adding a reference support for Microsoft OS Descriptors (https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors) with the Compatible ID for WinUSB?
I am adding that for my own device and may contribute it as a PR if there anyone else is interested.

I have an existing project written in 100% AVR assembly that I would like to extend it to include a basic USB hid joypad device. Is it possible and if so are there examples for implementing V-USB in a non C application?

From b7cf38b05b5e69b94d916b977b31786922a3cd1c Mon Sep 17 00:00:00 2001
From: Stephan Baerwolf [email protected]
Date: Wed, 17 Jul 2013 00:46:17 +0200
Subject: [PATCH] bugfix: usbFunctionDescriptor() may address flash

In case "USB_CFG_DESCR_PROPS_UNKNOWN" is configured to be
"USB_PROP_IS_DYNAMIC", then "usbFunctionDescriptor()" is called
with initial value of "flags" ("USB_FLG_MSGPTR_IS_ROM").
Since "usbMsgFlags" always is set to "flags" after
"usbFunctionDescriptor" returns, the dynamic RAM address
within "usbMsgPtr" may be interpreted as flash pointer!
The result is inconsitent data to be transmitted to the host!

This patch workarounds this issue by removing flag
"USB_FLG_MSGPTR_IS_ROM" in this special condition.
As a result addresses always will be interpreted as RAM ones.

Signed-off-by: Stephan Baerwolf [email protected]

usbdrv/usbdrv.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/usbdrv/usbdrv.c b/usbdrv/usbdrv.c
index d838935..23fccb7 100644
--- a/usbdrv/usbdrv.c
+++ b/usbdrv/usbdrv.c
@@ -345,6 +345,7 @@ uchar flags = USB_FLG_MSGPTR_IS_ROM;
#endif
SWITCH_DEFAULT
if(USB_CFG_DESCR_PROPS_UNKNOWN & USB_PROP_IS_DYNAMIC){

•        flags = 0;
       len = usbFunctionDescriptor(rq);
   }
  

  SWITCH_END

  1.8.1.5

Hello,
Exists some plans to v-usb works with avrxmega3 architecture, ex: attiny1614
Thank you

I propose to switch from "GPLv2-only, GPLv3-only, Proprietary" to "GPLv2+, Proprietary" licensing model.
I understand your potential concerns with uncertainty of such an approach.
However, despite already being possible, it simplifies integration with projects which are under GPLv2+
It might seem unnecessary due to a lack of such projects using V-USB, but it is only because V-USB does not allow for that yet.

An example scenario showing why it is needed:

• GPL v4.0 (v3.5) is released
• V-USB project updates to support GPLv4 with ease due to the centralized copyright maintained for the Proprietary licensing option.
• Projects utilizing V-USB are struggling, or just not bothering with the change, as it involves getting permission from every contributor, making them stuck with the outdated GPL options, making it impossible to make use of this code in opensource projects under the new GPL.
• Project borrowing code from the above projects are also subject to the above, as they cannot be licensed under GPLv2+.

This change would open up V-USB code to the vast number of projects using GPLv2+ and GPLv3+ licenses.
(Sorry for multiple edits - posted this before I finished typing)

WinUSB and WebUSB requests are likely to be static and thus stored in PROGMEM, but usbFunctionSetup() has no built-in facility for handling responses stored in flash. While it's reasonably straightforward to implement usbFunctionRead() to return data out of flash, it seems like the sort of thing that many developers will eventually write themselves, and everyone's will be approximately the same.

Feature request: make it possible for usbFunctionSetup() to return with usbMsgPtr set to a PROGMEM address, and a global flag somewhere can indicate that it's a flash address, and then usbdrv.c can handle the rest.

I'm currently writing firmware for a device which for full functionality would need more in-endpoints. Is it feasible with reasonable work to add this functionality?

To ask differently: is there a reason there are hardcoded functions for the two possible in-endpoints but usbFunctionWriteOut works for any number of endpoints?

Several messages like these appeared during compilation:
error: variable ‘usbDescriptorStringVendor’ must be const in order to be put into read-only section by means of ‘attribute((progmem))’
PROGMEM int usbDescriptorStringVendor[] = {

By adding 'const' to the definitions in usbdrv.h and usbdrv.c, the compilation completes normally, as shown below:
PROGMEM const int usbDescriptorStringVendor[] = {

Building on Linux (x86-64) fails. It looks like srandomdev() doesn't exist on Linux?

make[2]: Entering directory '/home/mark/Work/v-usb/examples/drivertest/commandline'
gcc  `libusb-config --cflags` -O -g -Wall -c opendevice.c
gcc  `libusb-config --cflags` -O -g -Wall -c runtest.c
runtest.c: In function ‘main’:
runtest.c:114:9: warning: implicit declaration of function ‘srandomdev’ [-Wimplicit-function-declaration]
         srandomdev();
         ^~~~~~~~~~
gcc -o runtest opendevice.o runtest.o `libusb-config --libs`
runtest.o: In function `main':
/home/mark/Work/v-usb/examples/drivertest/commandline/runtest.c:114: undefined reference to `srandomdev'
collect2: error: ld returned 1 exit status
Makefile:41: recipe for target 'runtest' failed
make[2]: *** [runtest] Error 1
make[2]: Leaving directory '/home/mark/Work/v-usb/examples/drivertest/commandline'
make[1]: Leaving directory '/home/mark/Work/v-usb'

In usbtool, it would be useful to have the ability to instead of specifying the USB device by VID/PID, be able to give a path like /dev/bus/usb/005/004 (for example).

That could allow usbtool to be used with Cypress EZ-USB devices, where once you download "vend_ax.hex", they only respond to a small number of USB requests. It's not possible to query manufacturer strings etc. from the device in that state, hence usbtool can't be used with it. At least, I think that's why I couldn't get it to work...

I built a video game controller adapter that uses USB for firmware updates (micronucleus bootloader) and converts Super Nintendo controllers to 3DO.

I thought it would be really cool if the adapter also could act as a USB joypad when the main application is active. My hardware has two Super Nintendo Controller inputs, so I was curious about how I could implement multiple HID devices simultaneously.

Is this even possible and does a USB hub code example exist?

Hello,
In my opinion wrong uC is used in with-vreg.sch schematic example, because as far as I know Atmega8-16P cannot be supplied from 3,3V. On the other hand Atmega8L-16P can be supplied from 3,3V but it's rated up to 8Mhz or maybe I'm missing something.

Hello dear,
I build small project that combine irmp and v-usb together.
My project based on http://www.recursion.jp/prose/avrcdc/ and use latest v-usb drivers.

The point is int that when I run timer for irmp (15KHz) after a while of time I cannot send data to host by setting usbSetInterrupt(). uC is not freeze, I can still send data to it and for eg usbFunctionWriteOut() is called, but my data are not printed out anymore into terminal software(I use gtkterm or minicom under Linux).

What I notice when I restart just terminal software, communication back for a while and I got the last message that was buffered when usbSetInterrupt() was called.

In the attachment I put my complete code.
The uart part can be even omitted, as I check the issue is related just to timer and its isr + usbSetInterrupt()

Maybe there is some way to flush the data or get back synchronization with host?
Best Regards,

avr.tar.gz

https://github.com/obdev/v-usb/blob/master/circuits/Readme.txt

Most examples have a 1M pull-down resistor at D+. This pull-up ensures that
in self-powered

AND, I only seen pull-up res in D- in schs provided in that folder...

I have a specific USB hub that refuses to detect any device using the V-usb example code. The device doesn't show up in Windows Device Manager or Linux lsusb. I have narrowed it down to the following lines of code in main.c:

usbDeviceDisconnect();  /* enforce re-enumeration, do this while interrupts are disabled! */
i = 0;
while(--i){             /* fake USB disconnect for > 250 ms */
    wdt_reset();
    _delay_ms(1);
}

If I remove that piece of code, the problem goes away. The problem also goes away if I use a different hub, or if I connect directly to the computer without a hub, or if I first plug the device into the hub and then connect the hub to the computer.

My theory is that this "disconnection" is not actually happening. So when the hub detects the device insertion, and asks it for identification, it gets no response because the device is still within this arbitrary delay period. And so it gives up.

So I guess my questions are:

1. What purpose does this "enforce re-enumeration" process serve? What problem is it intended to solve?
2. Why might it be causing the device to fail to enumerate? Why does it fail to perform as intended?
3. Am I okay to just remove the offending piece of code? Or can I change it in some way to work better?

The device I'm flashing is an ATmega88, which happens to be on a USBasp clone board (because it was convenient). The schematic is:

Good afternoon, there is a need to use v-usb when booting into bios, but it stubbornly refuses to work in bios (in windows everything works).
How can I get v-usb to work in bios?

Dear obdev team,

first of all, thank you very much for sharing the PIDs/VID with the community!
(overflo gave me the hint :-)).

I've a question regarding a composite device:

Out device (FLipMouse -> available here, v2 and here, v3 (not completed) ) uses a composite device with mouse,keyboard,joystick and CDC-ACM.

What PID do you recommend for this kind of device?

I can't connect to http://obdev.at/ so i can't get any further information.

I'm trying to get the custom-class example code's computer-side program to compile on openSUSE 13.2, but I'm getting errors that usb.h cannot be found. Merely changing usb.h to libusb.h to match what's provided by openSUSE's libusb-1_0-devel package results in errors like "unknown type name ‘usb_dev_handle’".

On the libusb website, I found this quote: "libusb-0.1 is the original version which is deprecated and unmaintained since many years". Thus I expect that Linux distributions that haven't yet dropped libusb-0.1 development support will do so in near future releases.

As an alternative to directly upgrading to libusb-1.0, the libusb project has released a compatibility layer that can be used with libusb-0.1 projects to make them work with libusb-1.0. I think it might be possible to include this directly in the V-USB project, helping users of newer Linux distributions use V-USB without a bunch of workarounds to use a development version of an outdated version of some library.

Hello,
Is possible to support the AVR-DB Family ex: AVR128DB28
Thank you.

Hi there,

I published a CCID class application driver recently on top of TinyUSB.
Now it appears people have to configure "pcscd" on Linux with USB IDs
to correctly assign the driver. On Windows this was a simple no-brainer.
The repo is here: https://github.com/ckahlo/seccid.

Is there any USB CCID class assigned yet, or could there be a new PID
assigned for the USB CCID class?

Best regards,
Christian

Not really an issue but something to simplify work with Microchip Studio (formerly known as Atmel Studio):
You can copy the attached file to the ProjectTemplate folder of Microchip Studio (usually located in %USERPROIFILE%\Documents\Atmel Studio\7.0\Templates):

v-usb.zip

When creating a new project, you can now select V-USB.
The template is based on commit 7a28fdc, I modified Readme.txt to reflect the file structure a bit more and added some information regarding F_CPU settings.

I hope it is in the sense of the community to post this here.
If you (obdev) want to publish this, feel free to do so. From my side it's all yours! :)
If you want to give credit, feel free to link either my GitHub profile.

Cheers
Chris