Recent Posts

Pages: 1 ... 8 9 [10]
USB / Re: USB VCOM host
« Last post by ADB on October 11, 2019, 02:55:29 am »
Hi Jan,

On an evaluation board of my microcontroller, I've pulled the ID pin low. My slave device for the time being is self powered. If I boot my host microcontroller first, followed by my slave board, an interrupt triggers on my host microcontroller indicating a state change, but my host remains in an unattached state.

Any suggestions?

Thanks again,

USB / Re: USB VCOM host
« Last post by ADB on October 04, 2019, 05:34:30 am »
Hi Jan,

Thank you for getting back to me.

Looking through my microcontroller's user manual, I don't believe I can setup the USB as an async. serial port.

Does USB OTG work if both devices are slaves at the outset? My chip provider has an older USB library that the one that I'm currently using that has an example for a USB serial host (code is very different between the 2 libraries), but I don't think it is implementing OTG.

I'm thinking of changing the state of the ID pin to make my microcontroller the host, which will hopefully allow we to use the aforementionned USB serial host problem. If that works, I should be able to use my USB protocol analyser to log what happening. I could then write code to try and achieve the same thing with my chip vendor's more recent library code and then implement OTG, as my microcontroller allows needs to be able to communicate with a PC.

For testing purposes can a PC be the USB device slave?

Thanks again for your comments,


USB / Re: USB VCOM host
« Last post by Jan Axelson on October 03, 2019, 09:41:12 am »
If both devices have available async. serial ports, the easiest solution is to cross-connect those.

Othewise, yes, one device will need to function as a USB host. A device with OTG hardware can negotiate to function as the host. You will also need firmware support for the VCOM function in the host.

Many chip providers offer example firmware for various functions.
« Last post by ADB on October 02, 2019, 03:26:34 am »
Hello Jan,

I've successfully developped a USB VCOM slave program on my microcontroller and am able to communicate with it using a PC.

I would like to adapt this program so that I can communicate with a "USB-to-UART bridge controller" on another board, which I presume will be setup as a slave. What would I need to do to, to adapt my micrcontroller program to make it a USB VCOM host program? The ID pin is pulled high, so by default my microcontroller is the slave. My microcontroller has USB OTG.

Based on my reading, my host program will need to provide extra signalling packets (SOF, SETUP, IN/OUT packets) + schedule transfers.

I see that OTG has circuitry to provide HNP and SRP protocols. Can HNP work in my case with 2 slaves orginally? Or would it be better if my microcontroller was the host at the outset?

Do you have any code examples for any of the above?

Thanks in advance for your comments,


Serial Ports / Re: Synchronous RS422
« Last post by Jan Axelson on September 28, 2019, 12:51:07 pm »
As dduley said, the faster driver sampled the data sooner, causing the data to be sampled during the transition time in the grey area between a 0 and a 1, rather than when the logic level was stable.
Serial Ports / Re: Synchronous RS422
« Last post by BasilNic on September 27, 2019, 07:34:26 am »
What's the reason for faster chips to create more problems like that exactly?
USB / Re: Windows polls unused USB HID?
« Last post by Jan Axelson on September 24, 2019, 08:42:55 pm »
Yes, the Windows HID driver polls the interrupt IN input whether or not an application has opened a handle to the HID. The specs don't forbid or require doing so. The only downside is that it can use bandwidth unnecessarily. For system devices like keyboards of course, the host needs to poll continuously.
USB / Windows polls unused USB HID?
« Last post by Renate on September 24, 2019, 01:13:02 pm »
I have an ATMega32u4 as an HID.
It takes commands on an interrupt endpoint.
It provides a realtime status out on an interrupt endpoint with a bInterval of 16.
It works perfectly when connected to a Windows app or an Android app.
No complaints there.

To double check polling on the in endpoint (and how bInterval got rounded),
I added some test code to the ATMega to toggle a test point when the in endpoint got loaded.
I saw what I expected: bInterval=10, poll=8, bInterval=16, poll=16.

But... On the Android when the the Android app was not running there was no polling.
On the Windows when the Windows app was not running there was still polling going on.
I don't have a Linux app, but I connected it to a RPi and polling went on when I cat /dev/hidraw0 and goes off when I ^C.
Ok, this does not really have anything to do with the USB standard exactly.
It's more of a question of whether a host should leave USB devices alone if the user is not using them.

Has anybody seen this sort of stuff or have an explanation?
I guess that MS wants to keep HID input buffers full in case somebody might want to use it.
USB / Re: Anything better than HIDAPI today?
« Last post by Jan Axelson on September 10, 2019, 07:49:45 pm »
I think you're probably aware of my HID example code here:

I have links to other HID host code here:

You mentioned WinUSB, indicating that perhaps you're not tied to HID. Another option could be virtual COM port:
USB / Anything better than HIDAPI today?
« Last post by bpaddock on September 10, 2019, 01:10:32 pm »
I've been using Signal11's HIDAPI for years.
Sadly it looks like it has been abandoned by its author.
As well as saying in the past "won't fix" some issues that really need fixed.

Today it won't even compile with modern GCC versions without modification,
as GCC points out some dubious coding practices.  From GCC 8.2:

HIDAPI/hid.c: In function 'hid_enumerate':
HIDAPI/hid.c:449:5: error: 'strncpy' specified bound depends on the length of the source argument [-Werror=stringop-over
     strncpy(cur_dev->path, str, len+1);
HIDAPI/hid.c:447:11: note: length computed here
     len = strlen(str);

While that is fixable by replacing strncpy with memcpy, I'm wondering if there is something better supported for communication with HID devices today?

I must be able to support Windows7 machines that may have never had any updates, ruling out WinUSB?
Must also run as a normal user and I can't install anything for some other limitations.

For completeness for those trying to get HIDAPI to compile,
one of the other issues is its dubious use of macros.

To compile with 8.1 or later must add a cast to (void *) to the RESOLVE macro.

#define RESOLVE(x) x = (x##_)(void *)GetProcAddress(lib_handle,  #x); if (!x) return -1;


That head scratchier expands to, as one example:

  HidD_GetSerialNumberString = (HidD_GetSerialNumberString_)(void *)GetProcAddress(lib_handle, "HidD_GetSerialNumberString"); if (!HidD_GetSerialNumberString) return -1;;

in case your head was hurting trying to figure it out...
The double semi-colon would also technically be an error.

Pages: 1 ... 8 9 [10]