USB OTG between microcontrollers

[tszaboo]

Hello,
Yesterday I had an idea, about connecting microcontrollers together with USB. Now, the OTG standard allows it to be host or slave. Cheap micros like the STM32F401 or PIC32s have OTG, and the CDC could make them work as it is a serial port. There is code for the host and the slave operation for the same micro, but this should work between different families and the host could be easily replaced with a PC or a RPi or similar SBC.
Now, the next step would be to use USB hubs to connect more than two microcontrollers together.
This opens endless possibilities. Basically boards could be chained, or connected together with just a standard USB HUB.
Backplanes could be implemented by using these protocol, where only two pins and standard libraries could take care about the entire communication, hot swapping it, timing it, arbitration and so on.
Hardware wise it is cheaper than using any serial communication protocol because a hub chip is cheaper than the next best thing, a 485 transceiver.

So my question is: Did anyone ever did this? Is this firmware-feasible? I don't see too much issues with the hardware side, but what is your opinion?
I see a lot of potential in this architecture.

I know that tablets and other consumer products use USB internally to connect stuff, I'm wondering if this can be adopted to the industrial/instrument environments.

[Psi]

Implement your own multihost SPI protocol. Or even use I2C.
It will be much faster, cheaper and easier than trying to talk USB between micros.

Ya dont want to deal with the USB stack and overheads unless you have no choice.

A USB based mcu -> mcu link is like having a ADSL network link between two computers in different rooms of your house. 

[6thimage]

It's possible - I remember seeing a cubesat which used a lot of USB internally at a failed attempt to make things easier.

