Data will be arriving at a moderate rate of 30MBps from an external device through a PCIe. I want to move the data immediately off of my acquisition machine and store it on a remote drive on a server. My acquisition machine is connected to my server on a 10GbE line.
What happens in between when my data arrive on my PCIe and when it leaves on my ethernet card? Any tips on how to design my system? Any special hardware needed?
First time poster, long-time listener
----edit----
input is arriving through kintex 7 eval board (https://www.xilinx.com/products/boards-and-kits/kcu105.html)
using the xillybus drivers (http://xillybus.com/) to communicate with an FPGA
output is moving to a TRENDnet 10 Gigabit PCIe Network Adapter
I have design choices about whether it will be a Windows or Linux machine.
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.
I want to read the CAN bus and get the data from a specific device on the CAN bus. I have implemented this previously using the Socket communication api that is available in the user space (sys/socket).
I now have a similar requirement but this time working on device drivers which work in the kernel space. The same socket communication is i suppose not available in the kernel space which is why i guess i am not able to compile the kernel module with #include .
An approach i have come up to is to create a device driver for device creation and a supporting user-space program to interact it and provide CAN data by using socket communication. If there is any better approach please suggest me.
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?
I've been having quite a time trying to use IPMI tools (such as OpenIPMI, FreeIPMI, and ipmitool) to discover and monitor a PCI device in my server. Using an IBM server going through IMM over the network using the IPMI tools, I can't seem to be able to get any information on the PCI devices in the server. The IPMI tools only return basic information on the system such as the BMC, chassis, power supplies, fans, etc. No information on the devices plugged into the PCI slots.
I've tried basic commands like "fru list", "sdr elist", etc. and haven't been able to get any information from the PCI slots.
Just hoping someone has had experience using these tools and is able to get information from the devices in the PCI slots.
Specifically, I would like to get the FRU information as well as device ID, I2C slave address, etc. for accessing the device.
Thanks for any information that you can provide...
There is no requirement in the IPMI spec that the PCI connector A side pins 40 and 41 that contain the SMBus are routed to the BMC. A vendor may do it but most do not.
Look at it this way, the BMC can turn off power to the PCI bus and main CPUs. You would not be able to read anything from them anyway.
This is why the AdvancedTCA specification requires management power and two IPMB buses to each blade slot. The AdvancedTCA spec requires the IPMB bus from each slot is connected to the BMC. The blade can power up and use a max 15 watts to supply IPM Controller and you can read the data you are looking for without powering on the main CPUs.
Hank Bruning
JBlade
I try to connect an Omron PLC (CP1L) to a PC through an Ethernet Option Board. I have setup connection correctly and is able to connect to the PLC to configure its IP and various settings.
Then I have problem getting the ladder program to run correctly.
Documentation indicates address A202.00 will turn on when communication is enabled, but when I simulate the ladder program, the address A202.00 always turn ON. Even when I disconnect the Ethernet cable, the address remain turn ON. I do not understand why the address remain turned on even there is not ethernet cable connecting the PLC and the PC.
Simulated ladder program indicates A202.00 always turn ON:
If you have the physical PLC then why are you running in simulation? If you want to debug the real system just plug into it with a USB cable and use "PLC -> Work Online...". I don't think networking simulates exactly right since the simulator itself uses simulated networking to work. In any case, if you are running in simulation then the state of the real ethernet port on the real PLC will have absolutely no impact on the simulation. It doesn't care that you even have a real PLC at all.
In any case A202.00 is just a "Port not busy" flag. You use it to guard rungs against trying to read/write from the same port at the same time or to trying to perform multiple simultaneous reads or writes. A202.00 is ON so long as the com port is not busy. If it is reading or writing then the A202.00 will go OFF for the duration of the read or write, preventing other communication rungs guarded with it from executing, and then returns to the ON state.