Does anyone know a good library to allow us to programmatically monitor a parallel port (or LPT port) in windows. There are lots of good ones for Serial ports but I have had no luck yet for parallel ports. C# would be preferred but we're happy to do the Interop work if it's c / c++.
Thanks
You need a driver that gives access to the parallel port. The inpout32.dll solution is nearly universally used. It also lets you pinvoke helper routines to execute the INP and OUT cpu instructions. Everything you'd ever want to know about parallel ports, including coding samples for inpout32 is assembled at Jan Axelson's home page.
Are you looking for something like this? How to find available parallel ports and their I/O addresses using Delphi and WMI its in Delphi, but I think you can find WMI in C# too.
Related
How to go about to get the process id of a process blocking a certain COM Port on Windows 7 and/or later?
I would like to get the PID programmatically. If possible using Python or C# but the language is not really important, I just want to understand the procedure.
This question has been asked numerous times on SO and many other forums for the last 10 years or so. The generally accepted answer is to use sysinternals to find the process using the particular file handle. Remember, a serial port is really just a file as far as the win32 api is concerned.
So, two answers for you:
Use sysinternals to find to offending application. I don't think this approach will work via python but you might hack something with .NET.
Use the NtQuerySystemInformation in a getHandles function. Take a look at the structures and figure out which fields are useful for identifying the offending process.
os.system("taskkill blah blah blah") against known serial port using apps. More on this idea at the end.
The 2nd idea sounds fun, however I just don't think the juice is worth the squeeze in this case. A relatively small number of processes actually use serial ports these days and if you are working in a specific problem domain, you are well aware of what the applications are called.
I would just run taskkill (via os.system) against any applications that I know 1) can be safely closed and 2) might actually have a port open. With this approach you'll save the headache of enumerating file handles and get back to focusing on what your application should really be doing.
I want to send a signal from a C++ application to a C# application. This is only to let the C# program know the other one is running. I already use C# but I'm not really good at C++ yet. Do I have to create pipes or is there a quicker and/or easier way to do this?
IPC is easy using the classic WM_COPYDATA. A good example can be found here.
I haven't found any very good resources in my search for answers to this question. At present I am using a TI CC2540 HCI over COM Port. I would like to move away from this solution for cost reasons. Commercial bluetooth low energy USB dongles can be had for very cheap. Let's use a CSR8510-based device for example.
I would like to implement the host and application with the CSR8510 dongle acting as the 'controller'. It does not use a serial port for HCI transport. How can I send/receive commands from this controller? CSR Support is not interested in discussing this because my quantities are too low (~10k)
I would like to specify certain low level options such as connection parameters, scan modes (limited discovery, general, etc.) so I need a relatively high level of control over the 'controller' dongle. Writing a kernel mode driver is not a route I can take.
Example dongle
The linux kernel will handle a lot of stuff for you if you open up an HCI socket. You can also open up L2CAP sockets to make connections to devices. Unfortunately the documentation is lacking (I've actually never found any), but the source code is fairly readable. Take a look at the Bluez gatttool to see how they access bluetooth dongles via sockets.
Note: there's a nasty bug in kernels <= 3.4 where multiple L2CAP connections get mixed together when using an L2CAP socket.
Here's a previous answer I gave to another question with some sample code: bluez with simultaneous classic and low energy devices
Can any ony kindly explain that how we can take serial data as input from parallel port using c#.
Or the serial communication through parallel port.
I really wouldn't transmit your data this way as you are heading for a world of pain. Far better to use a serial to USB IC such as the excellent ones made by FTDI. In simple terms these take your TTL serial data send it via USB. Thanks to the FTDI drivers the data appears as a virtual serial port which your program can read from in the usual way.
Hope this helps.
Ian
It is not clear from your question if you are looking for a software or hardware solution. AN external serial to paralell converter (hardware) provides the simpliest solution.
If you are looking for a software only solution, you want to do "bit banging". Unfortunately this requires precise timing, something which may be extremely difficult in managed code. This sort of program is typically implimented in a lower level language such as assembler or C where one has direct access to the hardware. Here is another article specifically addressing the use of the paralell port for serial communications.
It sounds like you're doing something wrong. If you need serial input, why not use the serial port? I believe that the RS232 standard is widely supported. The parallel port is for parallel data transfers.
Can standard pointers in .Net do this? Or does one need to resort to P/invoke?
Note that I'm not talking about object references; I'm talking about actual C# pointers in unsafe code.
C#, as a managed and protected run time engine, does not allow low level hardware access and the memory locations associated with actual hardware are not available.
You'll need to use a port driver or write your own in C++ or C with the proper Windows API to access the memory mapped I/O regions of interest. This will run in a lower ring than the C# programs are capable of.
This is why you don't see drivers written in C#, although I understand many are writing access routines with C++, but the main driver logic in C#. It's tricky, though, as crashes and restarting can become tricky, not to mention synchronization and timing issues (which are somewhat more concrete in C++ at a lower ring, even though windows is far from a real-time system).
-Adam
To expand on Adam's answer, you can't even perform memory-mapped I/O from a Win32 application without the cooperation of a kernel driver. All addresses a Win32 app gets are virtual addresses that have nothing to do with physical addresses.
You either need to write a kernel driver to do what you're talking about or have a driver installed that has an API that'll let you make requests for I/O against particular physical addresses (and such a driver would be a pretty big security hole waiting to happen, I'd imagine). I seem to recall that way back when some outfit had such a driver as part of a development kit to help port legacy DOS/Win16 or whatever device code to Win32. I don't remember its name or know if it's still around.