Hardware switchable USB Gadget Mode - possible?

[blixabloxa]

Hi All,

Thanks for this great project.

Just a query whether it would be possible to have USB Gadget mode switchable via a hardware switch and a spare GPIO input? I am new to RPi, and not sure how hard this would be to implement - I suspect some new coding would be required.

I would like to use my midi controller and minidexed in a standalone configuration sometimes, as well as sometimes connecting it to my computer and controlling it from my DAW, without having to reload the minidexed.ini with the USB Gadget mode switched on or off.

Thanks,
Enzo

[probonopd]

Hi Enzo, welcome!

USB Gadget mode was contributed by @diyelectromusic in
258a456

As far as I understand it, what you would like is to replace

MiniDexed/src/config.cpp

Line 39 in 258a456

m_bUSBGadgetMode = m_Properties.GetNumber ("USBGadget", 0) != 0;

by something that reads the value of a GPIO pin (low or high), instead of reading the value from the minidexed.ini file?

Something along the lines of

#include <circle/gpiopin.h>

    // Read the value of a GPIO pin
    CGPIOPin usbGadgetPin(GPIO_PIN_NUMBER);  // Replace GPIO_PIN_NUMBER with the actual GPIO pin number
    m_bUSBGadgetMode = usbGadgetPin.Read() != 0;

[probonopd]

@diyelectromusic what do you think? Maybe we should have something like

USBGadget=0  ; Default to 0 (not in gadget mode)
USBGadgetPin=26  ; Default GPIO pin 26

If either USBGadget is set to 1 or USBGadgetPin is pulled down, then we enable gadget mode.

Testing at #670

[probonopd]

A build for testing is available at #670

I have not tested it yet.

In minidexed.ini, edit

USBGadget=0  ; Default to 0 (not in gadget mode)
USBGadgetPin=26  ; Default GPIO pin 26

then attach a jumper to ground to pin 26. NO WARRANTIES as I have not tested this yet.

[diyelectromusic]

That might do it. If it was me, I'd probably leave the config option as it is and include a means to read the GPIO on startup and then decide between the two options - GPIO or config - which "wins".

My nervousness is that USBGadget mode has power requirements that really need to be thought about carefully and I a little nervous about the idea that it could be set accidentally when the Pi is powered the wrong way (see the wiki).

Also, I'd need to check when the GPIO is initialised in kernel.cpp - obviously it would have to be before we're checking for USB Gadget mode if we went down this route.

Update: that's ok - GPIOManager is initialised first.

Kevin

[probonopd]

@diyelectromusic

this ought not to be a standard feature of MiniDexed

Are your concerns also regarding the Raspberry Pi Zero and Zero 2?

[diyelectromusic]

My concern is a configuration option that could cause hardware problems with a Pi if the hardware isn't there to match or it is set accidentally (being an external dependency now) or some such. All other options are largely benign.

There will be a custom hardware solution for each use case, but perhaps not an elegent power safe solution for all.

Exactly. That's why I don't think this should be in the main build. Anyone competent enough to be worry about power issues should be competent enough to build the minidexed source and do something themselves in my view.

I notice you've merged that change in regardless however - so not quite sure what the point of discussing it here is then?

Also, you've now created a configuration option that will give you different things depending on something external to the minidexed.ini file. I strongly think that is a bad idea. Side effects and surprising behaviours are never good in my opinion.

As I suggested above if we wanted to do this, I'd strongly recommend using logic to decide how to combine the two configuration settings (minidexed.ini and hardware) rather than alter the configuration reading depending on "magic" actually within the config class itself.

Kevin

[probonopd]

Hi Kevin, I think we should distinguish

• Whether we should have the gadget mode at all for the various models - I tried with a Raspberry Pi Zero and it worked flawlessly for me. If we are concerned about other models, maybe we should disable it for those models
• How to enable the feature - via an ini file, or (optionally) via a pin setting, so that one doesn't have to change the config file every time to switch back and forth between device mode and gadget mode

I don't know exactly what you have in mind when you say "combine the two configuration settings (minidexed.ini and hardware)". I understand that some people will want to set gadget mode via the ini file, and others will want to use a hardware button/switch

If you are really that concerned, would it be a compromise to set the default for USBGadgetPin to 0?

[diyelectromusic]

I'm fine with gadget mode as a configuration setting, and I've tested the various configurations with different Pis - Zero, 3A+, 1A, 4, that support it, and others that don't.

The problem is that to use it you have to think carefully about where power is coming from, so I'm nervous about it depending on a hardware trigger (regardless of the Pi version) as that could change, for example, if a jumper gets knocked off, or a wire gets lose, or whatever. So whilst having USBGadget in the code is fine (default off), I don't think USBGadgetPin is a good idea for the main build.

@blixabloxa was talking of linking a USB Gadget Mode switch to the power source to ensure they were always working together. That is great for a custom build, but that won't be part of anyone else's configuration, but it shows the kind of diligence and thought required for, again as @blixabloxa states, " a custom hardware solution for each use case, but perhaps not an elegent power safe solution for all."

For all these reasons I'm not sure having this as a firmware option is a good idea. It just feels like sooner or later someone will fry a Pi... if they do it because they've wired it up wrong, there isn't much we can do, but if they do it because we've changed mode on them without them realising that feels a bit more significant to me.

