USB Microcontroller (Cortex) to Microcontroller (Cortex) Communication

[russ]

Posted on June 23, 2008 at 01:30

USB Microcontroller (Cortex) to Microcontroller (Cortex) Communication

[russ]

Posted on May 17, 2011 at 12:37

I am very new to the implementation of USB. I am developing a user interface for an industrial controller which uses a STM32F103 microcontroller. I want the user interface to have the same microcontroller and I want to use USB to directly connect them so that the user interface can easily communicate with the industrial controller. Communication needs to be bi-directional and I want to use DFU to allow firmware updates on both devices. Is this possible?

Also, how much space does the USB code provided by ST Micro take up in Flash (optimized). Thank you in advance.

[liqing]

Posted on May 17, 2011 at 12:37

Do you want to communicate bi-directionally in the user interface and the industrial controller by USB integrated in STM32F103? It think it is impossible. USB must have a host or OTG, but STM32F103 just a device without OTG, so they can't communicate each other if use STM32F103 in these two subsystems.

[lanchon]

Posted on May 17, 2011 at 12:37

no it's not. usb in the stm32 is device-only (not host) and it doesn't support usb otg (on-the-go). anyway, if it were possible, it'd have a fair chance of winning a Guinness award for most unnecessarily complex design ever.

[sjo]

Posted on May 17, 2011 at 12:37

OTG may not be as impossible as you may think - on future silicon anyway.

Cheers sjo [ This message was edited by: sjo on 12-06-2008 12:25 ]

[russ]

Posted on May 17, 2011 at 12:37

Quote:

On 12-06-2008 at 08:59, Anonymous wrote: no it's not. usb in the stm32 is device-only (not host) and it doesn't support usb otg (on-the-go). anyway, if it were possible, it'd have a fair chance of winning a Guinness award for most unnecessarily complex design ever. To defend myself in regard to the unnecessary complexity of the design: we have only one USB port on the user interface. This was implemented on the mechanical design level and is non-negotiable. To use the USB in its true form would be ideal because it would allow DFU bootloading and easy firmware updates for both the interface and the industrial controller. To have them speak to each other over the same USB protocol seems like a reasonable desire. It can't be that hard to implement :) I read the stream piping would be ideal for our application: Stream Pipes have no defined USB format, that is you can send any type of data down a stream pipe and can retrieve the data out the other end. Data flows sequentially and has a pre-defined direction, either in or out. Stream pipes will support bulk, isochronous and interrupt transfer types. Stream pipes can either be controlled by the host or device. This is what I want to do.

[st3]

Posted on May 17, 2011 at 12:37

Quote:

It can't be that hard to implement

It takes a great deal of effort to make something appear effortless - and USB is a prime example of this! What you want to do is fundamentally contrary to the basic architecture of USB: USB is not a peer-to-peer link; that is, you cannot just connect two USB devices together - you have to have one Host (or ''master'') to control one or more Device(s) (or ''slaves''). USB OTG (''On-The-Go'') is a development of USB that allows a node to act as either a Host or a Slave.

[jj]

Posted on May 17, 2011 at 12:37

Your application and desire are appealing.

While I love the STM32 there are ARM devices which support USB OTG. If st7's OTG comment is correct - then this (OTG) would be a good addition to the STM32's ''next spin.'' (at least add to the wish list) Perhaps a simple Uart would satisfy your ''STM to STM'' and ''PC to STM'' requirements. Once OTG is hashed out you could migrate...

[st3]

Posted on May 17, 2011 at 12:37

Quote:

If st7's OTG comment is correct

Check it out here:

http://www.usb.org/developers/onthego/

8-)

[lanchon]

Posted on May 17, 2011 at 12:37

hi russ1,

> we have only one USB port on the user interface. This was implemented on the mechanical design level and is non-negotiable. ugly situation yet interesting problem. how did you end up handling this?