USB IC suggestions

[Saimoun]

Hi

I want to add USB to my project. Say Full speed would be enough, and the device only needs to be a "device" (i.e. not host).
The device will need (among other things) to be USB MIDI class compliant.

Right now my MCU is a GD32E230 and it does not have USB. GigaDevice came up recently with the GD32L233 series which would suit me pretty well but it does not seem to be available on the market (yet?).

I'm actually considering simply using a second MCU (probably an STM32 or a GD32 because it's what I know) to handle the USB stuff, then I can also offload some of work on that second MCU.

My questions:

• Is it a good idea to have 2 MCUs?
• Or do you think it would be better to simply upgrade the MCU for one that has USB capabilities?
• Do you guys have any suggestions/experience with a USB IC chip? The cost matter, so the cheaper the better 

Thank you!
Simon

[ledtester]

You can bit-bang low-speed USB. Here's a MIDI controller made with an atmega328p:

https://www.instructables.com/USB-MIDI-Controller/

A key component is the V-USB firmware from Objective Development:

https://www.obdev.at/products/vusb/index.html

[mon2]

https://github.com/ValleyBell/UsbSerialMidi

https://github.com/nahueespinosa/usb_midi_bridge

https://github.com/tttapa/MIDI_controller/blob/master/doc/MIDI-over-USB.md

[MarkF]

I have used the FT245RL from FTDI in one of my projects.
For me, it just isn't worth all the work and CPU resources to implement a USB stack in software.
I opted for a parallel interface where you just strobe in/out each byte.  An 8-bit data bus and 4 control/status lines.
However, FTDI also has serial interfaces (FT232RL) if you don't have the necessary pin count.

They use to be around $4.50 each.  But, the only place I found that currently has stock is Element14/Newark at $8.00

There is also the SiLabs CP2012N with serial interface.  However, I have not used any of them.

You could just use a USB to TTL Serial Cable.  This one from Sparkfun works well for me.

[janoc]

I have used the FT245RL from FTDI in one of my projects.
For me, it just isn't worth all the work and CPU resources to implement a USB stack in software.
I opted for a parallel interface where you just strobe in/out each byte.  An 8-bit data bus and 4 control/status lines.
However, FTDI also has serial interfaces (FT232RL) if you don't have the necessary pin count.

They use to be around $4.50 each.  But, the only place I found that currently has stock is Element14/Newark at $8.00

There is also the SiLabs CP2012N with serial interface.  However, I have not used any of them.

You could just use a USB to TTL Serial Cable.  This one from Sparkfun works well for me.

I think you have missed the bit that he needs: "... USB MIDI class compliant."

FTDI can do all sort of things - as long as it is a serial port on the host side. Which won't really help the OP at all.

Right now my MCU is a GD32E230 and it does not have USB. GigaDevice came up recently with the GD32L233 series which would suit me pretty well but it does not seem to be available on the market (yet?).

I'm actually considering simply using a second MCU (probably an STM32 or a GD32 because it's what I know) to handle the USB stuff, then I can also offload some of work on that second MCU.

Why? Why the extra complexity, you will need to handle the communication between the two MCUs (plus MIDI is timing sensitive!). Just get an MCU that does all that you need - there are plenty of microcontrollers that have USB interfaces built-in and can handle whatever you throw at them on top of talking to the host over USB.

If you want a GigaDevice chip, e.g. the GD32F103 series (clone of STM32F103), GD32F303 or DF32F330 series would certainly do the job - and have more resources than the E230.

[janoc]

You can bit-bang low-speed USB. Here's a MIDI controller made with an atmega328p:

https://www.instructables.com/USB-MIDI-Controller/

A key component is the V-USB firmware from Objective Development:

https://www.obdev.at/products/vusb/index.html

Please, no.

This is a wonderful hack - and a total nightmare to actually make work somewhat reliably when connected to various hubs and host controllers because it is not USB spec compliant.

Moreover, it is only a low speed device, so you won't have a bulk endpoint available, for example. Doing it only using interrupt endpoint type is unsuitable for anything else but a simple midi controller that doesn't transfer much data. Which doesn't really matter much because the ATMega is pretty much unable to do anything else useful but service the USB bus anyway ...

[pigrew]

My questions:

• Is it a good idea to have 2 MCUs?
• Or do you think it would be better to simply upgrade the MCU for one that has USB capabilities?
• Do you guys have any suggestions/experience with a USB IC chip? The cost matter, so the cheaper the better 

