From: Martin.Kellermann on
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
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
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