-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is there a conflict with Toggle library? #247
Comments
Not familiar with the Toggle Library, link? |
Thanks for the quick response. Here's a link to the same issue I've posted on the Toggle site (which looks very quiet). I was working on a minimalised sketch along the lines you suggest. But I've also just come across a possible alternative which I'll install and try next, as its 'non-blocking' claim sounds promising. https://github.com/Gbertaz/NonBlockingDallas If I make significant progress with either that or the demo sketch I'll come back. |
I went quickly through the sources of Toggle and found no direct hint to interference with this library. Hypothesis:sensors.requestTemperatures(); calls a function that blocks until the sensor is ready UNLESS sensors.setWaitForConversion(true) is set. As the DS18B20 can take 750 milliseconds (12 bit resolution) before it "unblocks" the time of less than 200 ms of the Toggle library has passed. Solution is to use the async modus operandi and call sensors.setWaitForConversion(true) in setup(). PS, I am not familiar with - https://github.com/Gbertaz/NonBlockingDallas - however a quick look shows it uses #include <DallasTemperature.h> |
Hmm, replied to this late last night (Fri) but it's not turned up. Anyway it was merely a thank you and advising my intention to work on your suggestions today. With Saturday chores over, I started work on them an hour ago. As you probably gathered I'm an 'Arduino programmer' at best. Fair bit of Arduino experience now (some two years) and decades of hobbyist electronics. But this current project is my first with temperature sensing and therefore with the comprehensive DallasTemperature libary. I am struggling a bit. Editing my already rather complex sketch to get either a sufficient 'universal' reduction in blocked time, or specific code such as your WaitForConversion2, is proving a challenge. I've not given up, but for time being I'm going to abandon Toggle's short presses. Motivations are my impatience to finish the project, the risk of screwing up the existing sketch, and coding more "interesting stuff", to echo your phrase. So I'll now use long presses exclusively. Previous intention was about 15 'cases' from the one 'Toggled' button. But reckon I might get that down to eight or nine. At say 400 ms each that's around four seconds to trigger case #9; slow. I'll see how it goes and let you know. Here, or via email if you'd prefer, given that the original 'issue' is surely now resolved for anyone else with an interest. Or the forum for that matter - your choice entirely. Terry, East Grinstead, UK |
Think I've been there one once with my wife (years ago), there was a small tearoom with extraordinary scones.
Learning to control the sensor in an async way is easiest by working through the examples.
|
I've used DavidLloyd's Toggle library in other projects successfully. But after adding it to my current project it fails to recognise 'short' button presses, i.e. those delivering lows under 200 ms. It does recognise the 'long' button presses ( > 500 ms).
This conflict over resources, if that's what it is, appears to be with DallasTemperature, because if I comment out the statement
// sensors.requestTemperatures();
then short presses are correctly detected.
The text was updated successfully, but these errors were encountered: