USB HID

libarra
Tue Sep 15, 2015 6:10 pm
//—————————————————————————————————————————–

UPDATE 2018.03.01

[madias – Thu Mar 01, 2018 4:03 pm] –
So I think libarras version of USB HID is now outdated, since arpuss version has bugfixes and more features.
Maybe we should mark this topic/library “outdated?” (libarra wasn’t online for almost one year, even on github).

So new user should switch to -> viewtopic.php?f=13&t=2926

//—————————————————————————————————————————–
Original post:

Hi everyone,

I have ported the mouse and keyboard classes from the Arduino Due core, and also the joystick class from the Teensy. I modified the original libmaple usb_cdcacm files to use the report descriptor of a usb hid device which can use the three devices at the same time. Also I added instances of the three devices to the stm32f1 core to use them within any sketch, just as the Serial instance.

The usage of the keyboard and mouse is basically the same as with the Arduino Due, and I tried to keep it the same way with the joystick so the class is almost the same as the Teensy one, but it doesn’t require you to confirm you want to send data, as it is sent as soon as you set any button or axis value through the class methods.

To make this changes to the core compatible with Serial, I modified the the platform and boards of the stm32f1 core so there’s a menu option for the usb type (serial or hid). I believe I made the necesary changes to avoid problems for the other boards (currently hid only works for the maple mini) while compiling due to the usb type given to the compiler as an argument, but tell me if I screwed something.

There are 3 simple examples (one for each device) in the HID folder.

About the licenses of the ported libraries, I think they are quite permisive. For the usb_hid files they are based on the libmaple files and the usb_hid_device files are based mostly in the Arduino Due core files.

This is the github repository: https://github.com/libarra111/Arduino_STM32

Thanks for reading, and please tell me what you think :).

libarra


madias
Tue Sep 15, 2015 6:56 pm
Hi and welcome, libarra!
Thank you for your work, it’s really interesting for me, because I started a conversation of the USB_MIDI project (it was created long time ago in the leaflabs forum) and the problem is, that it’s completely incompatible with the “standard” repo. (USB_Serial is exchanged with USB_MIDI). So your method with the menu option is really interesting – maybe a possibility for me not to have two (more or less) identical repos (and keep them both up to date)!
https://github.com/madias123/Arduino_STM32_MIDI_project
(meanwhile really out of date – my offline version is newer)

regards
Matthias


libarra
Tue Sep 15, 2015 7:39 pm
Hi Matthias,

The idea of using the menu is not really mine, since I took it from the Teensyduino, as it has the menu to choose among various usb options. One of them even is marked as serial + hid so maybe we could add the serial interface to the others in order to reset automatically when uploading a sketch. I have taken a look at your github repo and I see you added your MIDI files and renamed the Serial ones. What can be done (as I did in my fork) is to add some #if defined(USB_MIDI) in the boards_setup.cpp file all the usb_*.h files and initialize only the usb device chosen from the usb type menu. If you want we can try to add your MIDI code and my ported HID code into one repo and see if the serial, midi and hid work fine with the menu.

Thank you for the welcome.

libarra


madias
Tue Sep 15, 2015 8:47 pm
Dear Liberra!
I think this would be a great idea, I’m a little bit busy getting I2s and DMA working (see my flagrantly topic –> viewtopic.php?f=19&t=533
I’ve done a complete list of all changes, so there is no need to search through all changes :)
a plus “+” means that I’ve add a file
a minus “-” means, that I’ve delete a file (bad! I marked them red)
EDIT means, that I’ve edit a particular file
The reason, why I deleted some files was that I got not rid of Serial.USB (so the device always talked to the PC as “serial device” – maybe this wont occur anymore, because there were many changes the last 6 months in the main repo.
So here is the list:

Files changed:
STM32F1:
boards.txt: EDIT only *MIDI* maple mini available
STM32F1/cores/maple
+ usb_midi.cpp NEW
+ wirish.h EDIT: +#include <usb_midi.h> ­ #include <usb_serial.h>
+ boards.h EDIT: defines on end, compare needed
+ usb_midi.h NEW
+ MinSysex.c NEW
+MinSysex.h NEW
+ rules.mk EDIT: some defines, can be replaced
­-usb_serial.cpp
­-usb_serial.h

STM32F1/cores/maple/libmaple/usb/stm32f1
+ usb_midi_device.c
­- usb_cdcacm.c
STM32F1/system/libmaple
+ MidiSpecs.h
+ MinSysex.h
+ MinSysex.c

STM32F1/system/libmaple/include/libmaple
+ MidiSpecs.h
+ usb_midi_device.h

STM32F1/system/libmaple/USB/stm32f1
+ usb_midi_device.c

STM32F1/variants/maple_mini/wirish
+ boards_setup EDIT: some additionals, compare needed

regards
Matthias


libarra
Wed Sep 16, 2015 12:41 am
Dear Matthias,

I have tried to add your midi files, but as you said, if the serial files are present it seems that Serial.begin() is executed, causing the maple mini to be detected as com port with the pid declared in the usb_cdcacm.c file, although the menu option prevents the delcaration of ‘SerialUSB Serial’ in usb_serial.cpp and the execution of Serial.begin(); in boards_setup.cpp.

I can confirm Serial is not declared because in your midi example I added Serial.end(); and I received the error that Serial was not declared, then I tried to use MidiUSB.end(); and I received the warning that the method had not been defined although you defined it in usb_midi.cpp.

Maybe some function definitions of usb_cdcacm.c are called from your files, I’ll check again what else I can find.

libarra


mrburnette
Wed Sep 16, 2015 12:44 am
@libarra

Welcome and thanks …

Every uC needs a HID keyboard, now ths Mini has it.

Ray


libarra
Wed Sep 16, 2015 1:37 am
Thank you Ray,

Yes I thought that too :). Let’s see what usb projects with the Maple Mini are posted in the forum.

libarra


victor_pv
Wed Sep 16, 2015 3:10 am
Let me try to understand, are these classes so a keyboard, mouse and joystick can be connected to the STM32, or so the stm32 board can present itself as those to a computer?

libarra
Wed Sep 16, 2015 4:04 am
Hi Victor,

The new classes are HIDKeyboard, HIDMouse and HIDJoystick, and the instances to use them are Keyboard, Mouse and Joystick. For example, if you want to simulate that you type “Hello World!!!” in a keyboard you use:

Keyboard.print(“Hello World!!!”);

if you want to simulate a mouse right click you use:

Mouse.click(MOUSE_RIGHT);

The same way you can send joystick data like the X and Y position of the stick or the buttons pressed in the joystick. So as you say, the Maple Mini is detected by the OS (Linux, MacOS, Windows or any other with HID drivers) as a HID Device with Mouse, Keyboard and Joystick functionality. If you have the chance, please test these HID classes and tell me what you think. When you install my fork of the core, you just need to select the Maple Mini board and the ‘Keyboard + Mouse + Joystick’ usb type, by doing this, Serial is disabled but you can use the Mini as a HID Device, to reprogram it you need to set the Mini to perpetual bootloader mode or just press the reset button when the loader searches for the DFU device.

libarra


RogerClark
Wed Sep 16, 2015 5:41 am
Sounds very cool

I’ll need to give it a try


Vassilis
Wed Sep 16, 2015 6:35 am
I like it !
Well done libarra !

libarra
Wed Sep 16, 2015 8:07 am
@Matthias: I don’t know what’s wrong with the MIDI initializer :?: , because as you told, it used the serial descriptor if available, so I decided to ‘erase’ the serial files just adding in them an #ifdef that only lets the code compile if the serial option is chosen. After that I uploaded again your MIDI test and since it didn’t find the serial initializer it used the HID one :evil: . So then again I only allowed the code of the HID files if it was chosen in the menu. And finally I repeated the same with the MIDI files to avoid any further problems.

Fortunately, now everything seems to work, and I have commited these changes to the repo, so it’s ready for everyone to try.

@Roger: Thanks, now there’s Matthias’ MIDI option too!

@Vassilis: Thank you!

libarra


madias
Wed Sep 16, 2015 8:37 am
@libarra: I know the MIDIcode is really a mess up (it was only a “blueprint” for the very old maple IDE and “our” libmaple repo is completely rebuild) I did several bugfixes but there are plenty of things to do
BTW: Here I did a quick&dirty sequencer demo a while ago, only with a maple mini and an ILI9341 SPI-Touch-TFT: https://www.youtube.com/watch?v=-jvCRHCk7wQ
I’ll try your repo asap! (Sadly I’m @work)

Thank you for your work! The USB-HID was really a “missing point of features” we discussed several times since the project began.

If you are interested:
a) there was a thread in June about “USB mass storage device” —> http://www.stm32duino.com/viewtopic.php?f=15&t=315
b) There was also a thread about everything STM32-USB related stuff: http://www.stm32duino.com/viewtopic.php … 427&p=3989

regards
Matthias


madias
Wed Sep 16, 2015 10:11 am
Little update:
I’d time to to try it out:
Sadly, it’s not working, because the maple mini is not shown up as “midi device” in the sequencer program or audio/midi setup.
This is strange, because in the USB device list it’s shown up as “Diro Synth” (this the name, I’d given to it – we must change this! :) )
So, I’ll do my best and ‘ll search for the error. I guess it’s the usb_cdcacm.c
Edit: Ok, tried different things… wont show up, I’ve to go deeper and this needs time.

