| Author |
Topic |
|
|
Jim Najpauer
9 Posts |
 Posted - 02 Mar 2007 : 08:09:40
|
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
|
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?
|
 |
|
|
akidder
1519 Posts |
Posted - 02 Mar 2007 : 13:44:22
|
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. |
|
|
|
Jim Najpauer
9 Posts |
Posted - 04 Jun 2007 : 08:04:12
|
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?
|
|
|
|
jjoseph
47 Posts |
Posted - 04 Jun 2007 : 15:10:55
|
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. |
|
|
|
Jim Najpauer
9 Posts |
Posted - 12 Jun 2007 : 07:52:43
|
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
|
|
|
|
beitman
63 Posts |
Posted - 18 Jun 2007 : 09:26:41
|
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 |
|
|
|
Jim Najpauer
9 Posts |
Posted - 18 Jun 2007 : 10:47:45
|
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. |
|
|
| |
Topic |
|
|
|
All Forums
Hardware
GCX DIO and A/D & QueryPerformanceCounter issues
Forum Locked
Send Topic to a Friend
Printer Friendly