Not sure that this is the correct title for the topic but anyway...
I am designing a system that has an embedded device connected to a PC. The PC runs a host application (in VB) and is "connected" to the embedded device using an "interface object" (which exposes a set of interfaces and in turn, communicates with the device over the application protocol).
The question is what type of object to use. One suggestion was that this should be a DLL that the the host program calls. Because there are things that have to be done periodicaly, the host app needs to execute some main exposed method in order to "drive" the DLL (like status checks etc). The other suggestion was that the DLL be made as an EXE which would run and open sockets etc. and then notify the host. The implication would be that the host needs to set up two threads, one for this communication object and the other for the GUI (and I understand that VB applications are not generally multithreaded).
Well, there is one host application (running GUI and business logic) that can, potentially, connect to a number of devices. In this case I assume that the host application will launch multiple instances of the object. I think that can be done if it is a DLL, but I assume not if it an EXE. Is this correct?
Also, it is correct that if it is a DLL, I would continuously have to call some method to have it perform it's continuous queries to the device?
I've been doing things like these for quite some time, so perhaps I have a few suggestions that would help.
First off, the question of using an EXE or a DLL. This is an easy thing to answer: are there any other software that might use the interface, in addition to this GUI & business logic application ? If not, then a DLL is more than enough. If yes, then using an EXE allows an added level of indirection, since the executable runs in a different process context. What we are talking here is that should there be a "server" that can be independently started and stopped which keeps status of the devices, and the GUI application queries the server, or should the GUI application be in charge of the status refresh. In the first case, it needs to be an executable, and in the second case, a DLL is enough.
Now, about the interface itself. I will use DLL as an example. Also, I recommend that you use C or C++ to program this DLL. Visual Basic is not very well suited for these kinds of tasks. Make no mistake, it's an alternative to building GUIs and business applications, but for interface objects/DLLs, Visual Basic outright sucks.
Since there might be multiple embedded devices, the DLL should contain an array of "device objects". Each of these objects holds relevant information (such as ID and status) of a single device. If the embedded devices can use multiple means of connecting to the PC (USB, Ethernet or parallel port), you should implement the connection type variable as part of the "device object". A single C++ class will do this job marvelously.
As for refreshing the status, the DLL, when it's loaded, can have an initialization function that starts a periodical timer. For example, every
10 ms, the array of device objects is passed through, using whatever connection method was specified to see if there is a device and what it's status and ID are. Quite straightforward. When the GUI application is shutting down, it uses a de-initialization function in the DLL to shut down the timer and clear the device object array. If you want to make it even more better, implement the connectivity to the device into the device object class. This means that when an instance of this class is constructed, it will automatically scan the wires for a device. For example, opens a socket object and connects to the device, if you're using a network connectivity. Naturally, you must know the amount of devices there are, so you won't create too many of the objects. Another alternative is to create a device object, attempt to connect it, and if the connection succeeds, the object is added to the array. If it fails, the object is destroyed as unnecessary.
The New ARM SoC ( CPU) has a much better inst' set and will kill Microsoft's "CE" , for everything is much easier , thus many will jump in and write free s/w .
DevDrvrs must not be written outside the OpSys , else you'll need "hooks" and much more .
I will write a free "NewForth" OpSys that will have none of the stupidity of C , Linux , Unix ... It will be so easy to read the source code , that millions will start to call it the only REALLY open source code .
Everything is in the OpSys , even you apps . It needs no firewalls because it's impossible to access a WRITE command . Your app can only say it needs MemAlloc , it has nothing to say about where it's placed .
It uses reuseable , modular code , thus it's TINY . Huge apps run in 200KB ! Only your data size needs "managing" . It's primary input is NOT keyboard , but audio . It boots to an audio menu . It needs no VoiceRecog for this trivial elimination .
There's no reason your DLL can't create a timer (with a callback) or thread to handle whatever ongoing work is required. You'd create the timer/thread in some initialization function, and, unless otherwise terminated, it would stay active until the application shuts down.
OTOH, if you want this device interface module to have a life of its own, and allow the management/GUI application to come and go, then you need to run as a separate process, and use some sort of IPC to talk between the management application and interface module. In that case a Win32 "Service" (aka a "daemon," in *nix parlance) is a good bet since those can run quite independently of things like user logons, or the desktop.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.