Class: DIO

[Dean Roddey]

General Description

This thread is for discussion of the DIO device class. Drivers that implement this device class will provide one or more digital inputs and/or outputs.

Fields Provided

[INDENT]It is assumed that, in the general case, the fields will likely be nameable by the user, therefore there are no naming convention limitations on the fields of this device class, other than that they MUST use the appropriate prefix indicator, i.e. that all of them be in one of the forms:

DIO#In_fieldname
DIO#Out_fieldname

DIO#sub~In_fieldname
DIO#sub~Out_fieldname

This indicates that the fields are implementing the DIO device class. They will all be either In_ our Out_ prefixed, to indicate the direction of the field, followed by an arbitrary field name part.

If initial default names are assigned until the user can/does rename them, then it is SUGGESTED that they in some way refer to device specific values, so that it is obvious what input or output each field refers to.[/INDENT]

Multi-Unit Considerations

[INDENT]Though it is generally assumed that these fields will be user nameable to reflect their function and therefore all on an equal footing, if the device provides banks of identical sets of inputs and outputs with a specific purpose, the driver MAY use sub-unit naming conventions. In that case the fieldname parts become fixed, and the sub-unit part becomes the user or device provided name. Each sub-unit must provide an identical set of fields.[/INDENT]

Semantic Requirements

[INDENT]All such fields should be semantically marked with the DigitalIO semantic field type, and follow the conventions indicated by that semantic field type. Outputs are not required to be readable. They MAY be but customization that is intended for generality shouldn't depend on readability of outputs.[/INDENT]

Backdoor Commands/Queries

[INDENT]None are required at this time.[/INDENT]

[Dean Roddey]

(reserved for expansion)

[Dean Roddey]

(reserved for expansion 2)

[Dean Roddey]

OK, here's an example of a very simple device class specification. For something simple like digital I/O, this is about as complicated as it will need to be, though it might have a bit more high level discussion in some cases if needed.

[Dean Roddey]

Added multi-unit considerations and access guidelines. This is probably a pretty fair representation of the major bits of info that these class definitions will provide. The big exception is those that have particular named fields, in which case all those must be enumerated and their function and type indicated. But for simpler ones like this, does this seem to be a sufficient definition?

[ellisr63]

Added multi-unit considerations and access guidelines. This is probably a pretty fair representation of the major bits of info that these class definitions will provide. The big exception is those that have particular named fields, in which case all those must be enumerated and their function and type indicated. But for simpler ones like this, does this seem to be a sufficient definition?

I have no clue what you just said... :oops:

[Dean Roddey]

Basically I just meant that, for a device class like this one, it's basically just a homogenous list of fields, all of which are the same type and have the same requirements, all of which are of a given semantic field type. So it's pretty simple to define this type of class.

If it were something like, say, an AV Processor, that one will have a bunch of fields with very specific names and data types and valid values and all that. In those, there'd be a lot more information in the device class to lay out what all of those fields are and exactly what they should do and so forth.

[Dean Roddey]

As with some other classes, clarification of read/write requirements and multi-unit naming stuff.