possible bug: ds9097 and not ds9097U
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
 |
possible bug: ds9097 and not ds9097U
by kako-2
::
Rate this Message:
Hi folks!
about 2 years ago I use owfs (2.7p19) continously. Previously I wanted to upgrade to a newer version, but not succeeded. I had no time to guess why, so I downgraded back to 2.7p19. Now I wanted to upgrade again, but it doesn't work again. Tried with many of versions, but doesn't. The newest says this: ************ [root@kako ~]# /opt/owfs/bin/owfs -d /dev/ttyS0 -m /mnt/1w --debug --8bit CONNECT: owfs.c:(100) fuse mount point: /mnt/1w DEBUG: ow_avahi_link.c:(75) Avahi support: libavahi-client loaded successfully DEBUG: ow_avahi_link.c:(77) Avahi library function found: avahi_client_errno DEBUG: ow_avahi_link.c:(78) Avahi library function found: avahi_client_free DEBUG: ow_avahi_link.c:(79) Avahi library function found: avahi_client_new DEBUG: ow_avahi_link.c:(80) Avahi library function found: avahi_client_get_domain_name DEBUG: ow_avahi_link.c:(81) Avahi library function found: avahi_entry_group_add_service DEBUG: ow_avahi_link.c:(82) Avahi library function found: avahi_entry_group_commit DEBUG: ow_avahi_link.c:(83) Avahi library function found: avahi_entry_group_is_empty DEBUG: ow_avahi_link.c:(84) Avahi library function found: avahi_entry_group_new DEBUG: ow_avahi_link.c:(85) Avahi library function found: avahi_entry_group_reset DEBUG: ow_avahi_link.c:(87) Avahi library function found: avahi_service_resolver_free DEBUG: ow_avahi_link.c:(88) Avahi library function found: avahi_service_resolver_new DEBUG: ow_avahi_link.c:(89) Avahi library function found: avahi_service_browser_free DEBUG: ow_avahi_link.c:(90) Avahi library function found: avahi_service_browser_new DEBUG: ow_avahi_link.c:(102) Avahi support: libavahi-common loaded successfully. DEBUG: ow_avahi_link.c:(104) Avahi library function found: avahi_simple_poll_free DEBUG: ow_avahi_link.c:(105) Avahi library function found: avahi_simple_poll_get DEBUG: ow_avahi_link.c:(106) Avahi library function found: avahi_simple_poll_loop DEBUG: ow_avahi_link.c:(107) Avahi library function found: avahi_simple_poll_new DEBUG: ow_avahi_link.c:(108) Avahi library function found: avahi_simple_poll_quit DEBUG: ow_avahi_link.c:(109) Avahi library function found: avahi_strerror CALL: ow_parsename.c:(95) path=[] DEBUG: owlib.c:(79) Globals temp limits 0C 100C (for simulated adapters) DEBUG: ow_ds9097U.c:(267) Attempt 0 of 3 to initialize the DS9097U DEBUG: ow_ds9097U.c:(356) Send the initial reset to the bus master. DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(434) wrong response (0F not 00) DEBUG: ow_ds9097U.c:(449) Failed first attempt at resetting baud rate of bus master /dev/ttyS0 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(434) wrong response (0F not 00) DEBUG: ow_ds9097U.c:(454) Failed second attempt at resetting baud rate of bus master /dev/ttyS0 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(434) wrong response (0F not 00) DEBUG: ow_ds9097U.c:(449) Failed first attempt at resetting baud rate of bus master /dev/ttyS0 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(434) wrong response (0F not 00) DEBUG: ow_ds9097U.c:(454) Failed second attempt at resetting baud rate of bus master /dev/ttyS0 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(418) wrong response (05 not 44) DEBUG: ow_ds9097U.c:(356) Send the initial reset to the bus master. DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(434) wrong response (0F not 00) DEBUG: ow_ds9097U.c:(449) Failed first attempt at resetting baud rate of bus master /dev/ttyS0 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(434) wrong response (0F not 00) DEBUG: ow_ds9097U.c:(454) Failed second attempt at resetting baud rate of bus master /dev/ttyS0 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(434) wrong response (0F not 00) DEBUG: ow_ds9097U.c:(449) Failed first attempt at resetting baud rate of bus master /dev/ttyS0 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(434) wrong response (0F not 00) DEBUG: ow_ds9097U.c:(454) Failed second attempt at resetting baud rate of bus master /dev/ttyS0 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_tcp_read.c:(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:(114) read: 1 - 0 = 1 DEBUG: ow_ds9097U.c:(418) wrong response (05 not 44) ********** Dont know why thinks the adapter is 9097U, this is just a cheap passive 9097, and it doesnt work. But is I downgrade to 2.7p19 it works again. What could be the problem? ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: possible bug: ds9097 and not ds9097U
by Paul Alfille-2
::
Rate this Message:
The timeouts changed to accomodate handshaking on some embedded devices.
Try: /opt/owfs/bin/owfs --passive=/dev/ttyS0 -m /mnt/1w --debug --8bit On Sun, Feb 5, 2012 at 12:03 PM, Kassai Istvan <kako@...> wrote: Hi folks! ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: possible bug: ds9097 and not ds9097U
by Roberto Spadim
::
Rate this Message:
about timeouts... there´s somehere that explain what´s timeout is used with each bus master?
2012/2/6 Paul Alfille <paul.alfille@...> The timeouts changed to accomodate handshaking on some embedded devices. Roberto Spadim Spadim Technology / SPAEmpresarial ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: possible bug: ds9097 and not ds9097U
by kako-2
::
Rate this Message:
Thanks Paul!
This way it's OK, works well! Taks again bye 2012-02-06 04:34 keltezéssel, Paul Alfille írta: > The timeouts changed to accomodate handshaking on some embedded devices. > > Try: > /opt/owfs/bin/owfs --passive=/dev/ttyS0 -m /mnt/1w --debug --8bit ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: possible bug: ds9097 and not ds9097U
by kako-2
::
Rate this Message:
Hi,
After you resolved this problem, I dicided to move this thermometer to a routerboard. I thought it won't be hard, but it was a mistake. I've installed an openwrt to a routerbord rb433ah, and prepared for owfs. (Installed the packages needed like fuse, owfs etc) I've disabled of course the serial terminal access by comment-out the /bin/ash line in the inittab: root@OpenWrt:~# cat /etc/inittab ::sysinit:/etc/init.d/rcS S boot ::shutdown:/etc/init.d/rcS K shutdown #ttyS0::askfirst:/bin/ash --login After it , seemed to be working, but not really. In the mountpoint directory appeared some other owfs related subdirs, but not the sensor related "3B.xxxxxx.." directory. When I was running owfs with --debug, that showed this: ************ root@OpenWrt:~# owfs --passive=/dev/ttyS0 -m /mnt/1w/ --8bit --debug CONNECT: owfs.c:main(100) fuse mount point: /mnt/1w/ CONNECT: ow_avahi_link.c:OW_Load_avahi_library(72) No Avahi support. Library libavahi-client couldn't be loaded CONNECT: ow_dnssd.c:OW_Load_dnssd_library(136) Zeroconf/Bonjour is disabled since dnssd library isn't found CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[] DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C 100C (for simulated adapters) DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 1 - 0 = 1 DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 0 OWFS DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 1 /mnt/1w/ DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 2 -o DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 3 direct_io DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 4 -f DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 5 -d DEBUG: owfs.c:main(125) fuse_mnt_opt=[(null)] DEBUG: owfs.c:main(127) fuse_open_opt=[(null)] FUSE library version: 2.8.5 nullpath_ok: 0 unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 INIT: 7.16 flags=0x0000007b max_readahead=0x00020000 INIT: 7.12 flags=0x00000011 max_readahead=0x00020000 max_write=0x00020000 unique: 1, success, outsize: 40 ************ Then I've installed every avahi* packages, and this debug list haven't changed. I made a soft-link (libavahi-client.so) to the libavahi-client.so.3.2.9 (even though I don't think this avahi lib loading failure correlated to this error) and the debug list became to : *********** root@OpenWrt:~# owfs --passive=/dev/ttyS0 -m /mnt/1w/ --8bit --debug CONNECT: owfs.c:main(100) fuse mount point: /mnt/1w/ DEBUG: ow_avahi_link.c:OW_Load_avahi_library(75) Avahi support: libavahi-client loaded successfully DEBUG: ow_avahi_link.c:OW_Load_avahi_library(77) Avahi library function found: avahi_client_errno DEBUG: ow_avahi_link.c:OW_Load_avahi_library(78) Avahi library function found: avahi_client_free DEBUG: ow_avahi_link.c:OW_Load_avahi_library(79) Avahi library function found: avahi_client_new DEBUG: ow_avahi_link.c:OW_Load_avahi_library(80) Avahi library function found: avahi_client_get_domain_name DEBUG: ow_avahi_link.c:OW_Load_avahi_library(81) Avahi library function found: avahi_entry_group_add_service DEBUG: ow_avahi_link.c:OW_Load_avahi_library(82) Avahi library function found: avahi_entry_group_commit DEBUG: ow_avahi_link.c:OW_Load_avahi_library(83) Avahi library function found: avahi_entry_group_is_empty DEBUG: ow_avahi_link.c:OW_Load_avahi_library(84) Avahi library function found: avahi_entry_group_new DEBUG: ow_avahi_link.c:OW_Load_avahi_library(85) Avahi library function found: avahi_entry_group_reset DEBUG: ow_avahi_link.c:OW_Load_avahi_library(87) Avahi library function found: avahi_service_resolver_free DEBUG: ow_avahi_link.c:OW_Load_avahi_library(88) Avahi library function found: avahi_service_resolver_new DEBUG: ow_avahi_link.c:OW_Load_avahi_library(89) Avahi library function found: avahi_service_browser_free DEBUG: ow_avahi_link.c:OW_Load_avahi_library(90) Avahi library function found: avahi_service_browser_new CONNECT: ow_avahi_link.c:OW_Load_avahi_library(99) No Avahi support. Library libavahi-common couldn't be loaded. CONNECT: ow_dnssd.c:OW_Load_dnssd_library(136) Zeroconf/Bonjour is disabled since dnssd library isn't found CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[] DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C 100C (for simulated adapters) DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 1 - 0 = 1 DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 0 OWFS DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 1 /mnt/1w/ DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 2 -o DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 3 direct_io DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 4 -f DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 5 -d DEBUG: owfs.c:main(125) fuse_mnt_opt=[(null)] DEBUG: owfs.c:main(127) fuse_open_opt=[(null)] FUSE library version: 2.8.5 nullpath_ok: 0 unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 INIT: 7.16 flags=0x0000007b max_readahead=0x00020000 INIT: 7.12 flags=0x00000011 max_readahead=0x00020000 max_write=0x00020000 unique: 1, success, outsize: 40 unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 56 getattr / CALL: ow_fstat.c:FS_fstat(22) path=/ CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/ DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) / unique: 2, success, outsize: 120 *********** And when I want to list the mountpoint directory further lines appearing in the debug: ************** unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 56 getattr / CALL: ow_fstat.c:FS_fstat(22) path=/ CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/ DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) / unique: 2, success, outsize: 120 unique: 3, opcode: ACCESS (34), nodeid: 1, insize: 48 unique: 3, error: -89 (Function not implemented), outsize: 16 unique: 4, opcode: OPENDIR (27), nodeid: 1, insize: 48 unique: 4, success, outsize: 32 unique: 5, opcode: READDIR (28), nodeid: 1, insize: 80 getdir[0] CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/] CALL: owfs_callback.c:FS_getdir(175) GETDIR path=/ DEBUG: ow_dir.c:FS_dir(63) path=/ CALL: ow_dir.c:FS_dir_both(98) path=/ DEBUG: ow_cache.c:Cache_Get_Dir(868) Looking for directory 00 00 00 00 00 00 00 00 DEBUG: ow_cache.c:Cache_Get_Common_Dir(881) Get from cache sn 00 00 00 00 00 00 00 00 pointer=0x2b924378 extension=0 DEBUG: ow_cache.c:Cache_Get_Common_Dir(910) Dir not found in cache DEBUG: ow_search.c:BUS_first(32) Start of directory path=/ device=00 00 00 00 00 00 00 00 DEBUG: ow_select.c:BUS_select(66) Selecting a path (and device) path=/ SN=00 00 00 00 00 00 00 00 last path=00 00 00 00 00 00 00 00 DEBUG: ow_select.c:BUS_select(79) Continuing root branch DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 1 - 0 = 1 DEBUG: ow_bus_data.c:BUS_sendback_data_bitbang(120) Splitting byte 0 of 1 = F0 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 8 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 8 - 0 = 8 DEBUG: ow_bus_data.c:BUS_sendback_data_bitbang(141) Consolidating byte 0 of 1 = F0 DEBUG: ow_cache.c:Cache_Add_Dir(473) Won't cache empty directory DEBUG: ow_cache.c:Cache_Del_Common(1375) Delete from cache sn 00 00 00 00 00 00 00 00 in=0x2b924378 index=0 CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/bus.0] DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /bus.0 CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/uncached] DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /uncached CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/settings] DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /settings CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/system] DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /system CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/statistics] DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /statistics CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/structure] DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /structure DEBUG: ow_dir.c:FS_dir_both(193) ret=0 DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) / unique: 5, success, outsize: 288 unique: 6, opcode: LOOKUP (1), nodeid: 1, insize: 46 LOOKUP /bus.0 getattr /bus.0 CALL: ow_fstat.c:FS_fstat(22) path=/bus.0 CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/bus.0] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/bus.0 DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /bus.0 NODEID: 2 unique: 6, success, outsize: 144 unique: 7, opcode: LOOKUP (1), nodeid: 1, insize: 49 LOOKUP /uncached getattr /uncached CALL: ow_fstat.c:FS_fstat(22) path=/uncached CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/uncached] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/uncached DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /uncached NODEID: 3 unique: 7, success, outsize: 144 unique: 8, opcode: LOOKUP (1), nodeid: 1, insize: 49 LOOKUP /settings getattr /settings CALL: ow_fstat.c:FS_fstat(22) path=/settings CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/settings] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/settings DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /settings NODEID: 4 unique: 8, success, outsize: 144 unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 47 LOOKUP /system getattr /system CALL: ow_fstat.c:FS_fstat(22) path=/system CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/system] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/system DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /system NODEID: 5 unique: 9, success, outsize: 144 unique: 10, opcode: LOOKUP (1), nodeid: 1, insize: 51 LOOKUP /statistics getattr /statistics CALL: ow_fstat.c:FS_fstat(22) path=/statistics CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/statistics] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/statistics DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /statistics NODEID: 6 unique: 10, success, outsize: 144 unique: 11, opcode: LOOKUP (1), nodeid: 1, insize: 50 LOOKUP /structure getattr /structure CALL: ow_fstat.c:FS_fstat(22) path=/structure CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/structure] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/structure DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) /structure NODEID: 7 unique: 11, success, outsize: 144 unique: 12, opcode: READDIR (28), nodeid: 1, insize: 80 unique: 12, success, outsize: 16 unique: 13, opcode: RELEASEDIR (29), nodeid: 1, insize: 64 unique: 13, success, outsize: 16 ^C DEBUG: ow_exit.c:ow_exit(18) Exit code = 0 ************** So in the mountpoint only the next subdirs are: root@OpenWrt:/mnt/1w# ls -la drwxr-xr-x 1 root root 8 Feb 6 18:29 . drwxr-xr-x 1 root root 2048 Feb 5 13:51 .. drwxr-xr-x 1 root root 8 Feb 6 18:29 bus.0 drwxr-xr-x 1 root root 8 Feb 6 18:29 settings drwxr-xr-x 1 root root 8 Feb 6 18:29 statistics drwxr-xr-x 1 root root 32 Feb 6 18:29 structure drwxr-xr-x 1 root root 8 Feb 6 18:29 system drwxr-xr-x 1 root root 8 Feb 6 18:29 uncached Has got an idea for anybody why it happens? Thanks a lot! kako Thanks Paul! This way it's OK, works well! Taks again bye 2012-02-06 04:34 keltezéssel, Paul Alfille írta:The timeouts changed to accomodate handshaking on some embedded devices. Try: /opt/owfs/bin/owfs --passive=/dev/ttyS0 -m /mnt/1w --debug --8bit ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: possible bug: ds9097 and not ds9097U
by Roberto Spadim
::
Rate this Message:
hum, try owhttpd and webbrowser to check if it's a fuse problem or not
2012/2/6 Kassai Istvan <kako@...>
-- Roberto Spadim Spadim Technology / SPAEmpresarial ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: possible bug: ds9097 and not ds9097U
by kako-2
::
Rate this Message:
owhttpd also shows the same directory structure as the owfs mounts.
Everything is there but the sensor related subdirectory lacks.
So as far as I can understand, it means fuse works. 2012-02-06 19:59 keltezéssel, Roberto Spadim írta: hum, try owhttpd and webbrowser to check if it's a fuse problem or not ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: possible bug: ds9097 and not ds9097U
by Paul Alfille-2
::
Rate this Message:
I wouldn't worry about the Avahi messages, it isn't important.
How do you know the isn't a hardware error with the sensor? Wiring problem. On Mon, Feb 6, 2012 at 2:28 PM, Kassai Istvan <kako@...> wrote:
------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: possible bug: ds9097 and not ds9097U
by kako-2
::
Rate this Message:
If I connect back to my PC-s serial port, it works, but not with the
routerboard's port. I've checked it many times.
the result when I run it on my pc: *********** [root@kako 1w]# ls -la összesen 4 drwxr-xr-x. 1 root root 8 febr 7 07.12 . drwxr-xr-x. 3 root root 4096 febr 5 16.53 .. drwxrwxrwx. 1 root root 8 febr 7 07.12 3B.CA8505000000 drwxr-xr-x. 1 root root 8 febr 7 07.12 alarm drwxr-xr-x. 1 root root 8 febr 7 07.12 bus.0 drwxr-xr-x. 1 root root 8 febr 7 07.12 settings drwxrwxrwx. 1 root root 8 febr 7 07.12 simultaneous drwxr-xr-x. 1 root root 8 febr 7 07.12 statistics drwxr-xr-x. 1 root root 32 febr 7 07.12 structure drwxr-xr-x. 1 root root 8 febr 7 07.12 system drwxr-xr-x. 1 root root 8 febr 7 07.12 uncached [root@kako 1w]# *********** And the debug says: *********** [root@kako ~]# /opt/owfs/bin/owfs --passive=/dev/ttyS0 /mnt/1w/ --8bit --debug CONNECT: owfs.c:main(100) fuse mount point: /mnt/1w/ DEBUG: ow_avahi_link.c:OW_Load_avahi_library(75) Avahi support: libavahi-client loaded successfully DEBUG: ow_avahi_link.c:OW_Load_avahi_library(77) Avahi library function found: avahi_client_errno DEBUG: ow_avahi_link.c:OW_Load_avahi_library(78) Avahi library function found: avahi_client_free DEBUG: ow_avahi_link.c:OW_Load_avahi_library(79) Avahi library function found: avahi_client_new DEBUG: ow_avahi_link.c:OW_Load_avahi_library(80) Avahi library function found: avahi_client_get_domain_name DEBUG: ow_avahi_link.c:OW_Load_avahi_library(81) Avahi library function found: avahi_entry_group_add_service DEBUG: ow_avahi_link.c:OW_Load_avahi_library(82) Avahi library function found: avahi_entry_group_commit DEBUG: ow_avahi_link.c:OW_Load_avahi_library(83) Avahi library function found: avahi_entry_group_is_empty DEBUG: ow_avahi_link.c:OW_Load_avahi_library(84) Avahi library function found: avahi_entry_group_new DEBUG: ow_avahi_link.c:OW_Load_avahi_library(85) Avahi library function found: avahi_entry_group_reset DEBUG: ow_avahi_link.c:OW_Load_avahi_library(87) Avahi library function found: avahi_service_resolver_free DEBUG: ow_avahi_link.c:OW_Load_avahi_library(88) Avahi library function found: avahi_service_resolver_new DEBUG: ow_avahi_link.c:OW_Load_avahi_library(89) Avahi library function found: avahi_service_browser_free DEBUG: ow_avahi_link.c:OW_Load_avahi_library(90) Avahi library function found: avahi_service_browser_new DEBUG: ow_avahi_link.c:OW_Load_avahi_library(102) Avahi support: libavahi-common loaded successfully. DEBUG: ow_avahi_link.c:OW_Load_avahi_library(104) Avahi library function found: avahi_simple_poll_free DEBUG: ow_avahi_link.c:OW_Load_avahi_library(105) Avahi library function found: avahi_simple_poll_get DEBUG: ow_avahi_link.c:OW_Load_avahi_library(106) Avahi library function found: avahi_simple_poll_loop DEBUG: ow_avahi_link.c:OW_Load_avahi_library(107) Avahi library function found: avahi_simple_poll_new DEBUG: ow_avahi_link.c:OW_Load_avahi_library(108) Avahi library function found: avahi_simple_poll_quit DEBUG: ow_avahi_link.c:OW_Load_avahi_library(109) Avahi library function found: avahi_strerror CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[] DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C 100C (for simulated adapters) DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 1 - 0 = 1 DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 0 OWFS DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 1 /mnt/1w/ DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 2 -o DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 3 direct_io DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 4 -f DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 5 -d DEBUG: owfs.c:main(125) fuse_mnt_opt=[(null)] DEBUG: owfs.c:main(127) fuse_open_opt=[(null)] FUSE library version: 2.8.6 nullpath_ok: 0 unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 INIT: 7.17 flags=0x0000047b max_readahead=0x00020000 INIT: 7.12 flags=0x00000011 max_readahead=0x00020000 max_write=0x00020000 unique: 1, success, outsize: 40 unique: 2, opcode: ACCESS (34), nodeid: 1, insize: 48 unique: 2, error: -38 (Function not implemented), outsize: 16 unique: 3, opcode: GETATTR (3), nodeid: 1, insize: 56 getattr / CALL: ow_fstat.c:FS_fstat(22) path=/ CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/ DEBUG: ow_parsename.c:FS_ParsedName_destroy(59) / unique: 3, success, outsize: 120 unique: 4, opcode: OPENDIR (27), nodeid: 1, insize: 48 unique: 4, success, outsize: 32 unique: 6, opcode: INTERRUPT (36), nodeid: 0, insize: 48 INTERRUPT: 5 unique: 5, opcode: READDIR (28), nodeid: 1, insize: 80 getdir[0] CALL: ow_parsename.c:FS_ParsedName_anywhere(95) path=[/] CALL: owfs_callback.c:FS_getdir(175) GETDIR path=/ DEBUG: ow_dir.c:FS_dir(63) path=/ CALL: ow_dir.c:FS_dir_both(98) path=/ DEBUG: ow_cache.c:Cache_Get_Dir(868) Looking for directory 00 00 00 00 00 00 00 00 DEBUG: ow_cache.c:Cache_Get_Common_Dir(881) Get from cache sn 00 00 00 00 00 00 00 00 pointer=0xb770b954 extension=0 DEBUG: ow_cache.c:Cache_Get_Common_Dir(910) Dir not found in cache DEBUG: ow_search.c:BUS_first(32) Start of directory path=/ device=00 00 00 00 00 00 00 00 DEBUG: ow_select.c:BUS_select(66) Selecting a path (and device) path=/ SN=00 00 00 00 00 00 00 00 last path=00 00 00 00 00 00 00 00 DEBUG: ow_select.c:BUS_select(79) Continuing root branch DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 1 - 0 = 1 DEBUG: ow_bus_data.c:BUS_sendback_data_bitbang(120) Splitting byte 0 of 1 = F0 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 8 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 8 - 0 = 8 DEBUG: ow_bus_data.c:BUS_sendback_data_bitbang(141) Consolidating byte 0 of 1 = F0 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 2 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 2 - 0 = 2 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 3 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 3 - 0 = 3 DEBUG: ow_tcp_read.c:tcp_read(64) attempt 1 bytes Time: 5.000000 seconds DEBUG: ow_tcp_read.c:tcp_read(114) read: 1 - 0 = 1 DEBUG: ow_search.c:BUS_next(74) Device found: 3B CA 85 05 00 00 00 6A DEBUG: ow_cache.c:Cache_Add_Device(561) Adding device location 3B CA 85 05 00 00 00 6A bus=0 DEBUG: ow_cache.c:Cache_Add_Common(650) Add to cache sn 3B CA 85 05 00 00 00 6A pointer=0xb770b94c index=0 size=4 DEBUG: ow_cache.c:Cache_Add_Device(561) Adding device location 3B CA 85 05 00 00 00 6A bus=0 *********** So as it shows it have found the sensor too. Ergo it coudn't be a wiring fault. 2012-02-06 22:50 keltezéssel, Paul Alfille írta: I wouldn't worry about the Avahi messages, it isn't important. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
ds9097 on embedded boards
by kako-2
::
Rate this Message:
Hi folks, I'm trying to make a working temperature logging device on embedded platform (because of consumption reason). I was already trying to prepare before, but haven't succeeded. It works on PC (But I don't want to let running a whole PC ) normally. So I dicided to move this simple thing to a routerboard 433AH. It didn't worked. only gives this directory structure: ************ root@drone:/mnt/1w# ls -la drwxr-xr-x 1 root root 8 Jan 1 00:21 . drwxr-xr-x 5 root root 1024 Jan 1 00:07 .. drwxr-xr-x 1 root root 8 Jan 1 00:21 bus.0 drwxr-xr-x 1 root root 8 Jan 1 00:21 settings drwxr-xr-x 1 root root 8 Jan 1 00:21 statistics drwxr-xr-x 1 root root 30 Jan 1 00:21 structure drwxr-xr-x 1 root root 8 Jan 1 00:21 system drwxr-xr-x 1 root root 8 Jan 1 00:21 uncached ************ I thought it doesn't work on routerboard. So I bought a wrap board ( http://www.pcengines.ch/alix2d2.htm ), which is x86 based and I'm trying on it to make it work. But the problem is the same :-( Of course I disabled the serial consol Is there anybody can help me, I don't know where to look for the rason of the failure ?! the "--debug" says when I start: *********** root@drone:~# owfs --passive=/dev/ttyS0 /mnt/1w/ --8bit --debug CONNECT: owfs.c:main(123) fuse mount point: /mnt/1w/ CONNECT: ow_avahi_link.c:OW_Load_avahi_library(72) No Avahi support. Library libavahi-client couldn't be loaded CONNECT: ow_dnssd.c:OW_Load_dnssd_library(136) Zeroconf/Bonjour is disabled since dnssd library isn't found CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[] DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C 100C (for simulated adapters) DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 0 OWFS DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 1 /mnt/1w/ DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 2 -o DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 3 direct_io DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 4 -f DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 5 -d DEBUG: owfs.c:main(152) fuse_mnt_opt=[(null)] DEBUG: owfs.c:main(154) fuse_open_opt=[(null)] FUSE library version: 2.8.3 nullpath_ok: 0 unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 INIT: 7.13 flags=0x0000007b max_readahead=0x00020000 INIT: 7.12 flags=0x00000011 max_readahead=0x00020000 max_write=0x00020000 unique: 1, success, outsize: 40 *********** When I try to list the mountpoint directory: **********unique: 2, opcode: ACCESS (34), nodeid: 1, insize: 48 unique: 2, error: -38 (Function not implemented), outsize: 16 unique: 3, opcode: GETATTR (3), nodeid: 1, insize: 56 getattr / CALL: ow_fstat.c:FS_fstat(22) path=/ CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/ DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) / unique: 3, success, outsize: 120 unique: 4, opcode: OPENDIR (27), nodeid: 1, insize: 48 unique: 4, success, outsize: 32 unique: 5, opcode: READDIR (28), nodeid: 1, insize: 80 getdir[0] CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/] CALL: owfs_callback.c:FS_getdir(175) GETDIR path=/ DEBUG: ow_dir.c:FS_dir(63) path=/ CALL: ow_dir.c:FS_dir_both(98) path=/ DEBUG: ow_cache.c:Cache_Get_Dir(806) Looking for directory 00 00 00 00 00 00 00 00 DEBUG: ow_cache.c:Cache_Get_Common_Dir(819) Get from cache sn 00 00 00 00 00 00 00 00 pointer=0xb7766f34 extension=0 DEBUG: ow_cache.c:Cache_Get_Common_Dir(843) dir not found in cache DEBUG: ow_search.c:BUS_first(32) Start of directory path=/ device=00 00 00 00 00 00 00 00 DEBUG: ow_select.c:BUS_select(72) Selecting a path (and device) path=/ SN=00 00 00 00 00 00 00 00 last path=FF 00 00 00 00 00 00 00 DEBUG: ow_select.c:BUS_select(77) Clearing root branch DEBUG: ow_transaction.c:BUS_transaction_single(99) send = 0 DEBUG: ow_transaction.c:BUS_transaction_single(168) end = 0 DEBUG: ow_cache.c:Cache_Add_Dir(405) Adding duirectory for 00 00 00 00 00 00 00 00 elements=0 DEBUG: ow_cache.c:Cache_Add_Common(595) Add to cache sn 00 00 00 00 00 00 00 00 pointer=0xb7766f34 index=0 size=0 CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/bus.0] DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /bus.0 CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/uncached] DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /uncached CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/settings] DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /settings CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/system] DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /system CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/statistics] DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /statistics CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/structure] DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /structure DEBUG: ow_dir.c:FS_dir_both(186) ret=0 DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) / unique: 5, success, outsize: 288 unique: 6, opcode: LOOKUP (1), nodeid: 1, insize: 46 LOOKUP /bus.0 getattr /bus.0 CALL: ow_fstat.c:FS_fstat(22) path=/bus.0 CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/bus.0] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/bus.0 DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /bus.0 NODEID: 2 unique: 6, success, outsize: 144 unique: 7, opcode: LOOKUP (1), nodeid: 1, insize: 49 LOOKUP /uncached getattr /uncached CALL: ow_fstat.c:FS_fstat(22) path=/uncached CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/uncached] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/uncached DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /uncached NODEID: 3 unique: 7, success, outsize: 144 unique: 8, opcode: LOOKUP (1), nodeid: 1, insize: 49 LOOKUP /settings getattr /settings CALL: ow_fstat.c:FS_fstat(22) path=/settings CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/settings] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/settings DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /settings NODEID: 4 unique: 8, success, outsize: 144 unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 47 LOOKUP /system getattr /system CALL: ow_fstat.c:FS_fstat(22) path=/system CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/system] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/system DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /system NODEID: 5 unique: 9, success, outsize: 144 unique: 10, opcode: LOOKUP (1), nodeid: 1, insize: 51 LOOKUP /statistics getattr /statistics CALL: ow_fstat.c:FS_fstat(22) path=/statistics CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/statistics] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/statistics DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /statistics NODEID: 6 unique: 10, success, outsize: 144 unique: 11, opcode: LOOKUP (1), nodeid: 1, insize: 50 LOOKUP /structure getattr /structure CALL: ow_fstat.c:FS_fstat(22) path=/structure CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/structure] CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/structure DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /structure NODEID: 7 unique: 11, success, outsize: 144 unique: 12, opcode: READDIR (28), nodeid: 1, insize: 80 unique: 12, success, outsize: 16 unique: 13, opcode: RELEASEDIR (29), nodeid: 1, insize: 64 unique: 13, success, outsize: 16 ********** Finally, when I leave the mountpoint dir: *********** DEBUG: owfs.c:ow_exit(31) owfs: ow_exit(0) CALL: ow_lib_close.c:LibClose(21) Starting Library cleanup CALL: ow_lib_stop.c:LibStop(23) Clear Cache CALL: ow_lib_stop.c:LibStop(25) Closing input devices DEBUG: ow_com.c:COM_close(93) COM_close: flush DEBUG: ow_com.c:COM_close(95) COM_close: restore DEBUG: ow_com.c:COM_close(99) COM_close: close CALL: ow_lib_stop.c:LibStop(27) Closing outout devices DEBUG: ow_connect.c:FreeOutAll(232) Freeing outbound (null) #0 CALL: ow_lib_close.c:LibClose(34) Finished Library cleanup DEBUG: ow_lib_close.c:LibClose(42) Libraries closed *********** If I connect back to my PC-s serial port, it works, but not with the routerboard's (and now with the alix) port. I've checked it many times. the result when I run it on my pc: *********** [root@kako 1w]# ls -la összesen 4 drwxr-xr-x. 1 root root 8 febr 7 07.12 . drwxr-xr-x. 3 root root 4096 febr 5 16.53 .. drwxrwxrwx. 1 root root 8 febr 7 07.12 3B.CA8505000000 drwxr-xr-x. 1 root root 8 febr 7 07.12 alarm drwxr-xr-x. 1 root root 8 febr 7 07.12 bus.0 drwxr-xr-x. 1 root root 8 febr 7 07.12 settings drwxrwxrwx. 1 root root 8 febr 7 07.12 simultaneous drwxr-xr-x. 1 root root 8 febr 7 07.12 statistics drwxr-xr-x. 1 root root 32 febr 7 07.12 structure drwxr-xr-x. 1 root root 8 febr 7 07.12 system drwxr-xr-x. 1 root root 8 febr 7 07.12 uncached [root@kako 1w]# *********** ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by Roberto Spadim
::
Rate this Message:
hum, check statistics if theres a short counter with value >0
Em 3 de abril de 2012 10:46, Kassai Istvan <kako@...> escreveu: > > Hi folks, > > I'm trying to make a working temperature logging device on embedded platform > (because of consumption reason). I was already trying to prepare before, but > haven't succeeded. It works on PC (But I don't want to let running a whole > PC ) normally. So I dicided to move this simple thing to a routerboard > 433AH. > It didn't worked. only gives this directory structure: > > ************ > root@drone:/mnt/1w# ls -la > drwxr-xr-x 1 root root 8 Jan 1 00:21 . > drwxr-xr-x 5 root root 1024 Jan 1 00:07 .. > drwxr-xr-x 1 root root 8 Jan 1 00:21 bus.0 > drwxr-xr-x 1 root root 8 Jan 1 00:21 settings > drwxr-xr-x 1 root root 8 Jan 1 00:21 statistics > drwxr-xr-x 1 root root 30 Jan 1 00:21 structure > drwxr-xr-x 1 root root 8 Jan 1 00:21 system > drwxr-xr-x 1 root root 8 Jan 1 00:21 uncached > > ************ > > I thought it doesn't work on routerboard. So I bought a wrap board ( > http://www.pcengines.ch/alix2d2.htm ), which is x86 based and I'm trying on > it to make it work. But the problem is the same :-( > > > Of course I disabled the serial consol > > Is there anybody can help me, I don't know where to look for the rason of > the failure ?! > > > > > > > the "--debug" says when I start: > > *********** > root@drone:~# owfs --passive=/dev/ttyS0 /mnt/1w/ --8bit --debug > CONNECT: owfs.c:main(123) fuse mount point: /mnt/1w/ > CONNECT: ow_avahi_link.c:OW_Load_avahi_library(72) No Avahi support. Library > libavahi-client couldn't be loaded > CONNECT: ow_dnssd.c:OW_Load_dnssd_library(136) Zeroconf/Bonjour is disabled > since dnssd library isn't found > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[] > DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C 100C (for > simulated adapters) > DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 0 OWFS > DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 1 /mnt/1w/ > DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 2 -o > DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 3 direct_io > DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 4 -f > DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 5 -d > DEBUG: owfs.c:main(152) fuse_mnt_opt=[(null)] > DEBUG: owfs.c:main(154) fuse_open_opt=[(null)] > FUSE library version: 2.8.3 > nullpath_ok: 0 > unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 > INIT: 7.13 > flags=0x0000007b > max_readahead=0x00020000 > INIT: 7.12 > flags=0x00000011 > max_readahead=0x00020000 > max_write=0x00020000 > unique: 1, success, outsize: 40 > *********** > > > > When I try to list the mountpoint directory: > **********unique: 2, opcode: ACCESS (34), nodeid: 1, insize: 48 > unique: 2, error: -38 (Function not implemented), outsize: 16 > unique: 3, opcode: GETATTR (3), nodeid: 1, insize: 56 > getattr / > CALL: ow_fstat.c:FS_fstat(22) path=/ > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/] > CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/ > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) / > unique: 3, success, outsize: 120 > unique: 4, opcode: OPENDIR (27), nodeid: 1, insize: 48 > unique: 4, success, outsize: 32 > unique: 5, opcode: READDIR (28), nodeid: 1, insize: 80 > getdir[0] > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/] > CALL: owfs_callback.c:FS_getdir(175) GETDIR path=/ > DEBUG: ow_dir.c:FS_dir(63) path=/ > CALL: ow_dir.c:FS_dir_both(98) path=/ > DEBUG: ow_cache.c:Cache_Get_Dir(806) Looking for directory 00 00 00 00 00 > 00 00 00 > DEBUG: ow_cache.c:Cache_Get_Common_Dir(819) Get from cache sn 00 00 00 00 > 00 00 00 00 pointer=0xb7766f34 extension=0 > DEBUG: ow_cache.c:Cache_Get_Common_Dir(843) dir not found in cache > DEBUG: ow_search.c:BUS_first(32) Start of directory path=/ device=00 00 00 > 00 00 00 00 00 > DEBUG: ow_select.c:BUS_select(72) Selecting a path (and device) path=/ > SN=00 00 00 00 00 00 00 00 last path=FF 00 00 00 00 00 00 00 > DEBUG: ow_select.c:BUS_select(77) Clearing root branch > DEBUG: ow_transaction.c:BUS_transaction_single(99) send = 0 > DEBUG: ow_transaction.c:BUS_transaction_single(168) end = 0 > DEBUG: ow_cache.c:Cache_Add_Dir(405) Adding duirectory for 00 00 00 00 00 > 00 00 00 elements=0 > DEBUG: ow_cache.c:Cache_Add_Common(595) Add to cache sn 00 00 00 00 00 00 > 00 00 pointer=0xb7766f34 index=0 size=0 > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/bus.0] > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /bus.0 > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/uncached] > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /uncached > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/settings] > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /settings > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/system] > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /system > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/statistics] > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /statistics > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/structure] > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /structure > DEBUG: ow_dir.c:FS_dir_both(186) ret=0 > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) / > unique: 5, success, outsize: 288 > unique: 6, opcode: LOOKUP (1), nodeid: 1, insize: 46 > LOOKUP /bus.0 > getattr /bus.0 > CALL: ow_fstat.c:FS_fstat(22) path=/bus.0 > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/bus.0] > CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/bus.0 > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /bus.0 > NODEID: 2 > unique: 6, success, outsize: 144 > unique: 7, opcode: LOOKUP (1), nodeid: 1, insize: 49 > LOOKUP /uncached > getattr /uncached > CALL: ow_fstat.c:FS_fstat(22) path=/uncached > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/uncached] > CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/uncached > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /uncached > NODEID: 3 > unique: 7, success, outsize: 144 > unique: 8, opcode: LOOKUP (1), nodeid: 1, insize: 49 > LOOKUP /settings > getattr /settings > CALL: ow_fstat.c:FS_fstat(22) path=/settings > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/settings] > CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/settings > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /settings > NODEID: 4 > unique: 8, success, outsize: 144 > unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 47 > LOOKUP /system > getattr /system > CALL: ow_fstat.c:FS_fstat(22) path=/system > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/system] > CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/system > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /system > NODEID: 5 > unique: 9, success, outsize: 144 > unique: 10, opcode: LOOKUP (1), nodeid: 1, insize: 51 > LOOKUP /statistics > getattr /statistics > CALL: ow_fstat.c:FS_fstat(22) path=/statistics > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/statistics] > CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/statistics > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /statistics > NODEID: 6 > unique: 10, success, outsize: 144 > unique: 11, opcode: LOOKUP (1), nodeid: 1, insize: 50 > LOOKUP /structure > getattr /structure > CALL: ow_fstat.c:FS_fstat(22) path=/structure > CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/structure] > CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/structure > DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /structure > NODEID: 7 > unique: 11, success, outsize: 144 > unique: 12, opcode: READDIR (28), nodeid: 1, insize: 80 > unique: 12, success, outsize: 16 > unique: 13, opcode: RELEASEDIR (29), nodeid: 1, insize: 64 > unique: 13, success, outsize: 16 > ********** > > > Finally, when I leave the mountpoint dir: > *********** > DEBUG: owfs.c:ow_exit(31) owfs: ow_exit(0) > CALL: ow_lib_close.c:LibClose(21) Starting Library cleanup > CALL: ow_lib_stop.c:LibStop(23) Clear Cache > CALL: ow_lib_stop.c:LibStop(25) Closing input devices > DEBUG: ow_com.c:COM_close(93) COM_close: flush > DEBUG: ow_com.c:COM_close(95) COM_close: restore > DEBUG: ow_com.c:COM_close(99) COM_close: close > CALL: ow_lib_stop.c:LibStop(27) Closing outout devices > DEBUG: ow_connect.c:FreeOutAll(232) Freeing outbound (null) #0 > CALL: ow_lib_close.c:LibClose(34) Finished Library cleanup > DEBUG: ow_lib_close.c:LibClose(42) Libraries closed > *********** > > > > > > > > > > > > If I connect back to my PC-s serial port, it works, but not with the > routerboard's (and now with the alix) port. I've checked it many times. > > the result when I run it on my pc: > > *********** > [root@kako 1w]# ls -la > összesen 4 > drwxr-xr-x. 1 root root 8 febr 7 07.12 . > drwxr-xr-x. 3 root root 4096 febr 5 16.53 .. > drwxrwxrwx. 1 root root 8 febr 7 07.12 3B.CA8505000000 > drwxr-xr-x. 1 root root 8 febr 7 07.12 alarm > drwxr-xr-x. 1 root root 8 febr 7 07.12 bus.0 > drwxr-xr-x. 1 root root 8 febr 7 07.12 settings > drwxrwxrwx. 1 root root 8 febr 7 07.12 simultaneous > drwxr-xr-x. 1 root root 8 febr 7 07.12 statistics > drwxr-xr-x. 1 root root 32 febr 7 07.12 structure > drwxr-xr-x. 1 root root 8 febr 7 07.12 system > drwxr-xr-x. 1 root root 8 febr 7 07.12 uncached > [root@kako 1w]# > > > *********** > > > > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@... > https://lists.sourceforge.net/lists/listinfo/owfs-developers > -- Roberto Spadim Spadim Technology / SPAEmpresarial ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by kako-2
::
Rate this Message:
There are two files under the owfs mountpoint named "shorts". One in the
./bus.0/interface/statistics/ and one in the ./uncached/bus.0/interface/statistics/ Both of them contains "0" 2012-04-03 16:35 keltezéssel, Roberto Spadim írta: > hum, check statistics if theres a short counter with value>0 > > Em 3 de abril de 2012 10:46, Kassai Istvan<kako@...> escreveu: >> Hi folks, >> >> I'm trying to make a working temperature logging device on embedded platform >> (because of consumption reason). I was already trying to prepare before, but >> haven't succeeded. It works on PC (But I don't want to let running a whole >> PC ) normally. So I dicided to move this simple thing to a routerboard >> 433AH. >> It didn't worked. only gives this directory structure: >> >> ************ >> root@drone:/mnt/1w# ls -la >> drwxr-xr-x 1 root root 8 Jan 1 00:21 . >> drwxr-xr-x 5 root root 1024 Jan 1 00:07 .. >> drwxr-xr-x 1 root root 8 Jan 1 00:21 bus.0 >> drwxr-xr-x 1 root root 8 Jan 1 00:21 settings >> drwxr-xr-x 1 root root 8 Jan 1 00:21 statistics >> drwxr-xr-x 1 root root 30 Jan 1 00:21 structure >> drwxr-xr-x 1 root root 8 Jan 1 00:21 system >> drwxr-xr-x 1 root root 8 Jan 1 00:21 uncached >> >> ************ >> >> I thought it doesn't work on routerboard. So I bought a wrap board ( >> http://www.pcengines.ch/alix2d2.htm ), which is x86 based and I'm trying on >> it to make it work. But the problem is the same :-( >> >> >> Of course I disabled the serial consol >> >> Is there anybody can help me, I don't know where to look for the rason of >> the failure ?! >> >> >> >> >> >> >> the "--debug" says when I start: >> >> *********** >> root@drone:~# owfs --passive=/dev/ttyS0 /mnt/1w/ --8bit --debug >> CONNECT: owfs.c:main(123) fuse mount point: /mnt/1w/ >> CONNECT: ow_avahi_link.c:OW_Load_avahi_library(72) No Avahi support. Library >> libavahi-client couldn't be loaded >> CONNECT: ow_dnssd.c:OW_Load_dnssd_library(136) Zeroconf/Bonjour is disabled >> since dnssd library isn't found >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[] >> DEBUG: owlib.c:SetupTemperatureLimits(79) Globals temp limits 0C 100C (for >> simulated adapters) >> DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 0 OWFS >> DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 1 /mnt/1w/ >> DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 2 -o >> DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 3 direct_io >> DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 4 -f >> DEBUG: fuse_line.c:Fuse_add(82) Added FUSE option 5 -d >> DEBUG: owfs.c:main(152) fuse_mnt_opt=[(null)] >> DEBUG: owfs.c:main(154) fuse_open_opt=[(null)] >> FUSE library version: 2.8.3 >> nullpath_ok: 0 >> unique: 1, opcode: INIT (26), nodeid: 0, insize: 56 >> INIT: 7.13 >> flags=0x0000007b >> max_readahead=0x00020000 >> INIT: 7.12 >> flags=0x00000011 >> max_readahead=0x00020000 >> max_write=0x00020000 >> unique: 1, success, outsize: 40 >> *********** >> >> >> >> When I try to list the mountpoint directory: >> **********unique: 2, opcode: ACCESS (34), nodeid: 1, insize: 48 >> unique: 2, error: -38 (Function not implemented), outsize: 16 >> unique: 3, opcode: GETATTR (3), nodeid: 1, insize: 56 >> getattr / >> CALL: ow_fstat.c:FS_fstat(22) path=/ >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/] >> CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/ >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) / >> unique: 3, success, outsize: 120 >> unique: 4, opcode: OPENDIR (27), nodeid: 1, insize: 48 >> unique: 4, success, outsize: 32 >> unique: 5, opcode: READDIR (28), nodeid: 1, insize: 80 >> getdir[0] >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/] >> CALL: owfs_callback.c:FS_getdir(175) GETDIR path=/ >> DEBUG: ow_dir.c:FS_dir(63) path=/ >> CALL: ow_dir.c:FS_dir_both(98) path=/ >> DEBUG: ow_cache.c:Cache_Get_Dir(806) Looking for directory 00 00 00 00 00 >> 00 00 00 >> DEBUG: ow_cache.c:Cache_Get_Common_Dir(819) Get from cache sn 00 00 00 00 >> 00 00 00 00 pointer=0xb7766f34 extension=0 >> DEBUG: ow_cache.c:Cache_Get_Common_Dir(843) dir not found in cache >> DEBUG: ow_search.c:BUS_first(32) Start of directory path=/ device=00 00 00 >> 00 00 00 00 00 >> DEBUG: ow_select.c:BUS_select(72) Selecting a path (and device) path=/ >> SN=00 00 00 00 00 00 00 00 last path=FF 00 00 00 00 00 00 00 >> DEBUG: ow_select.c:BUS_select(77) Clearing root branch >> DEBUG: ow_transaction.c:BUS_transaction_single(99) send = 0 >> DEBUG: ow_transaction.c:BUS_transaction_single(168) end = 0 >> DEBUG: ow_cache.c:Cache_Add_Dir(405) Adding duirectory for 00 00 00 00 00 >> 00 00 00 elements=0 >> DEBUG: ow_cache.c:Cache_Add_Common(595) Add to cache sn 00 00 00 00 00 00 >> 00 00 pointer=0xb7766f34 index=0 size=0 >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/bus.0] >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /bus.0 >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/uncached] >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /uncached >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/settings] >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /settings >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/system] >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /system >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/statistics] >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /statistics >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/structure] >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /structure >> DEBUG: ow_dir.c:FS_dir_both(186) ret=0 >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) / >> unique: 5, success, outsize: 288 >> unique: 6, opcode: LOOKUP (1), nodeid: 1, insize: 46 >> LOOKUP /bus.0 >> getattr /bus.0 >> CALL: ow_fstat.c:FS_fstat(22) path=/bus.0 >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/bus.0] >> CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/bus.0 >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /bus.0 >> NODEID: 2 >> unique: 6, success, outsize: 144 >> unique: 7, opcode: LOOKUP (1), nodeid: 1, insize: 49 >> LOOKUP /uncached >> getattr /uncached >> CALL: ow_fstat.c:FS_fstat(22) path=/uncached >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/uncached] >> CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/uncached >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /uncached >> NODEID: 3 >> unique: 7, success, outsize: 144 >> unique: 8, opcode: LOOKUP (1), nodeid: 1, insize: 49 >> LOOKUP /settings >> getattr /settings >> CALL: ow_fstat.c:FS_fstat(22) path=/settings >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/settings] >> CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/settings >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /settings >> NODEID: 4 >> unique: 8, success, outsize: 144 >> unique: 9, opcode: LOOKUP (1), nodeid: 1, insize: 47 >> LOOKUP /system >> getattr /system >> CALL: ow_fstat.c:FS_fstat(22) path=/system >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/system] >> CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/system >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /system >> NODEID: 5 >> unique: 9, success, outsize: 144 >> unique: 10, opcode: LOOKUP (1), nodeid: 1, insize: 51 >> LOOKUP /statistics >> getattr /statistics >> CALL: ow_fstat.c:FS_fstat(22) path=/statistics >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/statistics] >> CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/statistics >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /statistics >> NODEID: 6 >> unique: 10, success, outsize: 144 >> unique: 11, opcode: LOOKUP (1), nodeid: 1, insize: 50 >> LOOKUP /structure >> getattr /structure >> CALL: ow_fstat.c:FS_fstat(22) path=/structure >> CALL: ow_parsename.c:FS_ParsedName_anywhere(90) path=[/structure] >> CALL: ow_fstat.c:FS_fstat_postparse(39) ATTRIBUTES path=/structure >> DEBUG: ow_parsename.c:FS_ParsedName_destroy(54) /structure >> NODEID: 7 >> unique: 11, success, outsize: 144 >> unique: 12, opcode: READDIR (28), nodeid: 1, insize: 80 >> unique: 12, success, outsize: 16 >> unique: 13, opcode: RELEASEDIR (29), nodeid: 1, insize: 64 >> unique: 13, success, outsize: 16 >> ********** >> >> >> Finally, when I leave the mountpoint dir: >> *********** >> DEBUG: owfs.c:ow_exit(31) owfs: ow_exit(0) >> CALL: ow_lib_close.c:LibClose(21) Starting Library cleanup >> CALL: ow_lib_stop.c:LibStop(23) Clear Cache >> CALL: ow_lib_stop.c:LibStop(25) Closing input devices >> DEBUG: ow_com.c:COM_close(93) COM_close: flush >> DEBUG: ow_com.c:COM_close(95) COM_close: restore >> DEBUG: ow_com.c:COM_close(99) COM_close: close >> CALL: ow_lib_stop.c:LibStop(27) Closing outout devices >> DEBUG: ow_connect.c:FreeOutAll(232) Freeing outbound (null) #0 >> CALL: ow_lib_close.c:LibClose(34) Finished Library cleanup >> DEBUG: ow_lib_close.c:LibClose(42) Libraries closed >> *********** >> >> >> >> >> >> >> >> >> >> >> >> If I connect back to my PC-s serial port, it works, but not with the >> routerboard's (and now with the alix) port. I've checked it many times. >> >> the result when I run it on my pc: >> >> *********** >> [root@kako 1w]# ls -la >> összesen 4 >> drwxr-xr-x. 1 root root 8 febr 7 07.12 . >> drwxr-xr-x. 3 root root 4096 febr 5 16.53 .. >> drwxrwxrwx. 1 root root 8 febr 7 07.12 3B.CA8505000000 >> drwxr-xr-x. 1 root root 8 febr 7 07.12 alarm >> drwxr-xr-x. 1 root root 8 febr 7 07.12 bus.0 >> drwxr-xr-x. 1 root root 8 febr 7 07.12 settings >> drwxrwxrwx. 1 root root 8 febr 7 07.12 simultaneous >> drwxr-xr-x. 1 root root 8 febr 7 07.12 statistics >> drwxr-xr-x. 1 root root 32 febr 7 07.12 structure >> drwxr-xr-x. 1 root root 8 febr 7 07.12 system >> drwxr-xr-x. 1 root root 8 febr 7 07.12 uncached >> [root@kako 1w]# >> >> >> *********** >> >> >> >> >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Owfs-developers mailing list >> Owfs-developers@... >> https://lists.sourceforge.net/lists/listinfo/owfs-developers >> > > ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by Paul Alfille-2
::
Rate this Message:
So you've already done a lot of debugging -- the fuse system works, and the hardware works on another system.
Thus the problem is with serial port handling (hardware or kernel or maybe timing). digitemp http://www.digitemp.com/ has support for the DS9097E passive adapter and would be another test of the hardware. It shouldn't be a polarity issue, but it could be a voltage problem on the embedded board. The passive adapter steals power from the serial pins. Paul Alfille On Tue, Apr 3, 2012 at 1:27 PM, Kassai Istvan <kako@...> wrote: There are two files under the owfs mountpoint named "shorts". One in the ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by kako-2
::
Rate this Message:
2012-04-03 20:11 keltezéssel, Paul Alfille írta: So you've already done a lot of debugging -- the fuse system works, and the hardware works on another system.You mean it steals power for the adapter, or the sensor own? (I think for the sensor, cause the adapter has only passive parts) The sensor works in parasite mode. May the problem resolved by directly powering the sensor? Paul Alfille ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by Markus Gaugusch
::
Rate this Message:
I assume that the serial port of the embedded system only provides 5V on
its signal lines. If the DS9097 expects 12V and uses a voltage regulator to provide 5V to the bus, it will most probably fail. Can you measure voltage between 1wire and gnd pins on your adaptor? It should not be much less than 5 volts. best regards, Markus On Apr 3, Kassai Istvan <kako@...> wrote: > > > > 2012-04-03 20:11 keltezéssel, Paul Alfille írta: >> So you've already done a lot of debugging -- the fuse system works, and the >> hardware works on another system. >> >> Thus the problem is with serial port handling (hardware or kernel or maybe >> timing). >> >> digitemp http://www.digitemp.com/ has support for the DS9097E passive >> adapter and would be another test of the hardware. >> >> It shouldn't be a polarity issue, but it could be a voltage problem on the >> embedded board. The passive adapter steals power from the serial pins. >> > You mean it steals power for the adapter, or the sensor own? (I think for the > sensor, cause the adapter has only passive parts) > The sensor works in parasite mode. May the problem resolved by directly > powering the sensor? > > > >> Paul Alfille >> >> On Tue, Apr 3, 2012 at 1:27 PM, Kassai Istvan <kako@... >> <mailto:kako@...>> wrote: >> >> There are two files under the owfs mountpoint named "shorts". One >> in the >> ./bus.0/interface/statistics/ and one in the >> ./uncached/bus.0/interface/statistics/ >> >> Both of them contains "0" >> > > __________________ /"\ Markus Gaugusch \ / ASCII Ribbon Campaign markus(at)gaugusch.at X Against HTML Mail / \ ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by kako-2
::
Rate this Message:
2012-04-03 20:45 keltezéssel, Markus Gaugusch írta:
> I assume that the serial port of the embedded system only provides 5V > on its signal lines. If the DS9097 expects 12V and uses a voltage > regulator to provide 5V to the bus, it will most probably fail. > I use this homemade adapter: http://owfs.sourceforge.net/adapters/db-9.png > Can you measure voltage between 1wire and gnd pins on your adaptor? I've measured (all values relative to signal ground [Pin #5]). (All of them are 9pin DB9 type connectors!) On the Alix board : Pin voltage 3 -5,6 4 5,9 7 5,9 On the PC serial port : Pin voltage 3 -10,9 4 -10,8 7 -10,9 On the Routerboard : Pin voltage 3 -5,6 4 0 7 0 > It should not be much less than 5 volts. I can measure on the 1w bus (the output of the 9097 adapter) 5,9V Can you suggest anything to make it work? (Or does anybody know a dealer in hungary I can order a non-passive serial bus-master?) Thanks kako ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by Patryk-6
::
Rate this Message:
Dnia 04.04.2012 o 11:23 Kassai Istvan <kako@...> Kassai Istvan
<kako@...> napisał(a): > Can you suggest anything to make it work? (Or does anybody know a dealer > in hungary I can order a non-passive serial bus-master?) You said also that you have a router? If you just want few thermometers you can use this http://www.lecad.fs.uni-lj.si/~leon/other/wlan/wrt54ow/ You must know that there are two types of serial ports. One is with TTL level voltage which use 0V and 5V or 0V and 3.3V. This is used in wireless routers and some single board computers. Another standard is used in PC's and have voltage levels -12V nad +12V (or -5V +5V) AFAIK DS9097 will work only with -+ voltages. If you have basic soldering skills You can build Your own master with MAX232 and DS2480B. MAX232 can be bought in almost every electronics shop and Maxim/Dallas sends DS2480B samples for free. MAX232 is for voltage level conversion because DS2480B accepts TTL levels. If you want to have a ready to use device I think and USB adapter would be the best choice. These are basically build form and USB serial converter and a serial to 1-wire master DS2480B and are good for long networks. In Poland there is a company which builds an adapter like this (maybe they will send it to Hungary) http://www.meraprojekt.com.pl/mp00202.html Or you can buy from Hobbybords the are in US but probably ship to Hungary https://www.hobby-boards.com/store/products.php?product=1%252dWire-USB-Adaptor This one is a direct USB-1-wire adapter. -- p4trykx ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by kako-2
::
Rate this Message:
2012-04-04 12:02 keltezéssel, Patryk írta:
> You must know that there are two types of serial ports. One is with > TTL level voltage which use 0V and 5V or 0V and 3.3V. This is used in > wireless routers and some single board computers. Another standard is > used in PC's and have voltage levels -12V nad +12V (or -5V +5V) AFAIK > DS9097 will work only with -+ voltages. OK, now I see, why it doesn't work. The thing what I don't understand is, if these are two different standards, how can I log in my router from the PC through a nullmodem cable without any active converter? The one side is a +-12V type, the other is a 5V. > If you have basic soldering skills You can build Your own master It is the preferrable solution for me :-) > with MAX232 and DS2480B. MAX232 can be bought in almost every > electronics shop and Maxim/Dallas sends DS2480B samples for free. > MAX232 is for voltage level conversion because DS2480B accepts TTL > levels. So, I've found a lot of different type MAX232. (CPE, D, DW etc.) I found a version (MAX232N) that is in DIL, and I can solder it easyer then the SMD versions. Are they equally? Is the only difference that the one is in SMD the other is DIL? Is this adapter I can build from these parts, will work with the boards with the low-power type RS232? Do you think is it a good schematics: http://vesta.homelinux.free.fr/site/wiki/bus_1_wire.html#Interface_active_DS9097U or can you offer a better schematics for me? ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by Patryk-6
::
Rate this Message:
Dnia 04.04.2012 o 19:37 Kassai Istvan <kako@...> Kassai Istvan
<kako@...> napisał(a): > 2012-04-04 12:02 keltezéssel, Patryk írta: > The thing what I don't understand is, if these are two different > standards, how can I log in my router from the PC through a nullmodem > cable without any active converter? The one side is a +-12V type, the > other is a 5V. That's strange. Which router do you have? > So, I've found a lot of different type MAX232. (CPE, D, DW etc.) I found > a version (MAX232N) that is in DIL, and I can solder it easyer then the > SMD versions. Are they equally? Is the only difference that the one is > in SMD the other is DIL? I'm not an expert bu I think that the DIL version would be ok. MAX232 is a very popular chip so there are hudrets of versions from many manufacturers. But I think they are basically the same. > > Is this adapter I can build from these parts, will work with the boards > with the low-power type RS232? The version with MAX232 is for RS232 with -+ voltages so it will work with PC and if You want to connect it to the router You do not need MAX232. Fist make sure what kind of serial port do you have on a router (99% do not need MAX232) > > Do you think is it a good schematics: > http://vesta.homelinux.free.fr/site/wiki/bus_1_wire.html#Interface_active_DS9097U > or can you offer a better schematics for me? This one is good however you could add DS9503 chip it's a protection from electrostatic discharges. It's optional everything will work without. This are my schematics. For wireless router with TTL voltages. There is a little incompatibility, router has 0v 3.3V and DS2480 has 5V but it runs without problems for about 1.5 year now. http://owfs.org/index.php?page=wrt-router-mods----p4trykx The MAX232 chip is not used for connecting with 1-wire, it's just in case I wanted to connect console to the PC. Also the +12V is not needed it can be connected to +5V. I also attach another schematics it's dual 1-wire interface for my other router(Asus). It has additional ADUM1402 chip which is digital isolator and does 5v 3V conversion. It separates 1-wire bus from the router so I no matter what I do on 1-wire side I won't damage the router. You can just take the "half" of this schematics and omit ADUM1402. I can sen You eagle projects. And probably the easiest option is to buy FT232RL on a breakout broad UM232R http://www.elektroda.pl/rtvforum/viewtopic.php?t=1930288&highlight= And you get USB 1-wire converter. -- p4trykx ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
|
|
Re: ds9097 on embedded boards
by Molnar Domokos
::
Rate this Message:
Hi,
They are the _only_ guys in Hungary I know of who sell onewire stuff: http://www.hteurep.hu/alkatreszek.html No webshop, no pricing or stock availability info. You need to call :) I used them and a Polish webshop I can't recall right now. Availability of parts is a real pain in Hungary. They both charge 4-5 times the US going price for every onewire device. I bought an USB dongle at the time, which works well - I had no issues with it for over 3 years but I guess that has already been discontinued. You need to call them to find out what they have. Regards, Doma On 04/04/2012 11:23 AM, Kassai Istvan wrote: > 2012-04-03 20:45 keltezéssel, Markus Gaugusch írta: >> I assume that the serial port of the embedded system only provides 5V >> on its signal lines. If the DS9097 expects 12V and uses a voltage >> regulator to provide 5V to the bus, it will most probably fail. >> > I use this homemade adapter: http://owfs.sourceforge.net/adapters/db-9.png > > >> Can you measure voltage between 1wire and gnd pins on your adaptor? > I've measured (all values relative to signal ground [Pin #5]). > (All of them are 9pin DB9 type connectors!) > > On the Alix board : > Pin voltage > 3 -5,6 > 4 5,9 > 7 5,9 > > On the PC serial port : > Pin voltage > 3 -10,9 > 4 -10,8 > 7 -10,9 > > On the Routerboard : > Pin voltage > 3 -5,6 > 4 0 > 7 0 > > > > >> It should not be much less than 5 volts. > I can measure on the 1w bus (the output of the 9097 adapter) 5,9V > > > Can you suggest anything to make it work? (Or does anybody know a dealer > in hungary I can order a non-passive serial bus-master?) > > Thanks > kako > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@... > https://lists.sourceforge.net/lists/listinfo/owfs-developers > > ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Owfs-developers mailing list Owfs-developers@... https://lists.sourceforge.net/lists/listinfo/owfs-developers |
schem.png (27K) | Free embeddable forum powered by Nabble | Forum Help |
