2
\$\begingroup\$

I am developing a product that will communicate with each other via a cable and would like to use USB micro-B type connectors. However, the communication protocol will NOT be USB compliant. Is there a rule against creating such a product? I am planning to keep the power pins the same as standard USB so it can still be charged via a standard USB port or charger, but the data pins will use a proprietary protocol that cannot communicate with standard USB.

Thanks in advance, Jason

\$\endgroup\$
5
  • 1
    \$\begingroup\$ As long as it doesn't mess with other USB devices I don't see a problem with that. \$\endgroup\$
    – Handoko
    Commented Jun 3, 2014 at 21:46
  • 6
    \$\begingroup\$ What would happen if your device were to be plugged into a USB hub? Could either be damaged? If so, I'd call it a bad idea. \$\endgroup\$
    – DoxyLover
    Commented Jun 3, 2014 at 21:54
  • \$\begingroup\$ The power pins and voltage levels are the same as USB specifications so it will not damage either devices. The datapins will also be buffered and inactive (floating) unless it is invoked by the proper handshake stream (proprietary). \$\endgroup\$
    – Jason G.
    Commented Jun 4, 2014 at 0:30
  • \$\begingroup\$ Why don't you just USB? You can still run your secret protocol on top of USB, and then you can benefit from the tons of work that has gone into USB, as well as utilize many of the cheap USB controller ICs. Also, using USB connectors for a commercial product, but not actually using USB, would make you very sketchy. \$\endgroup\$
    – whatsisname
    Commented Jun 4, 2014 at 2:05
  • 1
    \$\begingroup\$ Unfortunately the product wouldn't work with standard USB protocol due to the flexibility of the device being able to not only use Digital IO on the datapins but also analog IO directly if it detects its sister device connected. The microcontroller of choice and budget constraints prevent us from achieving high speed full duplex communication required for USB data. \$\endgroup\$
    – Jason G.
    Commented Jun 4, 2014 at 3:29

2 Answers 2

Reset to default
2
\$\begingroup\$

The new USB-C standard defined at

http://www.usb.org/developers/docs/usb_31_102214.zip

now officially allows products to use non-USB protocols through USB ports.

Some requirements for this:

You'll need to use the USB-C connector rather than the micro-B that you mentioned in your question, but USB-C will soon be the universal standard, so this is a good idea anyway.

You'll need to provide a minimal USB interface on your device just to implement what's called a "billboard device" in case your device is plugged into a regular USB host, for the purpose of telling the host what your device is, in order to avoid user-unfriendly silent errors where you plug something in and nothing happens.

You can't directly start using your own protocol as soon as the device is plugged in. Instead, you have to do a protocol negotiation (on a separate line in the port) to indicate that you're switching to your protocol, in order to avoid confusing a regular USB host if your device is plugged into it. This negotiation would replace the proprietary handshake that you mentioned for your device.

You said your microcontroller can't handle high speed full duplex. But USB 2 runs at half duplex. Only USB 3 runs at full duplex. And for the USB billboard device that you're supposed to implement, apparently low speed (1.5Mbps) is allowed, which might be within your microcontroller and budget constraints.

\$\endgroup\$
1
\$\begingroup\$

Using usb connectors in a non-Standard acceptable method is against the USB specifications. Unless you are looking to conform to the USB specifications, there is no technical problem aside from end user problems. Non-standard usb connectors are fairly common, as is non-standard combinations (Usb female A to Usb Female A is common but against specifications, as are USB Y-Cables used to power external harddrives).

The only thing you can't do, according to the USB forum, is have the usb logo or name.

\$\endgroup\$
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.