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.

[Esposch T. Tapir]

It is obviously created by programmers not Engineers.

Hahaha, I was thinking the same thing.  Just didn't say anything because I didn't want to slander an entire profession when I haven't worked with any of them in the real world.

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.

It is worth noting that LUFA is, for the most part, incompatible with ASF.  Not that you need ASF, but it's definitely useful for certain tasks (e.g printf()ing to dot matrix LCDs).

[miguelvp]

It is obviously created by programmers not Engineers.

Hahaha, I was thinking the same thing.  Just didn't say anything because I didn't want to slander an entire profession when I haven't worked with any of them in the real world.

[/quote]

Some quick research would show that is not the case, blame design by committee if you want to point fingers, just too many cooks

[marcan]

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

It is obviously created by programmers not Engineers.

No, USB is one of the best (worst) examples of Design by Committee. A committee of engineers and a committee of programmers can both be equally dangerous. Worst is when you put together a committee of hardware and software engineers/programmers with nobody who actually understands both sides. The impedance mismatch of epic proportions guarantees a steaming pile of crap as the output.

Then again, it could be worse. It could be Bluetooth.

Anyway, as for abusing USB as a lower-level protocol, it's doable, but you can't get away from the basic USB topology where one side is the host and the other is the device. At a bare minimum, you have to configure each side's peripheral for the correct role, hardcode the speed mode to whatever you want, hardcode an address on the device (e.g. 1), set up a pair of IN/OUT endpoint pipes on both ends, and then just have the host side send OUT packets when it wants to, and poll for IN packets periodically. You need to make sure you implement data toggle (subsequent packets should be sent with alternating DATA0/DATA1 PIDs) since that's part of hardware packet retransmission support, if the hardware doesn't do that for you. You can ignore all of the enumeration/configuration/descriptor stuff which is the most painful part of USB.

If you want to have more than a point-to-point link, sorry, you're screwed. You're going to have to implement the enumeration crap to be able to talk to a standard hub chip. You can still get away with hardcoding things instead of parsing descriptors though, but at that point I'd say it's more trouble than it's worth.

If you had bare USB PHYs, and not the built-in peripherals which are smarter, you could abuse it at a lower level even (and e.g. improve throughput) but you still won't really get away from the master/slave requirement; ultimately you'd have to define some kind of bus arbitration protocol (since TX and RX share the same pair in USB) that would end up looking very similar to what normal USB does anyway.

If all you want is the equivalent of full-speed USB (12mbps), just use SPI or whatever. SPI works fine at 32MHz. Same with higher-baudrate RS485. USB is really asking for trouble.

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.

Honestly, there's a big difference between your average manufacturer sample code blob for CDC and a nice microcontroller interconnect system with all the features that you mentioned. If you're the kind of person that enjoys using those horrid monsters of sample code as a black box, you're not going to enjoy trying to work out how to do this and make it work properly. Real engineering isn't about copying and pasting sample code, and designing a microcontroller interconnect system around commodity USB peripherals requires real engineering, since you're going outside of established use cases.

[tszaboo]

Honestly, there's a big difference between your average manufacturer sample code blob for CDC and a nice microcontroller interconnect system with all the features that you mentioned. If you're the kind of person that enjoys using those horrid monsters of sample code as a black box, you're not going to enjoy trying to work out how to do this and make it work properly. Real engineering isn't about copying and pasting sample code, and designing a microcontroller interconnect system around commodity USB peripherals requires real engineering, since you're going outside of established use cases.

Then you must be glad to hear that I'm the guy that designs the circuit boards, not the guy who writes the code. Usually when I have to write code or decide to write code, I use whatever which gets the job done by the fastest possible, so I can go back to do what I actually enjoy. So a blob of code (which I described quite well) is fine as long as it works.

[marcan]

Then you must be glad to hear that I'm the guy that designs the circuit boards, not the guy who writes the code. Usually when I have to write code or decide to write code, I use whatever which gets the job done by the fastest possible, so I can go back to do what I actually enjoy. So a blob of code (which I described quite well) is fine as long as it works.

Fair enough, but I'm sure you realize that just as real board design isn't about copying and pasting template layouts from datasheets and app notes, real software/firmware engineering isn't about copying and pasting example code. For one, this is how non-compliant USB devices are made (e.g. example that code "works" but does not follow the standard, and then you get things like bus-powered devices reporting themselves to be self-powered because whoever wrote the firmware didn't know how to configure it properly, or that do not handle a perfectly legitimate request in the standard because, hey, the Windows drivers never use it). It's not really reasonable to expect to correctly design a device if you don't understand or care for an entire half of its development process and just resort to canned examples for it.

Quoting from your original message:

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.

That kind of system takes as much, if not more, engineering on the firmware side than on the PCB/circuit design side; it's a non-traditional use of the hardware on both fronts and you're not going to get away with just canned examples for either side. USB is a standard geared towards using it with something like a PC as the host, and it's highly unlikely that standard OTG libraries for micros will do everything you want properly.