madias
Wed Sep 16, 2015 12:51 pm
Additional info related to USB-keyboard and USB-Mouse:
Both example codes won’t work under OSX, but on Windows 7 on Parallels.
I’ll grab out my Arduino Due and I’ll try the same examples.
EDIT Ok, under Windows 7 even my MIDI example is working! So there must be a problem with the USB-initialization, because my MIDI-repo is working under OSX. Very strange….
Can somebody test the Keyboard, Mouse (perhaps MIDI) under Linux?

more edit:
There is a difference in the osx system manager: (left: my midi repo = working, right: HID version = not working)
Image
translation:
“erforderliche Stromstärke” = required amperage,
“Unbekannt – Gerät wurde nicht konfiguriert” = Unknown – device has not been configured
This “unknown – device has not been configured” is on every selected USB-HID: keyboard, joystick, mouse.
The normal “serial” is working under OSX.


madias
Wed Sep 16, 2015 4:04 pm
Ok, deeper details:
This is the whole USB output of OSX for my working MIDI repo:
+-o Diro [email protected] <class IOUSBDevice, id 0x100012048, registered, matched, active, busy 0 (376 ms), retain 12>
{
"sessionID" = 106066826633184
"iManufacturer" = 1
"bNumConfigurations" = 1
"idProduct" = 20
"bcdDevice" = 512
"Bus Power Available" = 250
"bMaxPacketSize0" = 64
"USB Product Name" = "Diro Synth"
"iProduct" = 2
"iSerialNumber" = 0
"USB Address" = 3
"bDeviceClass" = 0
"locationID" = 102760448
"bDeviceSubClass" = 0
"IOUserClientClass" = "IOUSBDeviceUserClientV2"
"PortNum" = 2
"IOCFPlugInTypes" = {"9dc7b780-9ec0-11d4-a54f-000a27052861"="IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle"}
"bDeviceProtocol" = 0
"USB Vendor Name" = "Diro "
"Device Speed" = 1
"idVendor" = 7855
"Requested Power" = 50
"IOGeneralInterest" = "IOCommand is not serializable"
"Low Power Displayed" = No
}

libarra
Wed Sep 16, 2015 4:28 pm
Hi Matthias,

I’m sorry, I didn’t mean to say the MIDI code was a mess, what I meant is that I don’t know why would the MIDI initialzer use the code of the other USB interfaces, since it is basically the same as the other USB interfaces (with it’s due differences), but the other USB interfaces don’t use the others’ code.

About your MIDI code I added, it seams to work on my win 7 64 bits (showing itself as Diro Synth), currently I’m having trouble to make it work with my Debian Jessie 64 bits. The HID works for me with my win7 and my Debian. Unfortunately I can’t test on Mac OS.

When I was trying to see why the MIDI code didn’t work I changed some values of the device descriptor, I thought I only modified the class and subclass numbers, but anyway, I’ll use again your repo code and will only add the ifdefs to avoid the MIDI code when it is not the selected USB type.

I checked your video and looks really cool :) .

I’ll check the USB mass storage to see what can be done.

About the USB Pids it looks really interesting that the STM32duino can have it’s own registered pids. I have seen some of their projects, for example ‘Glitch’, which is Arduino based and has registered 5 pids with openmoko, so I think they would accept the STM32duino request for pids, although I don’t know how it would work since the STM32duino project covers many boards and uCs. Is it ok if all of them share the same pids?

libarra


libarra
Wed Sep 16, 2015 5:06 pm
Dear Matthias,

I have updated the repo with your original code for the device class and subclass, hope it solves the problem in Mac OS.

libarra


madias
Wed Sep 16, 2015 6:46 pm
Thank you libarra,
I took a quick test:
OSX-MIDI: working!
Windows 7 MIDI: working!
Maybe someone with Linux? (again ;) )
The interesting part is, that neither keyboard, mouse or joystick is working.
Maybe I’ve some time tomorrow, so I’ll change the DeviceClass and DeviceSubClass for them and if it works under OSX, I’ll try it on Win7.
I think we should be compatible with all three “main” OS’s: Linux, OSX and Windows.

Edit: I’ll send you an updated version of my MIDI files, I deleted some files (everything with sysex) and I’ve written a complete new (working!) sysex code.
Sadly USB-MIDI is complete different to Serial-MIDI (I studied several hours…) , so the best Arduino MIDI library https://github.com/FortySevenEffects/ar … di_library
isn’t compatible. (But the library works well on STM32 (only with serial devices..)


strawberrymaker
Wed Sep 16, 2015 8:50 pm
+1 for that port! Really great to see that functionality ^^. Now I can even work on other Projects i had in mind, yay.

Maybe put it in the main repo?

~Straw


madias
Wed Sep 16, 2015 9:25 pm
Ok, quick fix for OSX (also tested under Windows7!)
Just one entry in the usb_hid.h:
instead of:
#define USB_DEVICE_CLASS_HID 0x03

libarra
Wed Sep 16, 2015 11:11 pm
@Matthias: great news MIDI is working on OSX and your win7!, I have now tested MIDI in an old Ubuntu 64 bits and it also works (at least I beleave so, my only test is to open Musecore while the Mini MIDI is connected and it plays a note every second or so) :) .

Also I have updated the usb device class in hid as you said and hid still works on win7 and ubuntu :) .

@Straw: Thanks!, I think it will be interesting to see people’s HID projects with the Mini and other STM32duino boards :) .


victor_pv
Thu Sep 17, 2015 2:28 am
libarra wrote:Hi Victor,

The new classes are HIDKeyboard, HIDMouse and HIDJoystick, and the instances to use them are Keyboard, Mouse and Joystick. For example, if you want to simulate that you type “Hello World!!!” in a keyboard you use:

Keyboard.print(“Hello World!!!”);

if you want to simulate a mouse right click you use:

Mouse.click(MOUSE_RIGHT);

The same way you can send joystick data like the X and Y position of the stick or the buttons pressed in the joystick. So as you say, the Maple Mini is detected by the OS (Linux, MacOS, Windows or any other with HID drivers) as a HID Device with Mouse, Keyboard and Joystick functionality. If you have the chance, please test these HID classes and tell me what you think. When you install my fork of the core, you just need to select the Maple Mini board and the ‘Keyboard + Mouse + Joystick’ usb type, by doing this, Serial is disabled but you can use the Mini as a HID Device, to reprogram it you need to set the Mini to perpetual bootloader mode or just press the reset button when the loader searches for the DFU device.

libarra


libarra
Thu Sep 17, 2015 3:19 am
Yes Victor, I suspect people around you are in danger of being “HID pranked” :D . Some other uses for a HID Mini could be making a little keyboard for handy key shortcuts, make your own gamepad/joystick or repair/extend functionality of an existing one.

libarra


zoomx
Thu Sep 17, 2015 6:27 am
This way we can replicate an USB Rubber Ducky!

RogerClark
Thu Sep 17, 2015 7:06 am
is it possible to change the code to switch to HID mode under software control, ? i.e we can force usb enumeration on Maple mini and generic boards, so I should be technically possible

libarra
Thu Sep 17, 2015 9:05 am
Hi Roger,

Do you mean, e.g. change from usb serial to usb hid in the sketch? If so, I think it is posible to change the code to do so, although MIDI will give trouble. Other option is to implement descriptors for a usb device with two or more interfaces, e.g. serial + hid. While porting the HID code to the Mini I read in this pdf ( http://www.st.com/st-web-ui/static/acti … 158241.pdf ) that when a pc detects a composite device it assigns a different driver for each interface.

libarra


darth_llamah
Thu Sep 17, 2015 12:48 pm
Example sketches seem to work fine on linux (Debian 8 x64)
Keyboard example- sends right Super key (windoze key)
[email protected]:~$ lsusb -s 003:029 -v

Bus 003 Device 029: ID 1eaf:0024
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x1eaf
idProduct 0x0024
bcdDevice 2.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0 No Subclass
bInterfaceProtocol 0 None
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 188
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 10
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0


madias
Thu Sep 17, 2015 2:19 pm
darth_llamah wrote:
Note: while having HID onboard the only option to make upload to Maple Mini was:
1. compile the sketch
2. press and hold Reset button on Maple
3. click Upload in Arduino and release Reset at the same time- serial upload *should* begin before bootloader executes main program

libarra
Thu Sep 17, 2015 2:58 pm
@darth_llamah: Thanks for testing the code in Linux!. Have you tried the commented lines in the example sketches?, I think one of the windows keys doesn’t work in Gnome to display the overview. in the Joystick example, if you wish you can use the name you want for the LED pin number (I’ll correct it in the next repo update) or you can comment the pinmode line, I only lkept it if anyone wanted to use the Mini led to indicate anything.

@Matthias: Yes, for now that’s the price for using MIDI or HID instead of Serial :x . Are you still having trouble with the Mouse and Joystick in OSX?, I’ve searched in the teensy forum, but the only things I found were about the device class number and that the joystick was detected as two joysticks. Do you have a real joystick to test on mac and take a look at it’s report descriptor? Maybe we can base the code on that. About your updated MIDI files, I’ll update them as soon as posible, are they in your repo?

libarra


madias
Thu Sep 17, 2015 3:12 pm
libarra wrote:
@Matthias: Yes, for now that’s the price for using MIDI or HID instead of Serial :x . Are you still having trouble with the Mouse and Joystick in OSX?, I’ve searched in the teensy forum, but the only things I found were about the device class number and that the joystick was detected as two joysticks. Do you have a real joystick to test on mac and take a look at it’s report descriptor? Maybe we can base the code on that. About your updated MIDI files, I’ll update them as soon as posible, are they in your repo?
libarra

darth_llamah
Thu Sep 17, 2015 3:37 pm
libarra wrote:@darth_llamah: Thanks for testing the code in Linux!. Have you tried the commented lines in the example sketches?, I think one of the windows keys doesn’t work in Gnome to display the overview. in the Joystick example, if you wish you can use the name you want for the LED pin number (I’ll correct it in the next repo update) or you can comment the pinmode line, I only lkept it if anyone wanted to use the Mini led to indicate anything.

libarra
Thu Sep 17, 2015 5:44 pm
darth_llamah wrote:
I didn’t have time for more extensive testing, I’ll try tomorrow. I can’t say if right windoze works in Cinnamon- my laptop has only one ;)

