Open benjaminmathews opened 7 years ago
Hi, Is this the only device connected to the bus?
Can you try running the C and C++ examples and see what they do?
If one of those hangs too, can you interrupt it (maybe run it under gdb) and send a stack trace (bt command in gdb)?
Do executable example scripts get saved on the device when I install the library? Couldn't find any..
I'm not very experienced with compiling and building and all that yet, so I guess it would be more productive if you could try that on your side. :P Or else, you can walk me through it. I'm game.
Here's what I tried:
g++ -g -Wall test.cxx -lupm-ds18b20 -I/usr/include/upm
Got this error: /usr/lib/gcc/i586-poky-linux/4.9.1/../../../../i586-poky-linux/bin/ld: /tmp/ccPBXUGF.o: undefined reference to symbol 'ds18b20_devices_found' //usr/lib/libupmc-ds18b20.so.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status
Is there some other library I should link while compiling? Or am I doing it all wrong?
Close - try adding:
-lupmc-ds18b20 -lmraa
Instead of writing your own .cxx file, you can just grab the one from this repo at examples/c++/ds18b20.cxx
It seems that instead of waiting 750ms after sending a measurement command to query the result, it was waiting for 750000ms (about 12 minutes). So - if you let it sit long enough, it will eventually get the correct data. A fix for this has been merged (cc0174910bd8ee62c4f99bc477ee5fbc4ca18f1a).
Cool! Thanks! :) I've left it running right now.. Just for fun. 😛 Another quick thing before you close this : I had come across another very similar issue just before facing this one. TL;DR - is it possible that this same delay issue is there in the init() function, such that it would show up when there are no sensors connected on the bus?
Details: Would I be right in saying that, when there are no sensors connected on the bus, the library (in the init() function, I think) is supposed to throw an error saying "no devices detected"? Because I have come across that error earlier, and I structured my code to use that error information. However, recently, I noticed that the code gets stuck over there just as in the above case... So, when there are no sensors connected on the bus, will the code return an error? And, is it possible that this same delay issue is there in that function too?
Update: Looks like it isn't a delay issue. I tried running the example using gdb, as you suggested. The stack trace for both cases (normal sensor.update(), and when no sensors are connected) are different. Should I post it over here or start a new issue for this?
Yes, start a new issue. I think the issue in that case is that we do a read on the bus during certain operations (like _reset()), and it's possible that the code can go into an infinite loop in MRAA. I am looking at that now. The issue is that it is not really an "exact science" when it comes to detecting the presence or absence of devices - I think mainly due to the interface circuit we use.
For example, simply reversing the diode, and disconnecting the bus line to the sensor, you will get the "no devices found" error. But of course, then you cannot talk to the device even if it is connected.
I think the solution to that (and we've had others report this problem) is to modify MRAA's uart_ow support to "timeout" if it cannot get a valid bit off of the bus. Right now, it will just spin forever, which is what you are seeing (and me too if I disconnect the device from the bus). I'll look into this and possibly submit a fix to MRAA.
Oh. I understand. In that case, do I need to open up an issue at all? (since you know the problem and are working on it)
No, I'll look into it.
👍 Thanks for all the help!
You bet. I've submitted MRAA PR #671 which adds a 5-second timeout to the low level byte reader. This should prevent a broken device/interface circuit from going into an infinite loop.
Thanks for reporting!
did you fix this issue?
@minhhieuec yes.
@jontrulson i'm newbie, could you tell me how to fix it please!
You can either wait for updated MRAA and UPM modules to be released, or try to compile them yourself. Sorry, I don't have the time to walk you through building things.
@minhhieuec check the MRAA/UPM readmes for installation and building instructions. If you're on a x86 board you can use the development repo with opkg
to update to the latest without having to build from source.
@Propanu Thank you very much, it worked perfectly. But when I add more 1 Ds18b20, i cant get the Temperater of them, could you help me to fix this problem?
I'm using
The code worked fine with the previous versions of mraa/upm. However, it seems to be having issues with the latest upm version. I don't know if this is a mistake at my end or some other issue. The sensor.update() function gets stuck - no response, no error messages. I cannot find a way to force opkg to install a previous version of upm to confirm that this is an issue with the update..
Found a spare board that had upm v1.0.1 and mraa v1.5.1 installed. So I tried the following:
Is there something I'm missing? Or something else I should try?