Am 11.02.2017 um 06:16 schrieb Alastair D'Silva:
>>
>> DS2408 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.
> What 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.
> Regardless of whether I have a second level of device types, I don't think I
> can do without a struct to have device instance state. My use case is this:
> - 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.
> - 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.
> - I would like to avoid querying the device every time a directory listing
> is done
>
You are right. Doing so would be bad.
> If 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.
>
> That 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.)
>
>> By 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.
>
> These are the commands I have implemented currently:
> ALL_OFF (sets all the channels on the device off, maybe a
> candidate
> for a simultaneous command?)
>
Yes.
> COUNT_CHANNELS returns the number of available channels to the master
>
Please do that in a static manner.
> SET_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!
> Do 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
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