libarra
Thu Sep 17, 2015 6:05 pm
madias wrote:
MIDI update: Sorry, but the github repo is totally out of date, I use a local “thing” (much rebuild), but before I give it away I’ve to make a big cleanup and write some (better) examples. Because I need MIDI on my current project I would suggest, that I’m working on it to get the chance to see what is not working and what should be polish. (Like get rid of the need in every sketch the convoy of all those “void USBMIDI:: xxx”))

darth_llamah
Fri Sep 18, 2015 7:57 am
libarra wrote:I have updated the Mouse example with a line using Mouse.move(x,y,w), it works in win7 but haven’t tested yet in Linux. At first I only tried X and Y movement, and it seemed that it didn’t work, so I checked the Due example and added that new line in the Mouse example. Remember that movement is represented with a signed char so from 1-127 you make a positive movement (to the right and down) and from 128-255 you make a negative movement. Same thing with the wheel movement.
libarra

libarra
Fri Sep 18, 2015 7:37 pm
darth_llamah wrote:
Mouse.move() from example works fine, also I don’t need to take care for X and Y values- HID uses PS/2 standard ;)

libarra
Fri Sep 18, 2015 8:02 pm
Dear Matthias,

While checking the joystick report (taken from the teensy), I noticed it has a section with the usage set as pointer, and the mouse report has a usage as pointer, so that may be the reason why the joystick example moves your mouse pointer around the screen :D . But why would OSX handle HID different from other OSs, wasn’t it supposed to be a standard? :lol:

libarra


darth_llamah
Sat Sep 19, 2015 8:15 am
libarra wrote:darth_llamah wrote:
Mouse.move() from example works fine, also I don’t need to take care for X and Y values- HID uses PS/2 standard ;)

libarra
Sun Sep 20, 2015 12:40 am
darth_llamah wrote:
PS/2 Mouse protocol is quite nicely described in Synaptics touchpad interfacing guide (PDF warning), section 2.1- “Mouse compatible relative mode” (which I’m using) and section 3- “PS/2 protocol”. However they describe X and Y movement data as a signed char.

darth_llamah
Sun Sep 20, 2015 9:58 am
libarra wrote:Thanks for the link.

libarra
Tue Sep 22, 2015 4:04 am
darth_llamah wrote:
No problem (besides code it’s taken from your examples ;) )

darth_llamah
Tue Sep 22, 2015 3:01 pm
I’m trying to add USB HID/Midi support to generic stm32f103c- I’m testing using Blue Pill board.
When board has bootloader onboard everything works fine.
BUT when there is no bootloader I must call HID.begin() or MidiUSB.begin() inside setup() otherwise device will not be enumerated on PC.
Question- when bootloader executes “main” program MCU has USB subsystem still ready to work (and just re-enumerates itself as HID device)?

madias
Tue Sep 22, 2015 3:59 pm
Interesting thing.
In my original MIDI repo I’ve always MidiUSB.begin() included in setup. Otherwise it didn’t work.
But why there is an interface between bootloader and main program. I don’t know. BTW I didn’t try it out on generic boards, but I have to do it for my main project.
So I would say, apart from the interesting question, you should always include MidiUSB.begin() to be on the safe side.
Do you only try MIDI out or you are going to work with it?
If yes, I will push myself to update the MIDI library (I got sysex support fully working for example, but I didn’t use any of the sysex files included)

darth_llamah
Tue Sep 22, 2015 4:18 pm
madias wrote:Interesting thing.
In my original MIDI repo I’ve always MidiUSB.begin() included in setup. Otherwise it didn’t work.

darth_llamah
Thu Sep 24, 2015 8:52 am
Sorry for double posting.
libarra merged support for generic stm32f103c boards to his repo.
Could you please test if USB works for other boards than Blue Pill, both with and without bootloader?
NOTE:
My Blue Pill without bootloader required to use HID.begin(), MidiUSB.begin() or Serial.begin() in setup() otherwise board was not enumerated. Also I didn’t check new joystick example yet.

libarra
Thu Sep 24, 2015 5:43 pm
Hi everyone,

I have created a branch (usb_libs) of the repo where I removed the cdcacm/serial, hid and midi files from the core, as well as the usb initialization from the boards_setup.cpp files of the stm32f1 folder. Then I added them as separate libraries for the stm32f1.

I think this will help test the new usb functionalities on other boards. In this new branch, there’s no usb type menu, the usb type library you want to use must be included in every sketch, and ***.begin() must be called in setup(). If you use a usb library different from serial, you’ll need to reset the board manually to upload a new sketch.

Please test and tell what you think.

libarra


libarra
Thu Sep 24, 2015 5:47 pm
darth_llamah wrote:
For now I’ve only checked if board is properly enumerated, I don’t have any midi capable software on laptop nor experience with midi controllers (I only use “analog” violin ;) )

victor_pv
Fri Sep 25, 2015 1:31 am
darth_llamah wrote:Sorry for double posting.
libarra merged support for generic stm32f103c boards to his repo.
Could you please test if USB works for other boards than Blue Pill, both with and without bootloader?
NOTE:
My Blue Pill without bootloader required to use HID.begin(), MidiUSB.begin() or Serial.begin() in setup() otherwise board was not enumerated. Also I didn’t check new joystick example yet.

libarra
Fri Sep 25, 2015 2:40 am
victor_pv wrote:
If I remember right, we have code for USB re-enumeration in 2 places:
1.-In the bootloader itself.
2.-in a core file, I believe boards_setup, when it sets the usb serial or right before it.

I haven’t followed this thread to see all the modifications, but it is possible the re-enumeration in the core was done within the usb serial.begin() code, and that is not being done now after the changes for the HID?

Please check board_setup.cpp and check if there is any code saying that is for usb re-enumeration right around serial.begin.

Roger knows better what file in the core has the re-enumeration stuff. From your description I would say that the files you use right now are missing that, that’s why it only enumerates when you use the bootloader too.


victor_pv
Fri Sep 25, 2015 4:21 am
The thing is, that code is for enumeration in Generic board (not maple variants with their special usb pull up circuit).
In maple boards, the enumeration is done by toggling a different pin.
Now I dont remember if the core ended up modified to just use this method in all the boards (maples included). If so, you could remove the generic_bootloader ifdef.
But if not, then rather than remove it, perhaps we should change it for something else.
If you guys have time, give it a try and see if it works for both types of boards and with/without bootloader by removing the ifdef.
If that fails in maples and maple clones, then the best would be to change the ifdef to check something else.
I wrote the code for toggling the pin, but Roger is the one that found the right place to use it and the right lenght of wait, so he knows better why it has the #ifdef. I would be surprised if he remembers though he is always correcting and adding things suggested by everyone, impossible to remember why something was done a certain way months after the fact. Even I dont remember why we put that there and I am sure he explained me the need for the ifdef.

There may be a thread buried somewhere with all the details.

EDIT, I forgot boards_setup.cpp is specific for each variant. In that case that toggling code is only present on generic variants, so should be safe to remove the ifdef and let it execute in every case, with and without bootloader.


libarra
Fri Sep 25, 2015 5:26 am
victor_pv wrote:The thing is, that code is for enumeration in Generic board (not maple variants with their special usb pull up circuit).
In maple boards, the enumeration is done by toggling a different pin.
Now I dont remember if the core ended up modified to just use this method in all the boards (maples included). If so, you could remove the generic_bootloader ifdef.

darth_llamah
Fri Sep 25, 2015 6:21 am
victor_pv wrote:I forgot boards_setup.cpp is specific for each variant. In that case that toggling code is only present on generic variants, so should be safe to remove the ifdef and let it execute in every case, with and without bootloader.

libarra
Sat Sep 26, 2015 2:11 pm
darth_llamah wrote:
BTW mouse works fine in Android- Moto G XT1039 with stock Android 5.1, keyboard and joystick not tested yet

darth_llamah
Sat Sep 26, 2015 2:45 pm
libarra wrote:Does the blue pill with bootloader gets enumerated as DFU to get the new sketch uploaded? Maybe getting rid of the ifdefs will allow the board to be enumerated as COM. If you agree I’ll commit that change.

libarra
Sat Sep 26, 2015 4:18 pm
darth_llamah wrote:
Yes, blue pill with bootloader is enumerated as DFU device. Please commit but I can check changes tomorrow.

darth_llamah
Sun Sep 27, 2015 12:11 pm
libarra wrote:darth_llamah wrote:
Yes, blue pill with bootloader is enumerated as DFU device. Please commit but I can check changes tomorrow.

libarra
Sun Sep 27, 2015 3:00 pm
darth_llamah wrote:
Nothing changed- with bootloader serial example sketch compiles fine but doesn’t work (board is enumerated as DFU device), without bootloader- compilation error.

