I have an "HP NC365T 4-port Ethernet Server Adapter" which is a PCI Express adapter. I also have a Kepler-class GPU with DMA (Direct Memory Access).
I would like to be able to directly transfer data from a socket on the adapter to the GPU, i.e. I don’t want the data to be transferred first to the CPU and then from the CPU to the GPU.
How can this be done? Do I need to use the capabilities of the adapter driver or the driver would not be involved? Ideally I am looking for some sample code to achieve the above.
Unless you have access to the driver source code (or a GPUDirect-compliant driver and stack is already available from the network card vendor), it's not possible to achieve this.
If you have access to the driver source code, the starting point would be to begin with the documentation provided here.
A full tutorial is outside of the scope of an answer I can provide here.
Related
I am trying to set up a simulation of an Ethernet net work in CANoe. This network has two nodes ("input" and "result"). The input node should receive a data stream from the "outside", e.g. another program on my computer. The idea was sending simple data (e.g. 101010 as bits) via TCP/UDP to the input node. This node then transfers these bits to the result node, which simply outputs the received data. So much for the basic setup.
What I am not able to accomplish is the connection from the outside into the CANoe simulation aka the input node. After hours of reading the CANoe help I am still not sure if that is even possible. So has anyone tried something similiar like this or has an idea how to approach this?
I hope it is clear what I want to achieve. I am relatively new to CANoe, so maybe my complete approach is wrong? Some input or alternative ideas would be appreciated.
It is definitely possible. CANoe allows usage of CANoe TCP/IP Stack to isolate Ethernet Communication from ECUs from Windows/OS ethernet communication. To use operating system stack :
In CANoe> Simulation Setup> TCP/IP Stack :
Select the Ethernet network used, set TCP/IP Stack Configuration for the particular network should be selected as "No TCP/IP Stack, use network of operating system"
This way CANoe will have access to windows system network adapters.
is there any bios interrupt that send and receive packet over the net?
if I want to make a boot loader which communicate with other computer, what am I supposed to learn?
any keywords? documents?
thanks
The standard PC BIOS has no runtime APIs for network communication.
Pretty much the only networking code you find in a BIOS is the PXE boot loader, which provides a pre-boot environment for downloading a kernel from a network server and executing it. This does not provide any post-boot runtime services though.
If you want to do network communication while you are running from disk, you need to implement your own networking stack.
We alread have a front panel based on uart commuication, I want to use it to commuicate to windows pc. The solution is use a chip covert UART to USB, chip driver on windows is virutal COM, the driver is shown in device manager and receives information from Front Panel, but it is not open source.
I want to know how can I develop a KMDF/UMDF driver to read/write the virtual COM driver to send KEY information to windows system, or let windows system recognise this is key info.
Please give me some sample code, links, documents or advice, thanks a lot.
Serial port KMDF sample: http://code.msdn.microsoft.com/windowshardware/Serial-73a4564d.
Look around there for additional documentation.
I am working on a smartcard reader project here i will have to read/write data from the smartcard reader.
Also i will have to read/write data from PC application.
There are two serial port on my microcontroller one connected to smartcard reader other to PC.
Smartcard reader <------> Microcontroller <-----> PC
I have ported linux & using /ttys0 & /ttys1 driver for this.
1> My question is if application have to find that some data is available to be read from the port than will i have to always check it with read() system call ?
2> Does ttys0 driver have internal buffer to store received data ? Or data is lost if application do not read data immediately ?
3> Here using seprate threads for rx/tx from each port, is it right approach ?
Please guide me i am new to Embedded linux.
//John
Yes, there's a fair amount of buffering on linux tty's.
You have a few choices for how to interact with them.
you can make them non-blocking, and frequently poll to see if you can read data from them (but this may result in uselessly spinning CPU cycles, slowing other tasks)
you can use select() to yield to the scheduler until one of your devices has data for you to act on
you can use blocking I/O, however since you have multiple ports that may also require multiple threads
TTY programming is similar to socket programming in Linux. So basically you can set the socket to be a asynchronous and receive a signal once data is available. Regarding buffering, yes it's buffered using two flipping buffers. You can check chapter 18 in Linux device drivers 3rd edition regarding TTY implementation in the kernel.
We are trying to connect two Hyper-V VMs through a serial port. Hyper-V exposes the serial port as a named pipe to the host system, and implements the server end of the named pipe. Consequentially, to connect them, we need to write a named-pipe client which connects to both VMs, and copies the data back and forth.
We have written such an application. Unfortunately, this application loses data.
If we connect two hyperterms, and have them exchange data, the transmission sometimes succeeds, but in many cases, the receiving end reports errors, or the transmission just deadlocks. Likewise, if we use the link to run a kernel debugger, it also seems to hang often.
What could be the cause of the data loss? What precautions must be taken when connecting named pipes in such a manner?
Edit: We have worked around the problem, using kdsrv.exe. The COM port of the debuggee continues to be exposed through a named pipe, however, the debugger end talks to kdserv via TCP.
The data loss is not due to the named pipes. It is infact the COM ports (emulated and physical) that may lose data since they operate with a small buffer in the UART.
The named pipe receives all the data that is written to the COM port. Your program reads data from the named pipe and writes it to another named pipe. This is where data loss can originate if you write too fast the receiveing COM port's UART can overflow leading to data loss.
You may need to add some delay to avoid exceeding the baud rate expected by the receiving side.
In addition, you are missing ResetEvent() calls in your program.
For your KD issues, you may need to add resets=0 to the connection string.
I did not try to connect VM via Serial but I connected VM and Host via usb (through network)
and it works.
If it is required for your software to establish serial connection try to test via serial emulators with work through tcp\ip.
I think John's suggestion is correct - if u are using a slow CPU to emulate TWO VM, then the guest OS's drivers for serial port is highly drifted away from the high speed version. So John's suggestion is to set the input/output side of the serial link to the slowest possible speed. Ie, you cannot use high baud rate for the inter-VM serial communication. Instead u have to use the slowest possible speed, and so that the VM guest driver will take that cue and use the slower version of the driver. But your physical machine must have sufficient CPU speed to run two VM concurrently, to avoid the "emulation drift" of the the serial driver.
Well, just my guess, but there is a VirtualBox version of your problem, seemingly no issues running it:
http://bodocsi.net/2011/02/how-setup-serial-port-link-in-virtualbox-between-two-guest-virtual-machine-in-linux/
But the following bug ticket for VirtualBox does describe many similarities to your problem:
https://www.virtualbox.org/ticket/1548
And reading the end seemingly indicate the solution has to do with VirtualBox's internal source code. Perhaps it is Hyper-V's problem?