Writing drivers -- advice on style

[openlx]

I'm interested in writing drivers for usbdmx for BSD/Linux...I've had a look at the sample code -- though I don't actually know obj C. Guessing how it works, am I right in saying that if there's any errors created they just get raised by the receive thread and don't actually interact with the transmit.

In other words when I'm trying to write drivers, (from a style point of view/experience of how the interface behaves) do I just write data out, or do I implement a state machine (which will slow things down, I suspect)?

Writing this I think I'm answering my own question -- just send data, keep an eye out for errors coming in, and not do a tightly coupled "full handshake". Any thoughts/advice?

Thanks

[ben.suffolk]

The way I wrote the example Objective-C code for the mac is mainly regular C wrapped up in an Objective-C class.

I took the view there that all commands were passed directly out, and anything received from the interface (be that a command response, either positive or negative, or an inbound DMX value change) I simply passed it onto the application. The receiver runs in a new thread so as not to get in the way.

You could quite happily 'throw away' the inbound positive responses for commands, and only worry about inbound DMX and errors. Maybe when you initilise the driver you could pass in the callback function that gets all the responses passed to it?

The way the firmware works is that commands are executed in order, and so the responses will come back in the order sent, although they may be interspersed with inbound DMX values, or errors.

Regards

Ben

[openlx]

Thanks for clarifying my thoughts -- I wasn't sure write() was atomic. Like you say, everything can be handled from a queue. All be it unordered. If the device gets in a strange state/out of state with the PC, something seriously bad will have happened and recovery is likely to be hard anyway!

Like I say, thanks for clearing things up