"Driver" or "Interface Object" - yes or no?

This is a money/opinion issue, not a technical one. If they can find enough customers to buy it the way it is, they're right. There's no "better software engineering" issue.

I make complex VME modules and have never furnished a driver. I describe the registers and let my customers write whatever code they like.

Most controls-type applications programs can access TCP/IP without a custom driver or DLL. LabView, for example, can talk to such a device, even one with a binary protocol, without any problems.

It usually is a good idea to provide some basic comm/demo program for Ethernet devices, just to prove to the customer that it actually works.

John

Thanks. 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

Anny ellementtary texttbbookk on tellecommunications prottoccolls will doo.

It depends on how sophisticated the information is that you want to send back and forth. If you have a TCP/IP stack in your peripheral, then just use any ordinary ethernet protocol - HTTP, FTP, NNTP, SMTP, UUCP, UTP, whatever you want. If it's just shuttling bytes back and forth, over a fairly reliable connection, then just shuttle bytes back and forth at will. If you don't have enough confidence in your equipment and your software to just send raw data, you could try something like Xmodem protocol or its descendants.

And when posting from google, don't click the "reply" link - scroll to the top of the post you're replying to, click the "show options" link, and click _that_ "reply" link - that way, it quotes context.

Good Luck! Rich

Their spec/manuals should include both the protocol and the timing/sequence rules. If they don't, people won't be able to make it work, at least not without a huge amount of fiddling.

If you have enough clout (ie, intend to buy enough units to impress them) insist on a good protocol manual first.

One thing about such protocols is that they must avoid both data errors and handshake hangups. I designed a temperature controller that had to be 100% compliant with my customer's protocol rules, and a couple of hundred thousand dollars of scientific stuff was burned up as a consequence. Aborting and restarting a user task had nasty consequences to the contents of comm buffers. Plus, one of their programmers decided to set a variable to "3000 centigrade" as a "setpoint undefined" flag... and you can guess what happened next. So I changed the rules to stop the smoke. They eventually fixed their code, too.

John

You could look at some of the RFCs that discuss a particular TCP/IP protocol you are familiar with.

--

John Devereux

"ElderUberGeek" skrev i en meddelelse news: snipped-for-privacy@g47g2000cwa.googlegroups.com...

Yes - There will be a parser and a serialiser at each end to deal with the data, handling failure cases, the mapping to machine architectures and cooperating with other tools not invented yet or tools that one does not have a business case for and therefore cannot write but users still want. A lot of work!!!

In almost *all* cases it is better to use an existing protocol than trying to hack one up yourself!!

F.ex. my favorite XML-RPC

- since you have got TCP/IP already. Or maybe SPREAD for distributed computing.

BEEP - a protocol framework

- the specs are rather nice and there are many design hints. There are even some implementations.

They are right, you are wrong.

Your PC already has the correct driver (TCP/IP stack and Ethernet hardware driver).

If they provided a DLL then they (and you) would be stuck in a never-ending hell of Windows/third-party-software-versions and driver/hardware incompatibilities. Google "DLL Hell".

Interfacing to most TCP/IP devices with common protocols takes a couple lines of code in any reasonably complete language, and can be done from userland without any need for additional "drivers". Heck, many TCP/IP-speaking devices can be configured and used from a web browser.

To see how this all works (and how computers from any manufacturer running software from any writer can talk to each other) look the RFC's for common TCP/IP protocols. The definition of the protocol is infinitely more valuable than any particular implementation of the protocol.

Tim.