szigeti
Posts: 10
Joined: Thu Sep 06, 2012 1:29 pm

Re: kernel patch for Dallas 1-wire interface

Wed Feb 13, 2013 7:24 am

rena555 wrote:
eikcam wrote:
netomx wrote:If mine says:
It was tried in place 2K ohm?
I was successful in 1K8 (1.8K ohms).

Code: Select all

[email protected]:/sys/bus/w1/devices/w1_bus_master1/28-0000030a0170# cat w1_slave
50 05 4b 46 7f ff 0c 10 1c : crc=1c YES
50 05 4b 46 7f ff 0c 10 1c t=85000
I'm using the wrong resistor?
85c is the initial value of the sensor on power up. It seems that your sensor isnt doing any calculations. What size resistor are you using? 4.7k?
1.8K is to small. Change it to 4,7K and it will be work.
I use 4,2K and it is also good.

netomx
Posts: 80
Joined: Tue Oct 11, 2011 4:06 am

Re: kernel patch for Dallas 1-wire interface

Wed Feb 13, 2013 3:02 pm

That post is old :p

User avatar
pluggy
Posts: 3635
Joined: Thu May 31, 2012 3:52 pm
Location: Barnoldswick, Lancashire,UK
Contact: Website

Re: kernel patch for Dallas 1-wire interface

Wed Feb 13, 2013 4:00 pm

The resistor is just a pullup, it will generally work over a wide range of values if the cable runs are short. If one wire sensors misbehave with longer runs of cabling, reducing the value of the resistor so the pull up is stronger will sometimes enable them to work. 4.7k is a good value to start at, but there isn't a wrong value. If it works, its good.
Don't judge Linux by the Pi.......
I must not tread on too many sacred cows......

tihmann
Posts: 2
Joined: Wed Feb 13, 2013 5:07 pm

Re: kernel patch for Dallas 1-wire interface

Wed Feb 13, 2013 5:37 pm

Would somebody be willing to compile the 1-wire driver with the pullup option for kernel 3.6. I haven managed to...or are they already available for download somewhere ?
Thank you for your support.

Yours,

T. Ihmann

Parkview
Posts: 58
Joined: Sun Feb 17, 2013 1:51 pm

Re: kernel patch for Dallas 1-wire interface

Sun Feb 17, 2013 2:18 pm

Hi,

As a test, I am trying to read the temperature from 13 DS-18B20's. Eventually I would like to read from around 20 of them, that will be scattered around the house. At the moment, I have some python code reading the sensors and writing the data to a remote (to the RPi) MySQL DB and writing the last reading out to a Nokia 5110 LCD screen.

My problem is, the kernel modules only seem to recognise the first 10 sensors! If I unplug 3, so that there are only 10 present then they all work. I can then swap out any 3 for the other unplugged 3 DS-18B20's and they work too, so all the sensors can be read, just not all at one time.

Is there a design limit to the number of DS-18B20 sensors the kernel modules can read at one time?

Thanks.

Cheers,
Parkview

mkj
Posts: 7
Joined: Sat Dec 08, 2012 4:22 am
Location: Perth, Australia
Contact: Website

Re: kernel patch for Dallas 1-wire interface

Sun Feb 17, 2013 2:47 pm

tihmann wrote:Would somebody be willing to compile the 1-wire driver with the pullup option for kernel 3.6. I haven managed to...or are they already available for download somewhere ?
Thank you for your support.

Yours,

T. Ihmann
I've put what I'm using at http://matt.ucc.asn.au/rpi/361-parasite-w1.tgz

If it works please let me know or comment on the pull request https://github.com/raspberrypi/linux/pull/186

fcara
Posts: 4
Joined: Tue Feb 19, 2013 12:27 pm

Re: kernel patch for Dallas 1-wire interface

Tue Feb 19, 2013 12:56 pm

HI to everyone. As a new owner of RPI, I'm trying to build some circuits to control my home-made brewery machine.
I use the I2C bus to control 3 devices: DS2482-800 for 1-wire temperature sensors, MCP23017 for controlling the hydraulic valves and ADS1115 ADC converter for kettle levels.

I have got an issue with the first one. The circuit foresee 3 temperature probes (DS18b20) individually connected to the first 3 bus lines of the DS2482-800. DS18b20 sensors are connected to +5v and ground and their data lines have been pulled-up with 3 resistors (4.7kohm) .
SCL and SDA lines of the DS2482-800 have been pulled up as well with 2 resistors (2.4 kohm).

I have raspbian wheezy with I2ctools and OWFS installed. everything works fine till the "i2cdetect -y 1" command wich shows the 2482-800 at the 0x18 address (as well as the other i2c devices connected).
The issue is when i try to start the "OWFS --i2c=ALL:ALL --allow_other_users /mnt/1-wire/". I got an error "owfs.c(56) No valid 1-wire buses found". i also checked the /mnt/1-wire/ directory but no subdirectories were there.

any help is really appreciated, thx

Parkview
Posts: 58
Joined: Sun Feb 17, 2013 1:51 pm