So if you really want to do this, you're going to have to think hard about what kind of features and constraints you really want, and talk to someone more experienced with the mess that is USB at both the hardware and higher logic layers to figure out if it's feasible. I think we've covered the simple case of peer-to-peer communications between two micros using a minimal protocol over USB hardware, which would definitely require writing some custom software but at least wouldn't be anywhere near as complex as a full USB stack. That doesn't handle hot swapping, hubs, etc, though, and going there is where things get tricky on the firmware side of things.

[tmbinc]

USB is not great, but it's not as horrible as people make it sound. Yes, it has unfortunate performance characteristics (like USB1.1's "sending a DATA packet over and over just to receive a NAK for it every time"), but once you see the limitations as trade-offs (ahem), it's something workable. Not great. Don't get me wrong. I'd still not use it for chip-to-chip connectivity.

Even enumeration isn't that complicated. Implement GET_DESCRIPTOR (simple, just return a fixed string based on wValue/wIndex), SET_CONFIGURATION (dummy), GET_STATUS (dummy), SET_ADDRESS (just poke your hardware's address register) and be done. It won't be standard compliant, but it gets you enumerated. That's ~50 lines of non-dense code.

And then, yeah, just use bulk transfers.


What makes USB really frustrating, in my mind, are two things: a.) you don't need to understand it in order to use it, and b.) USB is cheap.

For a.), it allows you to go with the black box approach (take vendor code, compile, use, throw it against the wall because it doesn't fully work and hangs every two hours) for quite a long time. You can develop USB devices these days without understanding which USB packets exist. That's different from, say, TCP/IP, where Ethereal is your friend and you get full insight down to ethernet level with a few mouse clicks. Or a serial port, where, to be honest, not many corner cases can happen anyway.

But with USB it's different. You _need_ to understand what's going on on the wire, otherwise the first issue you run into will turn into a heisenbugfestmess. The issue is that it's not easy to get there. usbmon and friends are not telling you what's going on on the wire, but instead what _should_ go on on the wire. I was scared of USB until I bought a (even back then overpriced) LeCroy analyzer from the BenQ germany auction. But it was the first time I could actually make sense out of those dreaded kernel messages a la "Device does not accept address" etc., and get a hint in debugging them other than just cargo-cult programming. USB analyzers thankfully got less expensive.

For b.), the issue is that USB is so mass-market, you can't trust anything anymore. Your hub? marcan will happily tell you horror stories. Cables? Don't get me started. Cheap usb controllers that just don't respond to certain commands, and an equal number of ugly workarounds in the kernel drivers? Check.

[marcan]

But with USB it's different. You _need_ to understand what's going on on the wire, otherwise the first issue you run into will turn into a heisenbugfestmess. The issue is that it's not easy to get there. usbmon and friends are not telling you what's going on on the wire, but instead what _should_ go on on the wire. I was scared of USB until I bought a (even back then overpriced) LeCroy analyzer from the BenQ germany auction. But it was the first time I could actually make sense out of those dreaded kernel messages a la "Device does not accept address" etc., and get a hint in debugging them other than just cargo-cult programming. USB analyzers thankfully got less expensive.

You're lucky to have had the cash. I wrote the device stack that my first USB device used in PIC18 assembler and debugged it with 4 LEDs. At more than one point I was latching and outputting packet fields via the LEDs. Getting it to work with Windows (which will unhelpfully tell you nothing about what went wrong when a device fails to enumerate - Linux at least vaguely hints at the source of the issue) was "fun". I certainly couldn't afford an oscilloscope or logic analyzer back then, let alone a USB analyzer.

For b.), the issue is that USB is so mass-market, you can't trust anything anymore. Your hub? marcan will happily tell you horror stories. Cables? Don't get me started. Cheap usb controllers that just don't respond to certain commands, and an equal number of ugly workarounds in the kernel drivers? Check.

I'm just going to say avoid Genesys Logic hub chips like the plague.

[miguelvp]

Maybe wait until USB Type-C is more common?





http://www.cypress.com/Type-C/

http://en.wikipedia.org/wiki/USB#USB_Type-C

Edit: more technical, lengthy and with a monotone voice announcer



and sorry for the Cypress overload, just happened to be watching the cypress channel when I ran into the Type-C connector

[donotdespisethesnake]

If anyone can figure out to make USB physical interface into a fast low-level data pipe, without all the USB protocol baggage, I think that would be very interesting. Peer-to-peer would be useful, network would be great.

From my understanding of USB, the USB device hardware has special stuff to be a device, and similar for host. At least OTG might be needed to perform necessary host functions.

[Brutte]

If anyone can figure out to make USB physical interface into a fast low-level data pipe, without all the USB protocol baggage, I think that would be very interesting. Peer-to-peer would be useful, network would be great.

USB device stack is really tiny. IIRC the simplest HID on AVR8 (ATMega16U2) occupies less than 2k of flash.
As most of decent USB uCs are 16k or more, I cannot see why would anyone want to dump USB interoperability for the price of that 1k of flash. Get a bigger tiny.

As for USB OTG, the smallest uC I know of is 64k. How much would you expect to save here?

