Re: PRB - serial gateway device implementation
From: Paul G. Tobey [eMVP] (ptobey)
Date: 11/03/04
- Next message: cyberninja: "WinCE security"
- Previous message: Bálint Kátay: "PRB - serial gateway device implementation"
- In reply to: Bálint Kátay: "PRB - serial gateway device implementation"
- Next in thread: Balint Katay: "Re: PRB - serial gateway device implementation"
- Reply: Balint Katay: "Re: PRB - serial gateway device implementation"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 3 Nov 2004 13:02:17 -0700
I'd say that, since you intend to acquire the data whether a client is
asking for it right now or not, yes, you need to start the acquisition
process, (however that may be implemented), on startup. You might do this
by making a stream driver which is loaded by the device manager on startup
and which opens the serial ports during the Init message and starts a thread
or several threads to handle the acquisition. At that point, you have the
acquisition part of your task handled. If you wish, you could do
essentially the same thing with an application, although you may have to
handle communication with other pieces of the system (to return data to
remote clients), through a different means than the more natural stream
interface that you can use with drivers (Open, Close, Read, Write,
IoControl).
The next thing is to figure out how clients will get the data. You're going
to have to figure out in more detail how they will want to get the data, I
think before coming to a decision. All of the things which you mentioned
are technically feasible, at some level, and there are others. You might,
for example, create a socket server program which can be attached to by a
custom program across the network and sent requests for data. Since you
control both ends of this communication pipe, you have to write more code,
but you have complete control over the protocol and it's likely that this
would work without much trouble. Web Services and DCOM both offer
'standard' interface publication as their big advantages. A client might be
written in almost any language and use your Web Service. It might also run
on any of a number of platforms. Your DCOM client could also be written in
several languages, but would probably be limited to Windows execution. How
will the data be used? Will only the last data from each serial port be
returned or will you be storing data for waveform or history return? Can
multiple clients get the data from a single serial port?
Paul T.
"Bálint Kátay" <val3@freemail.hu> wrote in message
news:u$ikl0dwEHA.3936@TK2MSFTNGP10.phx.gbl...
> Hy,
>
>
>
> Unfortunately nobody seems to be able to help with my problem at my
> university; they do not have enough experience at this field...
>
>
>
> Aim:
>
>
>
> I'm in a development process of a serial gateway device. (It is a
> university project for me.) The gateway device will be connected to 4
> measurement device on its 4 serial ports. The device itself is a SBC, with
> a
> 200 Mhz Pentium processor, 32 Mb RAM, some kind of storage. (Currently I
> use
> a floppy drive to boot MS-DOS and download the CE image via ethernet.)
>
>
>
> So far...:
>
>
>
> I built a BSP for the device by cloning the CEPC BSP. (Now it is only
> supports one serial port)
>
> I built a CE .NET (4.2) image for the device (it is now includes GUI
> and other may neglectable components. Now it is includes everything to
> implement web services - more on this later) (Note: The debug image failed
> to run - I think because of the memory configuration, but I didn't dig
> very
> deeply in this issue)
>
> I built the SDK
>
> I built COM handler, and data collector classes. (I used MFC for
> simplicity)
>
> I built a form application to test my classes. (The test was
> successful)
>
> I successfully built the sample webservice applications from the msdn
> library and from Mike Hall's blog. (I learned from those that the COM
> object
> is always reconstructed by every call.)
>
>
>
> What I have:
>
>
>
> Working image
>
> SDK
>
> Objects to handle the serial ports
>
>
>
> Problem:
>
>
>
> I now have to implement some kind of mechanism to safely expose my
> classes (or their functionality).
>
>
>
> Questions:
>
>
>
> First I though that I should expose my classes as web services
> (because it is seems to be easy, streamlined, no firewall issues, and can
> be
> implemented in a secure way). Other possible solution may be DCOM (and I
> bet
> that you can enumerate a lot more). Both webservices (with SOAP) and DCOM
> uses COM, so I thought that my next move should be to build a COM object.
> (Honestly this would be my first COM object (after the msdn examples)...)
> I
> have some doubts:
>
> - I need an object which is always in the memory, collects the data.
> COM is appropriate for this? (From my experiments it seems that this is
> not
> the case.)
>
> - Should I build a two level system, with an application that starts
> with the device, and a COM object which queries the application? (Which
> mechanism should I choose for the communication?) - I think this is the
> most
> promising solution, therefore the question in the brackets is the most
> important now.
>
> - The webservices support some kind of callback mechanism? (Can I
> callback/notify my client application if a new message arrived to the
> serial
> port, or I have to regularly query my webservice?)
>
>
>
> (- As I saw, the platform builder by default, supply driver only for
> three serial port. It is easy to modify one of the drivers to work as the
> driver for the 4th port?)
>
>
>
> Thanks for your help,
>
> Bálint Kátay.
>
> student at Budapest University of Technology and Economics, Hungary
>
>
>
- Next message: cyberninja: "WinCE security"
- Previous message: Bálint Kátay: "PRB - serial gateway device implementation"
- In reply to: Bálint Kátay: "PRB - serial gateway device implementation"
- Next in thread: Balint Katay: "Re: PRB - serial gateway device implementation"
- Reply: Balint Katay: "Re: PRB - serial gateway device implementation"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
