> I wanted to let you know that I tested the two methods, and there is no large difference between them in terms of timing. Â
Â
In that case I'd probably go with the dll method. It involves fewer physical parts to wear out and will get faster as CPU's get faster.
Â
>  I tested the timing by using VEE to tell me the time between when the loop started and finished, is this ok? Â
Â
Should be ok.
Â
> I believe that the rate determining step here is the data acquisition and processing by the card, Â
Â
For many data acq tests these days that is the case. At more than a billion (1e9 for non-US) clocks per second you can do a lot of number crunching in a millisecond. If you need the speed look at the measurement equipment and IO methods. Getting a 1000 element array of data from the equipment rather than a single point of data 1000 times is much faster. On the other hand, if the equipment can crunch the 1000 points of data into the one number answer you need then that is much faster.
Â
~~Les
---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Â
In that case I'd probably go with the dll method. It involves fewer physical parts to wear out and will get faster as CPU's get faster.
Â
>  I tested the timing by using VEE to tell me the time between when the loop started and finished, is this ok? Â
Â
Should be ok.
Â
> I believe that the rate determining step here is the data acquisition and processing by the card, Â
Â
For many data acq tests these days that is the case. At more than a billion (1e9 for non-US) clocks per second you can do a lot of number crunching in a millisecond. If you need the speed look at the measurement equipment and IO methods. Getting a 1000 element array of data from the equipment rather than a single point of data 1000 times is much faster. On the other hand, if the equipment can crunch the 1000 points of data into the one number answer you need then that is much faster.
Â
~~Les
---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Hey Duncan. No need to apologise - you've done your homework!
> If only VEE would let uint8
> values pass over the CFI, then
> everything would be ok!
Alas, it's a major bummer.
> however as I learnt later from
> the vrf archive this is a problem
> as when the data comes back, VEE
> takes a 0 byte to mean the end of
> the text, so this doesn't work (or
> maybe I am off the mark here?!?)
Nope, that's correct.
> Does anyone have suggestions on how
> to easily get around the problem, and
> allow me to get the right 512 unit8
> values displayed in VEE?
You were on the right track at first - short *pDst. As you found, VEE bumms
out on this and shows Int16 where UInt8 is desired. There are basically
three ways to handle the problem:
1. (Fastest) Write a dll to wrap this function, call it correctly in C and
cast the return values to short for return to VEE.
2. Use a buffer allocated with an alloc function, then use RtlMoveMemory
to copy one byte at a time to VEE Int16.
3. Swap & expand the Int16 values to UInt8 in VEE.
Method 1 is fastest, but uses a custom library:
WORD WINAPI Wrap_getram5(short cnt, short saddr, short *dest, short len)
{
INT i;
WORD wRet;
PBYTE pcDst = (PBYTE)malloc(len);
wRet = getram5(cnt, saddr, pcDst, len);
for(i = 0; i < len; i++) dest[i] = (short)pcDst[i];
return wRet;
}
Method 2 is very basic (change 3rd param in definition to int dest):
dest = GlobalAlloc(len);
getram5(cnt, saddr, dest, len);
realdest = AsInt16(Ramp(len, 0, 0));
(for count len, count output is i)
realdest[i] = GetUInt8(dest + i);
(end for count)
GlobalFree(dest);
GetUInt8 is a wrapper function that uses void __stdcall RtlMoveMemory(short
*pDst, int pSrc, long cb) to move 1 byte from pSrc to a VEE Int16 pDst.
There is no speed advantage over Method 3.
Method 3 loops through the Int16 array and swaps & expands the return values
back to their true form:
dest = AsInt16(Ramp(len / 2 + .5, 0, 0));
getram5(cnt, saddr, dest, len);
realdest = AsUInt8(Ramp(len, 0, 0));
(for count len / 2 + .5, count output is i)
realdest[i] = BitShift(dest[i], -8);
realdest[i + 1] = BitAnd(dest[i], 0xff);
(end for count)
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".