darth_llamah
Sun Sep 27, 2015 6:41 pm
libarra wrote:Could you try adding Serial.end(); before Serial.begin(); and maybe a little delay between them?

libarra
Mon Sep 28, 2015 10:17 pm
darth_llamah wrote:
It’s worse now.
Blue pill with bootloader doesn’t enumerate when HID, Midi or Serial is used- always 1eaf:0003 (DFU)
Blue pill without bootloader- HID and Midi work, Serial doesn’t work at all- device is not enumerated.

darth_llamah
Wed Sep 30, 2015 9:46 am
libarra wrote:I have added again the ifdef serial_usb without checking generic_bootloader in boards_setup.cpp. In boards.txt file I added the serial_usb build flag for the generic stm32f103c using the serial upload method. I compiled the serial example with these changes and it compiled, but I don’t know if it really works on the generic board.

EDIT:

I commited the changes to the usb_libs branch


libarra
Thu Oct 01, 2015 3:29 am
darth_llamah wrote:
Blue Pill without bootloader- Serial works fine now, no errors with compilation.
Blue Pill with bootloader- no error with Serial example compilation but device does not re-enumerate (always DFU)

darth_llamah
Thu Oct 01, 2015 7:33 am
libarra wrote:Is serial the only one having trouble with the bootloader, or does hid and midi also show as dfu?

libarra
Fri Oct 02, 2015 4:44 pm
I updated the the master and usb_libs branches adding the serial_usb flags for other uploading methods of the generic stm32f103c. I think this will execute the *.begin() in boards_setup.cpp, so there’s no need to call it in setup(). If using the usb_libs, then *.begin() must still be used in setup().

darth_llamah wrote:
Doesn’t help- still DFU


darth_llamah
Sat Oct 03, 2015 4:08 pm
libarra wrote:Maybe it would help increasing the for delay.

libarra
Sat Oct 03, 2015 7:33 pm
darth_llamah wrote:
Increasing delay helped, pull request pending.
I increased delay from 256 to 1024 (512 was not enough). Maybe less than 1024 will do but this works reliably.

darth_llamah
Sat Oct 03, 2015 9:13 pm
libarra wrote:darth_llamah wrote:
Increasing delay helped, pull request pending.
I increased delay from 256 to 1024 (512 was not enough). Maybe less than 1024 will do but this works reliably.

libarra
Sun Oct 04, 2015 3:39 pm
darth_llamah wrote:
Maybe this change will also “fix” generic boards without bootloader in master branch? I’ll check it out.

darth_llamah
Sun Oct 04, 2015 5:24 pm
libarra wrote:I thought the problem with the master branch was that it was needed to add ***.begin() in setup().

libarra
Tue Oct 06, 2015 12:32 am
darth_llamah wrote:I’ve just started fresh portable Arduino 1.6.6 with usb_libs branch, when I opened “updatable libraries” (yes, there is a popup for that now) I got:

mrburnette
Tue Oct 06, 2015 12:45 pm
libarra wrote:darth_llamah wrote:I’ve just started fresh portable Arduino 1.6.6 with usb_libs branch, when I opened “updatable libraries” (yes, there is a popup for that now) I got:

darth_llamah
Tue Oct 06, 2015 1:57 pm
mrburnette wrote:I do not think so… I’m running 1.6.6 hourly and I have no issues with ESP8266, Arduino, Teensy3.1, or STM32F1. My box is Windows 8.1 fully patched, so I do not know what the issue is, but I do not think we can blame it on the Arduino GUI.
https://www.arduino.cc/en/Main/Software

Ray


mrburnette
Wed Oct 07, 2015 12:14 am
darth_llamah wrote:
<…>
Is your hourly Arduino IDE portable or not?
Portable hourly 1.6.6 doesn’t work for neither of Arduino_stm32 forks/branches. I know I should test it in default environment but I don’t want to mess my installation.

darth_llamah
Wed Oct 07, 2015 4:41 pm
mrburnette wrote:By portable, I suspect you mean that I have established a “portable” directory?

libarra
Thu Oct 15, 2015 12:54 am
Hi everyone,

I have added the options of No USB, Keyboard+Mouse, and Joystick to the usb type menu in the master branch. With this change the report descriptor will only include the necesary parts. I replaced SERIAL_USB with USB_HARDWARE, but only for the stm32f1.

I tried to add the same changes to the usb_libs branch, but I found a problem. I wanted to use #define USB_HID_xxx in the sketch before including the hid library, but it seems the compiler does not have defined USB_HID_xxx for the library although it is defined before the include. I think the only solution for that would be to use a menu to set the report descritor parts to be delcared, but it doesn’t seem to fit with the usb_libs branch ‘style’. So for now I have not commited these changes to usb_libs branch.

About the poll, Roger suggested to use survey monkey, so I will try to have it setup as soon as posible.

libarra


RogerClark
Thu Oct 15, 2015 1:03 am
but it seems the compiler does not have defined USB_HID_xxx for the library although it is defined before the include

This is correct, the #define only applies to the sketch not to the library (This is a common problem we have it with other things relating to libraries e.g we wanted to change the SPI channel in a #define but this was not possible)

The only way to add a #define for a library is to include it in boards.txt, which passes it to platform.txt which then puts it in as a compiler define directive e.g. -DUSB_HID_xxx

But this is problematic in terms of development, because if you write a sketch that needs a specific USB HID function, you can’t set that function in the sketch, and its reliant on people selecting the correct menu option (from boards.txt) to control this.