Re: kernel patch for Dallas 1-wire interface

Fri Feb 22, 2013 1:59 pm

fcara wrote:HI to everyone. As a new owner of RPI, I'm trying to build some circuits to control my home-made brewery machine.
I use the I2C bus to control 3 devices: DS2482-800 for 1-wire temperature sensors, MCP23017 for controlling the hydraulic valves and ADS1115 ADC converter for kettle levels.

I have got an issue with the first one. The circuit foresee 3 temperature probes (DS18b20) individually connected to the first 3 bus lines of the DS2482-800. DS18b20 sensors are connected to +5v and ground and their data lines have been pulled-up with 3 resistors (4.7kohm) .
SCL and SDA lines of the DS2482-800 have been pulled up as well with 2 resistors (2.4 kohm).

I have raspbian wheezy with I2ctools and OWFS installed. everything works fine till the "i2cdetect -y 1" command wich shows the 2482-800 at the 0x18 address (as well as the other i2c devices connected).
The issue is when i try to start the "OWFS --i2c=ALL:ALL --allow_other_users /mnt/1-wire/". I got an error "owfs.c(56) No valid 1-wire buses found". i also checked the /mnt/1-wire/ directory but no subdirectories were there.

any help is really appreciated, thx
I can't really comment on the OWFS, as I have only used the Dec. 2012 wheezy image. Why use the 2482-800, when you can have at least ten DS-18B20's all connected on the same line (GPIO4)?

Cheers,
Parkview

dirk50
Posts: 3
Joined: Fri Feb 22, 2013 3:11 pm

Re: kernel patch for Dallas 1-wire interface

Fri Feb 22, 2013 3:26 pm

Hi Kristfin,
I had exactly the same problem with a perfectly good 18B20 (tested and working fine on a PIC microcontroller with a 2.2k resistor.) with wheezy 3.6.11+
I solved it finally with a 1k resistor. It worked fine then. I suppose that the Pi port needs a very strong pull-up.
You could test the optimum resistor value by fitting a 10k potmeter between Vpp and the sensor and then carefully varying the value.
I can't explain the strange value of 127937 with an 2k2 resistor.
Success, Dirk

fcara
Posts: 4
Joined: Tue Feb 19, 2013 12:27 pm

Re: kernel patch for Dallas 1-wire interface

Fri Feb 22, 2013 5:09 pm

Thx guys

@Dirk: are you meaning 1k pullup resistor for the SDA/SDL lines? or are you referring to the 18b20 pullup resistors? if the former, i think the raspi should not be able to detect the 2482-800. but that's not true because it can be detected (i2cdetect show it at the right address)

@PArkview: it is simply because I would like to use the same bus (I2C) for all sensors/actuators. it also led to a better SW architecture (only I2C drivers will be used)

anyway, if i will not find a fixing for that, i'll not have other option but connecting the 3 temp sensors to GPIO4

thx again

dirk50
Posts: 3
Joined: Fri Feb 22, 2013 3:11 pm

Re: kernel patch for Dallas 1-wire interface

Sat Feb 23, 2013 12:01 pm

kristfin wrote:hi,
was just testing this out. think i have followed all the guidelines, however i never get anything but 85000 reading. if i skip the resistor i get t=0, with 2k2 i get 127937 and with 4k7 and 10k i get 85000

Code: Select all

