Interfacing
1-wire and Dallas DS18b20
34
29941
View: 29941|Reply: 34
|
[Interfacing]
1-wire and Dallas DS18b20
[Copy link]
|
|
Hi,
I would like to interact with a therm device as Dallas DS18b20 using 1-wire interface. I am using raspbian for banana pi and there is only the 1-wire module (wire), not the w1-therm neither w1-gpio.
Will be these two module (w1-therm and w1-gpio) included in futur release of raspbian image for banana pi ? or where can I found the kernel header to be able to compile only these two module ?
Cordialy. |
|
|
|
|
|
|
|
The new image has include it, we will release it on later this month |
|
|
|
|
|
|
|
It seems that wire, w1-therm and w1-gpio are not available on Raspbian 3. Am I right? must I wait for next release ?
Thanks |
|
|
|
|
|
|
|
I didn't test any w1 device. But I am sure that the w1 driver has ported into the kernel |
|
|
|
|
|
|
|
Post Last Edited by zippetto at 2014-7-27 12:30
I've done several tests with a DS18B20 on 1-wire bus.
Last release of Raspbian modified for banana, kernel 3.4.90: unstable results;
Ubuntu core 14.04 with bananapi-bsp, kernel 3.4.90: unstable results;
For unstable results mean that sometimes w1_slave reads the value correctly, sometimes CRC error, sometimes the device disappears automagically.
I've used CON3-P07 and other pins for signal wire, changes to the fex but nothing.
I tried with other DS18B20 sensors, same results, while on the Raspberry board everything works perfectly.
Kernel module sunxi-w1 problem on A20? |
|
|
|
|
|
|
|
Dear,
Am interested to see this work - with the new raspbian 3.1. On a raspberry PI, it went OK, but still, cannot get it working on banana PI with raspbian 3.0: in the /sys/bus... nothing appears and in dmesg I get the complaint that the GPIO's are malconfigured (after adding the extra section for w1).
Any help is welcome.
kind regards,
Pieter |
|
|
|
|
|
|
|
Reply 7# pieter
With the official BananaPi kernel 3.4.90 1-wire only works as long as the CPU frequency is not dropping below approx. 500MHz. It seems, udelay is not properly scaled with CPU frequency. As a consequence the bus master misses the window when it should detect the slaves.
Test results for the 480us reset pulse (logic analyser):
1008MHz: 459us, 720MHz: 641us, 528us: 874us, 336MHz: 1372us (does not recognize slave)
This is clearly a bug in the kernel.
I have already a suspicion what the root cause for the strange udelay behaviour is, but I first need to check whether I am right.
Until the timing bug is resolved, keep the CPU frequency in the "safe" region. |
|
|
|
|
|
|
|
Reply 8# ucmaniac
Thanks! Thanks! Thanks!
I already got crazy.... tried to control wireless outlets via 433MHz but it always failed.
Now it is clear... if the udelay doesn´t work properly it can´t work.
Hopefully this will be fixed in the next version  |
|
|
|
|
|
|