I usually wouldn't like the two MCU solution. For full speed I'd much rather one MCU doing everything.

There are many application-specific USB interface IC which simplify the design, but only if you're using a standard USB protocol. Overall cost will be higher with two IC versus one.

E.g., for USB CDC (serial port), CP2102 is an option. FTDI sells other models like the FT232. Using the USB stack integrated into the MCU will add substantial software complexity versus a standalone USB IC. For HID protocol, you'd choose a different IC.

CH345 is the only MIDI IC that I notice... but it might not fit your particular application. For MIDI, using a MCU is likely best.

If you must use a particular MCU that doesn't have USB, then it can make sense to use a second MCU for USB, but that adds complexity and latency (due to the communications between the two MCU). You may also want to use USB MIDI 2.0, which could further restrict your selection of MCU (if you're looking for pre-written MIDI libraries).

The STM32 (and clone) MCU are reasonable solutions. RP2040 might also be an option. Other MCU (like SAMD or cypress or TI MSP430) will likely be more expensive. It'll likely be cheaper to use a chip with a "clockless" USB peripheral (if you don't otherwise need a crystal). the ESP32-S2 IC is also inexpensive (especially if you need wireless connectivity). If you're doing this in quantities >10k, then you probably can get a reasonable deal on any MCU you choose.

-Nathan

[wizard69]

   

Is it a good idea to have 2 MCUs?

There is only one answer here, it depends!
   

Or do you think it would be better to simply upgrade the MCU for one that has USB capabilities?

If you can get a USB stack for that upgraded micro controller then yes.   If not consider a canned USB interface solution like an FTDI.
   

Do you guys have any suggestions/experience with a USB IC chip? The cost matter, so the cheaper the better 

Pretty much the only thing I've had experience with is FTDI and that is slim at best.   I'm a bit old fashion and prefer old fashion RS232 for simple hardware.

Back to your original question about multiple processors, that is a question that takes lots of engineering thought.    As you may know these days it is extremely easy to buy SoC type processors with all sorts of cores in them.   Obviously there is a market for such chips.   Just realize it can be extremely difficult to get a system up and running well with multiple CPU's unless you implement preexisting software solutions.    That is operating systems and libraries.

On the flip side keeping a project simple, especially for home projects, makes a project much more likely to happen and be successful.  This strongly suggests a single CPU core.   In the end it really comes down to what you are off loading from one CPU to another.   For example say you are building a CNC controller with parallel PLC functionality, it can make lot of sense to run these two "processes" on separate cores.   Those cores can be on separate chips or on a SoC.

[SiliconWizard]

I would consider using TinyUSB. I have used it for implementing two USB Midi devices, and it was rather a breeze (IMO). Also makes porting to a different (supported) MCU very easy.
So you can have a look at the supported MCUs to make a choice.

The RP2040 certainly works fine for this purpose, this is for one of the devices I made. And it's cheap. Now, I don't know the quantities you need and whether this will be available in those quantities, and for how long.

[SiliconWizard]

Oh, and FTDI is cool, but they do not provide any chip that can allow you to customize the device class. So USB Midi is out of the question with any FTDI chip. Except maybe their microcontrollers (yes, they do have MCUs with integrated USB), but those use a proprietary core, and so are kinda oddball and not particularly cheap.

[Saimoun]

Thank you all for the replies!! Awesome, very useful info as always   

