Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Samstag, 16. Dezember 2006 02:11 schrieb Paul Alfille: > There are some subtilties with deeper branching. OWFS kee[s trak of the > last selected path to reduce redundant path selection (you have to turn off > all sister DS2409s at each level). I'll add a flag that marks the stored > path as untrustworthy. > There seem to be a problem with this flag now. As we have now a "discharge" and a "clearevent" node in the DS2409 code, I'll just left out setting this flag in the latter one to demonstrate the following: janskiste:~ # tclsh % package require ow ; OW::init /dev/i2c-1 ; OW::get uncached bus.7/,bus.6/,bus.5/,bus.4/,bus.3/,bus.2/,bus.1/,bus.0/,29.A7410100/,29.8F410100/,1F.141B0500/,1F.0F1B0500/,alarm/ % OW::get alarm 29.A7410100/,29.8F410100/ --- Connect keys in both keylocks --- % OW::get alarm 29.A7410100/,29.8F410100/,1F.141B0500/,1F.0F1B0500/ % OW::put 1F.141B0500/discharge 1 % OW::get alarm 29.A7410100/,29.8F410100/ % Huh? Both alarms were cleared? --- Connect keys in both keylocks again --- % OW::get alarm 29.A7410100/,29.8F410100/,1F.141B0500/,1F.0F1B0500/ % OW::put 1F.141B0500/clearevent 1 % OW::get alarm 29.A7410100/,29.8F410100/,1F.0F1B0500/ % Ahh, that's better. It seems to me the entire state of the DS2409 in the level directly *below* the discharged line is invalidated, too. Kind regards Jan -- Microsoft should switch to the vacuum cleaner business where people actually want products that suck. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Jan, Your patch works flawlessly, so I included it. Very nice. As a partially related note, some of the bus masters record if there are any devices after every RESET. We could use that for scanning, which would be even faster. Paul Alfille On 12/16/06, Jan Kandziora <[EMAIL PROTECTED]> wrote: Am Samstag, 16. Dezember 2006 02:37 schrieb Paul Alfille: > This is an ambitious, but tricky change. When you are happy with it, let me > test it too. I can construct a 2 level network here. > My idea is to transfer the BUS_select_branch() from BUS_next into BUS_select. This should do no harm -- BUS_next is the only place where it is called. That way, we could put BUS_select_branch() directly after the BUS_reset(). As BUS_select_branch returns immediately for the backbone, nothing changes when selecting the backbone. When selecting a branch, BUS_select_branch() will trigger the Smart-On-Command of that DS2409 *again*, thus generating a single reset pulse for the branch. This should work independent on how deep the DS2409 is located, as with the previous algorithm, all switches of the DS2409 up to that last DS2409 in the row are already set-up correctly, and all the chips in that branch (and the backbone) could receive the previously thrown BUS_reset() and BUS_select_branch(). As the BUS_next function and therefore, the 'uncached' directories always used this method to list nodes on branches, I think the attached minimalistic patch is safe. I'm not sure how it affects caching, though. If the thermostat handling is broken now (don't have one to test), I think BUS_select_branch() could be called safely after it, too. I didn't do it just to keep the possiblity to attach the thermostat to a branch, too. Maybe it works that way? Kind regards Jan -- DOS: n., A small annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Samstag, 16. Dezember 2006 02:37 schrieb Paul Alfille:
> This is an ambitious, but tricky change. When you are happy with it, let me
> test it too. I can construct a 2 level network here.
>
My idea is to transfer the BUS_select_branch() from BUS_next into BUS_select.
This should do no harm -- BUS_next is the only place where it is called. That
way, we could put BUS_select_branch() directly after the BUS_reset().
As BUS_select_branch returns immediately for the backbone, nothing changes
when selecting the backbone. When selecting a branch, BUS_select_branch()
will trigger the Smart-On-Command of that DS2409 *again*, thus generating a
single reset pulse for the branch.
This should work independent on how deep the DS2409 is located, as with the
previous algorithm, all switches of the DS2409 up to that last DS2409 in the
row are already set-up correctly, and all the chips in that branch (and the
backbone) could receive the previously thrown BUS_reset() and
BUS_select_branch().
As the BUS_next function and therefore, the 'uncached' directories always
used this method to list nodes on branches, I think the attached minimalistic
patch is safe. I'm not sure how it affects caching, though.
If the thermostat handling is broken now (don't have one to test), I think
BUS_select_branch() could be called safely after it, too. I didn't do it just
to keep the possiblity to attach the thermostat to a branch, too. Maybe it
works that way?
Kind regards
Jan
--
DOS: n., A small annoying boot virus that causes random spontaneous
system crashes, usually just before saving a massive project.
Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS.
diff -Naur owfs.orig/module/owlib/src/c/ow_bus.c owfs/module/owlib/src/c/ow_bus.c
--- owfs.orig/module/owlib/src/c/ow_bus.c 2006-12-14 20:50:04.0 +0100
+++ owfs/module/owlib/src/c/ow_bus.c2006-12-17 00:05:00.0 +0100
@@ -110,7 +110,7 @@
int BUS_next( struct device_search * ds, const struct parsedname * pn) {
int ret ;
-if ( BUS_select(pn) || BUS_select_branch( pn ) ) return 1 ;
+if ( BUS_select(pn) ) return 1 ;
ret = BUS_next_both( ds, pn ) ;
LEVEL_DEBUG("BUS_next return = %d "SNformat"\n",ret,SNvar(ds->sn)) ;
if (ret && ret!=-ENODEV) {
diff -Naur owfs.orig/module/owlib/src/c/ow_select.c owfs/module/owlib/src/c/ow_select.c
--- owfs.orig/module/owlib/src/c/ow_select.c2006-12-14 20:50:04.0 +0100
+++ owfs/module/owlib/src/c/ow_select.c 2006-12-17 00:02:54.0 +0100
@@ -88,6 +88,7 @@
/* proper path now "turned on" */
/* Now select */
if ( BUS_reset(pn) ) return 1 ;
+if ( BUS_select_branch(pn) ) return 1 ;
if ( pn->dev && (pn->dev != DeviceThermostat) ) {
//printf("Really select %s\n",pn->dev->code);
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Samstag, 16. Dezember 2006 02:11 schrieb Paul Alfille: > On 12/15/06, Jan Kandziora <[EMAIL PROTECTED]> wrote: > > Before I'll rumble through that, I'd like to add another node to the > > DS2409 chip: "clearevent" just issues a 0x66 "disconnect all lines" > > control command and clears the DS2409s event flags. I know "discharge" > > does this, too, but I don't like the 100ms time needed there. > > Sounds great, though the datasheet calls it "All Lines Off". Why choose > "clearevent" as the name? > Because it's effect to the user is to clear the event flags and alarm. The "all lines off" part of the 0x66 control command is ineffective in owfs as the next select may turn the lines off/on at its will. > > I'll plan to use this "clearevent" node with my DS2409 driven locks. The > > event is triggered on connection of an iButton to the lock. Then one does > > only have to scan the "alarm" directory of the backbone to check for new > > keys. > > There are some subtilties with deeper branching. OWFS kee[s trak of the > last selected path to reduce redundant path selection (you have to turn off > all sister DS2409s at each level). I'll add a flag that marks the stored > path as untrustworthy. > Ok. That marking has to be done in the "discharge" node, too. > > May I check in the change directly or should I send a patch? > > Please change directly. > Ok. Kind regards Jan -- Vor Onboard-Grafik sollte man mit Aufklebern wie auf Zigarettenschachteln warnen... - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
This is an ambitious, but tricky change. When you are happy with it, let me
test it too. I can construct a 2 level network here.
Paul
On 12/15/06, Jan Kandziora <[EMAIL PROTECTED]> wrote:
Am Freitag, 15. Dezember 2006 03:05 schrieb Paul Alfille:
> Jan,
>
> The DS2409 code has been quite a chore to implement. OWFS has the most
> flexible of any implementation I know -- support for unlimitted
branching,
> interleaved bus usage, and lazy bus changes. I'll be interested in any
> improvements you can make, but it isn't easy.
>
I made some progress in catching the "smart-on" problem -- a "single"
implementation in the DS2409 code branch just works as expected, only the
iButton connected to the main branch of the DS2409 responds to a 0x33
"read
ROM" command. Example code is attached.
The needed changes in the BUS_select code could be quite simple, I think.
Just
the final BUS_reset in ow_select.c, line 90 has to be replaced by a more
sophisticated reset method. Pseudocode:
iflast_branch_component(_path_) == "")
|| last_branch_component(_path_) == "bus.n")
{ BUS_reset(); }
else
{
Bus_select(last_branch_ds2409(_path_);
if last_branch_component(_path_) == "main")
{ DS2409_Smart_On_Main(_path_) }
else
{ DS2409_Smart_On_Aux(_path_) }
}
I'm digging deeper into the path functions next week, as the
last_branch...
pseudofunctions may be the toughest part to implement.
Kind regards
Jan
--
Windows ist Kommunismus: Es hört sich gut an, funktioniert aber nicht.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
On 12/15/06, Jan Kandziora <[EMAIL PROTECTED]> wrote: Before I'll rumble through that, I'd like to add another node to the DS2409 chip: "clearevent" just issues a 0x66 "disconnect all lines" control command and clears the DS2409s event flags. I know "discharge" does this, too, but I don't like the 100ms time needed there. Sounds great, though the datasheet calls it "All Lines Off". Why choose "clearevent" as the name? I'll plan to use this "clearevent" node with my DS2409 driven locks. The event is triggered on connection of an iButton to the lock. Then one does only have to scan the "alarm" directory of the backbone to check for new keys. There are some subtilties with deeper branching. OWFS kee[s trak of the last selected path to reduce redundant path selection (you have to turn off all sister DS2409s at each level). I'll add a flag that marks the stored path as untrustworthy. May I check in the change directly or should I send a patch? Please change directly. Kind regards Jan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Freitag, 15. Dezember 2006 03:05 schrieb Paul Alfille:
> Jan,
>
> The DS2409 code has been quite a chore to implement. OWFS has the most
> flexible of any implementation I know -- support for unlimitted branching,
> interleaved bus usage, and lazy bus changes. I'll be interested in any
> improvements you can make, but it isn't easy.
>
I made some progress in catching the "smart-on" problem -- a "single"
implementation in the DS2409 code branch just works as expected, only the
iButton connected to the main branch of the DS2409 responds to a 0x33 "read
ROM" command. Example code is attached.
The needed changes in the BUS_select code could be quite simple, I think. Just
the final BUS_reset in ow_select.c, line 90 has to be replaced by a more
sophisticated reset method. Pseudocode:
iflast_branch_component(_path_) == "")
|| last_branch_component(_path_) == "bus.n")
{ BUS_reset(); }
else
{
Bus_select(last_branch_ds2409(_path_);
if last_branch_component(_path_) == "main")
{ DS2409_Smart_On_Main(_path_) }
else
{ DS2409_Smart_On_Aux(_path_) }
}
I'm digging deeper into the path functions next week, as the last_branch...
pseudofunctions may be the toughest part to implement.
Kind regards
Jan
--
Windows ist Kommunismus: Es hört sich gut an, funktioniert aber nicht.
/*
$Id: ow_2409.c,v 1.15 2006/06/16 22:15:19 alfille Exp $
OWFS -- One-Wire filesystem
OWHTTPD -- One-Wire Web Server
Written 2003 Paul H Alfille
email: [EMAIL PROTECTED]
Released under the GPL
See the header file: ow.h for full attribution
1wire/iButton system from Dallas Semiconductor
*/
/* General Device File format:
This device file corresponds to a specific 1wire/iButton chip type
( or a closely related family of chips )
The connection to the larger program is through the "device" data structure,
which must be declared in the acompanying header file.
The device structure holds the
family code,
name,
number of properties,
list of property structures, called "filetype".
Each filetype structure holds the
name,
estimated length (in bytes),
aggregate structure pointer,
data format,
read function,
write funtion,
generic data pointer
The aggregate structure, is present for properties that several members
(e.g. pages of memory or entries in a temperature log. It holds:
number of elements
whether the members are lettered or numbered
whether the elements are stored together and split, or separately and joined
*/
#include
#include "owfs_config.h"
#include "ow_2409.h"
/* --- Prototypes --- */
/* DS2409 switch */
yWRITE_FUNCTION( FS_discharge ) ;
uREAD_FUNCTION( FS_r_control ) ;
uWRITE_FUNCTION( FS_w_control ) ;
uREAD_FUNCTION( FS_r_sensed ) ;
uREAD_FUNCTION( FS_r_branch ) ;
uREAD_FUNCTION( FS_r_event ) ;
yWRITE_FUNCTION( FS_clearevent ) ;
aREAD_FUNCTION( FS_r_single ) ;
/* --- Structures --- */
struct aggregate A2409 = { 2, ag_numbers, ag_aggregate, } ;
struct filetype DS2409[] = {
F_STANDARD ,
{"discharge" , 1, NULL,ft_yesno , fc_stable , {v:NULL}, {y:FS_discharge} , {v:NULL}, } ,
{"control" , 1, NULL, ft_unsigned , fc_stable , {u:FS_r_control}, {u:FS_w_control} , {v:NULL}, } ,
{"sensed", 1,&A2409, ft_bitfield , fc_volatile, {u:FS_r_sensed} , {v:NULL} , {v:NULL}, } ,
{"branch", 1,&A2409, ft_bitfield , fc_volatile, {u:FS_r_branch} , {v:NULL} , {v:NULL}, } ,
{"event" , 1,&A2409, ft_bitfield , fc_volatile, {u:FS_r_event} , {v:NULL} , {v:NULL}, } ,
{"clearevent", 1, NULL,ft_yesno , fc_stable , {v:NULL}, {y:FS_clearevent}, {v:NULL}, } ,
{"aux" , 0, NULL, ft_directory, fc_volatile, {v:NULL}, {v:NULL} , {i: 1}, } ,
{"main" , 0, NULL, ft_directory, fc_volatile, {v:NULL}, {v:NULL} , {i: 0}, } ,
{"single" , 15, NULL, ft_ascii, fc_volatile, {a:FS_r_single} , {v:NULL}, {i: 0 } , } ,
{"single_ds2400", 15, NULL, ft_ascii, fc_volatile, {a:FS_r_single} , {v:NULL}, {i: 1 } , } ,
} ;
DeviceEntry( 1F, DS2409 ) ;
/* --- Functions */
/* DS2409 */
static int OW_r_control( BYTE * data, const struct parsedname * pn ) ;
static int OW_discharge( const struct parsedname * pn ) ;
static int OW_w_control( const UINT data , const struct parsedname * pn ) ;
static int OW_clearevent( const struct parsedname * pn ) ;
/* discharge 2409 lines */
static int FS_discharge(const int * y, const struct parsedname * pn) {
if ( (*y) && OW_discharge(pn) ) return -EINVAL ;
return 0 ;
}
/* Clear 2409 event bits (and alarm state) */
static int FS_clearevent(const int * y, const struct parsedname * pn) {
if ( (*y) && OW_clearevent(pn) ) return -EINVAL ;
return 0 ;
}
/* 2409 switch -- branch pin voltage */
static int FS_r_sensed(UINT * u , c
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Freitag, 15. Dezember 2006 03:05 schrieb Paul Alfille: > Jan, > > The DS2409 code has been quite a chore to implement. OWFS has the most > flexible of any implementation I know -- support for unlimitted branching, > interleaved bus usage, and lazy bus changes. I'll be interested in any > improvements you can make, but it isn't easy. > Before I'll rumble through that, I'd like to add another node to the DS2409 chip: "clearevent" just issues a 0x66 "disconnect all lines" control command and clears the DS2409s event flags. I know "discharge" does this, too, but I don't like the 100ms time needed there. I'll plan to use this "clearevent" node with my DS2409 driven locks. The event is triggered on connection of an iButton to the lock. Then one does only have to scan the "alarm" directory of the backbone to check for new keys. May I check in the change directly or should I send a patch? Kind regards Jan -- A truly stable environment would be a concrete basement with no windows! Computers are no different. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Jan, The DS2409 code has been quite a chore to implement. OWFS has the most flexible of any implementation I know -- support for unlimitted branching, interleaved bus usage, and lazy bus changes. I'll be interested in any improvements you can make, but it isn't easy. Paul Alfille On 12/14/06, Jan Kandziora <[EMAIL PROTECTED]> wrote: That way, we really shot our own foot, as the Smart-On function cannot be used properly. It's just the same result as Direct-On. I'm not sure what to do. I tested a little with BUS_send_data and BUS_readin_data in the DS2409 code, but I couldn't get Smart-On working at all. The DS2409 doesn't seem to respond to the "reset stimulus" byte by issuing a reset on its main output. Kind regards Jan -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Donnerstag, 14. Dezember 2006 12:33 schrieb Jan Kandziora: > > But from the problems we encounter I think the following is done when > reading "1F./simultaneous/single" > > Byte 0 0x55 ROM Command (Match ROM) > Byte 1 0x1F Family Code (DS2409) > Byte 2..7 ID > Byte 8 CRC8 > Byte 9 0xCC Control Command (Smart-On Main) > Byte 10 0xFF Reset Timing for main branch > Byte 11 0xFF Reset Timing for main branch > > --- Additional reset for whole bus (so the previously selected DS2409 > branch AND the backbone are selected) > > Byte +0 0x33 ROM Command (valid only for previously reset main branch) > Byte +1 Garbage (wired AND of family codes) > Byte +2..+7 Garbage (wired AND of IDs) > Byte +8 Garbage (wired AND of CRC8s) > Paul, it's like I've written above. Each TRXN_START triggers "BUS_select", which, in lines 90 and 156 of module/owlib/src/c/ow_select.c issue at least one "BUS_reset". That way, we really shot our own foot, as the Smart-On function cannot be used properly. It's just the same result as Direct-On. I'm not sure what to do. I tested a little with BUS_send_data and BUS_readin_data in the DS2409 code, but I couldn't get Smart-On working at all. The DS2409 doesn't seem to respond to the "reset stimulus" byte by issuing a reset on its main output. Kind regards Jan -- 43rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Mittwoch, 13. Dezember 2006 23:09 schrieb Paul Alfille: > Look at http://owfs.sourceforge.net/commands.html > It is a list of devices and the listed command codes. > 0x0F for read_ROM works only for DS2401 (and DS2400 I guess). > 0x33 works for almost all chips, except > DS1821 (thermometer doesn't have an ID anyways) > DS2223, DS2224 (old chips I think) > Yes. That's why I favour the 0x33 ROM command. The DS2411 (DS2401 with Vdd) doesn't respond to 0x0F, too. > But 0x33 also has effects on DS1922 (which worries me) and DS2409 ( !!! > 0x33 = Smart-on AUX) > That's the Control/Memory command byte, so it is no problem () Arbitrary values under bus master control () Arbitrary values under slave control Byte 00x55 ROM Command (e.g. Match ROM) Byte 10x1F Family Code (e.g. DS2409) Byte 2..7 ID Byte 8 CRC8 --- From here on all the chips besides form the addressed DS2409 keep silent Byte 90x33 Control Command (e.g. Smart-On Aux) As I have no chips connected to the Aux output and the result shows the garbage of a wired AND, my observation may be correct... The following sequence is neccesary to achieve a correct 0x33 Read_ROM function on a DS2409 main branch: Byte 0 0x55 ROM Command (Match ROM) Byte 1 0x1F Family Code (DS2409) Byte 2..7 ID Byte 8 CRC8 Byte 9 0xCC Control Command (Smart-On Main) Byte 10 0xFF Reset Timing for main branch Byte 11 0xFF Reset Timing for main branch Byte 12 0x33 ROM Command (valid only for previously reset main branch) Byte 13 Family code of iButton connected on the main brach Byte 14..19 ID of iButton connected on the main brach Byte 15 CRC8 of iButton connected on the main brach But from the problems we encounter I think the following is done when reading "1F./simultaneous/single" Byte 0 0x55 ROM Command (Match ROM) Byte 1 0x1F Family Code (DS2409) Byte 2..7 ID Byte 8 CRC8 Byte 9 0xCC Control Command (Smart-On Main) Byte 10 0xFF Reset Timing for main branch Byte 11 0xFF Reset Timing for main branch --- Additional reset for whole bus (so the previously selected DS2409 branch AND the backbone are selected) Byte +0 0x33 ROM Command (valid only for previously reset main branch) Byte +1 Garbage (wired AND of family codes) Byte +2..+7 Garbage (wired AND of IDs) Byte +8 Garbage (wired AND of CRC8s) Again, as this problem would apply to *all* simultaneous nodes, it could be worth further investigation. The way I showed it up, temperature and voltage conversion of chips on the backbone is triggered always, even if only "1F./simultaneous/temperature" is triggered. Kind regards Jan -- "When you say 'I wrote a program that crashed Windows', people just stare at you blankly and say 'Hey, I got those with the system, *for free*'." -- Linus Torvalds - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Look at http://owfs.sourceforge.net/commands.html It is a list of devices and the listed command codes. 0x0F for read_ROM works only for DS2401 (and DS2400 I guess). 0x33 works for almost all chips, except DS1821 (thermometer doesn't have an ID anyways) DS2223, DS2224 (old chips I think) But 0x33 also has effects on DS1922 (which worries me) and DS2409 ( !!! 0x33 = Smart-on AUX) Paul Alfille On 12/13/06, Jan Kandziora <[EMAIL PROTECTED]> wrote: Am Mittwoch, 13. Dezember 2006 17:33 schrieb Paul Alfille: > > Many of the adapters have an id chip included, so this technique will only > work on DS2409 branches or the "more than one". > I added two additional nodes "present_ds2400" and "single_ds2400", to support both the "0x33 read ROM" and the older "0x0F read ROM" command. Please see the attached file for reference. When hooking up a key directly to the DS2482-800, both single and single_ds2400 work fine. present and present_ds2400, too. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Mittwoch, 13. Dezember 2006 17:33 schrieb Paul Alfille:
>
> Many of the adapters have an id chip included, so this technique will only
> work on DS2409 branches or the "more than one".
>
I added two additional nodes "present_ds2400" and "single_ds2400", to support
both the "0x33 read ROM" and the older "0x0F read ROM" command.
Please see the attached file for reference.
When hooking up a key directly to the DS2482-800, both single and
single_ds2400 work fine. present and present_ds2400, too.
Now I encountered a problem when using the DS2409 and the "present" and
"single" node. I attached two of my locks with the DS2409 (and a DS2408, too)
to the onewire backbone. On each main output, a single ds2401 key is
attached. Now, only "present_ds2400" and "single_ds2400" work fine.
Transcript:
janskiste:~ # tclsh
% package require ow ; OW::init /dev/i2c-1 ; OW::get uncached
bus.7/,bus.6/,bus.5/,bus.4/,bus.3/,bus.2/,bus.1/,bus.0/,29.5E410100/,29.8F410100/,1F.071B0500/,1F.0F1B0500/,alarm/
% OW::get 1F.071B0500/main/simultaneous/single
FS_r_single (simultaneous) dat=01.0201 crc8=00 crc8c=9e
% OW::get 1F.071B0500/main/simultaneous/single_ds2400
FS_r_single (simultaneous) dat=01.ba79a608 crc8=ee crc8c=ee
01.BA79A608
% OW::get 1F.0F1B0500/main/simultaneous/single
FS_r_single (simultaneous) dat=01.0201 crc8=00 crc8c=9e
% OW::get 1F.0F1B0500/main/simultaneous/single_ds2400
FS_r_single (simultaneous) dat=01.7abfa608 crc8=cf crc8c=cf
01.7ABFA608
--- now disconnect the ds2401 keys ---
% OW::get 1F.0F1B0500/main/simultaneous/single
FS_r_single (simultaneous) dat=09.06010100 crc8=00 crc8c=3c
% OW::get 1F.071B0500/main/simultaneous/single
FS_r_single (simultaneous) dat=09.06010100 crc8=00 crc8c=3c
%
The _ds2400 nodes work fine because they use the 0x0F command, which no other
chip than the DS2401 in the currently selected branch understands. The 0x33
command seems to activate the other chips on the backbone, too. 09 is the
wired AND from 29 and 1F, 06 is the wired AND of 5E, 8F, 07 and 0F etc.
That's just the kind of garbage I would expect from that problem.
I think it's possible to keep the backbone chips silent with the "Smart-On"
command of the DS2409, but it doesn't seem to work this way with owfs. H.
A problem with the bus selection scheme and "simultaneous" perhaps?
This problem applies to the other "simultaneous" nodes, too, I think.
>
> If I understand correctly it should be possible to return an error code
> from
>
> > FS_output_ascii (without "_z"). I'll try this for the new "single"
> > (really "single", not "id"?) node.
> >
> > "single" = "" if 0, -EFAULT if >1, else name(id)
>
> Correct (though not valid C syntax, of course). A bigger question is should
> the function return an error if it was used correctly?
>
Hm. It doesn't seem to work this way, still getting the glibc()...
But responding nothing is an option, too.
Kind regards
Jan
--
Windows ist Kommunismus: Es hört sich gut an, funktioniert aber nicht.
/*
$Id: ow_simultaneous.c,v 1.32 2006/12/13 04:27:51 alfille Exp $
OWFS -- One-Wire filesystem
OWHTTPD -- One-Wire Web Server
Written 2003 Paul H Alfille
email: [EMAIL PROTECTED]
Released under the GPL
See the header file: ow.h for full attribution
1wire/iButton system from Dallas Semiconductor
*/
/* General Device File format:
This device file corresponds to a specific 1wire/iButton chip type
( or a closely related family of chips )
The connection to the larger program is through the "device" data structure,
which must be declared in the acompanying header file.
The device structure holds the
family code,
name,
device type (chip, interface or pseudo)
number of properties,
list of property structures, called "filetype".
Each filetype structure holds the
name,
estimated length (in bytes),
aggregate structure pointer,
data format,
read function,
write funtion,
generic data pointer
The aggregate structure, is present for properties that several members
(e.g. pages of memory or entries in a temperature log. It holds:
number of elements
whether the members are lettered or numbered
whether the elements are stored together and split, or separately and joined
*/
/* Simultaneous is a trigger to do a mass conversion on all the devices in the specified path */
/* Added "present" From Jan Kandziora to search for any devices */
#include
#include "owfs_config.h"
#include "ow_simultaneous.h"
/* --- Prototypes --- */
/* Statistics reporting */
yREAD_FUNCTION( FS_r_convert ) ;
yWRITE_FUNCTION( FS_w_convert ) ;
yREAD_FUNCTION( FS_r_present ) ;
aREAD_FUNCTION( FS_r_single ) ;
/* Structures -- */
struct filetype simultaneous[] = {
{"temperature" , 1, NULL , ft_yesno, fc_volatile, {y:FS_r_convert}, {y:FS_
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
On 12/13/06, Jan Kandziora <[EMAIL PROTECTED]> wrote:
Am Mittwoch, 13. Dezember 2006 12:51 schrieb Paul Alfille:
>
> How about separating the functions as:
> "present" = 0 if no devices, "1" if more
> "single" = "" if 0 or >1, else name (ID)
> You can return other error codes, just not through FS_output_ascii_z
>
> I checked in a provisional "simultaneous/present" -- see if you like it.
>
Thanks for the simplifications, caching, and error handling you showed
there.
I'm not entirely happy with separated nodes, as they involve reading twice
and
therefore, have both a performance hit *and* introduced a race condition.
However, the "simultaneous/present" node is useful if someone wants to do
a
quick check prior to a scan ("uncached") of an usually unpopulated bus
segment.
Well, it really depends on what you intend to do with the data. You can only
get "empty" and "non-empty" reliably. "More than one" isn't truly reliable
(a CRC8 means 1/256 chance of false single)
Many of the adapters have an id chip included, so this technique will only
work on DS2409 branches or the "more than one".
If I understand correctly it should be possible to return an error code from
FS_output_ascii (without "_z"). I'll try this for the new "single" (really
"single", not "id"?) node.
"single" = "" if 0, -EFAULT if >1, else name(id)
Correct (though not valid C syntax, of course). A bigger question is should
the function return an error if it was used correctly?
Paul Alfille
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Mittwoch, 13. Dezember 2006 12:51 schrieb Paul Alfille:
>
> How about separating the functions as:
> "present" = 0 if no devices, "1" if more
> "single" = "" if 0 or >1, else name (ID)
> You can return other error codes, just not through FS_output_ascii_z
>
> I checked in a provisional "simultaneous/present" -- see if you like it.
>
Thanks for the simplifications, caching, and error handling you showed there.
I'm not entirely happy with separated nodes, as they involve reading twice and
therefore, have both a performance hit *and* introduced a race condition.
However, the "simultaneous/present" node is useful if someone wants to do a
quick check prior to a scan ("uncached") of an usually unpopulated bus
segment.
If I understand correctly it should be possible to return an error code from
FS_output_ascii (without "_z"). I'll try this for the new "single" (really
"single", not "id"?) node.
"single" = "" if 0, -EFAULT if >1, else name(id)
Kind regards
Jan
--
ELIZA: You have a tendency to feel you are superior to most computers.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
On 12/13/06, Jan Kandziora <[EMAIL PROTECTED]> wrote: The "read ROM" onewire command will either return the ID of the single connected device, obviously nothing if no slave is connected, or just plain garbarge if more than a single slave is connected. I'm after the ID, it saves me from doing a "search ROM". The "no chip connected" situation should return an empty string instead of FF., just like reading "uncached" would do. I will try to implement it today. It would be nice if we could tell apart the return of "garbage", but I'm currently having problems to identify this situation. In addition, it doesn't seem to be possible to return errors like -ENODEV in aREAD_FUNCTIONs. > 2. Should we use a name like "not_empty" or "search" ? > > > "search" would be a clear misnomer to me, as there is a "search ROM" command, and "read_ROM" is there to *avoid* the need to issue a "search ROM". Maybe just "simultaneous/id" (and r_id, of course)? How about separating the functions as: "present" = 0 if no devices, "1" if more "single" = "" if 0 or >1, else name (ID) You can return other error codes, just not through FS_output_ascii_z I checked in a provisional "simultaneous/present" -- see if you like it. Paul Alfille - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Am Mittwoch, 13. Dezember 2006 03:28 schrieb Paul Alfille: > > > > I'm impressed. You certainly figured out the code style. > > > > Questions: > > 1. We "read_ROM" and get a positlve result if any devices exist on the > > selected path? > > You currently return the name a of single device. And error if there are > none, or more than one. > > What do you really intend? Do you want to know if there are > A. exactly 1 (and it's number) ? > B more than 0 ? > C more than 1 ? > The "read ROM" onewire command will either return the ID of the single connected device, obviously nothing if no slave is connected, or just plain garbarge if more than a single slave is connected. I'm after the ID, it saves me from doing a "search ROM". The "no chip connected" situation should return an empty string instead of FF., just like reading "uncached" would do. I will try to implement it today. It would be nice if we could tell apart the return of "garbage", but I'm currently having problems to identify this situation. In addition, it doesn't seem to be possible to return errors like -ENODEV in aREAD_FUNCTIONs. > > 2. Should we use a name like "not_empty" or "search" ? > > > "search" would be a clear misnomer to me, as there is a "search ROM" command, and "read_ROM" is there to *avoid* the need to issue a "search ROM". Maybe just "simultaneous/id" (and r_id, of course)? Kind regards Jan - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
Jan, You currently return the name a of single device. And error if there are none, or more than one. What do you really intend? Do you want to know if there are A. exactly 1 (and it's number) ? B more than 0 ? C more than 1 ? Paul Alfille On 12/12/06, Paul Alfille <[EMAIL PROTECTED]> wrote: I'm impressed. You certainly figured out the code style. Questions: 1. We "read_ROM" and get a positlve result if any devices exist on the selected path? 2. Should we use a name like "not_empty" or "search" ? Paul Alfille On 12/12/06, Jan Kandziora <[EMAIL PROTECTED]> wrote: > Hi all, hi Paul, > > I made a small enhancement to owfs to implement the "read ROM" function > all > onewire chips have. With this function, a single key on a (sub)-bus can > be > identified without (fairly expensive) scanning. > > The attached code works with ibutton keys on the buses of a DS2482-800 > and > with ibutton keys on the sub-buses of the DS2409. I'm a little unsure if > the > error handling is correct, so I'll wait for your opinion until I make up > a > proper patch. Most mysterious to me is how to signalize an error. > Returning > -EINVAL leads to that: > > read_ROM (simultaneous) dat=ff. crc8=ff crc8c=14 ret=1 > read_ROM (simultaneous) dat=ff. crc8=ff crc8c=14 ret=1 > read_ROM (simultaneous) dat=ff. crc8=ff crc8c=14 ret=1 > *** glibc detected *** double free or corruption (fasttop): 0x08084b98 > *** > Abgebrochen > > Kind regards > > Jan > -- > The first law of demos: > - never try to actually use the system for anything > > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > ___ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers > > > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
Re: [Owfs-developers] Proposed Enhancement: "read_ROM" node in simultaneous directories
I'm impressed. You certainly figured out the code style. Questions: 1. We "read_ROM" and get a positlve result if any devices exist on the selected path? 2. Should we use a name like "not_empty" or "search" ? Paul Alfille On 12/12/06, Jan Kandziora <[EMAIL PROTECTED]> wrote: Hi all, hi Paul, I made a small enhancement to owfs to implement the "read ROM" function all onewire chips have. With this function, a single key on a (sub)-bus can be identified without (fairly expensive) scanning. The attached code works with ibutton keys on the buses of a DS2482-800 and with ibutton keys on the sub-buses of the DS2409. I'm a little unsure if the error handling is correct, so I'll wait for your opinion until I make up a proper patch. Most mysterious to me is how to signalize an error. Returning -EINVAL leads to that: read_ROM (simultaneous) dat=ff. crc8=ff crc8c=14 ret=1 read_ROM (simultaneous) dat=ff. crc8=ff crc8c=14 ret=1 read_ROM (simultaneous) dat=ff. crc8=ff crc8c=14 ret=1 *** glibc detected *** double free or corruption (fasttop): 0x08084b98 *** Abgebrochen Kind regards Jan -- The first law of demos: - never try to actually use the system for anything - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
