I am trying to convince a vendor that the proper way to provide an interface to their embedded system (that hooks up to a PC using TCPIP) is to provide a software component on the PC (like a driver). For some reason, they are of the oppinion that just providing the syntax for the messages that go back and forth should be enough (i.e. the actual data that corresponeds to a particular message in an agreed format). I believe that it is better software engineering to provide an encapsulation and buffer layer in shape of a software component (such as a DLL etc.).
Am I right? Wrong? How do I convince them? Any litterature to refer to?
I disagree about a driver being a good idea. I'd much rather have the spect for the protocol. If they want to provide code, then I'd want library routines in ANSI standard C, but such code is often of limited usefulness.
I agree with them.
In addition to the protocol spec, a library would be OK (in source form). Providing a "DLL" for some particular version of some particular OS for some partcular language is a bad idea.
A device driver is a very bad idea unless there is absolutely no way to perform the desired functions in user-space.
It's a huge amount of work to write a device driver that uses TCP/IP to communicate with the device. The result is (in my experience) difficult to use, difficult to debug, and difficult to maintain. Avoid device drivers if at all possible.
I think a device driver is a really bad idea. I worked for years at a company that provided device drivers that communicated with the device via TCP/IP (there was simply no other way to do it). You really, really, don't want a device driver.
Tell them you won't buy the product unless it has the features you want. Buy the product from one of their competitors that provides what you want. Pay them to do what you want.
Literature?
--
Grant Edwards grante Yow! By MEER biz doo
at SCHOIN...
visi.com
IMO, this is more subjective than black & white. To their credit, it sounds as if they are drawing the line instead of capitulating and extending into an area they don't feel they can be successful.
If they provide a software module, that gets them into the SDK business, which involves a lot more support / debugging of the client's unique software development environment. (Very different support skills, not to mention all the platform permuntations.)
However, providing just the messaging format is on the other end of the spectrum, unless the interface is trivially simple. It's foolhardy not to make it as easy as possible for the customer to absorb your product - the faster / easier it is, the quicker product sells and the lower the support costs.
It would be a reasonable middleground to provide reference code as an example, perhaps in both VB and VC++ (considering the target platform), which the client could confidently integrate and extend with little startup effort. This is code they've already written to develop / test / demo the product and cleaning it up to share as a reference driver shouldn't be too burdensome.
My $.02, Richard
p.s. - Posting the same message to multiple groups is considered bad form; it creates parallel conversations that don't benefit from each other. The preferred method is to "cross-post" - address the original message to a limited number (typically
Hi Richard. Thanks for your reply. I understand your points and tend to agree. My question I guess is about the definition of the protocol. Am I correct to assume that a proper spec for a protocol is not only the messahe syntax but also the flow/sequence in which they happen? Where can I perhaps see an example of a proper spec?
Thanks
PS - Sorry about the multiple post and thanks for your explanation
Well, yes, of course a good interface spec would include all the details necessary. So, if flow / sequence are significant, it would need to be defined. I would point you to any of a myriad controller chips for documentation examples. Say, Asix AX88796L Ethernet controller or Atmel's AVR microcontroller line to name a couple. (These are hardware interfaces, but involve proper syntax, timing, and sequencing in areas.)
You will find in practice that the format/syntax and sequences are generally documented, but there are almost always subtle details omitted and must be learned from experience (e.g., timing-specific conditions, exception cases, etc.); this is less so with major manufacturers. This is where proven code (mfr's or open source) is very valuable in getting started.
If the interface is a simple request/response format and requests are not inter-dependent, then not much discussion of sequencing is needed. If you're implying they should get deeper and spec the TCP behavior of the interface, that's the benefit of using TCP - it's well-documented and standardized, and they are only obliged to disclose where they are not fully compliant (though this is rarely done in practice).
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.