// no resistor
[email protected] /sys/bus/w1/devices $ cat 28-000002a88233/w1_slave
00 00 00 00 00 00 00 00 00 : crc=00 YES
00 00 00 00 00 00 00 00 00 t=0
// 2k2
[email protected] /sys/bus/w1/devices $ cat 28-000002a88233/w1_slave
ff 07 4b 46 7f ff 01 10 2f : crc=2f YES
ff 07 4b 46 7f ff 01 10 2f t=127937
// 4k7 or 10k
[email protected] /sys/bus/w1/devices $ cat 28-000002a88233/w1_slave
50 05 4b 46 7f ff 0c 10 1c : crc=1c YES
50 05 4b 46 7f ff 0c 10 1c t=85000
// version
[email protected] /sys/bus/w1/devices $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
i've tried more than one ds18b20.
any ideas what could be wrong?
sorry, I was replying to a question from Kristfin @nov 4th, thought it would show behind his post, but it ended up here.....
@fcara: the 1k is the sensor resistor for the 18B20 (connected between the sensor output and 3.3V, haven't tried parasite mode yet ).
The I2C SDA/SCL lines have fixed pull-up resistors on the board, no extra resistors needed (I have I2C working without external resistors).
In general: All GPIO lines can be pulled up by software. Don't know if that is actually used for w1 at GPIO-4
In general: As the performance of all bus systems like w1, I2C, SPI are influenced by the load (number of devices on the bus) and therefore - in the case of the raspberry - also the pull-up resistor, it would be a good idea to document if the lines use the internal GPIO pull-up. Now the modules that control the bus-lines are a black boxes, and that leads to confusion and lots of discussion....
I have used the same DS18B20 that's on the raspberry now, without any problems on a 16F877 pic controller with a 2k2 and 4k7 sensor resistor. On the raspberry the same 18B20 didn't work with both!
Maybe somebody can tell me what the modules exactly do......

D.

repton
Posts: 91
Joined: Sat Mar 17, 2012 6:06 pm
Location: North Yorkshire, UK.
Contact: Website

Re: kernel patch for Dallas 1-wire interface

Sat Feb 23, 2013 8:47 pm

fcara wrote:DS18b20 sensors are connected to +5v and ground and their data lines have been pulled-up with 3 resistors (4.7kohm) .
If you're using a DS2482 as your bus master then you don't need any pull up resistors on the data lines, it's only if you're using the kernel/GPIO driver that you need those.

Paul
UK Supplier of 1-Wire components, kits and modules:
http://www.sheepwalkelectronics.co.uk/

szigeti
Posts: 10
Joined: Thu Sep 06, 2012 1:29 pm

Re: kernel patch for Dallas 1-wire interface

Tue Feb 26, 2013 11:50 am

Parkview wrote:Hi,

As a test, I am trying to read the temperature from 13 DS-18B20's. Eventually I would like to read from around 20 of them, that will be scattered around the house. At the moment, I have some python code reading the sensors and writing the data to a remote (to the RPi) MySQL DB and writing the last reading out to a Nokia 5110 LCD screen.

My problem is, the kernel modules only seem to recognise the first 10 sensors! If I unplug 3, so that there are only 10 present then they all work. I can then swap out any 3 for the other unplugged 3 DS-18B20's and they work too, so all the sensors can be read, just not all at one time.

Is there a design limit to the number of DS-18B20 sensors the kernel modules can read at one time?

Thanks.

Cheers,
Parkview
It is hardcoded in the kernel.
https://github.com/raspberrypi/linux/bl ... rs/w1/w1.c line: 49

Code: Select all

[email protected] ~ $ cat /sys/bus/w1/devices/w1_bus_master1/w1_master_max_slave_count 
10
[email protected] ~ $

rudiratlos
Posts: 132
Joined: Tue May 01, 2012 8:47 am

Re: kernel patch for Dallas 1-wire interface

Fri Mar 01, 2013 7:37 pm

Hi,

is OWFS available without an i2c busmaster (DS2482) ?
I mean I wnat to see OWFS that is working with the bitbang driver, which works on GPIO4

rudiratlos
Posts: 132
Joined: Tue May 01, 2012 8:47 am

Re: kernel patch for Dallas 1-wire interface

Mon Mar 04, 2013 6:15 pm

Hi,

just want to inform the followers on this 1Wire thread, that the NEW piggy back board with pcb revision 2 has a 5Volt levelshifter and an ESD protection diode on board. I've tested it and I could access five 1Wire sensors on a ~ 270 meter long cable. All sensors (DS18B20) where connected in parasitic mode.

More infos are here: http://shop.basis.biz/shop/Raspberry-PI ... ack-board/
and here: http://shop.basis.biz/shop/images/manuf ... n_Rev2.pdf

lordgreg
Posts: 3
Joined: Mon Mar 11, 2013 6:06 am

Re: kernel patch for Dallas 1-wire interface

Mon Mar 11, 2013 6:43 am

Hi all,

we're currently testing Dallas sensors DS18B20 (7 of them at the moment), that are getting temperature measurements from the system using plain shell commands. Everything works. Okay, there are occasional wrong temperature readings (-0.62, 0.75 etc) which we ignore as wrong values (depending on few previous readings).

What the real problem is that, we get into the deadlock problems. As this is the w1 patch kernel, I'm trying to figure out if this kernel update would solve our issues (or maybe latest raspbian images don't have this problem anymor?).

Anyhow, next url describes the same problem we are having: ofws+w1=freeze.

And here is the messages log:

Code: Select all

