Try to use inpout32.dll

For issues with communication ports, protocols, etc.
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Try to use inpout32.dll

Post by MrSwiss »

INP and OUT do NOT work, except, in the DOS version of FBC.
It depends on the operating system (OS) to allow/disallow direct hardware (HW) access.

Multitasking OS's like WIN/LIN don't allow direct HW access.
Therefore, a driver is mandatory.
The .dll itself (without the driver being installed) is useless.
It only provides a means to communicate between application and driver.
To cut a long story short, you'll need them both.

Btw: driver installation is a once only thing (this requires "ADMIN/ROOT" privileges).
danube7
Posts: 10
Joined: Nov 16, 2018 20:29

Re: Try to use inpout32.dll

Post by danube7 »

Hi MrSwiss,

Thanks for the reply. What you said is sort of what I expected. Perhaps that point about the INP and OUT only working in DOS should be made more clear. The help file text does not refer to any specific OS.

As for the majority of the posts relating to this topic, it is not at all clear what version of FBC folks are using, what OS, etc. So it's very hard to understand why some folks have success and others not, and thus can't figure out how to proceed.

What I do understand is the following. Way back when, in the DOS days, direct port access, as needed by INP and OUT was allowed by Windows. Then XP came along and new external drivers were needed. INPOUT32.dll was written to solve this problem. These are the "Logix4U" drivers. Then windows 7 and 64 Bit OSs came along and the drivers needed to be re-written and signed. Phil Gibbons re-compiled the drivers and got them signed so they work in Windows 7. These are the "InpOut32 (x64)" drivers from "http://www.highrez.co.uk/downloads/inpout32/". The confusing part of those drivers is that in order to maintain compatibility, the name of the driver file is unchanged, but that file actually contains BOTH 32 and 64 bit drivers.

The problem is those latest drivers are now 10 years old, and Phil is no longer supporting the project. I am not sure what is entailed in getting a driver "signed" or what the direct implications are to FB, but if Windows no longer accepts those as legitimate drivers and doesn't allow them to be loaded, we are SOL.

It is the Highrez drivers that I have not had any luck installing on Windows 7 running FB. I know they work because around 2016, I had them working using a QB64 application. I ran into a weird problem then in that INP and OUT worked fine, and I could open a COM port by talking directly to the UART registers using those functions, but ONLY if there was a third party program first opening the port. I tried to resolve that problem but ran into a brick wall with one of the QB64 power users who really didn't understand the workings of a COM port so I got nowhere. I was forced to switch to FB (not a bad thing in the end). Since then, the QB64.net website crashed permanently and I gave up on trying to get QB64 to work. Although the QB64 forum is back on line (at QB64.org), the community here is much more responsive.

So, that sort of leads me to a couple questions.

1) Regarding the Hghrez drivers, does anyone have proof they work on Windows 10, using FBC 1.06 or 1.07?
2) How do I install the Highrez drivers in windows *manually*? I know there is an install file for the 32 bit version, and it reports success when I run it, but success I do not have. I get some of the same errors that others have reported in this thread. FBC is a 32 bit application? So I need the 32 bit drivers? Or is it 64 bit?

3) In the event the Highrez drivers can't be made to work, are there other drivers that have functioning INP and OUT routines that can be made to work?

So, I hope someone can help me and if I get these working, I intend to write up very carefully what I did to do so. I look forward to further replies. Thanks MrSwiss and others and stay safe wherever you are.

Dan
MrSwiss wrote:INP and OUT do NOT work, except, in the DOS version of FBC.
It depends on the operating system (OS) to allow/disallow direct hardware (HW) access.

Multitasking OS's like WIN/LIN don't allow direct HW access.
Therefore, a driver is mandatory.
The .dll itself (without the driver being installed) is useless.
It only provides a means to communicate between application and driver.
To cut a long story short, you'll need them both.

Btw: driver installation is a once only thing (this requires "ADMIN/ROOT" privileges).
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Try to use inpout32.dll

Post by MrSwiss »

Hi Dan,

first and foremost: I've never needed INP/OUT for serial communications ... they're outdated.
(I'm pretty certain that they're only kept for the DOS version of FBC.)
danube7 wrote:1) Regarding the Hghrez drivers, does anyone have proof they work on Windows 10, using FBC 1.06 or 1.07?
Well, I've not tried myself but the point with WIN drivers is typically: they work or they don't work.
(since people got it working, I assume that they must be OK)
In most cases independent of WIN version or FBC version. Just remember this applies to Windows_NT
and not the old "DOS based" Win9x versions.
Windows_NT = fully fledged operating system: 32 or 64 bit.
Windows 9x = DOS based graphics WinGUI (DOS is the OS below)

Most important for all external libraries: the lib. bitness MUST match the bitness of FBC (compiler).
In this case the driver too, but installers typically choose the appropriate version.
danube7 wrote:2) How do I install the Highrez drivers in windows *manually*? I know there is an install file for the 32 bit version, and it reports success when I run it, but success I do not have. I get some of the same errors that others have reported in this thread. FBC is a 32 bit application? So I need the 32 bit drivers? Or is it 64 bit?
As with everything else that is external to FBC, you'll have to refer to the documentation on the externals (.dll's whatever).
They are never covered by FB-Documentation (for obvious reasons).
danube7 wrote:3) In the event the Highrez drivers can't be made to work, are there other drivers that have functioning INP and OUT routines that can be made to work?
Can't answer that one, because I've never felt to need them (Open Com always did it, for me).

