USB hub support?

Did it make it in for launch?

Very excited about the next generation of Axo/Akso! Amazing work.

2 Likes

Another nice option would be to be able to use both USB ports as host (is that still called OTG with USB-C?).
Would that be possible in firmware, or are hardware changes needed for that?

@spacelordmother Hub support is absolutely critical in the long run.

It is theoretically possible for sure. We at one point had a branch that had it working to the point where I tested using a Behringer BCR2000 and a USB MIDI keyboard at the same time through a hub and it worked really well. That work is not currently enabled in the master branch, but I’m going to do everything I can to try to get it in for launch. If it isn’t there day one it will be soon after. I look at hub support as one of the highest priority things in my development queue.

@Piers USB-C is a bit complex. As I understand it, the concept of OTG no longer exists in USB-C. Every port can technically be dual role, i.e. switch between host and device. Akso’s host port is controlled by an IC that understands how to detect what the role of the connected device is. It also allows the port to change roles dynamically. The host port can easily be switched into another device port using this IC.

The device port does not currently have this IC control and is wired to appear permanently as a device to other compliant USB-C devices. The way power flows in from the device port is also designed with the assumption that the port is permanently a device. You could definitely turn it into a host port with some hardware hacks. Making it a non-compliant USB-C host port for legacy USB devices only would be even easier, but would still require a little hardware hacking.

It’s a design compromise that was made sort of assuming that hub support would exist. It’s going to be most practical to simply keep one port a device and one mostly a host and use a hub to connect multiple peripherals.

1 Like

@nsm Thanks for elaborating. I don’t fully understand USB-C yet, so I’m staying with USB-B for now on the Striso board.

As I understood from Johannes USB hub support is not implemented in the STM hal, and the usbh library from the ChibiOS-Contrib that was in Axoloti at some point (until 2019-10-24) didn’t use DMA, so took way too much CPU power.

Is your plan to use the ChibiOS-Contrib usb framework as is (taking the CPU usage for granted), implement DMA in it, or use some other framework?

I’d suggest to release Akso without hub support first, so it has a stable base and can be thoroughly tested, and have an experimental branch with hub support. Don’t put too many new things in at once! I feel that is one of the things that went wrong with Axoloti development.
And please don’t be shy and put your fork online so we can follow your progress :slight_smile:

Good luck with the launch!

Also note there is a hardware bug in the internal PHY, as mentioned in the Segger emUSB-Host manual:

19.3.2.2
Restrictions
Low-speed devices
On STM32Fxxx and STM32Lxxx MCUs low-speed USB devices connected via an external hub
are not recognized due to a hardware limitation. If connected in this way it may happen,
that the host controller gets disturbed and blocked. In order to return to normal operation,
a reset of the controller and the external hub may be necessary.
The issue seems to be related to the internal PHY of the STM32 MCUs. It usually not occurs,
if the high-speed USB controller is used in connection with an external (high-speed) PHY.

Hey @Piers.

I saw your post on the Daisy forum by the way. You’re exactly correct that my fork runs a recent version of ChibiOS to pick up the various H7 improvements that have been going in. I’m currently running against the stable_20.3.x branch and the associated contrib branch.

In general, I’d like to leverage Contrib as much as possible and only drop into the STM hal if absolutely necessary. You’ll be able to read through my approach when I get the code up.

The H7 has a bunch of complexity around memory regions, caching and DMA that is pretty different from the F4. Dealing with cache coherency is a challenge. The caches are extremely effective for performance on the H7 and need to be enabled so it’s something we have to deal with.

There is even the confusing issue of the revisions of the H7 like Y vs V which I think Giovanni had backwards; I think I saw your posts about that on the ChibiOS forums. I definitely want to try to keep things clean so we’re in a position to contribute back to ChibiOS itself, both main and contrib.

Going to try to get some code up for you to start playing with as soon as I can!