Feb 19 23:51:27 raspberrypi kernel: [264489.784186] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037aea8>] (schedule_timeout+0x198/0x230)
Feb 19 23:51:27 raspberrypi kernel: [264489.784219] [<c037aea8>] (schedule_timeout+0x198/0x230) from [<c037a670>] (wait_for_common+0xcc/0x198)
Feb 19 23:51:27 raspberrypi kernel: [264489.784265] [<c037a670>] (wait_for_common+0xcc/0x198) from [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4)
Feb 19 23:51:27 raspberrypi kernel: [264489.784302] [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4) from [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88)
Feb 19 23:51:27 raspberrypi kernel: [264489.784336] [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88) from [<c011557c>] (sysfs_remove_file+0x38/0x3c)
Feb 19 23:51:27 raspberrypi kernel: [264489.784415] [<c011557c>] (sysfs_remove_file+0x38/0x3c) from [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire])
Feb 19 23:51:27 raspberrypi kernel: [264489.784487] [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire]) from [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire])
Feb 19 23:51:27 raspberrypi kernel: [264489.784550] [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire]) from [<bf06a398>] (w1_process+0xdc/0xf0 [wire])
Feb 19 23:51:27 raspberrypi kernel: [264489.784603] [<bf06a398>] (w1_process+0xdc/0xf0 [wire]) from [<c0042e3c>] (kthread+0x84/0x8c)
Feb 19 23:51:27 raspberrypi kernel: [264489.784647] [<c0042e3c>] (kthread+0x84/0x8c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)
Feb 19 23:51:27 raspberrypi kernel: [264489.784735] php             D c037a204     0 14518  14517 0x00000000
Feb 19 23:51:27 raspberrypi kernel: [264489.784775] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154)
Feb 19 23:51:27 raspberrypi kernel: [264489.784814] [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154) from [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm])
Feb 19 23:51:27 raspberrypi kernel: [264489.784869] [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm]) from [<c02232f8>] (dev_attr_show+0x1c/0x48)
Feb 19 23:51:27 raspberrypi kernel: [264489.784910] [<c02232f8>] (dev_attr_show+0x1c/0x48) from [<c0114ff8>] (sysfs_read_file+0x90/0x134)
Feb 19 23:51:27 raspberrypi kernel: [264489.784947] [<c0114ff8>] (sysfs_read_file+0x90/0x134) from [<c00b88c4>] (vfs_read+0x98/0x16c)
Feb 19 23:51:27 raspberrypi kernel: [264489.784976] [<c00b88c4>] (vfs_read+0x98/0x16c) from [<c00b89d0>] (sys_read+0x38/0x70)
Feb 19 23:51:27 raspberrypi kernel: [264489.785009] [<c00b89d0>] (sys_read+0x38/0x70) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Feb 19 23:53:27 raspberrypi kernel: [264609.788083] w1_bus_master1  D c037a204     0  1693      2 0x00000000
Feb 19 23:53:27 raspberrypi kernel: [264609.788147] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037aea8>] (schedule_timeout+0x198/0x230)
Feb 19 23:53:27 raspberrypi kernel: [264609.788181] [<c037aea8>] (schedule_timeout+0x198/0x230) from [<c037a670>] (wait_for_common+0xcc/0x198)
Feb 19 23:53:27 raspberrypi kernel: [264609.788226] [<c037a670>] (wait_for_common+0xcc/0x198) from [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4)
Feb 19 23:53:27 raspberrypi kernel: [264609.788263] [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4) from [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88)
Feb 19 23:53:27 raspberrypi kernel: [264609.788296] [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88) from [<c011557c>] (sysfs_remove_file+0x38/0x3c)
Feb 19 23:53:27 raspberrypi kernel: [264609.788375] [<c011557c>] (sysfs_remove_file+0x38/0x3c) from [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire])
Feb 19 23:53:27 raspberrypi kernel: [264609.788441] [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire]) from [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire])
Feb 19 23:53:27 raspberrypi kernel: [264609.788503] [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire]) from [<bf06a398>] (w1_process+0xdc/0xf0 [wire])
Feb 19 23:53:27 raspberrypi kernel: [264609.788558] [<bf06a398>] (w1_process+0xdc/0xf0 [wire]) from [<c0042e3c>] (kthread+0x84/0x8c)
Feb 19 23:53:27 raspberrypi kernel: [264609.788600] [<c0042e3c>] (kthread+0x84/0x8c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)
Feb 19 23:53:27 raspberrypi kernel: [264609.788689] php             D c037a204     0 14518  14517 0x00000000
Feb 19 23:53:27 raspberrypi kernel: [264609.788728] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154)
Feb 19 23:53:27 raspberrypi kernel: [264609.788767] [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154) from [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm])
Feb 19 23:53:27 raspberrypi kernel: [264609.788819] [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm]) from [<c02232f8>] (dev_attr_show+0x1c/0x48)
Feb 19 23:53:27 raspberrypi kernel: [264609.788860] [<c02232f8>] (dev_attr_show+0x1c/0x48) from [<c0114ff8>] (sysfs_read_file+0x90/0x134)
Feb 19 23:53:27 raspberrypi kernel: [264609.788897] [<c0114ff8>] (sysfs_read_file+0x90/0x134) from [<c00b88c4>] (vfs_read+0x98/0x16c)
Feb 19 23:53:27 raspberrypi kernel: [264609.788928] [<c00b88c4>] (vfs_read+0x98/0x16c) from [<c00b89d0>] (sys_read+0x38/0x70)
Feb 19 23:53:27 raspberrypi kernel: [264609.788960] [<c00b89d0>] (sys_read+0x38/0x70) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Feb 19 23:55:27 raspberrypi kernel: [264729.792037] w1_bus_master1  D c037a204     0  1693      2 0x00000000
Feb 19 23:55:27 raspberrypi kernel: [264729.792099] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037aea8>] (schedule_timeout+0x198/0x230)
Feb 19 23:55:27 raspberrypi kernel: [264729.792131] [<c037aea8>] (schedule_timeout+0x198/0x230) from [<c037a670>] (wait_for_common+0xcc/0x198)
Feb 19 23:55:27 raspberrypi kernel: [264729.792178] [<c037a670>] (wait_for_common+0xcc/0x198) from [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4)
Feb 19 23:55:27 raspberrypi kernel: [264729.792214] [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4) from [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88)
Feb 19 23:55:27 raspberrypi kernel: [264729.792248] [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88) from [<c011557c>] (sysfs_remove_file+0x38/0x3c)
Feb 19 23:55:27 raspberrypi kernel: [264729.792326] [<c011557c>] (sysfs_remove_file+0x38/0x3c) from [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire])
Feb 19 23:55:27 raspberrypi kernel: [264729.792393] [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire]) from [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire])
Feb 19 23:55:27 raspberrypi kernel: [264729.792457] [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire]) from [<bf06a398>] (w1_process+0xdc/0xf0 [wire])
Feb 19 23:55:27 raspberrypi kernel: [264729.792510] [<bf06a398>] (w1_process+0xdc/0xf0 [wire]) from [<c0042e3c>] (kthread+0x84/0x8c)
Feb 19 23:55:27 raspberrypi kernel: [264729.792553] [<c0042e3c>] (kthread+0x84/0x8c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)
Feb 19 23:55:27 raspberrypi kernel: [264729.792641] php             D c037a204     0 14518  14517 0x00000000
Feb 19 23:55:27 raspberrypi kernel: [264729.792682] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154)
Feb 19 23:55:27 raspberrypi kernel: [264729.792721] [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154) from [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm])
Feb 19 23:55:27 raspberrypi kernel: [264729.792771] [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm]) from [<c02232f8>] (dev_attr_show+0x1c/0x48)
Feb 19 23:55:27 raspberrypi kernel: [264729.792811] [<c02232f8>] (dev_attr_show+0x1c/0x48) from [<c0114ff8>] (sysfs_read_file+0x90/0x134)
Feb 19 23:55:27 raspberrypi kernel: [264729.792847] [<c0114ff8>] (sysfs_read_file+0x90/0x134) from [<c00b88c4>] (vfs_read+0x98/0x16c)
Feb 19 23:55:27 raspberrypi kernel: [264729.792875] [<c00b88c4>] (vfs_read+0x98/0x16c) from [<c00b89d0>] (sys_read+0x38/0x70)
Feb 19 23:55:27 raspberrypi kernel: [264729.792906] [<c00b89d0>] (sys_read+0x38/0x70) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Feb 19 23:57:27 raspberrypi kernel: [264849.795996] w1_bus_master1  D c037a204     0  1693      2 0x00000000
Feb 19 23:57:27 raspberrypi kernel: [264849.796057] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037aea8>] (schedule_timeout+0x198/0x230)
Feb 19 23:57:27 raspberrypi kernel: [264849.796091] [<c037aea8>] (schedule_timeout+0x198/0x230) from [<c037a670>] (wait_for_common+0xcc/0x198)
Feb 19 23:57:27 raspberrypi kernel: [264849.796136] [<c037a670>] (wait_for_common+0xcc/0x198) from [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4)
Feb 19 23:57:27 raspberrypi kernel: [264849.796172] [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4) from [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88)
Feb 19 23:57:27 raspberrypi kernel: [264849.796206] [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88) from [<c011557c>] (sysfs_remove_file+0x38/0x3c)
Feb 19 23:57:27 raspberrypi kernel: [264849.796284] [<c011557c>] (sysfs_remove_file+0x38/0x3c) from [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire])
Feb 19 23:57:27 raspberrypi kernel: [264849.796350] [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire]) from [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire])
Feb 19 23:57:27 raspberrypi kernel: [264849.796413] [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire]) from [<bf06a398>] (w1_process+0xdc/0xf0 [wire])
Feb 19 23:57:27 raspberrypi kernel: [264849.796468] [<bf06a398>] (w1_process+0xdc/0xf0 [wire]) from [<c0042e3c>] (kthread+0x84/0x8c)
Feb 19 23:57:27 raspberrypi kernel: [264849.796510] [<c0042e3c>] (kthread+0x84/0x8c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)
Feb 19 23:57:27 raspberrypi kernel: [264849.796598] php             D c037a204     0 14518  14517 0x00000000
Feb 19 23:57:27 raspberrypi kernel: [264849.796638] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154)
Feb 19 23:57:27 raspberrypi kernel: [264849.796675] [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154) from [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm])
Feb 19 23:57:27 raspberrypi kernel: [264849.796727] [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm]) from [<c02232f8>] (dev_attr_show+0x1c/0x48)
Feb 19 23:57:27 raspberrypi kernel: [264849.796768] [<c02232f8>] (dev_attr_show+0x1c/0x48) from [<c0114ff8>] (sysfs_read_file+0x90/0x134)
Feb 19 23:57:27 raspberrypi kernel: [264849.796803] [<c0114ff8>] (sysfs_read_file+0x90/0x134) from [<c00b88c4>] (vfs_read+0x98/0x16c)
Feb 19 23:57:27 raspberrypi kernel: [264849.796834] [<c00b88c4>] (vfs_read+0x98/0x16c) from [<c00b89d0>] (sys_read+0x38/0x70)
Feb 19 23:57:27 raspberrypi kernel: [264849.796866] [<c00b89d0>] (sys_read+0x38/0x70) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Feb 19 23:59:27 raspberrypi kernel: [264969.799946] w1_bus_master1  D c037a204     0  1693      2 0x00000000
Feb 19 23:59:27 raspberrypi kernel: [264969.800010] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037aea8>] (schedule_timeout+0x198/0x230)
Feb 19 23:59:27 raspberrypi kernel: [264969.800042] [<c037aea8>] (schedule_timeout+0x198/0x230) from [<c037a670>] (wait_for_common+0xcc/0x198)
Feb 19 23:59:27 raspberrypi kernel: [264969.800088] [<c037a670>] (wait_for_common+0xcc/0x198) from [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4)
Feb 19 23:59:27 raspberrypi kernel: [264969.800124] [<c0116268>] (sysfs_addrm_finish+0x7c/0xc4) from [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88)
Feb 19 23:59:27 raspberrypi kernel: [264969.800158] [<c0114a0c>] (sysfs_hash_and_remove+0x4c/0x88) from [<c011557c>] (sysfs_remove_file+0x38/0x3c)
Feb 19 23:59:27 raspberrypi kernel: [264969.800236] [<c011557c>] (sysfs_remove_file+0x38/0x3c) from [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire])
Feb 19 23:59:27 raspberrypi kernel: [264969.800301] [<bf069ca4>] (w1_slave_detach+0x58/0xf0 [wire]) from [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire])
Feb 19 23:59:27 raspberrypi kernel: [264969.800364] [<bf06a2a4>] (w1_search_process_cb+0xb4/0xcc [wire]) from [<bf06a398>] (w1_process+0xdc/0xf0 [wire])
Feb 19 23:59:27 raspberrypi kernel: [264969.800417] [<bf06a398>] (w1_process+0xdc/0xf0 [wire]) from [<c0042e3c>] (kthread+0x84/0x8c)
Feb 19 23:59:27 raspberrypi kernel: [264969.800460] [<c0042e3c>] (kthread+0x84/0x8c) from [<c000e930>] (kernel_thread_exit+0x0/0x8)
Feb 19 23:59:27 raspberrypi kernel: [264969.800547] php             D c037a204     0 14518  14517 0x00000000
Feb 19 23:59:27 raspberrypi kernel: [264969.800587] [<c037a204>] (__schedule+0x2bc/0x568) from [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154)
Feb 19 23:59:27 raspberrypi kernel: [264969.800626] [<c037b720>] (__mutex_lock_slowpath+0xb8/0x154) from [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm])
Feb 19 23:59:27 raspberrypi kernel: [264969.800677] [<bf0780c4>] (w1_therm_read+0x34/0x30c [w1_therm]) from [<c02232f8>] (dev_attr_show+0x1c/0x48)
Feb 19 23:59:27 raspberrypi kernel: [264969.800717] [<c02232f8>] (dev_attr_show+0x1c/0x48) from [<c0114ff8>] (sysfs_read_file+0x90/0x134)
Feb 19 23:59:27 raspberrypi kernel: [264969.800754] [<c0114ff8>] (sysfs_read_file+0x90/0x134) from [<c00b88c4>] (vfs_read+0x98/0x16c)
Feb 19 23:59:27 raspberrypi kernel: [264969.800783] [<c00b88c4>] (vfs_read+0x98/0x16c) from [<c00b89d0>] (sys_read+0x38/0x70)
Feb 19 23:59:27 raspberrypi kernel: [264969.800814] [<c00b89d0>] (sys_read+0x38/0x70) from [<c000d980>] (ret_fast_syscall+0x0/0x30)
Reloading w1 mod locks everything up so to solve this, we had to reboot the system. Now, after ~100.000 temp readings, even this doesn't work anymore. We have to reboot the system at least twice per day now.