so that one doesn't have to change the config file every time to switch back and forth between device mode and gadget mode

Which is exactly what I think we /shouldn't/ be allowing - this isn't like the other options. This is not something to switch back and forth with unless you really know what you're doing (in my view). Most USB devices don't change mode like this - they are one or the other.

If we go ahead with USBGadgetPin, then in my view it definitely has to default to OFF to force a "you're on your own, if you break your Pi you get to keep all the pieces" responsibility on the user.

The second point is about how it has been implemented. I don't think having the function GetUSBGadget returning a different value based on a hardware setting is in keeping with how the class works. That logic should really be in the kernel code that checks for USBGadget then we can make the logic explicit, something like:
IF USBGadget THEN...
IF USBGadgetPin THEN...
etc..

Then it is clear to anyone reading the code what the configuration options are and how they will be interacting.

Kevin

[probonopd]

If you feel strongly about it, we can revert it: #673

[blixabloxa]

Hi All,

I understand the cons of having this option available. But couldn't we have a USBGadgetPin=0 or 1 option instead (as probonopd suggests in one of his replies above) with another option to then nominate the GPIO number (default 26). This would make this option no more dangerous than the USBGadget option in my view. Someone has to conciously make this change in the ini file, so user beware.

Also, what happens with a default minidexed (USBGadget=0) when someone plugs in the power USB, and then inadvertantly plugs the other USB of the RPi into a powered computer instead of a passive controller? Does this fry the RPi as well? Is this power issue always there anyway?

Enzo

[blixabloxa]

Hi Kevin,

When I tested the current solution, I disconnected GPIO26 from GND, just to see what happened while the minidexed was powered up. There was no change, and it just continued to work in USB Gadget Mode - so the initial boot state remained. I am not sure if this alleviates your concern about the state of GetUSBGadgetMode changing. I can re-test to confirm this.

This solution you propose looks OK to me. The decision is not mine of course, and I'll leave it to you and probonopd to agree and then to do the coding (I am just a hack at python coding - maybe I should use this as a C++ learning exercise).

Thanks,

Enzo

[diyelectromusic]

Thanks but yes, that is what I'd expect. At the moment it is only checked in two places - on power up and then when reporting the mode to the user. You would have to change it between those two events (or get unlucky and have a glitch).

But if the check is used at some other point in the future elsewhere in the code it could create a window for a really hard to track down and find, unpredictable bug.

My own view is we don't write code that we know has a potential problem, (although unrealised), when we can do it properly with no cause for problems. It is much easier to do it right whilst it is fresh in our minds than have to debug and fix a weird issue in the future because some assumption turns out to be false.

Kevin

[probonopd]

Agree that if we can do it properly, we should. I was implicitly assuming that the decision host/gadget happens only once on startup and didn't even consider that it might change over the runtime. I was thinking in terms of "strapping pins", like many SOCs and MCUs use. After the system has booted, you can do with those pins whatever you want, because they are checked only on boot time for settings that influence the startup.

Do you think you could send a PR for this in the near future @diyelectromusic? Or would you like me to revert the existing solution for now?

[diyelectromusic]

Ok yes - can do. I'll try to take a look later this week.

If I implement as I've suggested then yes, it would be more like a strapping pin anyway!

Kevin

[diyelectromusic]

Just looking quickly now, it looks like it is treated as a strapping pin, being only read on config.load, so maybe the dynamic thing isn't an issue after all (I think the config is only loaded once - I'll need to check).

I still think we should be reporting to the user what is going on though, so if the pin is configured, it is obvious on boot what has or hasn't caused USB gadget mode to be enabled. And I still think it ought not to happen as a side effect of loading the config as I've said previously.

Anyway, as I say, I'll take a look later this week and this time try to read the code properly :)

Kevin

[diyelectromusic]

Ok. So, this wasn't deliberate, but I've just updated the firmware to investigate an issue I'm having with Circuitpython and MiniDexed (that I've asked Rene about) and now have nothing working at all USB wise on my Pi 4...

Then I glance at the screen and see "USB Gadget Mode: Enabled" and I'm like WTF? Really? Sigh, edit minidexed.ini - nothing there...

Then I realise... My Pi 4 MiniDexed PCB uses GPIO 26 for the encoder...

The code currently in our main tree defaults to looking at pin 26 if there is no USBGadgetPin present in minidexed.ini and regardless of the setting of USBGadget. The upshot is that any legacy installation that uses GPIO 26 for anything now might try to enable USB Gadget mode by mistake. As I have just done. And if USBGadget Mode isn't supported on that Pi, will end up disabling USB. And not realise. Thankfully it clicked for me what was going on.

So this is proof to me that this change has to be reverted I'm afraid and done properly with more safeguards and checks.

Sigh... Caught out by my own hypotheticals... that's a new one for me!

Update: I'll start the update from the current main tree (so don't change anything else or my branch will be instantly out of date!) and take a look now :)

Kevin

[blixabloxa]

Thanks Kevin! Looking forward to testing this once there is a test build.

[probonopd]

It's now available at #674. Thanks @diyelectromusic