First and foremost I aware of a "similar" question/answer here: USB: low latency (< 1ms) with interrupt transfer and raw HID
In my case I'm at the start of my project and currently choosing the "right hardware" for the job. I want to transfer raw sensor data from an IMU to a host PC in roughly <1ms. So my Idea was to use a Teensy or Arduino uC to handle the interface between IMU and PC. The current priority is driving the input latency down as best as possible using (ideally) the USB protocol. I'm well aware that once on the PC I have to deal with a non real-time system.
Is there anything "hardware-wise" that I have to pay attention when choosing my Microcontroller?
Related
I want to send data through USB between STM32 and Raspberry Pi. I don't want to use USB to Serial convertor, but instead have a actual USB Connection (maybe CDC class). I have to send data at high rate (Full speed). Please guide on how to achieve this?
A USB-serial connector is simply a microcontroller implementing a USB CDC/ACM virtual COM port and bridging to a UART which you would connect to a microcontroller's UART interface.
In your case you can simply implement the CDC/ACM directly on the STM32 using either of its USB device controller peripherals (USB support varies depending on the specific device https://www.st.com/resource/en/application_note/dm00296349-usb-hardware-and-pcb-guidelines-using-stm32-mcus-stmicroelectronics.pdf).
How you actually implement that will depend on what specific part, and what library or framework ecosystem you are using (e.g. SPL, CubeMX, Mbed). There are reference implementations, examples, drivers and libraries for all of these.
Your milage may vary, but I have measured ST's own USB library and example CDC/ACM virtual COM for STM32F1xx on a 72MHz MCU achieving 700kbits/s. Note that the performance is independent of the baud rate you might set on the host when you open the he VCP. Setting the baud rate simply sends a control packet to the device that can be used to set the baud rate of a UART in bridging applications. In your case such control packets can be ignored. There are similar packets for modem control signals such as DTR, RTS, CTS and RI, which you might choose to us for flow control or other signalling.
What protocol shall i suse for best realtime communication from Raspberry pi to ESP32.
I'm doing some computation on R pi (FFT on signals) and the result shall be sent every 10ms to ESP32.
Esp32 puts the result to LED display and stepper motor.
Raspberry pi is on ethernet and ESP32 on wifi (LAN, home network)
I need to transfer 10 bytes of data every 10ms, but the time delay and frequency response shall be very small. What protocol shall i use? I think MQTT is to slow? Any other idea ?
Anything involves a wireless communication can't be trusted in terms of consistent package delivery with low latency. I don't think you can achieve your 10ms goal for every package with WiFi. There's too many external factors.
Having said that, from your question, I understand you make a measurement/calculation on ESP32 and want to use it somewhere else with low latency. Since an outdated measurement/calculation is redundant, you need to implement a datagram. If your problem definition is suitable to skip a package every now and then, I would use UDP packets. If it arrives in 10ms with no complication, there's no problem with both UDP or TCP. But when it doesn't, UDP will just ignore the fault and send the next data package while TCP will try to deliver it even after 10ms.
Also please be aware that even in TCP, you can have some amount of undelivered packages. (packet loss)
You're pushing the limits of what a WiFi connection can do. Low latency, low jitter data transfers are certainly not guaranteed. If the WiFi channel is even mildly utilized, collisions will introduce delays of several tens or hundreds of milliseconds. The frequency of those delays depends directly on channel utilization. As Bora said, raw UDP datagrams are your best bet. You have to build into the protocol a mechanism to recover from samples which are lost or arrive to late to be useful. All in all, this is not a trivial task, so good luck :)
I want to make a VoIP ATA (Analog Telephone Adapter) Device using Raspberry Pi, furthermore, I also want to add FXS ports to the Raspberry Pi. Kindly, tell me whether it is possible or not. If Yes, then how?
Here is the
Reference Link
This is probably possible, but not with the Pi alone.
You will need to design and build some external circuitry to convert between telephone line audio (which apparently runs at 48 volts) and audio signals which the Pi can produce. Also it looks like the Pi has no audio input, so you might need to either add a USB audio device or use an analog to digital converter that the Pi has to read the audio signal coming in from the phone line, if it can be polled fast enough.
You might have better luck with a board that has a real microphone jack on it already, instead of the Pi.
Then on the software side you need to attach the audio out, whatever you are using to get audio in, and any circuitry you need to open/close the circuit or send special ring voltages to your VoIP software of choice. Working out how to write that driver code is going to depend heavily on what physical circuit you actually build and what VoIP software you want to have talk to it.
That link above has a design for a line-level audio to phone audio conversion circuit which may help you get started. You could also take the circuitry part of the project over to the Electrical Engineering StackExchange site.
We are doing research into running a server on a Pi, and communicating with it via a webapp (over a local network) to control 2-3 servos. It appears that the Rpi has only one hardware configured PWM pin, but this can be worked around via servoblaster. However, since Servoblaster utilizes the Rpi's DMA, will it interfere with the Pi's ability to operate a web server? I apologize if this question is unclear i am somewhat unfamiliar with the software/network concepts involved. Additionally, is there a good resource for understanding the DMA function further?
Thanks in advance for any help.
You can control Servos using Software PWM, which will not require any further hardware or using DMA
If you care about performance and want more powerful hardware consider ODROID-X, it has 1.4GHz processor and 1GB RAM and cost $130, it is the best value for the price.
For other alternatives check Small low cost linux pc's
I have a NIC card and a HDD both connected on PCIe slots in a Linux machine. Ideally, I'd like to funnel incoming packets to the HDD without involving the CPU, or involving it minimally. Is it possible to set up direct communication along the PCI bus like that? Does anyone have pointers as to what to read up on to get started on a project like this?
Thanks all.
Not sure if you are asking about PCI or PCIe. You used both terms, and the answer is different for each.
If you are talking about a legacy PCI bus: The answer is "yes". Board to board DMA is doable. Video capture boards may DMA video frames directly into your graphics card memory for example.
In your example, the video card could DMA directly to a storage device. However, the data would be quite "raw". Your NIC would have no concept of a filesystem for example. You also need to make sure you can program the NIC's DMA engine to sit within the confines of your SATA controller's registers. You don't want to walk off the end of the BAR!
If you are talking about a modern PCIe bus: The answer is "typically no, but it depends". Peer-to-peer bus transactions are a funny thing in the PCI Express Spec. Root complex devices are not required to support it.
In my testing, peer-to-peer DMA will work, if your devices are behind a PCIe switch (not directly plugged into the motherboard). However, if your devices are connected directly to the chipset (Root Complex), peer-to-peer DMA will not work, except in some special cases. The most notable special case would be the video capture example I mentioned earlier. The special cases are mentioned in the chipset datasheets.
We have tested the peer-to-peer PCIe DMA with a few different Intel and AMD chipsets and found consistent behavior. Have not tested the most recent generations of chipsets though. (We have discussed the lack of peer-to-peer PCIe DMA support with Intel, not sure if our feedback has had any impact on their Engineering dept.)
Assuming that both the NIC card and the HDD are End Points (or Legacy Endpoints) you cannot funnel traffic without involving the Root Complex (CPU).
PCIe, unlike PCI or PCI-X, is not a bus but a link, thus any transaction from an Endpoint device (say the NIC) would have to travel through the Root Complex (CPU) in order to get to another branch (HDD).