Yes, it has support for USB OTG HS but it does not have an on-chip HS PHY.
This is from the datasheet:
"The devices embed a USB OTG high-speed (up to 480 Mb/s) device/host/OTG peripheral. The USB OTG HS supports both full-speed and high-speed operations. It integrates the transceivers for full-speed operation (12 MB/s) and features a UTMI low-pin interface (ULPI)
for high-speed operation (480 MB/s). When using the USB OTG HS in HS mode, an external PHY device connected to the ULPI is required."
This is from the datasheet:
"The devices embed a USB OTG high-speed (up to 480 Mb/s) device/host/OTG peripheral. The USB OTG HS supports both full-speed and high-speed operations. It integrates the transceivers for full-speed operation (12 MB/s) and features a UTMI low-pin interface (ULPI)
for high-speed operation (480 MB/s). When using the USB OTG HS in HS mode, an external PHY device connected to the ULPI is required."
Reading.. it seems the 723 & 733 series has in inbuilt integrated HS PHY in the IC but the 722 and 732 do not. Thank you for that careful clarification.
The 723 has 256KB of flash and the 733 has 512KB. The STM32F723E-DISCO seems to be the only evaluation/discovery board that has a integrated USB HS PHY but requires manual hacking to get the i2s lines. The nucleo boards are FS/ext HS PHY.
The question I have is - it sounds possible to develop for a external HS OTG PHY initially but to take the integrated PHY at a later date. I can see that the external PHY brings 60MHz signal out but I suspect that shouldn't create noise and the external PHY safeguards the chip. At least this option means it should work whilst there's a shortage of ICs.
That is unless you need to low-level program the PHY registers.
The 723 has 256KB of flash and the 733 has 512KB. The STM32F723E-DISCO seems to be the only evaluation/discovery board that has a integrated USB HS PHY but requires manual hacking to get the i2s lines. The nucleo boards are FS/ext HS PHY.
The question I have is - it sounds possible to develop for a external HS OTG PHY initially but to take the integrated PHY at a later date. I can see that the external PHY brings 60MHz signal out but I suspect that shouldn't create noise and the external PHY safeguards the chip. At least this option means it should work whilst there's a shortage of ICs.
That is unless you need to low-level program the PHY registers.
Last edited:
Unfortunately all STM32 evaluation boards have limitations regarding UAC2 development. I used STM32F723E-DISCO initially for UAC2 SW development at USB HS but testing was limited to UAC1 speeds as I did not want to hack the board. I found it easiest to design my own board for more serious UAC2 development.
BTW most STM32F7/H7 MCUs have been out of stock for a long time. Suppliers cannot even provide shipping estimates currently for these.
BTW most STM32F7/H7 MCUs have been out of stock for a long time. Suppliers cannot even provide shipping estimates currently for these.
With the 723 supporting HS OTG it leaves only the UAC2, I know the CUBE supports AC1 so I assume you had to write UAC2 against the inbuilt codec.
That would do for the first step to get me up and running, then unmount the ball array and tack in a shielded cable for the i2s.
?? https://elixir.bootlin.com/linux/v6.0/source/drivers/usb/gadget/legacy/audio.c#L20
That means if not selecting CONFIG_GADGET_UAC1, you will get UAC2 (details e.g. https://elixir.bootlin.com/linux/v6.0/source/drivers/usb/gadget/legacy/Kconfig#L75 )
Actually UAC2 is the preferred one, the UAC1 gadget function has some features missing (e.g. multirate) as it's considered a bit outdated. Also the g_audio module with its hard-coded composition of gadget functions is legacy and kernel USB admins frown upon accepting new features for it. It's OK for a single-function gadget, but IMO advanced users will want to explore audio + network to give users a web interface for advanced configuration/updates etc. The up-to-date way is configfs instead (e.g. http://trac.gateworks.com/wiki/linux/OTG#ConfigFs or many other examples).
You will need to have dwc2 configured properly too (takes DTS + some configs). The by far most reliable method is using rpi kernel >= 5.18y https://github.com/raspberrypi/linux/tree/rpi-5.18.y , no kernel config changes required for a fully working dwc2 + g_audio with compiled-in f_uac2.
Or the STM32 path if you do not need a complex SW stack with networking/BT/etc. and/or advanced DSP between USB and I2S.
The issue with 5.18.y is that it breaks wifi. This is the second attempt at this. If I hook up a monitor and keyboard I then uname -a returns that it's 5.18 64bit kernel running. However attempting to start the wifi on either RPI4 or Zero2W fails. Switch SD card to a RPI distributed build and wifi works. This is the original reason for abandoning an alsa based solution. So it's not quite as straight forward as it seems. From previously building we debugging it appears that the RPI gets an IP address then the wlan interface is pulled down and can't be found from that point onwards.
I agree that ALSA-based linux solution allows DSP and cross domain (ie streaming over TCP/IP) however it requires an RPI4 or something with grunt. I've had this working with UAC1 and an RPiOS image with the RPI Zero2W having stuttering issues. The RPI4 keeps up. The zero could possibly the solution that everyone would love but it's not thanks to Broadcom.
So this is looking like an STM32 option is the way to go - not because linux can't do it but because of issues with RPi and 5.18.y builds (the RPiOS is a far earlier 5.x base version of the linux tree) that makes it a pain to develop on. It may be a code and test over serial but it seems to be less flaky than RPi.
Pavel, maybe I'm just tied after a hard day at work limiting my patience but the configuration for linux/UAC2 seems a little complex if you're attempting to rely on the internet hence it's not really making room much sense - I can see configfs and it's a directory configuration but I've not seen a OTG example of UAC1/2.
I agree that ALSA-based linux solution allows DSP and cross domain (ie streaming over TCP/IP) however it requires an RPI4 or something with grunt. I've had this working with UAC1 and an RPiOS image with the RPI Zero2W having stuttering issues. The RPI4 keeps up. The zero could possibly the solution that everyone would love but it's not thanks to Broadcom.
So this is looking like an STM32 option is the way to go - not because linux can't do it but because of issues with RPi and 5.18.y builds (the RPiOS is a far earlier 5.x base version of the linux tree) that makes it a pain to develop on. It may be a code and test over serial but it seems to be less flaky than RPi.
Pavel, maybe I'm just tied after a hard day at work limiting my patience but the configuration for linux/UAC2 seems a little complex if you're attempting to rely on the internet hence it's not really making room much sense - I can see configfs and it's a directory configuration but I've not seen a OTG example of UAC1/2.
Last edited:
If you hit problems, please report a github issue to the RPi people. 5.18.y (and newer) has been used by a number of users, just for the uac2 gadget installations. Maybe they do not use wifi, personally I use ethernet for RPi development, just plugging a cable is faster than fussing with wifi configuration for me.
The u_audio module is fine, just it's in maintenance mode, no new features. It's basically a hard-coded composite device configuration with single function, the very same can be achieved with a few lines of configfs. Configuring f_uac2 is same like any other function, the function params are https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/configfs-usb-gadget-uac2
The configfs advantage is e.g. you can change your USB IDs, device names etc.
But for plain USB - I2S bridge the STM32 path makes more sense, IMO.
The u_audio module is fine, just it's in maintenance mode, no new features. It's basically a hard-coded composite device configuration with single function, the very same can be achieved with a few lines of configfs. Configuring f_uac2 is same like any other function, the function params are https://github.com/torvalds/linux/blob/master/Documentation/ABI/testing/configfs-usb-gadget-uac2
The configfs advantage is e.g. you can change your USB IDs, device names etc.
But for plain USB - I2S bridge the STM32 path makes more sense, IMO.
Also - generating the async feedback value in a microprocessor code is relatively simple as it can be directly related to fill level of the output FIFO. If the playback part is decoupled by many buffers and async processes like in an OS, relative capture/playback speed must be measured which is complicated and difficult to make robust. An example implementation is in https://github.com/HEnquist/camilladsp or https://github.com/alsa-project/alsa-utils/tree/master/alsaloop . Again - if you do not need the DSP, the RPi way is not the best idea.
I've used CamillaDSP on a Moode RPI, and my simple early attempt with RPi with linux used alsaloop to bridge to a driver for GPIO i2s. I see your point - the more queues (buffers) the harder a e2e feedback system to regulate is. All each section can do is regulate from/to it's local queues. If done right with thresholds this should maintain or smooth but that will not guarantee faultless playback or sampling.
Agreed - this is looking like the best option is the STM32. It allows stripping down of interrupts and bus contention. Although the achilies heal is minimal stock is available for creating your own boards hence the hacked discovery board which is all the fun of SMT hacking, lifting pins and soldering fine wires with bridge supports to prevent them from snapping. From the board photos the STM32 is legged, although the codec is a ball array - one needs to be hacked to get the signals and prevent the codec from disrupting the i2s bus.
Anyways it's going to be another 8 hours before I can look at this again. In the meantime I have the fun of telling two directors they need prioritise demand for a shared engineering team between themselves.. and it's my 8th day on the job.
No. The ST-Link MCU (STM32F103?) is legged but actual STM32F750 MCU is a ball array. But I2S (or SAI) is available on various GPIO pins. One alternative is SAI1_B at PF6-PF9 as those pins are available through Arduino connectors.
Well I've been playing with the STM CUBE IDE - this looks like a decent attempt at being an ide by a vendor.
I like the concept that you can sort out the pin parameters, assign and then generate code. I'm using the latest version - USB OTG HS and FS, i2s, i2c and UAC1 available from scratch. I've had a quick look at the code generated and it seems reasonable as a stub starting point for a STM beginner. I also found the alt-pin functions too which is pretty useful.
So the DISCO STM has onboard flash and ram, but also PSRAM. Is this mapped automatically into the address space if enabled?
I like the concept that you can sort out the pin parameters, assign and then generate code. I'm using the latest version - USB OTG HS and FS, i2s, i2c and UAC1 available from scratch. I've had a quick look at the code generated and it seems reasonable as a stub starting point for a STM beginner. I also found the alt-pin functions too which is pretty useful.
So the DISCO STM has onboard flash and ram, but also PSRAM. Is this mapped automatically into the address space if enabled?
Thankyou. I’m going to put an order in for the discovery board along with a few extras.
F412 is HS only. Tiny usb run on the F412, is seen as UAC2 by W11 driver and I have used a 16.16 feedback value for the async mode. This sounds like UAC2, but to be honest I'm not sure it is realy. Question behind this is does UAC2 require a FS link (USB2) or can it run, with speed limitation, on a HS link ?
Have just took a look at F412 datasheet. F412 appears not to support external HS PHY, embedded FS only. So my previous question was incorrect. So F412 cannot be used in HS applications.
UAC2 can be implemented by means of either FS or HS. But HS gives speed advantage over FS allowing to support high frequency / bit depth audio streams. UAC2 with FS makes no much sense.
My bad, I swapped FS and HS. So F412 is FS only not HS.
Good to have confirmation that UAC2, with speed limitation, can run on FS. It confirms that the tests I've made with Tiny USB have a positive result.
Good to have confirmation that UAC2, with speed limitation, can run on FS. It confirms that the tests I've made with Tiny USB have a positive result.
That's an interesting platform / environment !.
On electro-smith GitHub, picture of the board shows that the MCU is a STM32H750IBKx, x is 5 or 6. after checking only 6 exists.
This MCU has 2× USB OTG interfaces (1FS, 1HS/FS), but no High Speed PHY , you'll need to add an external PHY such as STULPI01B or USB3300 to reach USB2 High Speed compliance.
On electro-smith GitHub, picture of the board shows that the MCU is a STM32H750IBKx, x is 5 or 6. after checking only 6 exists.
This MCU has 2× USB OTG interfaces (1FS, 1HS/FS), but no High Speed PHY , you'll need to add an external PHY such as STULPI01B or USB3300 to reach USB2 High Speed compliance.