This ends up with loads of support problems because people don’t read the comments in sketches and will not set the correct menu option, they will just say that the sketch does not work :-(

So ideally you will need to work out another way to do this (but I must admit, I can’t see how because the first place in the code that things get run is in main() which is far after the USB initialisation is complete.

The only thing you can do in main is force USB re-enumeration and switch USB HID type, ie it would start as USB serial etc.

This is not ideal but may be all that is practical


darth_llamah
Thu Oct 15, 2015 5:19 pm
libarra wrote:I have added the options of No USB, Keyboard+Mouse, and Joystick to the usb type menu in the master branch. With this change the report descriptor will only include the necesary parts. I replaced SERIAL_USB with USB_HARDWARE, but only for the stm32f1.

libarra
Fri Oct 16, 2015 4:31 am
RogerClark wrote:but it seems the compiler does not have defined USB_HID_xxx for the library although it is defined before the include

This is correct, the #define only applies to the sketch not to the library (This is a common problem we have it with other things relating to libraries e.g we wanted to change the SPI channel in a #define but this was not possible)

The only way to add a #define for a library is to include it in boards.txt, which passes it to platform.txt which then puts it in as a compiler define directive e.g. -DUSB_HID_xxx

But this is problematic in terms of development, because if you write a sketch that needs a specific USB HID function, you can’t set that function in the sketch, and its reliant on people selecting the correct menu option (from boards.txt) to control this.

This ends up with loads of support problems because people don’t read the comments in sketches and will not set the correct menu option, they will just say that the sketch does not work :-(

So ideally you will need to work out another way to do this (but I must admit, I can’t see how because the first place in the code that things get run is in main() which is far after the USB initialisation is complete.

The only thing you can do in main is force USB re-enumeration and switch USB HID type, ie it would start as USB serial etc.

This is not ideal but may be all that is practical


RogerClark
Sat Oct 17, 2015 11:56 pm
Guys,

I’ve on the on and off for the last 4 weeks, so I’ve only sporadically been keeping up with your work.

However I’m back home now, so I may have some time to work out how best to integrate your work into the main repo if thats possible

It sounds like you are using a specific branch as you need to change boards.txt and this may have too much impact on users who do not want USB HID

Could you let me know what you think would be the best way to integrate your changes into the main repo ?

Thanks

Roger


darth_llamah
Sun Oct 18, 2015 10:20 am
RogerClark wrote:Could you let me know what you think would be the best way to integrate your changes into the main repo ?

RogerClark
Sun Oct 18, 2015 10:36 am
Ok

I will investigate how the polling system in PHPBB works.

It looks like its not on by default, and I probably have to create the poll, as I’m not sure I want to enable poll creation for all users, otherwise we could have a proliferation of polls ;-)

Re Testing on other boards.

I have a few other variants like the F103VET and the F103ZET, but i suspect that if it works on the BluePill, it will work on all generic boards, ( with the exception of the Ugly board, as that one wont even run the generic booloader)


darth_llamah
Sun Oct 18, 2015 10:45 am
RogerClark wrote:Re Testing on other boards.

I have a few other variants like the F103VET and the F103ZET, but i suspect that if it works on the BluePill, it will work on all generic boards, ( with the exception of the Ugly board, as that one wont even run the generic booloader)


RogerClark
Sun Oct 18, 2015 9:25 pm
darth_llamah wrote:RogerClark wrote:Re Testing on other boards.

For now only Maple Mini and generic stm32f103c support is present. Still tests on other f103c boards would be usefull.


darth_llamah
Sun Oct 18, 2015 9:53 pm
RogerClark wrote:darth_llamah wrote:RogerClark wrote:Re Testing on other boards.

For now only Maple Mini and generic stm32f103c support is present. Still tests on other f103c boards would be usefull.


RogerClark
Sun Oct 18, 2015 10:46 pm
OK

I see the changes specifically to the generic f103c

So those changes would need to be applied to the other variants

As we already have USB re-enumeration elsewhere in the code, it may be better to make that into a separate function rather than duplicating it in each board

I’ll take a look…


libarra
Sun Oct 18, 2015 10:58 pm
RogerClark wrote:It sounds like you are using a specific branch as you need to change boards.txt and this may have too much impact on users who do not want USB HID

RogerClark
Sun Oct 18, 2015 11:04 pm
OK..

No worries


RogerClark
Sat Oct 24, 2015 6:25 am
OK.

I finally had time to enable poll’s on one of the sections of the forum.

PHPBB admin requires that polls be manually enabled for each individual section and sub section, which is very time consuming to administer, so I’m just going to enable poll creation by me in Builds and Announcements

I’ve added a test poll to there.

Please can you draft your question and the available options (max 10 options are allowed by PHPBB) and the post them here, and I’ll create a new post in Builds and Announcements so we can have a poll on this

Thanks

Roger


libarra
Sun Oct 25, 2015 2:49 am
RogerClark wrote:OK.

I finally had time to enable poll’s on one of the sections of the forum.

PHPBB admin requires that polls be manually enabled for each individual section and sub section, which is very time consuming to administer, so I’m just going to enable poll creation by me in Builds and Announcements

I’ve added a test poll to there.

Please can you draft your question and the available options (max 10 options are allowed by PHPBB) and the post them here, and I’ll create a new post in Builds and Announcements so we can have a poll on this

Thanks

Roger


RogerClark
Tue Oct 27, 2015 12:04 am
Did you come to a decision about the stuff relating to Victor and the USB MSC code?

Or do you want me to create the poll with those 3 options?


libarra
Tue Oct 27, 2015 6:31 am
RogerClark wrote:Did you come to a decision about the stuff relating to Victor and the USB MSC code?

Or do you want me to create the poll with those 3 options?


RogerClark
Tue Oct 27, 2015 6:50 am
OK.

I think we need to change the title to

Which way do you prefer the usb HID to be managed?

1.- In the master branch and HID options on via a menu (as with Teensyduino).
2.- As in the usb_libs branch (The usb device class files (for Serial, MIDI, and HID) are each located in the libraries folder).
3.- Some other way.

We’ve had issues in the past where code is reliant on menu options, so my vote would be for a separate branch or ideally option 3.

i.e co-existence of multiple USB devices


libarra
Wed Oct 28, 2015 6:50 am
RogerClark wrote:OK.

I think we need to change the title to

Which way do you prefer the usb HID to be managed?

1.- In the master branch and HID options on via a menu (as with Teensyduino).
2.- As in the usb_libs branch (The usb device class files (for Serial, MIDI, and HID) are each located in the libraries folder).
3.- Some other way.

We’ve had issues in the past where code is reliant on menu options, so my vote would be for a separate branch or ideally option 3.

i.e co-existence of multiple USB devices


RogerClark
Wed Oct 28, 2015 7:03 am
I’m not sure if this is possible, but can we get the USB to re-enumerate if you call something like HID.begin() ?

I know that @ahull was looking at Serial.begin() and Serial.end() and then calling Serial.begin() again, and it doesn’t currently work.

We suspect that after Serial.end() has been called that the USB bus would need to be re-enumerated when Serial.begin() was called, but I don’t think anyone has had time to investigate (perhaps @ahull ‘Andy’ has, but I’m not sure)

I recall that LeafLabs wrote a some notes about issues that they had with the bootloader when they originally wrote it, as they wanted to put the Serial and DFU in the bootloader, and for the sketch to communicate with the bootloader to use Serial USB.

However from what I recall Windows would not allow one device to use 2 different drivers, i.e a DFU driver and a Virtual Serial driver.

I can’t quite find the link to the information at the moment, but perhaps its out of date and doesnt apply to Windows 7 and newer

(Sorry I’m not an expert in USB matters)


libarra
Wed Oct 28, 2015 8:01 am
RogerClark wrote:I’m not sure if this is possible, but can we get the USB to re-enumerate if you call something like HID.begin() ?

I know that @ahull was looking at Serial.begin() and Serial.end() and then calling Serial.begin() again, and it doesn’t currently work.

We suspect that after Serial.end() has been called that the USB bus would need to be re-enumerated when Serial.begin() was called, but I don’t think anyone has had time to investigate (perhaps @ahull ‘Andy’ has, but I’m not sure)

I recall that LeafLabs wrote a some notes about issues that they had with the bootloader when they originally wrote it, as they wanted to put the Serial and DFU in the bootloader, and for the sketch to communicate with the bootloader to use Serial USB.

However from what I recall Windows would not allow one device to use 2 different drivers, i.e a DFU driver and a Virtual Serial driver.

I can’t quite find the link to the information at the moment, but perhaps its out of date and doesnt apply to Windows 7 and newer

(Sorry I’m not an expert in USB matters)


RogerClark
Wed Oct 28, 2015 8:36 am
Thanks libarra

I’ve only looked at the USB descriptors in the bootloader, as I had to make some changes, and it only has one device (DFU) but that device has muliple “ALT” sub functions.

I’ll need to dig out my Arduino Pro mini, as I think that has Serial USB and also can have HID as well (though I can’t recall how you enable it)

I did quick search for usb composite device and found this

https://msdn.microsoft.com/en-us/librar … 85%29.aspx

https://msdn.microsoft.com/en-us/librar … 85%29.aspx

So at least under windows, it now looks like it may be possible to do this, and from what I understand from the doc written by Leaflabs it was always OK on Linux (and probably OK on OSX)

So…

I think we really need to investigate how to build a composite USB device descriptor, as this would give us the best of both worlds i.e no need to mess around with menus or branches in the code

However I realise this isn’t easy.


darth_llamah
Wed Oct 28, 2015 9:20 am
Once again I refer to Nicohood’s HID, master branch (for Arduino <=1.6.5). If I read the code correctly device descriptor is built on-the-fly:
-always USB serial is present unless “no USB core” is selected
-each HID device requires ***.begin() and then its descriptor is appended to default one
In the end Leonardo doesn’t have unused devices defined. Example sketch: http://llamah.no-ip.org/USB_IR_Remote_Control.ino

mrburnette
Wed Oct 28, 2015 12:29 pm
RogerClark wrote:
<…>
I’ll need to dig out my Arduino Pro mini, as I think that has Serial USB and also can have HID as well (though I can’t recall how you enable it)
<…>

RogerClark
Wed Oct 28, 2015 7:36 pm
Ok

Nicohood’s HID, master branch (for Arduino <=1.6.5)
I need to download that repo and look at how it works


ahull
Thu Oct 29, 2015 1:38 am
libarra wrote:

I think in one of the posts of this topic I included a sketch code which called Serial.begin() and Serial.end(), alternating them, each time the maple mini button was pressed and it did work for me (the maple mini was ‘connected’, ‘disconnected’, and ‘connected’ again), maybe it worked due to the delay between each button press.

libarra
Thu Oct 29, 2015 7:30 am
RogerClark wrote:So at least under windows, it now looks like it may be possible to do this, and from what I understand from the doc written by Leaflabs it was always OK on Linux (and probably OK on OSX)

So…

I think we really need to investigate how to build a composite USB device descriptor, as this would give us the best of both worlds i.e no need to mess around with menus or branches in the code

However I realise this isn’t easy.


keru
Thu Oct 29, 2015 5:55 pm
is there a way to use serial and HID ? Is that what’s called ‘composite USB’ ?
Would that impact the flashing or it doesn’t matter ?
Thanks.

darth_llamah
Thu Oct 29, 2015 6:33 pm
keru wrote:is there a way to use serial and HID ?

RogerClark
Thu Oct 29, 2015 7:53 pm
Re: Boards always showing as 3 devices

At the moment,i think there is still legacy code that calls begin() on the USB serial class, during initialisation.

This is because in the original Leaflabs example code they didnt have any calls to Serial.begin() in setup()

I know this will break some code, i.e people who have not put Serial.begin() in their setup(), but if we remove the call to usb serial begin from the init code, the board will not show as any usb device at all.

So if someone only wanted HID they could just call HID.begin() instead.

I guess it gets more complicated if they want to Serial and HID and other stuff e.g. midi or mass storage, because we’d need to dynamically keep adding more devices to the composite device, and expect wed keep needing to force enumeration.

( however I have a feeling thats possibly what happens on the AVR Leonardo
( but Ive not had time to check)

Perhaps a work around is to have additional versions of begin that dont force enumeration, so that we could defer enumeration until the last begin() for usb in setup()


keru
Thu Oct 29, 2015 8:32 pm
darth_llamah wrote:
I can’t say, I’ve been working only on making HID work on BluePill

darth_llamah
Thu Oct 29, 2015 8:46 pm
keru wrote:Is bluepill something specific or the ‘minimal stm32 system’ from ebay is basically it ?

keru
Thu Oct 29, 2015 8:56 pm
ok that’s a ‘bluepill’ I have too.
Reset makes my board flash a few seconds then stop, so I think the board and bootloader are ok.
I’ll check if it’s my system. Thanks, I can’t wait to try to use the HID !

that’s what I get when I reset the board
[27011.426972] usb 1-2: USB disconnect, device number 36
[27011.723089] usb 1-2: new full-speed USB device number 37 using xhci_hcd
[27011.852363] usb 1-2: New USB device found, idVendor=1eaf, idProduct=0003
[27011.852368] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[27011.852370] usb 1-2: Product: Maple 003
[27011.852372] usb 1-2: Manufacturer: LeafLabs
[27011.852374] usb 1-2: SerialNumber: LLM 003
[27013.195698] usb 1-2: USB disconnect, device number 37
[27013.464493] usb 1-2: new full-speed USB device number 38 using xhci_hcd
[27013.594097] usb 1-2: New USB device found, idVendor=1eaf, idProduct=0024
[27013.594101] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[27013.594104] usb 1-2: Product: Maple
[27013.594105] usb 1-2: Manufacturer: LeafLabs
[27013.594257] usb 1-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[27013.595855] input: LeafLabs Maple as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:1EAF:0024.0017/input/input37
[27013.648913] hid-generic 0003:1EAF:0024.0017: input,hidraw4: USB HID v1.10 Mouse [LeafLabs Maple] on usb-0000:00:14.0-2/input0


darth_llamah
Thu Oct 29, 2015 9:25 pm
keru wrote:ok that’s a ‘bluepill’ I have too.
Reset makes my board flash a few seconds then stop, so I think the board and bootloader are ok.

keru
Thu Oct 29, 2015 9:30 pm
Under linux it’s more tricky to fit into the DFU time window.
What works for me:
1. Verify sketch (only compiles, no upload)
2. Press and hold reset button, USB plugged
3. Click Upload
4. When the progress bar goes to ~50% release reset button

I tried but I can’t seem to end up with the right timing


Alternative- search for Continuous Bootloader Mode- for BluePill it requiret to short one of GPIO pins to GND or 3.3V (don’t remember which one and if it was GND or not).

I’ll check thanks for the advice

DFU uploader for linux doesn’t wait for the device.
There could be a way maybe waiting for dfu-util -l to say something, no?


keru
Thu Oct 29, 2015 9:40 pm
it seems that the reset util tries to reset something like /dev/ttyACMx (or USBx), but since I flashed the device as HID, it doesn’t find a serial device to give `upload-reset`

RogerClark
Fri Oct 30, 2015 12:54 am
Ah

If your build does not have serial, i.e only had HID, there is no way for the IDE to tell the board to reset and go into the bootloader

Normally, the IDE sends a special reset string and toggles DTR etc which the core reads and interprets as a reboot command and then reboots, which then runs the debugger.

So if you don’t have serial its never going to work.

If you have a physical button on your board, you can hold it down during the initial flashing led sequence to for it to hold in DFU mode, otherwise the bootloader will just jump to the sketch code after less than a second (I can’t remember the precise timing)


keru
Fri Oct 30, 2015 1:51 am
thank you for the clarification, it all makes sense now :)

ahull
Sat Oct 31, 2015 12:09 am
ahull wrote:libarra wrote:

I think in one of the posts of this topic I included a sketch code which called Serial.begin() and Serial.end(), alternating them, each time the maple mini button was pressed and it did work for me (the maple mini was ‘connected’, ‘disconnected’, and ‘connected’ again), maybe it worked due to the delay between each button press.

keru
Sat Dec 05, 2015 4:10 am
I don’t know if this can help or even if this is the right place, I’m sorry if it’s not … but I thought I would share since this thread got me interested in using the generic board as a keyboard.

Flabbergast here http://deskthority.net/workshop-f7/tmk- … ml#p270371 made the TMK firmware work on a generic STM32F103 and the baide maple mini clone, using chibios. It’s possible to keep the stm32duino’s bootloader too.


Luc_Exe
Wed Jun 01, 2016 2:37 pm
The download in the original post saved my life.

I had to create a list of 500 1-wire iButtons (DS1990A), just selected the usb keyboard + mouse from the menu and paired it with the 1-wire library plus a little sketch to avoid all the hard work and common mistakes by wrong reading the small engraved key of each ibutton.

So, 2 hours coding and testing + 10 minutes to error-free read the 500 devices, instead of 10 hours doing it manually and probably with many errors.


niash
Tue Aug 09, 2016 11:50 am
Hello,
Thanks for all the effort for making Stm32duino & to “libarra” for bringing USB-HID to the stm32duino.
I am trying to make USB-RAW-HID with the libarra’s fork. My findings as of now is that from MapleMini to PC is working fine whereas the other way doesnot happen. DataIn Endpoint 1 configured with Interrupt-Attributes & DataOut Endpoint 2 as Bulk-Attributes. RAW-HID report descriptors are same as defined in the usb_hid.c I am making effort looking other projects, understand & change in stm32duino. I shall update when I make some progress.
Any inputs?
Thanks.

RogerClark
Tue Aug 09, 2016 9:39 pm
There is a branch of the repo where I integrated the various USB changes

https://github.com/rogerclarkmelbourne/ … addMidiHID

I was hoping to merge this back into the master of the repo, but the problem is that if a user selects any USB device except Serial, they will not be able to upload withe the bootloader as there no way to reset the processor except via Serial ( at the moment)

Ideally we need a composite device that always has Serial, as well as whichever other devi es the user wants, but I am not an expert in USB and dont have time to write this myself


simonf
Tue Aug 09, 2016 11:41 pm
RogerClark wrote:

I was hoping to merge this back into the master of the repo, but the problem is that if a user selects any USB device except Serial, they will not be able to upload withe the bootloader as there no way to reset the processor except via Serial ( at the moment)

RogerClark
Tue Aug 09, 2016 11:44 pm
If you power cycle or press reset you get into the bootloader but most people don’t want to bother doing that

ahull
Wed Aug 10, 2016 7:40 am
This idea may have been suggested before, but would it be possible to re-enumerate the device in a manner similar to the Cypress CY7C68013A series 8051 based devices.

My understanding of the way these work, is that the enumerate as one device, this then updates the firmware, causing the device to re-enumerate as a different device. I’m not sure if this would be a workable solution in our case though, so your thoughts are welcome.


cologne86
Fri Sep 16, 2016 2:17 am
hello,
at first thank you for your great work
i built a small joystick and the library works perfect for that.
I only have a question about PB10. It seems the internal pull-up ist working for serial, but not for the joystick.
Could that be? i seems weird to me :D I have no problem with the other 10 buttons.

i will try to use another pin, so it will probably not be a problem at all.


petr
Sat Oct 01, 2016 1:52 pm
RogerClark wrote:There is a branch of the repo where I integrated the various USB changes
https://github.com/rogerclarkmelbourne/ … addMidiHID
I was hoping to merge this back into the master of the repo, but the problem is that if a user selects any USB device except Serial, they will not be able to upload withe the bootloader as there no way to reset the processor except via Serial ( at the moment)

EDN_A
Fri Nov 11, 2016 6:00 pm
RogerClark wrote:There is a branch of the repo where I integrated the various USB changes

https://github.com/rogerclarkmelbourne/ … addMidiHID

I was hoping to merge this back into the master of the repo, but the problem is that if a user selects any USB device except Serial, they will not be able to upload withe the bootloader as there no way to reset the processor except via Serial ( at the moment)

Ideally we need a composite device that always has Serial, as well as whichever other devi es the user wants, but I am not an expert in USB and dont have time to write this myself


libarra
Mon May 15, 2017 1:52 am
Hello guys, sorry for the quite long time without communication from my part…

I have just updated my repo. Now if you choose any of the HID options it will also include usb serial, so you can use both the Serial and HID interfaces in the same sketch.

Now the maple mini (I don’t have other boards to test) is listed as a composite device with the serial and HID interfaces, although if you use the “Serial” usb type, it will be listed just as always. if you have any trouble in windows with the device not being recognized, it may help unistalling it and check for hardware changes in the device manager.


Joe Crabhammer
Thu May 18, 2017 3:54 am
libarra wrote:Hello guys, sorry for the quite long time without communication from my part…

I have just updated my repo. Now if you choose any of the HID options it will also include usb serial, so you can use both the Serial and HID interfaces in the same sketch.

Now the maple mini (I don’t have other boards to test) is listed as a composite device with the serial and HID interfaces, although if you use the “Serial” usb type, it will be listed just as always. if you have any trouble in windows with the device not being recognized, it may help unistalling it and check for hardware changes in the device manager.


petr
Thu May 18, 2017 5:16 am
I have noticed it. It’s apparently better than my idea with switching between interfaces. Now if @RogerClark has time to include it in the main repo?

mamrezo
Thu May 18, 2017 12:41 pm
petr wrote:I have noticed it. It’s apparently better than my idea with switching between interfaces. Now if @RogerClark has time to include it in the main repo?

libarra
Thu May 18, 2017 2:59 pm
Joe Crabhammer wrote:
Hi. First time poster here. You solved the blocker preventing these all important HID updates from getting put into master, and nobody’s noticed :cry:

petr
Fri May 19, 2017 9:46 pm
libarra wrote:Hello guys, sorry for the quite long time without communication from my part…
I have just updated my repo.

libarra
Fri May 19, 2017 10:19 pm
petr wrote:Where’s your repo? I tried to search in your posts but couldn’t find it.

petr
Fri May 19, 2017 10:24 pm
Only Roger knows if PR against his master is preferred.

RogerClark
Sat May 20, 2017 2:12 am
I can try to merge the Master back into the AddMidiHID and see if the changes from the master are pulled in without an collisions.

Alternatively, as the AddMidiHID branch name confused a lot of people I could delete that branch and pull @libarra’s master to a new USBMidiHID branch


petr
Sat May 20, 2017 8:10 am
The latter sounds like minimal work for both of you, which is good in times when everyone is busy working on many things.

libarra
Sat May 20, 2017 1:56 pm
RogerClark wrote:I can try to merge the Master back into the AddMidiHID and see if the changes from the master are pulled in without an collisions.

Alternatively, as the AddMidiHID branch name confused a lot of people I could delete that branch and pull @libarra’s master to a new USBMidiHID branch


RogerClark
Sat May 20, 2017 10:37 pm
Can you tell me a good name for this branch, as I know there was a lot if confusion about the name I gave to the old branch.

ag123
Sat May 20, 2017 11:04 pm
i aren’t really against having usb-hid as a composite device, just that i’m thinking this is much better done as a *library*, i.e. it should be a separate implementation and leaving the usb-serial in the core untouched. this is so that for the ordinary cases, it would simply be usb-serial, this minimize complications to the different use cases and platforms (windows, linux, mac etc).

some large usb device class implementations can really be called applications themselves amounting to being ‘the sketch’ itself implementing the usb-device class. e.g. usb mass storage literally requires implementing a scsi device over usb

the library should be documented such that to use this library one should undef SERIAL_USB in platforms.txt, this is so that the alternate usb implementation from the library can be used.
(read roger’s comment below, editing platforms.txt and undef SERIAL_USB may not be required, one concept is one could call usb.end() to end the current device, then pull D+ / D- low for 10ms (usb reset) so that the host would start re-enumerating usb devices, in the mean time we call a new usb.begin() implementation and start as a new usb device class. this concept is *very useful* as it means that you can have a *sketch* that runs with USB-Serial ask the user what usb device the user wants, then do a usb reset (D+/D- low 10ms) and warp into a new usb device class) :mrgreen:

this would be the preferred approach as for ‘ordinary’ cases, normally one would expect basically a serial interface there, and it isn’t a surprise that Serial and SerialUSB is most commonly used for arduino – host interfacing, including simply printing and receiving commands / data as a user interface.

the trouble of course is that beyond USB-Serial, there can be usb hid, usb mass storage, usb cdc ethernet, usb audio and many other useful usb device classes. given the limited ram and possible complications and possible conflicts, and to simply use cases, it would be better if the usb device classes be abstracted as ‘libraries’ so that if one wants to use the different usb device class, one should first ‘disable’ usb-serial by editing platforms.txt

i’m actually quite keen to include ST’s ‘usb core middleware’ (i’d think distributed within those ST’cube hal stuff) in which ST actually included some device classes implementations (notably cdc (e.g. usb-serial), usb mass storage, usb-hid, usb-audio) along with an extendible common ‘usbcore’. i think this may be found in stm32generic as well as stm’s core, just that i’m not too sure if the ‘license terms’ may have certain issues. the implications of including those st’s codes some of them seem to have origin from keil is that it turns these stm32 devices into usb devices with a ready usb device class implementation for popular device classes e.g. usb mass storage, hid, cdc, audio, etc

the alternate is of course to implement it similar in spirit to this usb hid implementation, but as i’d prefer as ‘libraries’ so that it may be distributed as part of the ‘core’ set of libraries without possible complications

just 2 cents


RogerClark
Sat May 20, 2017 11:22 pm
Having the other USB types as a library seems a good idea if its technically possible.

I recall a USB mass storage demo sketch that I tried a long time ago, which kind-of worked.

From what I recall, I think the initialisation code calls Serial USB begin() so that users dont need to do it.

But we may be able to call Serial USB end() to kill it and then call USB HID begin to reset the USB bus and get HID instead of serial.

I think however that removing the Serial USB begin may not be a good idea as it may break loads of existing sketches


ag123
Sat May 20, 2017 11:34 pm
i briefly dig my toes in it only to realise just how complex the usb protocol stack can be
http://www.stm32duino.com/viewtopic.php … 367#p27723

e.g. to implement usb mass storage, one would need to basically program a scsi device and translate those scsi commands say and interfacing with the sd card, i think this is one of a popular scenario
the effort of which is no less than doing a full blown ‘app / sketch’, it could literally be ‘the sketch’ itself.

and my guess is implementing things like usb-cdc-ethernet (i.e. usb ethernet dongle) may be similarly complex
then there is a wish for a core ‘common’ usb core component which we could hook devices classes to this ‘core’ and letting this ‘usb core’ do some of the usb protocol work that’s common.

this ‘usb core’ is actually found in st’s cube mx usb protcol stack, st literally called this a ‘usb middle-ware’ or rather ‘usb device library’
um1734 stm32 cube usb device library
http://www.st.com/resource/en/user_manu … 108129.pdf

And st literally developed some of the device classs as well as described earlier. only thing of course is could we simply use those st’s cube mx codes, which seemed pretty invloved (note some of them are *partial* implementations) in themselves?


ag123
Sat May 20, 2017 11:40 pm
back to this topic, i think the ‘libraries’ approach is pretty much the better approach for ‘usb device classes’ given the large number of different usb device classes / use cases
just that as usb enumeration etc would pretty much be *mutually exclusive* say vs UsbSerial

i.e. you can’t enumerate as usb-serial and then separately as a composite device.
you would need to enumerate as a usb-composite (e.g. serial + hid) device and that being the case it would be necessary to undef SERIAL_USB in platforms.txt so that the 2 devices won’t conflict with each other during enumeration
^^ actually i’m not to sure if this is indeed the case

hence, uses who wants to use specific new usb device classes would need to manually edit platforms txt themselves as it differs from the default usb-serial use case
———-
hi roger, i just read your comment about the usb.end(), i’d think that’s one thing worth testing as we’d be able to avoid having to mess with platforms.txt and SERIAL_USB

i think you are likely correct about the usb.end(), as i’d imagine it would be possible to simply pull D+ and D- low for 10ms (usb reset) to get the host to start re-enumerating again. while we can write a different usb.begin() to start a different device class


RogerClark
Sun May 21, 2017 12:29 am
I just checked and there is usb serial end

https://github.com/rogerclarkmelbourne/ … pp#L88-L93

And yes.

I think if you call end and reset the USB bus, you should be able to get the board to enumerate as a different device

I’m just not sure how the host PC etc will handle getting a reset soon after its just started to setup for USB CDCACM

Though it should be easy to test.

Re: Mass storage.

There have been posts about this

http://www.stm32duino.com/viewtopic.php?t=315

The code is here

https://github.com/joeferner/maple-usbMassStorage

Though I don’t know if it still works – however we have not changed the core of the USB significantly, so I suspect it could be made to work


ag123
Sun May 21, 2017 12:40 am
thanks roger, i may ‘mess with it’ when i get some breather of time to ‘play with it’, additionally i like the idea of doing a usb reset and ‘warping’ into a different device, this could possibly make those stm32 boards with loads of flash work as a multi function usb device e.g. first run as a sketch then offer on usb-serial, select 1) mass storage, 2) hid, 3) audio etc, after the selection usb reset and warp :D

