Post by Alastair D'SilvaPost by Jan KandzioraDS2408 codebase which handles the various HD44780 displays connected to
the DS2408. It's ugly, it's error-prone and it's hard to debug.
Please don't require us to put even more quirks into the existing driver
sources.
Agreed, what I was thinking of was adding an init/term function and a struct
that represents a device instance (rather than a whole family of devices),
and adding a DeviceEntryExtended2 to set that up. That way, the driver can
query the device when inited, find out it's real type, and pass the
appropriate filetype table (probably from a separate .c file), so we don't
have the horrible overloading that exists in the DS2408 driver.
All the things owlib knows about a family is purely static. This is
required for the correct interaction of owserver and the client, which
may be an abitrary number of owserver layers.
Changing that creates a horrible amount of complexity. Please don't do
that. We can't possibly maintain it. I was glad I found a simple trick
for the "external" sensors where the upper level owservers know nothing
about lower level definitions but it's ugly, too.
Post by Alastair D'SilvaWhat I'm stuck on is that none of the existing infrastructure seems to have
a concept of a device instance, only types of devices, and I'm not sure it
can be easily retrofitted.
You are right. OWFS does not store anything device-specific. It's
stateless in that regard, which is a wise choice because devices may be
in an arbitrary state depending whether they had been powered on or off.
(The only exception is the cache, but that's a node->value store only
for user programs which isn't queried for owlib's internal workings. You
could query it but please don't do it. It would confuse unaware
programmers.)
If you'd need to distinguish device states, please store these on the
device itself. If you need owlib to do a quick check for a state after a
device command, include a 1-bit cycle to query that state before
continuing. It's simple to implement and the robust way to do it.
Post by Alastair D'SilvaRegardless of whether I have a second level of device types, I don't think I
- The implementation library allows an arbitrary number of channels
- I have a command which returns the number of channels
This is something the user program (on top of OWFS) has to know. So the
user program is the place to store that information.
Post by Alastair D'Silva- I would only like to display files for the permitted channels
This is a nice-to-have feature. Given the amount of complexity you have
to add to support this, I would first walk away, then turn around, throw
something heavy at it, then run away.
Post by Alastair D'Silva- I would like to avoid querying the device every time a directory listing
is done
You are right. Doing so would be bad.
Post by Alastair D'SilvaIf you have any ideas, I'm all ears. Maybe querying the device for it's
state when necessary wouldn't be disastrous...
Include the number of R/G/B channels into the second/third etc byte of
the ID so OWFS magically knows it just from looking at the ID.
There are plenty of ID bits available and the number of devices ever
manufactured sure wouldn't hit millions.
Post by Alastair D'SilvaThat feels a lot like "640kb ought to be enough for everyone"...
It was. What went wrong wasn't that number but DOS living for too long
though better solutions existed.
You don't have that problem. You are not required to stick to an
inferior system. Your slaves are just software. If a better solution
comes up later, there's no problem to re-flash the devices.
(Please include a way to self-program your devices via onewire.)
Post by Alastair D'SilvaPost by Jan KandzioraBy the way, if you do an onewire LED driver, the feature I adore most is
synchronous control over a whole bus. So multiple LED units can be pre-
programmed to dim in a controlled fashion starting at a single point in
time.
You had to implement a new command similar to "Convert T" to achieve this.
That would break any existing driver but is extremly simple to implement
inyour own driver (and the simultanenous code, of course).
That sounds like a great idea, thanks.
ALL_OFF (sets all the channels on the device off, maybe a candidate
for a simultaneous command?)
Yes.
Post by Alastair D'SilvaCOUNT_CHANNELS returns the number of available channels to the master
Please do that in a static manner.
Post by Alastair D'SilvaSET_CHANNEL fades a channel to a specified RGBW value over a
specified time
GET_CHANNEL gets the current RGBW value of a channel, and the
fade time remaining
It should be relatively straightforward to add a COMMIT command which
only starts fading the requested channels once received.
A much better design would allow the user program to push presets into
the device RAM, and into a EEPROM backing store for each preset slot.
Whether to store a RAM preset into EEPROM is selected by another
command. That's the way the other onewire devices do it.
That way, the device doesn't have to be set-up after each power fail.
But even if you don't have a backing store, complex presets for a number
of channels reflect real-life requirements for lighting applications.
Presets could simply be ramps (start value absolute, end value–absolute
or relative, speed) but the slot should be able to include an arbitrary
number of channels involved.
The COMMIT command does have to use the preset slot, not the channel! We
are doing a synchronous command over multiple devices so channel numbers
aren't unique. You would introduce a tie between the channels on
different devices.
If you want to make it perfect, give the COMMIT command another byte
besides the preset slot which is checked against a user-presetable
and/or-mask inside the device and only react when the masks match.
Include a setting which controls what happens if any ramp isn't
completed when a new "COMMIT" command (masked, of course) arrives.
Options: Switch to new preset from ramp start value/switch to new preset
from current ramp value/ignore and signal error.
Your GET_CHANNEL command makes no sense to me. Basically it asks me to
use the device as a time source for my user program fading control. Why
would I do that? If I had multiple devices, which source should I
select? That's arcane design. Avoid!
Post by Alastair D'SilvaDo you have any other suggestions?
Please include a POR state bit and a way to query/reset it. This makes
life much easier for user programs which have to make sure all devices
are set up properly.
Include a conditional search filter which triggers on POR, "Fade
completed" and "Error condition". And a status register to find out
which condition hit.
The idea is the user program starts a conditional search multiple times
per second and most of the time no device at all reacts. That way
conditional search is a cheap operation.
When a device needs new directives, it reacts to conditional search and
is serviced by the user program.
Kind regards
Jan