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.
Related
Is it possible to capture a USB data from a usb communication between two devices by just tapping the lines and giving it to another controller with USB modules ?
To explain better A is communicating with B . C knows what interface they are using and in what endpoints they are communicating . Intension of C is to just listen what they are communicating. And C don’t want A and B to know that he is listening to their communication.
Thank you
In principle, it is possible.
It depends on the features of the USB module of the microcontroller. If it has something like a pure "listener" or "tap" mode, it should work. But I'm not aware of any USB module capable of this. This means nothing as there are so many different microcontrollers.
What you are asking for is basically "is it possible to build USB hardware analyzer/sniffer". As there are sniffers on the market, the answer to this question is yes.
One possible approach (if you are not that much interested in the physical layer) is to use USB PHY (e.g. Microchip USB3343 for USB 2.0) in passive mode. In such scenario the USB PHY does translate the USB signalling to ULPI. Then you can process the ULPI data to extract the USB packets. If you are interested in High Speed (or faster, e.g. USB 3.0 SuperSpeed) then pretty much the only viable approach is to use FPGA to do the processing.
If you are interested in seeing what kind of effort is needed to achieve USB 2.0 sniffing in hardware using the USB PHY approach, then check out the OpenVizsla project.
I am working on a project that uses the Arduino Due (microcontroller ATSAM3X8E). My goal is to be able to track the values of some of the key variables I am using in my firmware in real time. The fact is that I need to plot the change in the values of the variables over time.
In order to do this, I have decided to send the data to my PC through the native USB port. The real time constraint I am having is that I need to send the values of 20 variables (each of them 8 bytes long) within 0.1 ms. There is a native USB port available on the Arduino Due, which is connected to the USB peripheral of the chip. I have tried using UART over USB by setting up the Due in USB device mode. I can only get up to speeds of 115200 baud using Serial (UART) communication (any higher speeds don't allow the Due or my host PC to send the data correctly).
So, I did some home work and found that USB based devices have different classifications based on what they do. I want to know if there is a high speed protocol with a speed of at least 2 M bits/sec I can use on top of USB to data across to my PC from the Due, and, if there is an equivalent driver I can use on my Windows PC to successfully capture that high speed data - any recommendations would be greatly helpful.
Thanks in advance!
Subramanian
The Arduino Due's native USB port is capable of high-speed USB (480 Mbps), and by default it will appear to the computer a USB virtual COM port. This is a virtual serial port, so you can send data as fast as the USB drivers will allow, and you are not limited by the virtual "baud rate" of the COM port, which is an irrelevant setting. I think the virtual COM port will be fast enough for you and you should try it before doing something more complicated.
To use this port, use the SerialUSB in your Arduino program. The object has the same interface as Serial. You should already have a drivers for it if you installed the Arduino IDE or you are running Windows 10.
Please note that USB virtual COM ports usually use USB bulk endpoints, which don't guarantee any paritcular latency or throughput. If your computer is busy talking to other devices on the bus, you might get less throughput then you were hoping for, but you have a lot of margin of error here so I don't think it will be a problem in practice. If you want to be safe, just make sure that you can buffer up a few milliseconds of data on the device side so you aren't losing any data. You might have to look at the internals of the Arduino core code to see how big its buffers are.
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.
we are developing a sendor device, with a arm7(current: LPC2368) .
this device samples a mv signal,A/D, and need to send this signal data to the PC.(continusly)
at the same time, PC need send command to arm7 (like get temperature, control status, etc..)
rs232 is too slow, so we choose USB.(20K/s - 200K/s)
but the question is, we donnot known how to do usb programming(both pc and arm..)
any direction? any portal? any tutorial?
currently we only sim the device as a HID....
For the ARM side you need a USB Stack. For the PC side you need to implement an USB driver and an application interfacing the driver. It is therefore easier to stick to one of the common profiles (HID, Mass Storage, Virtual COM). For all these you will be able to find USB stacks and not to have to implenent your own. Also you won't need to implement a USB driver for the PC.
I think that the easiest thing to do is to use a Virtual COM approach. From the PC side it would like you are accessing a Serial Port. The speed however can be higher than standard RS232 ports. I have found this USB Stack targetting an earlier processor. You could adapt it for your needs or use it as reference. Generally a Virtual COM driver for the PC will be provided along with the ARM USB stack.
Another approach is to use libusb. This will allow you to interact with USB without writing a kernel driver.
For application notes and commercial USB stacks look here. If you are determined to write your own stack and driver, Jungo is the industry leader for embedded USB stacks and drivers.
I have a piece of hardware that sends USB data over ethernet (only the data stored in the package will be send). On a remote PC the data is recieved via ethernet. How can I send this data to the USB driver so it translates the data into commands applications can use?
You're better off getting hardware that does the reciprocal, sends the IP-based USB information to the USB subsystem, rather than try and hack the software driver itself. I can't imagine your hardware vendor doesn't have a device that does this.
You need a server listening on whatever port/socket that you are trying to connect to. Twisted Matrix makes decent Python libraries for network communications.
I think this is going to be troublesome.
USB is generally set up to associate a driver with a connected device, based on the device's various ID numbers, as discovered during bus traversal.
Your data comes in over Ethernet, so the platform's USB driver stack won't know anything about the device in question. This means you somehow need to directly talk to the proper driver, and also get it prepared to handle events from a (from its point of view) non-connected device.
I can think of several reasons why even a well-designed USB stack won't handle this happily.
On Linux, you might be able to "cheat" by interpreting the data yourself and sending it on, using the same API:s the actual driver would have used. That won't work for any USB device of course, it requires you know what the device is.
It's doable on windows as well, but you need a lot of kernel/usb knowledge to make it work i don't think i will be wrong by estimating this task as few man years (you can reduce this estimation dramatically if you have a limited selection of devices/types of device to support.
You will need to develop a bus driver that will simulate the host controller driver to the native usb host, unfortunately this interface is not public and we did not managed to get MS cooperation on that.
There is additional option to work on hub level, instead on controller level, this interface is available, but i did not managed to find my notes on that.
You can download the evaluation version and investigate the driver stack it might give you a clue where to start.