RogerClark
Sun May 21, 2017 12:59 am
I agree…

Having the USB device selectable by code is generally better than needing to select it from the IDE menu, because people can then just load the code + libraries and it works.

Having code which requires people to change the IDE settings to get it to work is confusing to say the least, so we generally avoid it if possible.


libarra
Sun May 21, 2017 9:51 pm
I may be the only one, but I don’t find it confusing nor hard to use a menu option next to the one I used to select the board I’m using…

Other thing I wanted to mention is that trying to change the usb interface of the device on the fly, at least in windows, is not really a good idea if you will be doing it frequently. At least with libmaple is not convenient because windows will still have the stm32 board installed with one interface, lets say serial, and when you change on the same ‘sketch’ the interface to any other type, windows will think there is an error in the device, so you will have to unistall the current driver for the board and check for changes in the device manager so windows detects it as the new interface. I you change the usb interface of your device once in a long while It will not really matter, but if you want to do it to send for example serial messages to the PC while using other interface it is not practical.

I’m not trying to be negative about the idea of the usb interfaces as independent libraries but I don’t think of it as a practical task to achieve.


RogerClark
Sun May 21, 2017 10:07 pm
I think we would need to test for whether its practical on Windows.

When switching from DFU. bootloader to Serial Sketch, Windows does not have a big problem.

