|
From: Martin.Kellermann on 23 Jun 2008 12:34 Hello group, I wanted to interface to some separate hardware from my VB6- application and perform DMA-accesses to and from it. For that I had the low-level drivers generated by the Jungo Driver Development Kit which also creates some sample-code for VB. Using this sample-code I could successfully write to my hardware and read from it over the PCIe-interface. My next goal is to have the hardware write to my processor for higher performance on upstream data. My initial idea was to declare a variable in VB and then transfer its address (found by using VarPtr) via RTLMoveMemory. The hardware would then write the appropriate amount of data into the address transfered (=into the variable). However, as one can imagine, this approach failed as the variable was most likely just sitting somewhere in cache without the processor knowing it was modified. What I am looking for is some idea on how I can do a DMA-transfer from hardware into software using VB. One idea would be a variable defined similar to "volatile" in C, however to from what I found this seems to be something that VB6 is lacking. If anyone could provide any ideas, I am very interested to hear. Cheers, Ye_ol_man
From: Jim Mack on 23 Jun 2008 15:07 Martin.Kellermann(a)gmx.de wrote: > Hello group, > > I wanted to interface to some separate hardware from my VB6- > application and perform DMA-accesses to and from it. > For that I had the low-level drivers generated by the Jungo Driver > Development Kit which also creates some sample-code for VB. > Using this sample-code I could successfully write to my hardware and > read from it over the PCIe-interface. My next goal is to have the > hardware write to my processor for higher performance on upstream > data. > My initial idea was to declare a variable in VB and then transfer > its address (found by using VarPtr) via RTLMoveMemory. The hardware > would then write the appropriate amount of data into the address > transfered (=into the variable). > However, as one can imagine, this approach failed as the variable > was most likely just sitting somewhere in cache without the > processor knowing it was modified. > > What I am looking for is some idea on how I can do a DMA-transfer > from hardware into software using VB. One idea would be a variable > defined similar to "volatile" in C, however to from what I found > this seems to be something that VB6 is lacking. How do you tell the driver what address to use? And can this address be a user-mode (ring 3) address, or must it be a kernel-mode (ring 0) address? Is the data transfer area presumed to be owned by the invoking process, or by the driver itself? Specifics would help. In general, a driver (and its buffers) live in system space and the driver would provide a mechanism for copying data between it and user memory. Directly connecting the driver to your process memory is not often supported. -- Jim Mack MicroDexterity Inc www.microdexterity.com
From: Martin.Kellermann on 24 Jun 2008 03:03 On Jun 23, 9:07 pm, "Jim Mack" <jm...(a)mdxi.nospam.com> wrote: > Martin.Kellerm...(a)gmx.de wrote: > > Hello group, > > > I wanted to interface to some separate hardware from my VB6- > > application and perform DMA-accesses to and from it. > > For that I had the low-level drivers generated by the Jungo Driver > > Development Kit which also creates some sample-code for VB. > > Using this sample-code I could successfully write to my hardware and > > read from it over the PCIe-interface. My next goal is to have the > > hardware write to my processor for higher performance on upstream > > data. > > My initial idea was to declare a variable in VB and then transfer > > its address (found by using VarPtr) via RTLMoveMemory. The hardware > > would then write the appropriate amount of data into the address > > transfered (=into the variable). > > However, as one can imagine, this approach failed as the variable > > was most likely just sitting somewhere in cache without the > > processor knowing it was modified. > > > What I am looking for is some idea on how I can do a DMA-transfer > > from hardware into software using VB. One idea would be a variable > > defined similar to "volatile" in C, however to from what I found > > this seems to be something that VB6 is lacking. > > How do you tell the driver what address to use? And can this address > be a user-mode (ring 3) address, or must it be a kernel-mode (ring 0) > address? Is the data transfer area presumed to be owned by the > invoking process, or by the driver itself? > > Specifics would help. In general, a driver (and its buffers) live in > system space and the driver would provide a mechanism for copying data > between it and user memory. Directly connecting the driver to your > process memory is not often supported. > > -- > Jim Mack > MicroDexterity Inc > www.microdexterity.com Hi Jim, some more specifics on what I'm doing. First of all I declare my variable, e.g. as long, afterwards I initialise the connection to my hardware. On a user-input I transfer the address of the variable to my hardware. On the hardware I receive this address and create a PCIe memory-write TLP to this address. The SW-application is stalled after the address-transfer until I have done the data-transfer from the HW: dim a& a=10'just to have a value in ...initialisation.. memCopy(VarPtr(Hardware-Handle), VarPtr(a),2) ' transfer the address to the hardware ' On the hardware I take this address and create a PCIe memory-write TLP to this address ' with a data-content of e.g. 20 msgbox "Click when you did the transfer back on the hardware" 'Suspend until the data-transfer has been done msgbox a' ==> Still shows the old value. That's the way I tell the driver which address to use. I guess, that's just a user-mode address and probably also owned by the invoking process. The trouble is, I'm less of a software guy but more in the HW. Working with drivers on the PC-side is something that I'm not really familiar with. Does the above make some sense or am I completely barking up the wrong tree? Cheers, Martin
|
Pages: 1 Prev: listview1 Next: How to load a function from a dll whose name is known only at runtime |