Skip to content
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

Open
terrypin999 opened this issue Sep 8, 2023 · 5 comments
Open

Is there a conflict with Toggle library? #247

terrypin999 opened this issue Sep 8, 2023 · 5 comments

Comments

@terrypin999
Copy link

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.

@RobTillaart
Copy link
Contributor

Not familiar with the Toggle Library, link?
Is it possible to create a minimal sketch that shows the problem, e.g. based upon the minimal sketch of the DS18B20?

@terrypin999
Copy link
Author

Thanks for the quick response. Here's a link to the same issue I've posted on the Toggle site (which looks very quiet).
https://github.com/Dlloydev/Toggle/issues/3

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
'Non blocking temperature sensor library for Arduino'

If I make significant progress with either that or the demo sketch I'll come back.

@RobTillaart
Copy link
Contributor

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.
Even at lower resolutions this requestTemperatures() can block for 375 or 190 ms. which is already near the 200ms.
I expect that only at a resolution of 9 bits the SHORT toggle can be recognized as the blocking is "only ~95 ms".
Still you can expect 50% of the time blocking.

Solution is to use the async modus operandi and call sensors.setWaitForConversion(true) in setup().
You must guard the conversion timing yourself by checking isConversionComplete()


PS, I am not familiar with - https://github.com/Gbertaz/NonBlockingDallas - however a quick look shows it uses
this Arduino-Temperature-Control-Library library

#include <DallasTemperature.h>

@terrypin999
Copy link
Author

terrypin999 commented Sep 9, 2023

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

@RobTillaart
Copy link
Contributor

East Grinstead, UK

Think I've been there one once with my wife (years ago), there was a small tearoom with extraordinary scones.
Was a local price winner. I recall the entrance was down a few stairs,

DS18B20

Learning to control the sensor in an async way is easiest by working through the examples.
Its like,

  1. start conversion,
  2. do something else,
  3. check if it is ready,
  4. if ready read the value else goto 2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants