GPIO under Windows 10 supported ?

[af0815]

There are comming some Intel Motherboards (8th Gen Intel® Whiskey Lake) ECM-WHL_2824 with GPIO.

In the manual you found 8 GPIOs

Signal PIN PIN Signal
DIO_GP20 1 2 DIO_GP10
DIO_GP21 3 4 DIO_GP11
DIO_GP22 5 6 DIO_GP12
DIO_GP23 7 8 DIO_GP13
SMB_SCL_S0 9 10 SMB_SDA_S0
GND 11 12 +5V

Has somebody experience howto deal with this GPIO under Windows 10 ! Is this possible to handle the GPIO from fpc/Lazarus ?

[PascalDragon]

More often than not these GPIOs are not available to the outside world as they're either used by the chipset or are simply not connected to anything (without even pins available).

To use them nevertheless you'd probably have to check whether the driver that already binds to the GPIO controllers (which serve multiple GPIOs) provides an API. If you really have a board that allows you to connect GPIO pins then you should use Linux as that provides a GPIO API that can be used from user space across controllers.

[af0815]

I have got some information. There are drivers for win10 64 for this board and a library.

Headerfiles are available and the library too, but i see with the CFF-Explorer it is a .NET (see attached picture

 

Code: Pascal  [Select][+][-]

1. // AIODll.h : Declaration the entry point for the DLL application.
2. //
3.  
4. #ifndef __AIODLL_H_
5. #define __AIODLL_H_
6.  
7. #include "StdAfx.h"
8. #include "aiodef.h"
9.  
10. #ifdef __cplusplus
11. //extern "C" {
12. #define EXPORT extern "C" __declspec(dllexport)
13. #else
14. #define EXPORT __declspec(dllexport)
15. #endif
16.  
17. EXPORT ULONG __stdcall GetAvalueIOVersion(void);
18. EXPORT BOOL __stdcall AvalueIODLLStart(void);
19. EXPORT BOOL __stdcall AvalueIODLLStop(void);
20. EXPORT void __stdcall GetErrorMessage(PSTR);
21. EXPORT BOOL __stdcall PortOutput(UINT_W , UCHAR_B);
22. EXPORT UCHAR_B __stdcall PortInput(UINT_W);
23. EXPORT BOOL __stdcall PortWrite(UINT_W Port_Index, ULONG data, UCHAR_B size);
24. EXPORT ULONG __stdcall PortRead(UINT_W Port_Index, UCHAR_B size);
25. EXPORT BOOL MemoryWrite(ULONG addr, UCHAR_B data);
26. EXPORT BOOL MemoryWriteW(ULONG addr, UINT_W data);
27. EXPORT BOOL MemoryWriteDW(ULONG addr, ULONG data);
28. EXPORT UCHAR_B MemoryRead(ULONG addr);
29. EXPORT UINT_W MemoryReadW(ULONG addr);
30. EXPORT ULONG MemoryReadDW(ULONG addr);
31.  
32. EXPORT BOOL __stdcall InitialDigitIOPort(UINT_W);
33. EXPORT BOOL __stdcall ConfigDigitalIOPort(UINT_W);
34. EXPORT BOOL __stdcall DisabledDigitIOPort(void);
35. EXPORT BOOL __stdcall DigitalOutput(UCHAR_B);
36. EXPORT BOOL __stdcall DigitalOutputW(UINT_W);
37. EXPORT BOOL __stdcall DigitalOutputBit(UCHAR_B, UCHAR_B);
38. EXPORT UCHAR_B __stdcall DigitalInput(void);
39. EXPORT UINT_W  __stdcall DigitalInputW(void);
40. EXPORT UCHAR_B __stdcall DigitalInputBit(UCHAR_B);
41. EXPORT UCHAR_B __stdcall DigitalInputBitW(UCHAR_B);
42. EXPORT BOOL __stdcall DigitalInputPort(UCHAR_B *dat);
43. EXPORT BOOL __stdcall DigitalInputPortW(UINT_W *dat);
44. .....
45. #ifdef __cplusplus
46. //}  // for extern "C"
47. #endif
48.  
49. #endif
50.  

Is such a dll useable in fpc ?

[PascalDragon]

Headerfiles are available and the library too, but i see with the CFF-Explorer it is a .NET (see attached picture

The header you quoted is definitely a C/C++ header file, not a .NET one (and that should be easily portable to FPC). Is that really the only DLL available there? Cause C/C++ can't directly use a .NET assembly either (and no, this code does not look like C++/CLR).

[af0815]

There is a AIODLL.lib file too in the sample code. And *.cpp, *.vcxproj.* files too (= Visual Studio Files). The AIODLL.dll and some *.sys. *.inf, *.cat files are in the driver dir.

But it is good the codes looks not like a C++/CLR. I can not give more information or publish parts of the drivers/code (NDA).

[PascalDragon]

Can you use Visual Studio to compile the example and check whether the resulting executable links against the AIODLL.dll or not (you can use objdump.exe (provided by FPC) with argument -x for that)? If yes you could try to link against the DLL using FPC as well and execute for example the GetAvalueIOVersion() function. If not it might be doing something different... maybe it's using the .NET library as a COM component?