0

I recently run into a problem that causing my whole code processing slow down, for example i had a millis timer set for one minute but it took 1:30m to finish, pressing buttons was laggy etc.

After hours of digging and commenting out codes piece by piece i finally found out what is causing the slow down!

my DS18B20 temperature sensor DATA pin is connected to pin A0 when i remove the library and related codes to the sensor processing became MUCH faster more snappier/responsive...

After googling a bit i realized that everyone connected the sensor to pin 2 of Arduino!

So is the processing slow because DS18B20 is on pin A0 instead of pin 2 or there's something wrong with the sensor itself or it is because of This library?

Improve this question
2

Indirectly it's the library.

That library uses the OneWire.h library. The OneWire protocol requires some reasonably precise timing, and because of the the OneWire.h library turns off interrupts while it communicates.

While interrupts are disabled nothing else can happen. That means that the timer interrupt that drives millis() can't "tick" - so the millis count doesn't increase while you communicate with the temperature sensor.

Improve this answer
6
  • Hi Majenko, which library do you suggest? – ElectronSurf Jul 15 '19 at 18:47
  • 1
    There's not really anything you can do on an Arduino. You just have to put up with it and maybe compensate for the time taken communicating. – Majenko♦ Jul 15 '19 at 18:51
  • you mean changing the library not gonna fix the problem? – ElectronSurf Jul 15 '19 at 18:52
  • 1
    You would need to do it in hardware. Maybe with a DS2482-100 I2C to OneWire adapter. – Majenko♦ Jul 15 '19 at 18:54
  • 1
    Yes it is. In the header file: #include <OneWire.h> – Majenko♦ Jul 15 '19 at 18:58
1

The software function managing the 1-wire protocol generally has several non-interruptable sections in order to ensure the bus timings. This can make your processor unavailable for long periods of time.

Worse, some implementations do not allow any interrupt at all.

And even if your implemenation would allow being interrupted, it is generally blocking the main loop as it is not executed in an interrupt itself.

Using a hardware implementation for the 1-wire control instead of a full software would release the CPU from managing the timing and waiting for the 1-wire to complete. But such hardware implementation are not commonly available in microcontrollers.

There is however a middle way. An open source implementation using the microprocessor's or controller's UART to ensure the timings is available ( https://github.com/MaJerle/onewire_uart ) - MAXIM also has an application note for it ( https://www.maximintegrated.com/en/app-notes/index.mvp/id/214 ). This also offloads the processor and it can be interrupt driven.

Is the processing slow because DS18B20 is on pin A0 instead of pin 2 ? That might have an influence if the processor that is on your Arduino board would have a (partially) 1-wire compatible source on another pin, in which case the libary would have to take advantage of that.

Is there something wrong with the sensor itself? That would not be generally the case, but in case you have two sensors on the same bus, the 1-wire protocol is slower as it needs to find all peripherals and the master has to indicate which one it is addressing.

Is it because of "This library"? It is not because of that library, but there are other implementations (see the link above) that use hardware resources to improve performance at the cost of using a hardware resource (some MCU's have only 1 HW UART so you'ld not have a second one if you also need RS232 communication for instance on other signal lines).

Improve this answer
2
  • the UART thing seems pretty awsome but too advanced for a user like me, i tried to read the documents but the more i read more i lost! we connect one side of UART to two transistor and other side goes to arduino? i'll pick your answer as correct one if you please help me figure this out... – ElectronSurf Jul 15 '19 at 20:36
  • The 1-wire bus is bidirectionnal, so it must be possible for the slave to pull the line low. Standard TX operation of a UART is to always drive the output. The application note (majerle.eu/documentation/ow/html/page_appnote.html ) proposes a solution where two cascaded transistors transform the TX in an open-drain output. The same application note indicates that if your uC allows opendrain on the output itself, that you do not need this (it is said that the STM32 allows this) - in that case the TX and RX pins are connected together. In both cases you have a true one-wire bus. – le_top Jul 17 '19 at 19:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.