[RESOLVED] Access same serial port by different process?

Hi Gurus,

I am writing a dll for communicating with another device through 1 serial port.
I tried using 2 applications to load this dll and find that only the first application could access the com port. I could manage to get these 2 application to share a varaible in this dll but do not know how to share the com port.
Seems like the handle to the com port in the dll could not be shared by different processes.

Is there any way to achieve this?

Hope I could be enlightened.

Regards,
Learner_ng

When you open a COM port, you use set dwShareMode = FILE_SHARE_READ, FILE_SHARE_WRITE.

Here is my example:
CreateFile( "COM1",
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED,
NULL);

I would say that you can not use DLL for this purpose. Use .EXE COM server that will open serial port once and then manage all connections to it or write custom driver. For my application I've used .EXE server.

Use .EXE server?
Pardon me for being an ignorant learner, I've never done this before, moreover I couldn't change the design as I like as I'm only task to write for certain portion of the dll.
Anyway thanks.
Is there really no way to do this? I think I'll try the dwShareMode = FILE_SHARE_READ, FILE_SHARE_WRITE. method.

Learner

Hi Quang,

I tried the method of using dwShareMode = FILE_SHARE_READ, FILE_SHARE_WRITE. It doesn't seems to work for me.
Did you actually succeded doing it?

Regards,
Learner

I don't think the serial port can be shared. You should try the .EXE server solution posted above. What it means basically is that you'll have a proxy to the serial port. Your application will be the clients/consumers.

But you'll have to be extracarefull to dispatch the data received on the serial port to the correct consumer.

Here is the deal: you might be able to get away with DLL if your communication falls into the Master-Slave scenario where PC application is the master ALWAYS initiating communication and different programs do not have to access serial port at the same exact time. If this is the case then you could use synchronization objects to control access to the serial port.

Your communication routine might look like this:

Code:

---

1. wait until serial port is available (use named mutex to do this)
2. open serial port  (obviously check for errors)
3. configure serial port (baud, parity, etc)
4. write data to the serial port
5. wait until the data is transmitted COMPLETELY out of the serial HARDWARE NOT SOFTWARE TX buffer
6. if you expect device to respond then wait for the responce data read data if it is received or time out if it is not received
7. close serial port
8. release serial port (release mutex)

---