Although USB hubs are cheap, you need to design a host that can enumerate all of the attached devices (I'm guessing USB microcontrollers have limits on the number of devices they can connect to). Then you have the issue that the host has to control all transfers, which leaves you in a situation of USB being a faster, but significantly more complicated, equivalent of I2C or CAN. So unless you require the faster speed, it's not worth the effort. And if only one device requires a faster speed, then why not use SPI for it and I2C for the rest?

If all you are intending to use the USB for is CDC, then I2C or CAN are going to save you a lot of headaches.

I don't know of any tablets that use USB internally - laptops sometimes use USB for the touchpad and card reader, but that's about it. Tablets and phones tend to use interfaces that have very little overheads, as it saves space and power. As for industrial use, CAN or RS485 tend to be used - price is not really a concern and hot-plugging definitely isn't. One of the main advantages of CAN is the built in CRC and I've seen quite a few applications where the messages are sent in fixed timeslots - which couldn't really be done with USB.

[Rerouter]

Another vote for canbus over USB, and when your talking less than 2m, you can really pump up the speeds, even the common MCP2515 can handle almost 3mbps at those distances, which for a mult drop network is hard to beat, (yes it looses performance over 485, but the collision detection and similar make it a nice tradeoff)

[tszaboo]

Yeah, I'm familiar with CAN, 485, or SPI. I've learned to hate CAN over the last few years. 485 is the protocol that I'm liking for communication between microcontrollers, but that only gives you the basics, everything else ha to be implemented by the firmware. I have worked with several SPI implementation, whatever the application called for, SPI has speed/distance limit, also it stops working if there is a slight ground difference between the boards.
If CDC is used you can pretty much connect any slave to the master which has standard CDC implementation. Like imagine connecting PIC24 a MSP430 and a STM32 (being the master) in the same system. USB slave stacks work out of the box. I2C is just plain slow, I rarely use it to anything else than housekeeping.
The endpoint/number of slaves limitation is a good point, I have to look into it.
And hardware cost wise the USB has a great advantage. There is a PHY is in every chip, even high speed in some newer micros.

[technix]

I have learned to like I²C with SMBus address resolution protocol thrown in as it is really versatile when networking up a whole bunch of micros. Backplane support isn't that difficult and since everything speaks SMBus ARP there is no worry of address collision. Long runs can also be achieved using Cat5e over four twisted pairs sending differential signals.

[mazurov]

The overhead of using USB is prohibitive. Here's the host implementation providing the bare minimum (designed to fit into standard Arduino) -> https://github.com/felis/USB_Host_Shield_2.0 , the MAX3421E SIE-specific piece is in usbhost.h (and we are developing 3.0 which will work on other SIE), the rest is what you must have in your micro to be able to send a single data byte to your peripheral.

SPI has no speed limit; distance/ground issues are fixable with (opto) line drivers. By itself, USB won't give you anything but the basics either, CDC is the same raw data transfer. If you like the USB _bus_ that much - standalone USB transceivers are available.

[nctnico]

Hello,
Yesterday I had an idea, about connecting microcontrollers together with USB. Now, the OTG standard allows it to be host or slave. Cheap micros like the STM32F401 or PIC32s have OTG, and the CDC could make them work as it is a serial port. There is code for the host and the slave operation for the same micro, but this should work between different families and the host could be easily replaced with a PC or a RPi or similar SBC.
Now, the next step would be to use USB hubs to connect more than two microcontrollers together.

It is an interesting idea but the requirement to support a USB hub will prove to be problematic.

[JTR]

It is an interesting idea but the requirement to support a USB hub will prove to be problematic.

This ^^^^

However if you dropped the hub idea then you could use the USB SIEs with your own protocol (or complete lack of one...) All of a sudden you have something that actually has a lot going for it, if you have the smarts to get a "PIPE" up and running without all the enumeration crapola that is not needed for point to point nodes of known quantity. You don't even need SOF, suspend etc.

Have not done this myself yet but I have thought about it often. Cannot (yet) see why it is not very doable and have advantages over I2C and SPI etc...

 

[tszaboo]

It is an interesting idea but the requirement to support a USB hub will prove to be problematic.

This ^^^^

However if you dropped the hub idea then you could use the USB SIEs with your own protocol (or complete lack of one...) All of a sudden you have something that actually has a lot going for it, if you have the smarts to get a "PIPE" up and running without all the enumeration crapola that is not needed for point to point nodes of known quantity. You don't even need SOF, suspend etc.

Have not done this myself yet but I have thought about it often. Cannot (yet) see why it is not very doable and have advantages over I2C and SPI etc...

Yes, the hub was the part I wasnt so sure about. After reading into it, I think the USB host hardware inside a 100 Mhz category microcontroller isnt going to support more than 1 devices connected. While there are USB switches, that is not something I would like to go into.
So I guess the HUB idea only works if the host is a raspberry pi or something similar higher performance system.

USB is usually the only differential communication on micros which has built in PHY. It should send 12 Mbit over 10m+ cables, which is definitely better than SPI or I2C, it uses standard cheap cables, and power is also provided. I tend to use standards if possible, makes your life easier on the long run.

I'll experiment with 2 mircos. It is just a matter of getting a second STM32discovery board.

[mikeselectricstuff]

If all you want is a fast link between two MCUs then an option might be to not use the USB higher level protocols and just send raw packets.
Ditto ethernet.
But unless you really need the speed, or the USB comes nearly free with the part, something RS485 or CAN is going to be orders of magnitude simpler to do and simpler to debug.
 

[Jeroen3]

(Ab)using the USB peripherals just for the differential drivers and (dma) buffers might work out.
It has less wiring than a parallel bus. And might be easier than paralleled spi.

[westfw]

just send raw [USB] packets.

Now THAT's an interesting idea.  Has anyone done it? Are there any published examples out there?  Do you even need a USB "host" side?

[tszaboo]

just send raw [USB] packets.

Now THAT's an interesting idea.  Has anyone done it? Are there any published examples out there?  Do you even need a USB "host" side?

I believe the closest to "raw" packets is the USB bulk. I dont think you can just load 64 bytes of data into the memory and send it through USB like with SPI. I've checked the PIC32 Family Reference Manual as an example:

1. Software pre-initializes the appropriate BDs, and sets the UOWN bits to ‘ ’ to be ready for
a transaction.
2. Hardware receives a TOKEN PID (IN, OUT, SETUP) from the USB host, and checks the
appropriate BD.
3. If the transaction will be transmitted (IN), the module reads packet data from data memory.
4. Hardware receives a DATA PID (DATA0/1), and sends or receives the packet data.
5. If a transaction is received (SETUP, OUT), the module writes packet data to data memory.
6. The module issues, or waits for, a handshake PID (ACK, NAK, STALL), unless the endpoint
is setup as an isochronous endpoint (EPHSHK bit UEPMx<0> is cleared).
7. The module updates the BD, and writes the UOWN bit to ‘ ’ (SW owned).
8. The module updates the U1STAT register, and sets the TRNIF interrupt.
9. Software reads the U1STAT register, and determines the endpoint and direction for the
transaction.
10. Software reads the appropriate BD, completes all necessary processing, and clears the
TRNIF interrupt

The emphasis is on the Hardware in the second point. Part of the message is handled by the hardware, which prevents us from doing any low level hacking. I think the reason for this is the simple fact, that 12mbit is already too much for a microcontroller.

[mikeselectricstuff]

Even so , as long as you have host & device functionality, it ought to be possible to do something a lot simpler than using a whole USB stack.

[Howardlong]

Can the OP define a bit more accurately what they need?

O Multimaster or single master
O Speed required
O Physcial scope (within a single physical device or distrubuted between several devices at maximum distance x)

Trying to massasge USB to do something it doesn't want to is going to be difficult because here are many different approaches to implementing a USB stack, and where the hardware/firmware boundary lies as you've found.

[westfw]

12mbit is already too much for a microcontroller.

Not if all you want to do is something like 2-endpoint XMODEM.  Send an ACK, have a lump of data appear in the HW buffer memory.
There are times I'd love to have a "lump oriented" data transfer between two micros, rather than the usual byte-oriented interface.  The USB peripherals with their dedicated buffers come pretty close, even on chips that don't have any other DMA capability.  (OTOH, if you DO have DMA, you ought to be able to get this from any standard peripheral.)

[tszaboo]

Can the OP define a bit more accurately what they need?

O Multimaster or single master
O Speed required
O Physcial scope (within a single physical device or distrubuted between several devices at maximum distance x)

Trying to massasge USB to do something it doesn't want to is going to be difficult because here are many different approaches to implementing a USB stack, and where the hardware/firmware boundary lies as you've found.

I'm just exploring the possibilities of using USB in an emedded system. There isnt an immediate application I'm trying to use this.
Single master of course.
12Mbit/Full speed
Good question. I could see this happening between just two boards, or daisy chained with every board having a hub, or a backplane, where a backplane has the hubs.
Right now, I see two possible implementations, which should work:
1. The master is a RPi or other SBC, which can handle more slaves.
2. it is used between two microcontrollers, both of them having CDC stack implemented.

[technix]

Can the OP define a bit more accurately what they need?

O Multimaster or single master
O Speed required
O Physcial scope (within a single physical device or distrubuted between several devices at maximum distance x)

Trying to massasge USB to do something it doesn't want to is going to be difficult because here are many different approaches to implementing a USB stack, and where the hardware/firmware boundary lies as you've found.

I'm just exploring the possibilities of using USB in an emedded system. There isnt an immediate application I'm trying to use this.
Single master of course.
12Mbit/Full speed
Good question. I could see this happening between just two boards, or daisy chained with every board having a hub, or a backplane, where a backplane has the hubs.
Right now, I see two possible implementations, which should work:
1. The master is a RPi or other SBC, which can handle more slaves.
2. it is used between two microcontrollers, both of them having CDC stack implemented.

Since you are already using CDC, why not just run UART over RS485 or RS422 at a higher baud rate in the first place?

[Esposch T. Tapir]

I've been doing a bit of USB stuff recently, and it is an absolute nightmare.
The protocol is overly complex and you will have to read hundreds of pages of documentation (USB Complete by Janet Axelson is recommended by quite a few people and is a fantastic alternative to the official spec) just to figure out how to send a single 64 byte packet.

If you run CDC on both host and device this should simplify things a bit, but it will still be orders of magnitude harder than something like I2C or RS232.
If you're dead set on USB, isochronous vendor might work better for some purposes than CDC.  Can get 500kB/s each way with guaranteed latency of 1ms.

If you use the PHY to enable your own protocol (as Mike was suggesting before) it could be fun, although I suspect that this'd be painful!

Still, though, due to the ridiculous complexity and overheads, I'd recommend avoiding USB unless there is no other alternative.

[tszaboo]

Since you are already using CDC, why not just run UART over RS485 or RS422 at a higher baud rate in the first place?

I'm not going to explain this N+1 times. I'm not looking for a substitute.

I've been doing a bit of USB stuff recently, and it is an absolute nightmare.

It is obviously created by programmers not Engineers.

The protocol is overly complex and you will have to read hundreds of pages of documentation  just to figure out how to send a single 64 byte packet.

I make it usually in four steps. 1. Download manufacturers' example 2. Copy it into your project 3. Use it as any other serial port 4. download drivers after realizing why it is not working.

I must say I have very little experiance with the host site, I did a flash drive with FAT16 some years ago. It was 15 minutes to get the sample code to work. So I really dont understand what is the big deal about the USB being too complicated. Copy the code, call the handler every millisecond, done.

Unless you want more than one slave, or do something which doesnt have code. That is what I wanted to do as the others pointed out, that is not gonna worth the effort. That is why I said the post above, that I see that two possibilities, the first one having no challenges. The second one is still something I consider doing.

[nctnico]

If you have a good USB framework then it is not difficult to work with USB. Most of the work is understanding how the stack works. Writing your own stack from scratch is just insane.

[mikeselectricstuff]

It's fine as long as the manufacturers code works and is applicable to your requirements, but good luck if you need to debug or modify it.

[tszaboo]

It's fine as long as the manufacturers code works and is applicable to your requirements, but good luck if you need to debug or modify it.

Yes, I've seen that code. It is like the gates of hell wide open. Structures containing pointers to functions returning values of random hex. Callbacks and defines scattered with #ifdefs. Not something I'm comfortable modifying, still it works as the black box.

[nctnico]

LUFA is a good place to start. If you are unlucky you have to write the hardware drivers but that is still much less work than creating your own stack from scratch.