Hi Matthias,
(*) My power meter has a blinking LED which indicates the current power
usage.
A photo resistor in front of that will see enough ambient light so that I
need
an adaptive threshold for the counter. I can do that in hardware, or
simply
program an AVR to do it. Guess which is
On Wed, 21 Apr 2010 08:28:36 +1000, Dr Nathan Hurst wrote:
What's wrong with a simple string in a 1-wire accessible location.
It's just not what Jim wrote about. :-P
--
Matthias Urlichs
--
Hmm...I thought that's basically what I was saying...a string or other
description in standard format at a standard address that OWFS could
download and use to configure itself for that device.
BTW: it looks like I just got funding for an embedded systems
programmer for the summer to work on this
On Mon, 19 Apr 2010 19:59:20 -0700, Jim Kusznir wrote:
I think that there's a cleaner, easier, more capable method: Have the
device identify itself.
It's a trade-off. The downside, unfortunately, to what you're suggesting
is that the information needs to be stored on-chip. That eats Flash
(or
In either case (fixed design or a slave-loaded configuration) would
work best if we standardized on the communication mechanisms.
By this I'm thinking of how memory read and writes are done.
Pascal did a nice job simulating the standard 1-wire data transfer
with TA1 TA2 address and CRC16
What's wrong with a simple string in a 1-wire accessable location.
The decoding should all be done in the driver, so we just need to be
able to distinguish devices and features. Leave that to the device
designer.
njh
On Tue, Apr 20, 2010 at 01:45:29PM +, Matthias Urlichs wrote:
On Mon, 19
My $0.02:
I don't think this approach (unique ID numbers/families/subfamilies
for capabilities) is a good approach. This means for each new
configuration, a new ID needs to be registered, OWFS needs to be
patched to support, etc. As you suggested, this process would only be
used on
Given that most of these devices are not so likely to have 4B created
over their lifetime, would you be willing to allow the device designer
to designate more bits of subtype (subsubtype) to identify functional
capability within the device? This would be purely the choice of the
designer.
As
Hi,
I wrote:
However, I do think that I'd rather implement a 'tell me what you can
do' feature command, than allocate a new ID for every crazy ^w
interesting idea I might have.
On the flip side, Louis Swart lo...@louisswart.co.za replied that
he'd be amenable to delegating sub-ID of 'his'
Very easily.
We would even show only the relevant properties based on the ID number.
All I ask is that the slave be generally available. Either
commercially, or as published code.
Paul Alfille
On Fri, Apr 16, 2010 at 5:21 PM, Matthias Urlichs matth...@urlichs.de wrote:
On the flip side, Louis
On Fri, Apr 16, 2010 at 09:21:40PM +, Matthias Urlichs wrote:
Hi,
I wrote:
However, I do think that I'd rather implement a 'tell me what you can
do' feature command, than allocate a new ID for every crazy ^w
interesting idea I might have.
On the flip side, Louis Swart
On Tue, 13 Apr 2010 15:22:06 -0400, Paul Alfille wrote:
Take the DS2423 counter. It has 16 counters that monotonically increment
with memory page writes. 2 of the ranges are strangely linked to an
external pin. How will you add another 8 or 9 counters?
Well, make more of these ranges
On Mon, 12 Apr 2010 12:20:17 +, I wrote:
One idea which comes to mind: all Dallas chip IDs I've seen so far end
with x00 (or 010800 or some combination thereof). I propose to use
some of these bits as a signature, so that OWFS knows that it can use a
special command (is there a global
Is that Family code 42? Or the last few digits of the unique ID portion?
I think the convention has been to use Family codes above 0x80 for 3rd
party devices, and even then make sure they aren't aliased to a known
device in the lower range. (i.e. Maxim makes some custom runs with
family codes
Small correction, BAE0910 use FC family code.
This FC range could be segmented and shared as long as the two
identification functions 0x11 and 0x12 (read version read type) are
implemented to allow master to differentiate them.
I also like the idea to setup a registry.
Pascal
2010/4/13 Paul
On Tue, 13 Apr 2010 11:36:35 -0400, Paul Alfille wrote:
Is that Family code 42? Or the last few digits of the unique ID portion?
The latter. Plus command code 42, with a few to-be-determined sub-
functions like send feature bits or send exception log or whatever.
My basic thinking is that I
It's up to you, but I find it more appealing to add the support for
your devices in one area rather that have special conditions for every
existing device looking for your modifications.
I can see why you's want to keep the same family code for
reimplementations, but I think you will find
I've bitten the bullet last week and implemented a generic 1wire slave
library in C, for AVRs, licensed under GPLv3.
http://github.com/smurfix/owslave
Basic features currently need 3k flash; this can definitely be improved.
Contributions are welcome. in particular, the framework looks OK
(the
Very interesting Matthias!
It looks like you intend these chips to be drop-in replacements for
discontinued Dallas designs.
And so should be supported by software (like OWFS) without any changes?
Paul Alfille
On Sun, Apr 11, 2010 at 4:34 PM, Matthias Urlichs matth...@urlichs.de wrote:
I've
On Mon, 12 Apr 2010 06:52:09 -0400, Paul Alfille wrote:
Very interesting Matthias!
Thanks. I aim to please. ;-)
It looks like you intend these chips to be drop-in replacements for
discontinued Dallas designs.
Not only discontinued ones, but extending them. For instance, not just
a ds2423,
20 matches
Mail list logo