Additional info:

* 7 x DS18B20 cables are different length (min: 5m, max: 12m).
* temperature readings for all sensors are made every minute.
* raspbian cpu is stable, top doesn't report any misbehaviours.

Could someone help us out. We're really struggling to find the solution on how to avoid this lock-ups.

Thank you!

Parkview
Posts: 58
Joined: Sun Feb 17, 2013 1:51 pm

Re: kernel patch for Dallas 1-wire interface

Mon Mar 11, 2013 12:53 pm

lordgreg wrote:Hi all,

we're currently testing Dallas sensors DS18B20 (7 of them at the moment), that are getting temperature measurements from the system using plain shell commands. Everything works. Okay, there are occasional wrong temperature readings (-0.62, 0.75 etc) which we ignore as wrong values (depending on few previous readings).
<snip>
Could someone help us out. We're really struggling to find the solution on how to avoid this lock-ups.
Thank you!
--------------
Hi lordgreg,

I have tested ten x DS18B20 sensors: http://www.bdug.org.au/projects/raspber ... nditioning I read them using some Python code and they all worked great, with no lockups at all. From my last check, I think I had some 50K+ readings stored in a MySQL DB. As per the blog listed above, the sensors where just stacked next to each other, so I could check their differences. I now have five of them spread out over perhaps a total of 30m on two cabling strings. I hope to add a separate string of seven more sensors in three weeks or so. I realise my cabling config is not optimal, so I have ordered a 1W bus master chip just in case the extra sensor run overloads the RPi. I am using:

$ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux

Once again, from my testing of ten sensors, the where well within spec. Are you using a 5V VDD line, or parasitic power? What sized pull up resistor are you using? How far apart are the sensors? What cabling topology are you using? Have you tried reading them via some python code?

Cheers,

Parkview

Parkview
Posts: 58
Joined: Sun Feb 17, 2013 1:51 pm

Re: kernel patch for Dallas 1-wire interface

Mon Mar 11, 2013 1:25 pm

szigeti wrote: <snip>
It is hardcoded in the kernel.
https://github.com/raspberrypi/linux/bl ... rs/w1/w1.c line: 49

Code: Select all

[email protected] ~ $ cat /sys/bus/w1/devices/w1_bus_master1/w1_master_max_slave_count 
10
[email protected] ~ $
Thanks for that szigeti. I will have a play and see if I can expand that to 20. Does anyone know of why it was coded to 10 sensors, as opposed to say, 20 or 30?

Thanks. Cheers, Parkview.

repton
Posts: 91
Joined: Sat Mar 17, 2012 6:06 pm
Location: North Yorkshire, UK.
Contact: Website

Re: kernel patch for Dallas 1-wire interface

Mon Mar 11, 2013 5:49 pm

lordgreg wrote:Additional info:

* 7 x DS18B20 cables are different length (min: 5m, max: 12m).
I don't know if it's just the way you worded it but from that it sounds like you have each sensor wired individually back to your Pi in a star topology. It might well not be the cause of your problems but you should bear in mind that the 1-Wire system is supposed to be a bus topology and not a star. Instead of wiring each sensor individually back to the Pi you should have the cable running from the Pi to the first sensor, then from there to the second sensor, and then on to the third, and so on.

