Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: DIO
#1
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
Software Geek Extraordinaire
Reply
#2
(reserved for expansion)
Dean Roddey
Software Geek Extraordinaire
Reply
#3
(reserved for expansion 2)
Dean Roddey
Software Geek Extraordinaire
Reply
#4
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
Software Geek Extraordinaire
Reply
#5
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?
Dean Roddey
Software Geek Extraordinaire
Reply
#6
Dean Roddey Wrote: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:
tia, Ron

My Go Big or Go Home Retirement HT...
Yamaha CX-A5100, (3) JBL 2360As/EV DHA-1s, (3) 1/4 Pie bass bins, (2) MiniDSP DDRC-88M, (4) JBL 8340As, (4) JBL 8320s), PS3, (2) Intel NUCs, Monoprice Redmere HDMI cables, Monster HTPS7000, )2) Furman rack conditioners, (2) Danley DTS-10 subs, Panasonic AE8000, Panamorph UH-480 anamorphic lens, SeymourAV 180 (195" diagonal) scope screen, Yamaha P7000s (for the subs), 2 Crest Audio CM2008 8 channel amps, and (3) Parasound Zamps.
Reply
#7
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
Software Geek Extraordinaire
Reply
#8
As with some other classes, clarification of read/write requirements and multi-unit naming stuff.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 4,358 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 2,618 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,363 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 1,350 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 1,483 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Security Dean Roddey 33 4,331 08-13-2014, 03:02 PM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 3,204 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 1,007 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,131 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 917 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)