Now for the throughput, Full-speed USB reaches 1MB/s out of theoretically 12Mbps available (half duplex). Neither here is the place for improvements. Get Hi-Speed instead of reinventing the wheel.

[nctnico]

Most USB host/OTG microcontrollers also have ethernet. You can cross connect their MACs (without PHYs in between) and you'll have a 100Mbit DMA capable interface in between. A small CPLD could act as a hub between several PHY-less ethernet devices.

[tszaboo]

Most USB host/OTG microcontrollers also have ethernet. You can cross connect their MACs (without PHYs in between) and you'll have a 100Mbit DMA capable interface in between. A small CPLD could act as a hub between several PHY-less ethernet devices.

That sounds like science fiction to me. MII or RMII is not a symmetrical interface. What happens with clocks, enables, error signals? Could you give us an example?

[Jeroen3]

I stumbled upon USB SSIC in the 3.1 standard, which translates to USB SuperSpeed Inter Inter-Chip.
So your idea is already being considered by the USB people.

[nctnico]

Most USB host/OTG microcontrollers also have ethernet. You can cross connect their MACs (without PHYs in between) and you'll have a 100Mbit DMA capable interface in between. A small CPLD could act as a hub between several PHY-less ethernet devices.

That sounds like science fiction to me. MII or RMII is not a symmetrical interface. What happens with clocks, enables, error signals? Could you give us an example?

The interface is symetric. The clock comes from the PHY so provide an appropriate clock (IIRC 25 or 50MHz) to both controllers. Connect TX to RX and cross 'receive data valid' with 'transmit enable'. If you add bus buffers you can create a bidirectional bus between multiple devices while using the colission / carrier sense signal + some logic to signal the bus being busy or free. This may be less straightforward due to timing issues but the idea should work.

[tszaboo]

I stumbled upon USB SSIC in the 3.1 standard, which translates to USB SuperSpeed Inter Inter-Chip.
So your idea is already being considered by the USB people.

2.0 had High-Speed Inter-Chip already. It has different physical layer.
http://ww1.microchip.com/downloads/en/AppNotes/00001602A.pdf
I consider it as a failure, never got any wind, like the wireless USB.

[photon]

One brilliant move the USB folks made was for the bus to supply power. This one idea alone ensures the survival of USB for at least the next 10 years. This does not help it be a board level bus much less a chip level bus.

[abyrvalg]

USB HSIC is alive! Example: application CPU <-> cellular modem interconnect in every iPhone starting from 4s.
But that's a direction completely opposite to OP's idea: HSIC keeps the same complex protocols while simplifying the PHY to work point to point (no hubs) and just few cm distance.

[John_ITIC]

Since I design USB Protocol Analyzers for a living I though I'd chime in my $0.02...

The bottom line is that USB is designed to be completely plug-and-play for the user, no configuration of IRQs and I/O addresses as prior buses like ISA and the like. USB 1.1 was designed to replace the commonly used PC parallel port, keyboard port and mouse port with a single port. All this functionality however means that for the engineer that actually have to implement all this magic, it becomes orders of magnitude more complex. If you need to understand on-the wire protocols then you need a hardware protocol analyzer. USB analyzers used to be thousands of dollars but can now be had for hundreds.

USB is designed to have 90% of the complexity on the host controller side (i.e. PC hardware and device drivers). The host controller schedules all transactions to all discovered devices on the bus (up to 127 devices), handles traffic across hubs, discovers capabilities of unknown devices and much more. Essentially, the host controller handles all bus transactions in hardware and the associated host controller device driver sets up the data transfers as instructed by higher-layer software.

Therefore, if you have two chips known that you need to have communicate then USB is not well suited. Instead choose a simple SERDES protocol or a semi-fast parallel protocol, depending on bandwidth requirements. If using FPGAs, there is cheap of no-cost IP available that can be leveraged.

Finally, USB has nothing to do with Ethernet. A USB 2.0 PHY actually doesn't have separate TX and RX signals but rather a shared set of differential D+ and D- signals that alternate between sending and receiving. USB 3.0 has two sets for dual simplex but still nothing to do with Ethernet. The host controller and device still have very different capabilities in USB 3.0. You can in USB 3.0 hook up two PHYs against each other only if you develop your own MAC layer (in FPGA). Again, this is hugely complex (but interesting...).

/John.

[nctnico]

A quick note: ethernet has been mentioned because a MAC (MII / RMII interface) can be used to create a point-to-point or point-to-multipoint on board network without PHYs or a switch very easely.

[Psi]

An ARM cpu with 32KB in system reprogrammed flash inside every usb cable... What could go wrong??

Damn, my usb cable has a virus

[donotdespisethesnake]

It's funny how the OPs fairly straightforward idea turns into 3 pages of people missing the point and going off on irrelevant tangents. No one really addressed the key question.

Oh well, that's engineers for you

[photon]

It's funny how the OPs fairly straightforward idea turns into 3 pages of people missing the point and going off on irrelevant tangents. No one really addressed the key question.

The point, being the OPs idea of using USB as a bus between microcontrollers, has been addressed. It's not a good idea.