search

Pi4J / pi4j-v1

DEPRECATED Java I/O library for Raspberry Pi (GPIO, I2C, SPI, UART)
http://www.pi4j.com
Apache License 2.0
1.31k stars 446 forks source link

Add 1-wire support using GPIO pin #32

Closed savageautomate closed 9 years ago

savageautomate commented 11 years ago

Feature request to add support in Pi4J for the GPIO bit-banging 1-wire Linux kernel driver:

pi@raspberrypi:~$ sudo modprobe wire pi@raspberrypi:~$ sudo modprobe w1-gpio pi@raspberrypi:~$ sudo modprobe w1-therm

See this article for details: http://webshed.org/wiki/RaspberryPI_DS1820

marcandreuf commented 9 years ago

I implemented an example in JAVA using the modprobe driver and reading from the file. Just like the article. At least I could read temperature values in a Raspberry pi :-)

https://github.com/marcandreuf/sunfounder-sensors-raspi-4j/blob/master/src/main/java/org/mandfer/sunfunpi4j/Ex16_Ds18b20.java

I hope it helps.

ademcaliskan commented 9 years ago

I would suggest an static function for listing all available wired devices as an Array or List.

Adem

DataWorm commented 9 years ago

Schups code looks fine, but it is a few months old. Until now there has been no reaction on his merge request... Is there a chance, that it will get merged soon or got this issue postponed for a specific reason?

natdan commented 9 years ago

I've only got active now (someone was of impression that he's following this project while he wasn't). I'll go through the code over weekend and do the necessary. Sorry for the delay...

savageautomate commented 9 years ago

BTW, it will get merged into the 'develop' branch which means that it will be available in the 1.1-SNAPSHOT builds.

DataWorm commented 9 years ago

Seems to take some more weekends? ;-) Could we help in some way? Is there something that needs to be improved (apart from some javadoc comments) before it could be merged?

natdan commented 9 years ago

All help appreciated. Do you know how to lay laminate? Or at least remove existing tiles from kitchen floor? I think I got confused by Robert's message thinking he has already done it. Will start looking into it tonight. Sorry about it.

DataWorm commented 9 years ago

I think I could learn it on-the-fly. But free support for such tasks is limited to Berlin! ;-)

natdan commented 9 years ago

OK. I've skimmed through Schups's code and I am not 100% sure what to do. Code itself is fine and I'll pull b76d065 and f16c54c - it will, at least buy us some time. Only thing is that it, probably, will be just WIP or initial (working) starting point for One Wire interface. My only problem is that it doesn't (at this moment) capture 'idea' of 1-wire interface and in this format I cannot see it being implemented with simple bit banging through GPIO. TmpDS18B20 class, for instance, must be tied to a file (direct, one of, implementations of 1-wire protocol through kernel driver). I would be more interested seeing something closer to the low level driver which, then can be implemented through /sys file system (as here) or bit banging or ... whatever is there. Implementation for test it third one I can envisage here. Still good place to start all with! Thanks Schups :) BTW 9f591711da7939d3c0bb87e17b682e30eace006b doesn't go under 1-wire protocol. Maybe it should be pulled after reviewed by Robert...

schup commented 9 years ago

I agree - native implemenation of the 1-wire protocol would be nice. Unfortunately I don't know the interals of the 1-wire protocol.

I've sumitted the merge request to get some feedback on the implementation and if the general approach would be good enough for now. It is WIP :-) The code is not really documented and well tested. Since the DS18B20 sensor is the only 1-wire device I have ever used there may be some specifics that wouldn't work well with other devices.

9f59171 - I merged the development branch back in to make sure it isn't breaking anything. I would suggest to not merge the feature branch until has stabilized a bit more :-)

Cheers, Peter

natdan commented 9 years ago

I've made implementation of one wire protocol some 20 years ago for 8031 (8051) µControllers and there are some resources on the internet (oh, what a understatement), so I don't mind looking more into it when time allows... And I hope it is going to be soon as I would like to use RPi + 2x1820 (or newer equivalent) soon as replacement for my hot water/heating controller. Anyway - you've tested your code with real device and it works - that's really good start! :) Will merge it as soon as return from the business trip.

DataWorm commented 9 years ago

Of course a bit-banging implementation might be nice but kernel support on the other side might be more efficient?! The DHT11 or DHT22 sensors for example (which would be my next feature requests) uses a single dataline but with another manchester-like protocol. I saw multiple implementations for it without kernel support. The python implementations have a lot of read fails due to the timing. C implementations perform much better but still can have read fails. W1 might have the same issue?! Therefore a kernel support would be a better working solution, wouldn't it?!

natdan commented 9 years ago

There's nothing wrong relying on kernel support and I see implementation of one wire protocol that users that particular kernel module as a primary implementation. But API (java interfaces) shouldn't really be kernel module specific (i.e. talking about exposed files) but to expose higher (lower?!) level functions one wire protocol itself defines. They will nicely translate to kernel module implementation, but at the same time allow other implementations and ability to move to other platforms(), too. DHT11/22 protocol API should be specification agnostic, too. Maybe we can start with C implementation (and JNI bridge to it) and see if anyone comes up with a kernel module, too. That would allow us to move from one implementation (which might not be ideal) to better one later without breaking compatibility of systems using it. () Server API defined pi4j works perfectly on Lejos and Haiku - not as a fully fledged pi4j port but more like cut down hacked version... Still code that works on pi4j (and uses Server API) works perfectly without any changes on those platforms because API is implementation agnostic...

natdan commented 9 years ago

Done. Again, apologies for not have done it sooner. Your code is now in develop branch. See pull request comments for failing tests..

savageautomate commented 9 years ago

Unit test code merged. This W1 impl is now available in the latest 1.1-SNAPSHOT build. Thanks!

giampiero7 commented 8 years ago

Hi @savageautomate, I'd just like to point out that WiringPi includes the driver for the MaxDetect series 1-wire sensors:

https://github.com/WiringPi/WiringPi/blob/master/devLib/maxdetect.c

It might be nice including it in Pi4J too :) I'll let you decide if it is worth having it as an enhancement...

Cheers, Giampiero