All Forums
 Hardware
 General Hardware, ADSmartIO, Digital I/O and A/Ds
 GCX DIO and A/D & QueryPerformanceCounter issues
 Forum Locked
 Send Topic to a Friend
 Printer Friendly
Author Topic  

Jim Najpauer

9 Posts

Posted - 02 Mar 2007 :  08:09:40  Show Profile  Email Poster
GCX:

1 - The manuals available do not define the software location of the leds.

Through testing we found the leds as follows:

LEDOUT2 BIT_20 // LED2 D1 Red PXA GP21
LEDOUT0 BIT_19 // LED0 D3 Green PXA GP20
LEDOUT1 BIT_18 // LED1 D2 Amber PXA GP19

2 – During testing we noted that "error" information is/can be output on the serial port rather than be returned by the function GetLastError.

While working with the DIO interrupts we found the following (output by the GCX serial port):

DIO_EnableInterrupt : HWInt: 0xX Mode: 0xX
ParameterError (InterruptMode & ~ValidInterruptModeFlags[X]).
OEMInterruptConnect: FAILED -- BAD PARAMETER(S).
InterruptConnect: Error From KernelIoControl()
DIO_EnableInterrupt :
InterruptConnect for interrupt 0xX returned NULL
DIO_EnableInterrupt failed, disabling interrupt.

In what document is this information defined?


3 – The interrupt(s) (pulsed events) we have functioning appear to indicate that a spurious initial interrupt is being generated; but at this point in time we have not-yet confirmed this.

Is there any specific information not yet in the documentation with respect to interrupt(s)?


4 - The DIO specification defines IOCTL_GET_DRIVER_VERSION as 0xA0.

When we execute this, to get the version, we are not successful. GetLastError returns 0x20100501.

Example code:

BOOL ok;
DWORD bytes;
#define DIO_DRIVER_VERSION_SIZE_10 10
wchar_t version[DIO_DRIVER_VERSION_SIZE_10];

ok = DeviceIoControl(
hdioDriver,
DIO_IOCTL_GET_DRIVER_VERSION, // = 0xA0
NULL,
0,
&version,
sizeof(version),
&bytes,
NULL);
if(ok){
RETAILMSG(1, (TEXT("\\r\\n L returned: %d)"), bytes));
}else{
// GetLastError returning: [0x2010 0501]
DWORD error = GetLastError();
RETAILMSG(1, (TEXT("\\r\\n GetLastError: 0x%x"), error));
}

Example code execution output: GetLastError returned 0x20100501


5- We are unable to locate the "error codes" mentioned in the specifications.

The winerror header does not explicitly define the values we see.

Examples of GetLastError return values: 0xE0100004, 0x20100501, 0xE0100003,


6 – Our initial test of/on the analog inputs, specifically AIN1 through AIN4 showed that it was usable.
However we cannot locate information relative to obtaining version information, and
record data appears to indicate that "abnormal reads" are being performed.

Example code:

// Defined ADS AIN errors must be above a 10-bit value (i.e. > 0x3FF)
#define AIN_ERROR_HANDLE 0xFFFFFFFE
#define AIN_ERROR_READ_VALUE 0xFFFFFFFF

BOOL readOk;
DWORD ainValue, ainBytes;
HANDLE hain = NULL;

hain = CreateFile( // return HANDLE hFile
TEXT("AIN1:"), // LPCTSTR lpFileName
GENERIC_READ, // DWORD dwDesiredAccess
0, // DWORD dwShareMode
NULL, // LPSECURITY_ATTRIBUTES
OPEN_EXISTING, // DWORD dwCreationDispostion
FILE_ATTRIBUTE_NORMAL, // DWORD dwFlagsAndAttributes
NULL); // HANDLE hTemplateFile
if(hain){
readOk = ReadFile( // return BOOL (non-zero is success)
hain, // HANDLE hFile
&ainValue, // LPVOID lpBuffer
sizeof(ainValue), // DWORD nNumberOfBytesToRead
&ainBytes, // LPDWORD lpNumberOfBytesRead
NULL); // LPOVERLAPPED lpOverlapped

if(readOk){
return(ainValue);
}else{
RETAILMSG(1, (TEXT(" ERROR: AIN ReadFile\\r\\n")));
CloseHandle(hain);
return(AIN_ERROR_READ_VALUE);
}
}else{
RETAILMSG(1, (TEXT(" ERROR: AIN CreateFile")));
return(AIN_ERROR_HANDLE);
}