Once again this is only possible if
a) your communication is syncronized and is driven by your software on the PC end
b) your PC applications access serial port independently (let's say it is NOT the case when one application is communicating to the device and the other one is monitoring communication).

The terminology suggest is somewhat confusing (cleint :( , server :eek: proxy.. :cry: ) but the way it will work is this.

Yes you have to use sort of client/server architecure but thats not exactly the one used in networking - just the model part. You need to to use your dll by one application and this application may not even have any user interface. All the other application which needs the port basically talk to the port through this application and one good way to implement this communication is through pipes.

I hpe this give some pointers.

Hi All,
Glad to see so many expert opinion.

Regarding changing the architecture from dll to something else, that is really my last resort as I'm only writing portion of this dll, moreover its not up to me to decide on this change. I'll try to propose this if all else fails with the Dll.

Regarding Opening of the port and closing it, I've somehow thought about it and discussed about it. It might be too cumbersome and slow to implement that way, but might be an eventual solution and we're Keeping this in view.

On the part of using pipes? I've never used pipes before. Are you implying I could use pipe in the dll to achieve this? Hmmm.. Maybe I should research on pipes.

Well I've also heard about duplicating the handle or inherit it in order to share the port access. Wonder any one could have an tips on doing it? I tried specifying the security_attributes bInheritHandle to true but it doesn't seems to work.

Learner

Oh read up on pipes. So pipes is actually used for a server application to communicate with a client appication right? In that case, it means I can't use it in the dll. Hmm.. Guess its really hard to achieve this "mission impossible" bounded with many restriction. :( But do learn alot from you guys ;)
I'm still not giving up on this. Will keep look out for more alternatives (if there is) for the dll method.

yes your serial application would use the dll as you have implemented it - there is not change there. Now other application will talk to this application through pipes for all their serial requests.

Quote:

---

Regarding Opening of the port and closing it, I've somehow thought about it and discussed about it. It might be too cumbersome and slow to implement that way, but might be an eventual solution and we're Keeping this in view.

---

It may be slow depending on what you are trying to do. Obviously, I do not have any idea of what exactly you guys are trying to achive but serial communication is not the fastest thing in the world (right?). I mean the time it will take to open and close serial port really becomes irrelevant at this point.

In regards to creating an .EXE COM server that will allow you to share the serial port it does not really involve redesigning the whole project. You'll just need to move the low level part of communication into a stand alone executable. Your DLL in this case will contain a higher level communication routine that will be used by all of your applications. In this case, as PadexArt mentioned "you'll have to be extracarefull to dispatch the data received on the serial port to the correct consumer". In other words when you receive data from the serial port you will need to know exactly which application it needs to be dispatched to. You will also still need to synchronize the way applications write to the port to prevent data corruption (just like in case when you have 2 threads writing into the same file buffer). The bottom line is - you will have to send/receive data in packets (which is fine if your hardware on the other end of the cable can do that).

Hi Gradiov,

You're right that serial comms itself is slow but we've no control over that as that device is only using serial com to talk. But apart from that we'll try to reduce the lag in every possible way. Regarding the .EXE com server, I'll keep this in mind. Will Try to propose this method for consideration. Anyway its always good to learn new things.

Reply,
I'm a bit confused. the applications are now loading my Dll and accessing the function using the function pointers. How do pipes play their role in this? I thought All the applications need is to call the Dll function ? Pardon me, I'm really not pretty well verse in programming. Or maybe after I read more about using pipes before getting your attention.

Thanks so much . :)

Well, since the data is coming through the serial port assincronosly and you do not have any control over when device on the end sends data, then polling approach (open/close) just won't work for you.

In regards to the pipes - it is just a way of communicating between several applications which you can use just as any other one available (RPC, DDE, Shared memory etc.). My point though is that regardless of what you will choose to communicate between the processes you still can have only one program having a direct access to the serial port and that it will serve data to all other ones.

I would say - forget it !

A serial port is what it says it is - a port on the computer.

Only one application can access the port at any time - or, if you are using sharing, all of your applications have access to the port at the same time.

You can't have your cake and eat it in this instance.

Either

(1) You only have one application reading from the port.

or

(2) All applications read from the port, and will receive the same data.

You are running down a dead end in your (implied) assumption that COM port access works the same as network sockets (which I think is where you got the idea from in the first place - am I right ?).

So, make your decision and write your application appropriately.

Of course, if you control the server-side of the COM port then you can have a protocol (i.e. messaging system) which will enable multiple connections - just all connections will use the single connection and the message 'header' (i.e. the first few bytes) will tell server what 'connection' it needs to access.

So, you could have a connect, send, and disconnect message which wraps up the data on a per-client basis so server (which must have the concept of multiple connections) knows which 'virtual' connection to send the data to.

E.g. let's say that every client has a unique ID which is an integer. Before each message, you send the client ID so that server can then relate this ID to wherever the message needs to go to in order to be processed.

That's going to take ages to explain... it's the kind of operation I could write a chapter about in a book.

It really does depend on what control you have on server side code.

Darwen.

Hi All,

Actually my dll is the only one accessing the comport. There is no problem getting data and returning data to the different application loading my dll.

Example
I got 2 application both loading my dll concurrently. Let them be APP1 and APP2 where APP1 is the first application loading the DLL.
2 functions in my DLL. DLL_Ftn1, DLL_Ftn2
DLL_Ftn1 just computed some end result based on input parameters and return the result.
My DLL_Ftn2 actually gets data from from calling Application and sends over to comport. note that the dll is the only one accessing the com port.

APP1 and APP2 could call DLL_Ftn1 with different input arguments and also get the different computed result succesfully. This shows that there is no problem for the dll to dispatch data to the APP1 and APP2 although they both make calls to the same DLL_Ftn1.
I think that's because the DLL has got seperate data space for APP1 and APP2.

Problem lies here. When APP1 make calls to DLL_Ftn2, it works well. But when APP2 makes calls to DLL_Ftn2, it doesn't work. Although Dll generally has different data space, some data could be shared => APP1 and APP2 could both update a certain variable in the dll.
Although the dll is the only one accessing the com port, seems like the dll loaded by APP2 is not able to send the data out.
Is it really not achievable using purely a dll?

Learner

I think you are really confusing yourself with the way you understand DLLs. Your DLL does not access the serial port! It does not have it's own processing space. It is loaded into the other application's processing space and all it does is provide code for App1 and App2 to access the serial port (the same way as MFC DLL provides your applicaitons with high level routines).

I see that dll is able to share data between different processes using #pragma data_seg, that's why I thought its able to have its data space.
Hmm.. I guess you're right. Looks like using Dll for this function is really no way out.
Thks for your time and effort. :))

Regards

Leaner