Best approach for solving such issues:
provide your sources, together with the errors/warnings at compile time.
danube7
Posts: 10
Joined: Nov 16, 2018 20:29

Re: Try to use inpout32.dll

Post by danube7 »

Thanks MrSwiss,

I will proceed more carefully with the Highrez drivers (which I know worked for me at one time) and report what error messages I get. But that will take time as I will need to be methodical.

Agreed about COM. I started on this path because QB64 did NOT work properly when opening the com port. That same problem I described earlier where I required a third party serial COM program to "open" the port for me allowed me to use INP, OUT and OPEN COM, but only while that third party program was running. In doing that, I found some interesting uses for INP and OUT.

For example, *instead* of opening the COM port using OPEN COM, you can write directly to the UART to control all the features of the port. For one thing, this allows one to assert DTR independently of the OPEN command. That enables "DTR signaling" as a user in a post in this forum inquired about at one point. Being able to control the DTR and RTS lines like that gives me 2 more "bits" to control DIY hardware, hence the interest. But, if in the end if I cannot do it, at least I can open the port conventionally and have serial port control - that is invaluable.

We've got USB, Ethernet, wireless,... but despite all that, one of the simplest, most efficient ways to connect to a precision voltmeter (like the HP/Agilent 34401 or the Keithley 2000 series) is through the serial port. As long as BASIC is relevant, so is the serial port; they've both been around since the 1960's.

Thanks,
Dan
12val12newakk
Posts: 35
Joined: Nov 14, 2019 17:04

Re: Try to use inpout32.dll

Post by 12val12newakk »

I want to connect the MCP3201 directly to the LPT
to get the code from the ADC requires 50 requests to the port.
one request( for both writing and reading )using this library takes 3+ μS.
I remember exactly that when it was under Windows xp
through the built-in access to ports, the request was 1.2 μS.
How can I reduce the request time ?

here is the working code STM32

Code: Select all

   unsigned short Read_MCP3201 (void)
{
   int i=0;    
	unsigned short  AdcResult=0;   //must 16 BIT 
        CS_MCP3201_High;  ///CS   
	      __disable_irq ();
       for(i=0;i<16;i++)
       {
             CLK_MCP3201_Low;  //ADC_CLK=0 
			  	   CLK_MCP3201_High;  ///clk
			      AdcResult<<=1;   
       if(HAL_GPIO_ReadPin(DATA_MCP3201_GPIO_Port, DATA_MCP3201_Pin))  
							{ AdcResult |= 1;}   
       }  
			   __enable_irq ();
      CS_MCP3201_High;  ///CS 
			    AdcResult<<=3;
           AdcResult>>=4;   
       return(AdcResult);                          
 }
mon2
Posts: 1
Joined: Dec 13, 2020 17:50
Location: Windsor, Ontario, Canada
Contact:

Re: Try to use inpout32.dll

Post by mon2 »

calatorius wrote:EUREKA!

I got it, it's incredible but the only thing to run was to have the .def file create with pexports in inpoutx64.dll.
with this code:

Code: Select all

#inclib "InpOutx64"
Declare Sub Out32 Alias "Out32" (port As short, data As short)
Declare Function Inp32 Alias "Inp32" (port as short) as short
Dim As short MyData=2, MyPort=&h61
print inp32(&H3da)
Print "all is fine"
sleep
And the dll with its .def in the same directory compile and run fine.
The fact is that I don't know why inclib needs a def file :|
@calatorius, could I trouble you into sharing the full details of this process?

Stuck in the same spot as you were. Very new to FB and have a few hours into this but chasing my own tail.

Have inpout32 and inpoutx64 downloaded on my Win10 x64 box; driver installed ok.

Now attempting to declare the DLL access and running into the same issues.

Built the .def files as follows:

pexports inpoutx64.dll > inpoutx64.def
pexports inpout32.dll > inpout32.def


all files are inside the same folder.

mytest.bas file:

Code: Select all

#inclib "inpOut32"
Declare Sub Out32 Alias "Out32" (port As short, data As short)
Declare Function Inp32 Alias "Inp32" (port as short) as short
Dim As short MyData=2, MyPort=&h61
print inp32(&H3da)
Print "all is fine"
sleep
Compiling at the command prompt yields:

Code: Select all

C:\Program Files (x86)\FreeBASIC>fbc mytest.bas
mytest.o:fake:(.text+0x36): undefined reference to `Inp32@4'
Any suggestions / hints on how to fix this issue?

Will keep trying in the meantime. Have attempted to use gendef tool with the same results.

The gendef tool creates a different .def file

Code: Select all

C:\Program Files (x86)\FreeBASIC>type inpout32.def
;
; Definition file of inpout32.dll
; Automatic generated by gendef
; written by Kai Tietz 2008
;
LIBRARY "inpout32.dll"
EXPORTS
Inp32@4
Out32@8
IsInpOutDriverOpen
DlPortReadPortUchar@4
DlPortWritePortUchar@8
DlPortReadPortUshort@4
DlPortWritePortUshort@8
DlPortReadPortUlong@4
DlPortWritePortUlong@8
IsXP64Bit
MapPhysToLin@12
UnmapPhysicalMemory@8
GetPhysLong@8
SetPhysLong@8
srvaldez
Posts: 3373
Joined: Sep 25, 2005 21:54

Re: Try to use inpout32.dll

Post by srvaldez »

@mon2
the .def file is only used/needed to build an import lib
you don't need an import lib to use a dll but the dll needs to be either in the FB lib folder or where your program source is located
also the dll needs to be either where your executable is or on the system path
Post Reply