We could also prevent Serial.end() being called by default, so the only thing Windows would see is when the new device e.g. HID is enumerated.

Coincidentally, there is another thread where someone reported that they do not get the Serial device unless their sketch calls Serial.begin() in setup.

I checked the core, and its supposed to be called automatically in the board setup function, but either its not getting called or it doesnt work for everyone.


libarra
Mon May 22, 2017 10:06 pm
RogerClark wrote:Coincidentally, there is another thread where someone reported that they do not get the Serial device unless their sketch calls Serial.begin() in setup.

I checked the core, and its supposed to be called automatically in the board setup function, but either its not getting called or it doesnt work for everyone.


ag123
Mon May 22, 2017 10:30 pm
the catch is probably that you need to enumerate as a different VID/PID e.g. 1eaf:0005
the host would then think that it is a new device and initiates that accordingly

RogerClark
Tue May 23, 2017 12:02 am
ag123 wrote:the catch is probably that you need to enumerate as a different VID/PID e.g. 1eaf:0005
the host would then think that it is a new device and initiates that accordingly

libarra
Wed May 24, 2017 12:08 am
RogerClark wrote:ag123 wrote:the catch is probably that you need to enumerate as a different VID/PID e.g. 1eaf:0005
the host would then think that it is a new device and initiates that accordingly

Collie147
Wed May 24, 2017 12:30 pm
Probably not the best place to put this, but as its libarra’s library and the thread is active I thought I’d have a pop.

Having some trouble getting the USB HID stuff to work. Keyboard.begin()/Mouse.begin() is fine, but as soon as I put in Keyboard.write() or Keyboard.print() the board does nothing after upload. It’s a bluepill by the way. Changed R10 from a 10K to 1K5 still the same. Once I comment out the Keyboard.write and reupload it works fine. No Keyboard detected by the computer either.