CloseHandle(hain);

An example of an "abnormal read" is the value 0x3FF.


In summary:

With respect to DIO:
In what document is serial output information defined?
Is there any specific information not yet in the document with respect to interrupt(s)?
How, in software does one read the version information?
Where are the "error codes" defined?

With respect to the Analog Inputs (AIN1..4):
How, in software does one read the version information?
How are "abnormal readings" avoided?


Looking forward to your response
Regards
jim
Sent 02-Mar-07 08:18am

Jim Najpauer

9 Posts

Posted - 02 Mar 2007 :  08:36:04  Show Profile  Email Poster
Just an update with respect to the "abnormal readings" on the analog inputs:

Over-night testing of the analog input channels showed no "abnormal readings". However when the touch screen was accessed "abnormal readings" occured.

Appears that there might be an issue with the touch screen driver.

Any thoughts?
Go to Top of Page

akidder

1519 Posts

Posted - 02 Mar 2007 :  13:44:22  Show Profile  Email Poster
Thanks for the details both here and to our sales group. We're going through the items and will respond to you shortly.

Feel free to contact us at support.us@eurotech.com any time you hit a snag in your development process.
Go to Top of Page

Jim Najpauer

9 Posts

Posted - 04 Jun 2007 :  08:04:12  Show Profile  Email Poster
Thank you for letting us know that analog channel input readings have been fixed on the GCX.

We have been doing some preliminary time measurement testing... we have found that the QueryPerformanceCounter function cannot be used as the counter is non-monotonic, i.e. counter will jump backward!

We looked on the ADS forum and have noticed the above function has been corrected on the BitsyX, AGX and VGX.

Has this function been corrected on the GCX?
Go to Top of Page

jjoseph

47 Posts

Posted - 04 Jun 2007 :  15:10:55  Show Profile
This fix should be incorporated into the GCX 4.20.21 build and builds 5.00.06 and later.

If you have difficulties with this feature on these builds please let us know at support.us@eurotech.com.
Go to Top of Page

Jim Najpauer

9 Posts

Posted - 12 Jun 2007 :  07:52:43  Show Profile  Email Poster
We’ve downloaded the GCX 4.20.21 build (dated 23-May-2007).

We cannot perform time measurement testing ... the QueryPerformanceCounter function cannot be used as the counter is non-monotonic, i.e. counter will jump backward!

The following example code can be used to replicate the problem:


int WINAPI WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPWSTR lpCmdLine,
int nCmdShow){
//
LONG ldC, X=9;
LARGE_INTEGER startCount, endCount, deltaCount;
//
while(TRUE){
QueryPerformanceCounter(&startCount);
X = X * X * X;
QueryPerformanceCounter(&endCount);
//
deltaCount.QuadPart = endCount.QuadPart - startCount.QuadPart;
//
ldC = (LONG)deltaCount.QuadPart;
//
if(0 > ldC){
RETAILMSG(1, (T("\r\nStart Count: 0x%016I64X"),
startCount.QuadPart));
RETAILMSG(1, (T("\r\nEnd Count: 0x%016I64X"),
endCount.QuadPart));
}
}
//
//
//--------------
Results:
Start Count: 0x0000000A5354784C
End Count: 0x0000000A5354783A

Start Count: 0x0000000ADFF02B83
End Count: 0x0000000ADFF02B70

Start Count: 0x0000001350225A1E
End Count: 0x00000013502259FA



Looking forward to a quick response
Go to Top of Page

beitman

63 Posts

Posted - 18 Jun 2007 :  09:26:41  Show Profile  Email Poster
Jim:

Thank you for pointing this issue out and supplying your example code. This was in fact a problem with the GCX. I have submitted a new build to our validation lab with a solution to this issue.

The support team will keep you posted on the release.

Bruce Eitman
Go to Top of Page

Jim Najpauer

9 Posts

Posted - 18 Jun 2007 :  10:47:45  Show Profile  Email Poster
Bruce,
Thank you.
Meantime could you please confirm that OS Timer, address 0x40A0_0010, OSCR OS Timer Counter Register is monotonic - we are using this while we await the build.
Go to Top of Page
  Topic  
 Forum Locked
 Send Topic to a Friend
 Printer Friendly
Jump To:
Eurotech Support Forums © Eurotech Inc. Go To Top Of Page
This page was generated in 0.05 seconds. Snitz Forums 2000