I have been tasked to write a device driver for an embedded system which has two microcontroller interfaced via USB. The data transfer between two controller will take place across USB.
I am facing difficulty in reading USB specification.
Which USB class is suitable for communicating between two controllers?
USB is an asymmetric protocol where there is a host and a device, and the host is the one who initiates all communication. The device can conform to a USB Device Class, or your device can just have a vendor-defined interface that doesn't conform to any particular class.
Without knowing anything about the data you are sending between the microcontrollers, I would suggest just using a vendor-defined interface (USB device class code 0xFF). The host can initiate custom control transfers on endpoint 0 that transfer arbitrary data between the host and device. You can also use bulk/interrupt/isochronous endpoints to transfer data.
The USB CDC ACM class is used for virtual serial ports, and it provides a way to send bytes back and forth between the host and device; many devices use it for a generic communication mechanism.
The HID (Human Interface Device) class is another one that is designed for things like keyboards, but it can also be used for generic communication.
The main point of using a USB Device Class is that it allows you to take advantage of built-in drivers that different operating systems have for these types of devices without having to write your own driver. You might look to see if your host microcontroller has special USB drivers for one of those device classes. If it doesn't then there is not much point in using a USB Device Class. It sounds like you will be writing the code on both ends of the USB cable and you don't intend to take your device and plug it into any other type of USB host, so there is no point in forcing your protocol to conform to a USB class.
Related
I need to connect a custom board having STM32F767zIT6 as the MCU to a window PC through a USB. The aim of the board is to filter CAN-BUS messages. The existing solution uses a CANBUS-USB adapter through one of the CAN interfaces but I have been asked to implement the USB functionality on the board since it has a USB2.0 mini-B port. I need to receive CAN messages through one of the CAN interfaces and transmit it through the USB interface to a GUI on the PC and also receive CAN formatted messages from the GUI via the USB to another CAN interface on the board. I have been playing around with the HAL_library for STM32 using STM32CubeMX but I need guidance and materials I can learn faster. If possible a similar open source implementation I can learn from.
For USB Host Controllers there are the UHCI/OHCI/EHCI/XHCI specification that define how to program a driver. Is there an equivalent specification for USB Device Controllers?
No. Generally, every USB-capable microcontroller has a USB block that you can control by writing to some registers in your code, but those registers are pretty different on the different microcontrollers and I have not heard of any attempt to standardize them.
I'm trying to configure/write VHDL code that would let me output or input data from the USB port on a Basys3 FPGA board. Problem is I have yet to found any threads or questions that talk about this topic.
The nearest thing to an answer I've found is this:
Provide input data to FPGA using USB
and it does not contain what I'm looking for.
Any clues anyone¿?
The Basys3 board has a usb-uart bridge chip as described in the reference manual. This will appear to a PC (or any device with a usb host and the appropriate usb-serial drivers) as a virtual com port. Sending data to and from a PC com port is quite easy.
You will need a uart implementation on the FPGA. There are lots of example designs on the web. One way is to implement a soft core microblaze processor with a uart peripheral in the FPGA. This example looks like it includes foundation for the functionality you desire.
The simplest implementation from the PC side is using a terminal program such as putty, Tera Term or realterm. Most languages include com(serial) port libraries or bindings. This type of interface tops out at a raw bandwidth of around 3-12Mbits per second depending on the drivers and implementation.
Read the manual for the Basys 3 board. It will explain how you can interface with USB devices plugged into the USB port. Be warned, however, that your options are pretty limited.
Short version: if you plug in a USB mouse or keyboard, they will be exposed to your design as an emulated PS/2 device. USB storage devices can be used to configure the FPGA. Other devices are not supported.
I have the following problem:
A micro controller with the possibility to talk with PC via several communication interfaces: RS232, USB are present. Ethernet is not available. The software is bare metal with optional embedded OS.
The hardware is not important as this is applicable to any microcontroller and physical communication interface.
Several communication channels are needed simultaneously:
1 for a simple console - debug purpose: uC <-> PC
1 for getting real time samples from the ADC to PC: uC -> PC
1 for sending real time samples from PC to DAC: PC -> uC
1 setting different parameters of the acquisition/conversion, start/stop, etc: uC <-> PC
Ideally only one physical interface should be used RS232 or USB (preferable).
Is there something already available to multiplex different channels on a single physical one ? message passing, remote procedure call.
If you have an IP stack on the uC, then you can probably use SLIP or PPP to communicate through a serial link. On the other extreme, if you have a barebones system take a look at those protocols and things like HDLC because you will end up implementing something similar.
An obvious choice would be to use a TCP/IP stack. Each open "socket" is independent of any other and a link can support multiple simultaneous connections.
TCP/IP can be transported over Ethernet or over a serial connection via PPP or SLIP. A an asynchronous serial connection (COM port) can be emulated over USB by implementing a CDC/ACM class device, however if your device is to be released commercially you will need a USB vendor ID.
Some sort of multi-threading kernel may make handling multiple connections simpler, but is by no means necessary.
RS232
Almost nobody still ships RS232 on a PC/Notebook.
Is there something already available to multiplex different channels on a single physical one?
You aleady mentioned that you wanted to use USB, which supports multiple pipes on a device, called endpoints. The USB standard allows up to 32, but a specific micro controller may have implemented less endpoints, or has restrictions on endpoint types.
On the PC (Host) side you can use WinUSB or LibUSB to access these pipes.
Edit:
I use USB-to-RS232 converters personally, they can work but I must advise rather strongly against them for new designs:
Different USB Port can result in different COM port number
Unplugging a USB2COM while the port is "in use" results in COM port not working when replugging
Many driver issues on cheaper converters
Good luck trying to find Win8 drivers for older adapters
The 1ms USB frame time can negatively impact some RS232 protocols
All problems are minor, but you can avoid them when using USB directly.
real time samples
This raises the question of available bandwidth, where USB ususally has 12 MBit/s (or even 480 on some high-end micros). Most USB-2-RS232 adapters max out at 460800 or 921600 Baud.
This question is a bit vague, and I apologzie for that, but a fairly vague answer will do :)
How do people typically access memory adresses of external devices (say, connected to a PC through USB, or even just say, a multipurpose microcontroller)? I'm wondering how software is able to find address to write to registers or EEPROM space.
For example if I want to write a value to register 0x1234, does software just send this information (the register and the value to be written) to some sort of driver that "talks" to the device and takes care of the value change through hardware?
Is implementation of this functionality mostly a hardware endeavor?
Thanks!
Let's use as an example a fairly common USB peripheral controller that is based on an 8-bit 8051 microcontroller core. One side of it attaches to the USB host controller on a desktop computer. The other end goes to a USB device controller that presents itself as a FIFO endpoint to the host.
Some 8051 firmware will be required to initialize the device side. A class driver will be required on the host side. Once those are in place, the application developer will have a device name on the host side which may be opened for read/write. Sometimes a vendor will provide a library to perform device specific tasks and isolate the user from the raw device. Often a Windows DLL is available to hide the low level I/O and present device operations as function calls.
Additional 8051 firmware monitors the FIFO from device end and interprets messages sent from the host application or DLL then takes actions. These actions may be low level such as read/write from a memory location or register. They may be high level such as setting the PWM value of a programmable counter array.
So your hypothetical description of a write to register 0x1234 is not far from how it is often implemented.