As I said I don't know if this is the cause of your problems or not but it will certainly help your system be more reliable if you wire it as a bus instead of a star.

Paul
UK Supplier of 1-Wire components, kits and modules:
http://www.sheepwalkelectronics.co.uk/

lordgreg
Posts: 3
Joined: Mon Mar 11, 2013 6:06 am

Re: kernel patch for Dallas 1-wire interface

Tue Mar 12, 2013 10:24 am

@Parkview: first of all, thank you for your reply. I also read your blog about wiring and measuring temperature and found it very useful. so thank you again for that.

First of all, I've used wrong cable for wiring (untwisted 6x0.22mm), now we're going to UTP CAT5 cable (like you've used). Secondly, my connection scheme is kind of messed at the moment- here's the link to it: https://docs.google.com/drawings/d/1FxF ... rWH2Q/edit.

I'm planning to rewire sensors completely (bus scheme- using cat5, y ethernet connectors).

I have a few other question (also about wiring you've used):
- you said you've used A PAIR for 5V/ground/data. If I understand corectly, I should connect white-orange and orange together for 5V. Currently, I'm using 3.3V (from Raspberry Pi).
- can a sensor (on stubbed topology) be on a cable (Currently, I have a sensor on 1m cable) or should be only sensor connected directly on bus cable? here's the scheme that would ease what I'm trying to achieve: https://docs.google.com/drawings/d/1DL1 ... 00uYU/edit.
- also, I'm planninng to connect sensors with RJ45 Y splitters (http://www.amazon.co.uk/Adapters-Direct ... B0009LZCSU)

also, to answer your questions:
- What sized pull up resistor are you using? 4.7kOhm
- How far apart are the sensors? few within 1m, others from 2 to 6m.
- What cabling topology are you using? meseed at the moment. star like. (check scheme again).
- Have you tried reading them via some python code. -not the issue since I'm reading them directly through shell commands.
- OS- the same as you have.

@repton: I would like to thank you for your reply also. As mentioned above, I have totally messed topology, which, as said, I'm planning to drastically improve.

Thank you both for your help and answers in advance,

Regards.

repton
Posts: 91
Joined: Sat Mar 17, 2012 6:06 pm
Location: North Yorkshire, UK.
Contact: Website

Re: kernel patch for Dallas 1-wire interface

Tue Mar 12, 2013 12:20 pm

lordgreg wrote: - can a sensor (on stubbed topology) be on a cable (Currently, I have a sensor on 1m cable) or should be only sensor connected directly on bus cable?
You can have stubs but the shorter the better. Maxim's own guides suggest a maximum of 3m but if you have a big network keeping them much shorter than that will help reliability.

Paul
UK Supplier of 1-Wire components, kits and modules:
http://www.sheepwalkelectronics.co.uk/

Parkview
Posts: 58
Joined: Sun Feb 17, 2013 1:51 pm

Re: kernel patch for Dallas 1-wire interface

Tue Mar 12, 2013 12:22 pm

lordgreg wrote:@Parkview: first of all, thank you for your reply. I also read your blog about wiring and measuring temperature and found it very useful. so thank you again for that.

First of all, I've used wrong cable for wiring (untwisted 6x0.22mm), now we're going to UTP CAT5 cable (like you've used). Secondly, my connection scheme is kind of messed at the moment- here's the link to it: https://docs.google.com/drawings/d/1FxF ... rWH2Q/edit.

I'm planning to rewire sensors completely (bus scheme- using cat5, y ethernet connectors).

I have a few other question (also about wiring you've used):
- you said you've used A PAIR for 5V/ground/data. If I understand corectly, I should connect white-orange and orange together for 5V. Currently, I'm using 3.3V (from Raspberry Pi).
- can a sensor (on stubbed topology) be on a cable (Currently, I have a sensor on 1m cable) or should be only sensor connected directly on bus cable? here's the scheme that would ease what I'm trying to achieve: https://docs.google.com/drawings/d/1DL1 ... 00uYU/edit.
- also, I'm planninng to connect sensors with RJ45 Y splitters (http://www.amazon.co.uk/Adapters-Direct ... B0009LZCSU)

also, to answer your questions:
- What sized pull up resistor are you using? 4.7kOhm
- How far apart are the sensors? few within 1m, others from 2 to 6m.
- What cabling topology are you using? meseed at the moment. star like. (check scheme again).
- Have you tried reading them via some python code. -not the issue since I'm reading them directly through shell commands.
- OS- the same as you have.

@repton: I would like to thank you for your reply also. As mentioned above, I have totally messed topology, which, as said, I'm planning to drastically improve.

Thank you both for your help and answers in advance,

Regards.
Hi lordgreg,

do a google search for a Maxim 1-W document titled something like: "Guidelines for reliable Long Line 1-Wire Networks - AN148.pdf" as the title says, it gives you the low down on what they recommend.

You don't have to use two wires paired up, I just did it to lower (halve) the cable resistance, as over time, I might end up with some long cable runs. Yes, I used the Orange for Vdd, Blue pair for GND and Green pair for data.

The only reason I mentioned trying to read them via Python, was because of your kernel errors. I am presuming here that the Python modules might use a different technique of reading the sensors, but I might be wrong on that. You also have more control over what you can do with data once you have it. I am just sticking my data in a remote server MySQL DB.

The RPi also has a 5V power on the GPIO's. You could try powering the data line with that instead of the 3.3V line. My thinking is that it will help with over coming long distance cable resistance, not that your cable(s) are very long.

The RJ-45 'Y' splitters look like a good find. I would think they should work well.

All the best.

User avatar
g7ruh
Posts: 67
Joined: Mon Apr 23, 2012 9:49 am
Location: Blackfield UK

Re: kernel patch for Dallas 1-wire interface

Tue Mar 12, 2013 1:06 pm

I am using DS18B20 sensors with an I2C to 1-Wire bridge (the 2482-100). I am using the sensors in passive mode and ran into unreliable readings problem when I added another sensor. Having thought about the wiring and voltage / capacitance related issues and perused the data sheet for 2482 I concluded that it may need higher current driver so I added the FET (BSS84) to drive the 1-wire bus as per the spec sheet (1 FET and a 2K2 resistor to 3.3 volts). Since then I have added more sensors and there is no problem (see https://cosm.com/feeds/98993 ) with 6 sensors on 1-wire. The "kpi" is a model A using wifi.

I have had 25 sensors at the end of a long cat 5 E twisted pair (up two floors, through roofspace and down two floors) it worked fine on a single run. When I tried twice the length (using another cable to come back again) it did not, so I found the limit of passive and 3.3v powered sensors, at least here.

Parkview
Posts: 58
Joined: Sun Feb 17, 2013 1:51 pm

Re: kernel patch for Dallas 1-wire interface

Tue Mar 12, 2013 2:09 pm

g7ruh wrote:<snip>

I have had 25 sensors at the end of a long cat 5 E twisted pair (up two floors, through roofspace and down two floors) it worked fine on a single run. <snip>.
Hi g7ruh,

have you blogged how you went about modifying the kernel to get over the 10 sensor kernel limit, or any notes on what to do?

Thanks.

Cheers, Parkview

rudiratlos
Posts: 132
Joined: Tue May 01, 2012 8:47 am

Re: kernel patch for Dallas 1-wire interface

Tue Mar 12, 2013 4:33 pm

Hi,

I've tested a levelshifter circuit with a MOSFET (BS170), an ESD protection diode and a Pullup of 2.7kOHM (see page 17 of this: http://shop.basis.biz/shop/images/manuf ... n_Rev2.pdf ). I had 5x DS18B20 at the end of a ~260Meter long CAT5 cable. The readings (intervall @ 5 minutes) where stable over a longer time (1-2 hours).

Return to “Interfacing (DSI, CSI, I2C, etc.)”