Experimental HID and Midi support

Guys

Spurred on my a posting by @madias, I’ve had a go at merging some experimental Keyboard, Mouse, Joystick and Midi support into a branch of the F1 repo (Updated taken from here https://github.com/libarra111/Arduino_STM32)

See

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

I’ve only tested Maple mini at the moment, and I’ll look at Blue Pill (Generic F103C) as soon as I can.

What USB device the board enumerates as is controlled via a menu in the IDE. I know this is not ideal, but this is they way that libarra111’s repo does it.

I think the only alternative to menu’s is to not enable Serial USB by default and perhaps use Serial.begin() to enable USB Serial and HID.begin() to enable HID
(Note at the moment these are separate devices, you can have Serial and HID etc )

Thank you Roger!
Additional info:
Once a board is flashed with a different USB_HID than “Serial” you need to get into “Perpetual Bootloader Mode” for the next code upload, because “Serial” isn’t available anymore.
This is no magic for the mini but on customized boards this might be a problem (thoose without buttons..)
Info #2:
The MIDI implementation is a little bit “crude” in this repo, because libarra111 had taken a very old version of my “MIDI-standalone-repo” (It was my fault, because I never synced it), so if someone wants to deal with SYSEX and other things beyond MIDI basic stuff, it could be worth to look into my more actual one. Sadly I have no time to put in all changes into this “new” USB_HID repo. See > https://github.com/madias123/Arduino_STM32_MIDI_project

RogerClark wrote:
I think the only alternative to menu’s is to not enable Serial USB by default and perhaps use Serial.begin() to enable USB Serial and HID.begin() to enable HID
(Note at the moment these are separate devices, you can have Serial and HID etc )

Re:branch name in github

It hopes this would just be a temporary name and I could merge it back into the master.

But I think there may be some resistance to this

Its a shame that the IDE does not have a way to have a master header associated with the sketch that would allow the #defines to be configured

It would resolve loads of problems including SPI channel as well as this usb stuff

I wonder if people would freak out if I merged this branch into the master.

Or perhaps changed it so that Serial USB is not enabled by default and you have to call Serial.begin(); to enable it

I suspect a lot of sketches would break if I removed the call to Serial.begin that gets called by the startup code.

Personally, I’m always doing a Serial.begin() myself in the Setup() of my sketches.

RogerClark wrote:I wonder if people would freak out if I merged this branch into the master.

Or perhaps changed it so that Serial USB is not enabled by default and you have to call Serial.begin(); to enable it

I suspect a lot of sketches would break if I removed the call to Serial.begin that gets called by the startup code.

madias wrote:RogerClark wrote:I wonder if people would freak out if I merged this branch into the master.

Or perhaps changed it so that Serial USB is not enabled by default and you have to call Serial.begin(); to enable it

I suspect a lot of sketches would break if I removed the call to Serial.begin that gets called by the startup code.

Ok.

I will need to check if the code is smaller if Serial.begin is not called.

BTW, I think we could also support mass storage, as I have seen code for that as well.

The tricky part is how to add all these features so that they do not cause code bloat for people who just want a basic system without USB

I’ve taken a quick look at this using the selections in the USB menu to see how much Flash and RAM the various types of USB use

No USB
flash: 5,564
RAM:1,720

Serial
flash: 11,348
RAM: 2,560

Midi
flash: 10,876
RAM: 2,384

Keyboard + Mouse + Joystick
flash:11,088
RAM: 2,568

The values are because the usbMidi etc files have #ifdef’s in them which mask out all of their code if their specific #define is not set.

But. If I simply remove the call to Serial.begin() it has the effect of not compiling in the USB at all, So… the linker seems to be doing its job.

However, if I hack the #defines, so that all USB types are defined at once, it compiles and links, But …

There is currently a problem, because it looks like the all 3 types of USB devices are defining the same global variables used by the core USB code

So even if I call MidiUSB.begin(); in the sketch, the board still enumerates with the characteristics of Maple Serial

I think this is likely to be because each of the midi files defines a static variable called Config_Descriptor as well as Device_Descriptor, and I’m surprised that the compiler has not failed to compile this, as I can’t see how all of these are not in the same scope at the same time.

The very minimum would be to rename these to something specific to each of the USB devices e.g usbMidi_Config_Descriptor etc

I’m going to change the code to do this, but I suspect there are other parts of the code that will need to be changed.

I have found one big drawback with disabling USB Serial by default.

If USB Serial is disabled, there is no way for the IDE to reset the board back into the bootloader , so you have to manually reset the board each time.

So I don’t think that we can have the option of no USB when using the bootloader, and ideally we need a composite device that contains Serial + the other device requested.
But that would require each USB device to be a composite device, which would require a big rewrite – and I know nothing about USB, and don’t have time to make such a big change ;-(

Ok, this is definitely a “no go”.
So we can take the best compromise and leave it as libarra111 did: With the menu. So we can also decide to use no Serial/USB at all.

…and about MIDI flash/ram size compared to Serial:
USB MIDI is about 99% the same as USB Serial, so it would make me wonder if there are much differences (I think USB MIDI would be a bit larger because of a sysex buffer, but this sysex buffer isn’t implemented in this version only in my one).

Matthias

I have not looked at the implementation for midi vs Serial, but I agree, I would expect midi to be bigger than Serial.

Perhaps Serial has some ineffecient code ( it is quite old code)

RogerClark wrote:I have found one big drawback with disabling USB Serial by default.

If USB Serial is disabled, there is no way for the IDE to reset the board back into the bootloader , so you have to manually reset the board each time.

So I don’t think that we can have the option of no USB when using the bootloader, and ideally we need a composite device that contains Serial + the other device requested.
But that would require each USB device to be a composite device, which would require a big rewrite – and I know nothing about USB, and don’t have time to make such a big change ;-(

@simonf

Yes.

I wasn’t sure if the code that Matthias linked to (and which I merged by hand into the new branch) had a solution for this, but it doesn’t

I could merge the experimental branch into the master, but I wonder how many people would want to use it, and how many people would have problems with board not resetting prior to upload – as they didnt realise they’d have to do it manually if they don’t have USB Serial

I would like keyboard support but I need serial as well. I currently use 2 sparkfun micros for that project it would work with a blue pill but I need the keyboard interface and the serial port to program it.

Not being able to program easily would be a drawback for most. I use a STlink V2 clone one of the best £2.50 I’ve spent.

I could on the other hand just write a serial to keyboard driver for the windows app but at the moment they can just open up a notepad widow and hit test but and it types all the status info. Trying to get the engineers to use termite on site would be a nightmare.

@simonf

Ideally we need everything to be a composite device, whose device descriptors get built on the fly dependent on what devices you call begin() upon

or perhaps have some new global instanced called USB so we can do USB.begin(SERIAL | MIDI) or USB.begin(SERIAL|HID|JOYSTICK) etc

As I can remember MIDI + Serial would be a problem, because the MIDI HID code is a crude hack and exchanged/cloned many of the Serial HID code (I’m sure with the same variables), so indifferences are inevitable. But MIDI is a very special interest derivative, so people who are dealing with MIDI and STM32 should know what they are doing. There is also less sense using MIDI and Serial at the same time, apart from the programming phase. But in that phase you can use the perpetual Bootloader mode or just do a manual reset.
I think more people would be interested in Keyboard/Mouse/Joystick stuff. There is also a last HID mode we have forgotten: mass storage. A while ago I dreamt about updating the firmware on already made devices (for friends, family, customers..) just with file drag&drop (like ST Link 2.1)
Ok, we need an USB-Guru here!

Matthias

There is some mass storage code kicking around, I will try to find it, as I am sure I looked at it before.

I think its a library not core code.

and Yes… We need a USB expert

I recall someone posting with a lot of info about USB, but I cant remember who it was.