Any ideas?

I’m presuming it should be fine and its most likely my cheapo aliexpress bluepill.
Sketch below with basic keyboard output (based on blink for convenience)
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 13 as an output.
pinMode(PC13, OUTPUT);
//Serial.begin(115200);

Keyboard.begin();

}

// the loop function runs over and over again forever
void loop() {
digitalWrite(PC13, HIGH); // turn the LED on (HIGH is the voltage level)
Keyboard.println("ON");
//Serial.println("HIGH");
delay(1000); // wait for a second
digitalWrite(PC13, LOW); // turn the LED off by making the voltage LOW
Keyboard.println("OFF");
//Serial.println("LOW");
delay(1000); // wait for a second
}


libarra
Thu May 25, 2017 2:19 am
Collie147 wrote:Probably not the best place to put this, but as its libarra’s library and the thread is active I thought I’d have a pop.

Having some trouble getting the USB HID stuff to work. Keyboard.begin()/Mouse.begin() is fine, but as soon as I put in Keyboard.write() or Keyboard.print() the board does nothing after upload. It’s a bluepill by the way. Changed R10 from a 10K to 1K5 still the same. Once I comment out the Keyboard.write and reupload it works fine. No Keyboard detected by the computer either.

Any ideas?

I’m presuming it should be fine and its most likely my cheapo aliexpress bluepill.
Sketch below with basic keyboard output (based on blink for convenience)
// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 13 as an output.
pinMode(PC13, OUTPUT);
//Serial.begin(115200);

Keyboard.begin();

}

// the loop function runs over and over again forever
void loop() {
digitalWrite(PC13, HIGH); // turn the LED on (HIGH is the voltage level)
Keyboard.println("ON");
//Serial.println("HIGH");
delay(1000); // wait for a second
digitalWrite(PC13, LOW); // turn the LED off by making the voltage LOW
Keyboard.println("OFF");
//Serial.println("LOW");
delay(1000); // wait for a second
}


libarra
Thu May 25, 2017 5:19 am
Collie,

I have commited the changes, your sketch should work now.

By the way, you don’t need to initialize the Keyboard, Mouse, or Joystick because all of them with the Serial are initialized by libmaple with USBDev.begin(), but it doesn’t hurt to do it.

Collie147 wrote: No Keyboard detected by the computer either.


Collie147
Thu May 25, 2017 7:14 am
Champ! Thanks, and thanks for the info on the drivers too!

petr
Thu May 25, 2017 7:25 am
libarra, could your implementation be extended somehow to provide a generic HID device to user? I used V-USB’s HID implementation for transmitting my own data this way. I just wrote the descriptor and send/receive functions and that was it. Even the descriptor was kinda generic actually – it just took me a while to find one that would be accepted by Windows, OSX and Linux. So only the send/receive routines were “custom” (user defined), the rest could have been hardcoded in the library.

Maybe it’s not necessary when the serial over USB is working (it wasn’t on V-USB, IIRC). But the great advantage of HID based custom communication is that it doesn’t need any driver nor configuration/setup on PC side. You just plug it in and it works out of the box.


petr
Thu May 25, 2017 1:53 pm
BTW, I’ve tried the libarra HID Keyboard in Linux (worked perfectly) and Windows 10 (didn’t work at all, “driver not installed”).
Is it supposed to work in Windows 10 or not?

libarra
Fri May 26, 2017 5:01 am
Collie147 wrote:Champ! Thanks, and thanks for the info on the drivers too!

Lennyz1988
Mon Aug 14, 2017 1:18 pm
[libarra – Thu May 25, 2017 5:19 am] –

If you are using windows you may need to uninstall your board’s driver as Serial in the device manager, and check for changes in the hardware. When it is detected it will install 3 usb drivers: Composite, Serial and HID. Once it’s done installing the drivers your board should work as a composite device with Serial and HID.

Thanks! This did the trick for me. Working perfectly fine on Windows 10 x64.


douginarug
Wed Oct 11, 2017 2:45 pm
I’m using Arduino IDE 1.6.9, Windows 7, a Maple Mini r3 (from eBay) (with a STM32F103C8T6). Using the Keyboard + Mouse setting.

I tried to get this to work, but even after uninstalling the serial driver in device manager and resetting it so it reinstalled, it still does not show up as a HID device. It only reinstalls the serial. I also tried connecting it to an old windows XP machine.
I have read through most of this forum thread, skimming past the MIDI stuff, and I am wondering if I have missed something.

Should I be using a different IDE? There is a lot of conflicting info of which one to use with a stm32.
Edit: I just tried IDE 1.6.13 and still no HID device.

Are there some examples specifically for the maple or maple mini? Here is my code…

const int button0 = PB11;
const int button1 = PB10;
void setup() {
pinMode(PB1, OUTPUT); //for the LED
pinMode(button0, INPUT_PULLUP);
pinMode(button1, INPUT_PULLUP);
//Keyboard.begin();
//USBDev.begin();
}
void loop() {
if ((digitalRead(button0)== LOW)) Keyboard.press('a'); else Keyboard.release('a');
if ((digitalRead(button1)== LOW)) Keyboard.press('b'); else Keyboard.release('b');
// The next section blinks the LED so I can tell if the sketch is running
digitalWrite(PB1, HIGH); // turn the LED on (HIGH is the voltage level)
delay(2); // wait
digitalWrite(PB1, LOW); // turn the LED off by making the voltage LOW
delay(498); // wait
}


ofnicolson
Sat Oct 14, 2017 5:42 pm
Hi everyone,

I’m trying to make my Maple Mini act as a USB keyboard. I’ve installed the code at https://github.com/libarra111/Arduino_STM32 but I can’t find the examples mentioned (the original post says they live in a HID folder which I can’t find).

Can anyone point me at sample code that acts as a USB keyboard, please?

Many thanks,
Ollie


ofnicolson
Sun Oct 15, 2017 7:47 am
Ah, OK. I figured it out – I’d been trying to include Keyboard.h and getting “can’t find HID.h” errors. But apparently Keyboard.write() works without any includes or initialization.

Thanks libarra!


douginarug
Thu Oct 19, 2017 1:38 pm
[libarra – Thu May 25, 2017 5:19 am] –
If you are using windows you may need to uninstall your board’s driver as Serial in the device manager, and check for changes in the hardware. When it is detected it will install 3 usb drivers: Composite, Serial and HID. Once it’s done installing the drivers your board should work as a composite device with Serial and HID.

Hey I got it!
You may want to add an extra step to this quote from Libarra. At least for Windows 7 users. If you can’t get windows to recognize your Maple as a HID device, Uninstall your driver like Libarra says and then, when it asks if you want to “Confirm Device Uninstall”,
Put a Check in the checkbox that says “Delete the driver software for this device.”
Then press the OK button. Then reset your Maple.

Thank you Libarra (and others) for all your hard work.


arpruss
Wed Dec 13, 2017 1:02 am
Here’s a bug I found in the fork: some iinterfaces entries are out of range of the N_STRING_DESCRIPTORS. Changing them to 0 should fix this. This is in usb_device.c.

I didn’t actually try your fork, but when I had the same bug in my USBHID library, the device wouldn’t work either with my Android phone or with the Ubuntu VM. After fixing, it works.


florisla
Tue Feb 27, 2018 1:03 pm
Hi all,

I’m using USB HID now on a Hy-Tiny board (STM32F103TB) in Keyboard+Mouse mode on Windows 7.

Thanks to all who contributed, this is great stuff to work with.

I wanted to share one issue I encountered (and found a fix for).

At first, I did not succeed in getting the Serial and the HID device to be functional at the same time.

With the standard drivers installed, I had a ‘Maple Serial’ but then the HID device was not present.

To enable the HID device, I removed and deleted the serial driver and then scanned for hardware changes —
in which case the HID keyboard appeared (1EAF 0004 MI_02 Col02).

But of course, then I had no serial driver anymore (which is handy for doing firmware uploads).
The serial device was shown without a driver as Other Device -> Maple (1EAF 0004 MI_00).

As soon as I installed the serial driver, the HID device would disappear again and I lost the keyboard functionality.

The solution is to use the –id 0 option to wdi-simple.exe in install_drivers.bat (for the serial device, not the DFU).


mrburnette
Tue Feb 27, 2018 1:19 pm
[florisla – Tue Feb 27, 2018 1:03 pm] –

The solution is to use the –id 0 option to wdi-simple.exe in install_drivers.bat (for the serial device, not the DFU).

Very interesting. I am assuming you are using Windows 10 or 8.1?

Ray


florisla
Tue Feb 27, 2018 11:20 pm
No, this is on Windows 7 x64.

arpruss
Wed Feb 28, 2018 1:32 am
[florisla – Tue Feb 27, 2018 1:03 pm] – The solution is to use the –id 0 option to wdi-simple.exe in install_drivers.bat (for the serial device, not the DFU).

Excellent! I wasn’t able to get both serial and HID working at the same time in Win 8.1, and I hope this will work.


madias
Thu Mar 01, 2018 4:03 pm
So I think libarras version of USB HID is now outdated, since arpuss version has bugfixes and more features.
Maybe we should mark this topic/library “outdated?” (libarra wasn’t online for almost one year, even on github).

So new user should switch to -> viewtopic.php?f=13&t=2926


florisla
Fri Mar 02, 2018 12:01 am
Thanks,
I wasn’t aware of that.

I’ll see if I can make it work with that library.


Leave a Reply

Your email address will not be published. Required fields are marked *