I can see why most of you are against the idea of having 2 MCUs. Ironically your answers actually convinced me this is the way to go 
Let me give you a bit more context (for simplicity I'll call MCU 1 my main MCU and MCU 2 the MCU handling the USB):

• MCU 1 doesn't do anything complicated code-wise (like USB, WiFi, graphics, or DSP f.x.)
• Timing is very important on MCU 1 (unlike the USB-side which does not need to be as precise)
• Because of the first 2 points, the code on MCU 1 is all "bare metal": I'm not using any lib, I configure all peripherals directly and even a (small) part of the code is written in Assembly for optimisation
• Thanks to that I'm actually beating my competitors by a ton performance-wise, and I can get a small not-powerful <$1 MCU to do it

Hence my idea of having a second MCU:

• That would save me tons of work re-writing/adapting the whole code for a different MCU
• I would not have to worry about optimisation on the code of MCU 2
• I could implement USB relatively fast using a lib like TinyUSB (thanks for the tip!)
• It's so hard nowadays to find an MCU that is in stock - I know I'm very stuck with my current MCU 1 (but for now the GD32E230 series seems very available), but at least for MCU 2 I can easily change if I need to, thanks to the use of the library

Then the communication between the 2 MCUs could be very simple, f.x. UART:

• like I said above timing on the USB commands is not an issue - besides MIDI is UART so all it would add is a (tiny) bit of latency, or have I missed something?
• how is that so complicated? On MCU 1 I'll simply handle UART with an interrupt - much simpler than having to add a whole USB stack. And on MCU 2 it's just converting the MIDI messages into UART and vice-versa. Or have I missed something here as well?

And yes a standalone IC like the CH345 would be perfect, but I am also considering adding firmware update over USB. Which I think (please correct me if I am wrong) is easier when you have a second MCU handling the USB? The MCU 2's code will not need to be updated, as it will simply "forward" the commands, and then it can connect to the SWD interface of the MCU 1.
(just like most of the STM32 development boards for example, with an STM32F103 acting as an ST-Link connected to the main MCU's SWD interface)

So unless I am wrong all is left is to find a decent MCU 2! 
-> RP2040 looks good - and yes that price is insane for the amount of power - but it needs a separate flash chip tho?
-> I'm trying to stay away from the xx32F103 series since this chip is so demanded... $22 for 1 sample no thanks   
-> Ideally I'd like a GigaDevice to stay in the same brand, but TinyUSB does not list them as supported - so I'll probably end up with an STM32

Thank you all again - I'll keep searching and updating here. If you have anything to say about my little debate I'll happily hear it! 
Simon

PS: Apologies for not giving the whole picture before - I think I needed to read your answers to get it clearer in my head

[HwAoRrDk]

And yes a standalone IC like the CH345 would be perfect, but I am also considering adding firmware update over USB.

Even if your USB interface is limited to MIDI like with such a chip, could you not do firmware updates over SysEx? I believe a lot of other audio equipment does that.

[Saimoun]

Even if your USB interface is limited to MIDI like with such a chip, could you not do firmware updates over SysEx? I believe a lot of other audio equipment does that.

Oooh that's a good one! Did not think about that, it would for sure reduce dev time a lot!

Problem is then to find a decent MIDI-USB Class Compliant USB IC - here f.x. https://electronics.stackexchange.com/questions/87601/implementing-a-class-compliant-usb-midi-device
one person mention the CH345 to be buggy.

[pigrew]

While certainly possible, I've never seen JTAG used for a product updating its firmware. The more common approach is a USB bootloader using USB DFU. Getting JTAG up and running might be a pain... not sure. The STM32 has a UART bootloader in its ROM, which would be much easier to use, and many MCU will also have a USB bootloader in their ROM. But... what about updating the USB MCU's firmware in the field?

Full speed USB will have a latency of up to about 1.3ms. If you run your communications bus between MCU fast enough (maybe 1 MHz?), that latency would be insignificant compared to the USB latency.

USB timing does matter. Some actions have to be taken within 10ms (e.g., reset recovery time), and many control requests have to be complete within 50ms.

The complexity of two MCU design is defining your protocol between the MCUs, including figuring out the race conditions that could exist in the communications.

I think using two MCU also means that you'll have more supply chain issues. Sourcing two things should be harder than sourcing a single thing. The RP2040 is hard to substitute, but at the moment has good availability, and likely is not going to be used in so many commercial products.

[Saimoun]

While certainly possible, I've never seen JTAG used for a product updating its firmware. The more common approach is a USB bootloader using USB DFU. Getting JTAG up and running might be a pain... not sure. The STM32 has a UART bootloader in its ROM, which would be much easier to use, and many MCU will also have a USB bootloader in their ROM. But... what about updating the USB MCU's firmware in the field?

I meant SWD not JTAG - just like the ST-Link updates the software on another STM32.
As for updating the USB MCU's firmware - that's the bit I really like, it won't be needed because none of the logic will be in that MCU, it will just be a "dumb" USB to UART/I2C/anything converter. Yes that does not include firmware bugs - but hopefully it will be simple enough we find most of them before manufacturing the product.

Full speed USB will have a latency of up to about 1.3ms. If you run your communications bus between MCU fast enough (maybe 1 MHz?), that latency would be insignificant compared to the USB latency.
USB timing does matter. Some actions have to be taken within 10ms (e.g., reset recovery time), and many control requests have to be complete within 50ms.

Gosh that is slow    I guess I do not know enough about USB, but even a basic UART at 50kHz will only take 0.5ms to transfer 3 bytes + a few microseconds for the MCUs to receive/send. So I think it will be fine latency-wise?

And how come FS USB running at 12Mbps has such a long latency?

[pigrew]

I meant SWD not JTAG - just like the ST-Link updates the software on another STM32.
As for updating the USB MCU's firmware - that's the bit I really like, it won't be needed because none of the logic will be in that MCU, it will just be a "dumb" USB to UART/I2C/anything converter. Yes that does not include firmware bugs - but hopefully it will be simple enough we find most of them before manufacturing the product.

It's a bad habit of mine to call SWD as JTAG... I still would look into the ROM bootloaders instead of SWD....

And how come FS USB running at 12Mbps has such a long latency?

USB has bidirectional data wires. The protocol has the USB host initiate communications every 1ms, and there is no way for the USB device to initiate communications. One advantage of this is that there will be no collisions. High speed USB allows a microframe every 125us, providing reduced latency.

[Saimoun]

It's a bad habit of mine to call SWD as JTAG... I still would look into the ROM bootloaders instead of SWD....

I see Yes the bootloader option might be simpler, especially if the "USB MCU" (MCU 2) is already connected to the UART anyways! To use the bootloader I simply need a way to switch that Boot0 pin, thinking maybe it could be pulled down by say a 100k resistor (to avoid floating under start), and at the same time driven by the USB MCU to be able to pull it high?

Thanks about the explanation about the FS USB speed.

Regarding the choice of MCU 2, I am pretty convinced on either a GD32F150, a GD32E103, a STM32F070, or one of the famous xx32F103. The idea is to write a code that would work on any of these - so I can use whatever is most available and cheapest at the production time.

So right now I am just learning tons of about USB and the stack, trying to understand the overall picture. Then I guess I'll start with the code from TinyUSB, they do not support officially GD32F150 but I'm hoping I can adapt things to make it work.

[ledtester]

Re: using the FT232 ...

On physical page 33 of this PDF there is a design idea for using the FT232BM as a USB <-> MIDI interface:

https://www.edn.com/wp-content/uploads/EDN_Design_Ideas_2008.pdf

The article mentions that there are drivers available to treat a serial port as a MIDI device.

[Saimoun]

@ledtester: thanks this is a great idea - but class compliance is a requirement for me.


Update on the progress:

• I took a deeper look into USB MIDI hardware, but it seems the CH345 or the MFM0860 are pretty impossible to get? I could not find any other USB-MIDI IC.
• Second option is the MCU way. I have been looking at my choice of MCU (GD32F150, GD32E103, GD32L233, STM32F070, or any xx32F103), and good news is they all use the same registers! All located at the same place in memory and literally identical.

So the plan is for now to experiment with TinyUSB on a blue pill (STM32F103) and then port it (which should not be too hard since they all use the same registers) to whatever MCU I end up using on the final board.

Problem is there is not much documentation with TinyUSB... ? Might create a new topic for that.

[MarkF]

If all you're trying to do is connect your MIDI device to a computer via USB, I use an MIDI interface from Roland (my model is discontinued). 
Their cheapest is probably the UM-ONE mk2 USB MIDI Interface.




The programming is pretty easy if you use DirectMusic on Windows to do the grunt work.  After that it's just getting the Note On/Off and the Control messages.
Re: A Work-In-Progress Raspberry Pi-based MIDI Sequencer & Controller!

[fchk]

TI TIVA seems to have rather good availability right now. Suggestion:

https://www.digikey.de/de/products/detail/texas-instruments/TM4C123FE6PMI/4036454
863 pieces available.

https://www.ti.com/lit/ds/symlink/tm4c123fe6pm.pdf

Has everything you need, including OTG USB and lots of UARTs. TI has got a good driver library and an own USB stack for use with it's CCS IDE/compiler.

You should really consider buying stock for the amount you are going to need within the next two years.

fchk

[Saimoun]

And how come FS USB running at 12Mbps has such a long latency?

USB has bidirectional data wires. The protocol has the USB host initiate communications every 1ms, and there is no way for the USB device to initiate communications.

I have now read a lot about USB, and actually the above is only true for the interrupt transfer type.
MIDI over USB uses Bulk transfer types, which happens as often as possible (as long as it does not go over the other transfer types).
In an empty USB bus (f.x. just my device and the host), that would be about every 125ns.

@fchk: thanks for the tip. Price is way above the GD32F150 tho 

@MarkF: thanks, but the device itself needs to have USB.