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
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
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
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
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
Welcome and thanks …
Every uC needs a HID keyboard, now ths Mini has it.
Ray
Yes I thought that too . Let’s see what usb projects with the Maple Mini are posted in the forum.
libarra
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
I’ll need to give it a try
Well done libarra !
, 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 
. 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
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
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.
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)
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.
This is the whole USB output of OSX for my working MIDI repo:
+-o Diro Synth@6200000 <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
}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
I have updated the repo with your original code for the device class and subclass, hope it solves the problem in Mac OS.
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..)
Maybe put it in the main repo?
~Straw
Just one entry in the usb_hid.h:
instead of:
#define USB_DEVICE_CLASS_HID 0x03 .
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 .
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
. 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
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
Keyboard example- sends right Super key (windoze key)
matus@laptok:~$ 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
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
@Matthias: Yes, for now that’s the price for using MIDI or HID instead of Serial 
. 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
@Matthias: Yes, for now that’s the price for using MIDI or HID instead of Serial
. 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
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
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”))
libarra
Mouse.move() from example works fine, also I don’t need to take care for X and Y values- HID uses PS/2 standard
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 . But why would OSX handle HID different from other OSs, wasn’t it supposed to be a standard? 
libarra
Mouse.move() from example works fine, also I don’t need to take care for X and Y values- HID uses PS/2 standard
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.
No problem (besides code it’s taken from your examples
)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)?
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)
In my original MIDI repo I’ve always MidiUSB.begin() included in setup. Otherwise it didn’t work.
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.
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
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
)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.
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.
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.
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.
BTW mouse works fine in Android- Moto G XT1039 with stock Android 5.1, keyboard and joystick not tested yet
Yes, blue pill with bootloader is enumerated as DFU device. Please commit but I can check changes tomorrow.
Yes, blue pill with bootloader is enumerated as DFU device. Please commit but I can check changes tomorrow.
Nothing changed- with bootloader serial example sketch compiles fine but doesn’t work (board is enumerated as DFU device), without bootloader- compilation error.
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.
EDIT:
I commited the changes to the usb_libs branch
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 wrote:
Doesn’t help- still DFU
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.
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.
Maybe this change will also “fix” generic boards without bootloader in master branch? I’ll check it out.
https://www.arduino.cc/en/Main/Software
Ray
<…>
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.
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
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
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
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
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)
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)
For now only Maple Mini and generic stm32f103c support is present. Still tests on other f103c boards would be usefull.
For now only Maple Mini and generic stm32f103c support is present. Still tests on other f103c boards would be usefull.
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…
No worries
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
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
Or do you want me to create the poll with those 3 options?
Or do you want me to create the poll with those 3 options?
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
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
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)
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)
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.
-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
<…>
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)
<…>
Nicohood’s HID, master branch (for Arduino <=1.6.5)
I need to download that repo and look at how it works
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.
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.
Would that impact the flashing or it doesn’t matter ?
Thanks.
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()
I can’t say, I’ve been working only on making HID work on BluePill
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
Reset makes my board flash a few seconds then stop, so I think the board and bootloader are ok.
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?
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)
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.
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.
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.
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.
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
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)
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.
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
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.
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)
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
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.
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.
Hi. First time poster here. You solved the blocker preventing these all important HID updates from getting put into master, and nobody’s noticed
I have just updated my repo.
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
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
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) 
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
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
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?
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
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
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.
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.
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.
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.
the host would then think that it is a new device and initiates that accordingly
the host would then think that it is a new device and initiates that accordingly
the host would then think that it is a new device and initiates that accordingly
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
}
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
}
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.
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.
Is it supposed to work in Windows 10 or not?
[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.
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
}
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
Thanks libarra!
[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.
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.
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).
[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 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.
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
I wasn’t aware of that.
I’ll see if I can make it work with that library.
