I got the DS18B20 running on both my Mega2560 and a Teensy 3.6 using code found on the internet but there's an issue with the time it takes to generate outputs from even just a single sensor. I read that the total time is just under one second, but my testing with a single sensor reveals a total time of about 0.62 seconds for a single sensor setup and about 1.09 seconds to do 5 sensors. In the code I'm using, the "Loop" code that is, there's two statements that get the data: the first one, "sensors.requestTemperatures()", instructs the sensors to start the measurement; and the second one, "sensors.getTempCByIndex(n)", reads in the values with a separate statement for each of the sensors -- ie sensors.getTempCByIndex(0) ... sensors.getTempCByIndex(4) for a 5 sensors setup. From this a calculate that the first statement takes about 0.5 seconds and the 5 sensor reads takes another 0.59 seconds for a total of 1.09 seconds.
The other thing is that I've seen other code that refers to the sensors actual 64 bit address and not by index and I have to wonder if the direct address method is faster. But, more to the point, how best to code the conversion and reads so that the code isn't tied up for more than a second to get the 5 reads. I guess one way would be to start the conversion, then execute other code, then read in the values from the sensors then repeat. But, if there's a more elegant method and particularly one that's a lot faster I would appreciate any pointers to faster code.
I know, for example, that the typical method for reading digital pins requires first setting the "pinMode()" and then doing a "digitalRead()" but that there are much faster ways to do this by writing directly to the port -- is there a comparable method to speed up the temp reads with the DS18B20? I can appreciate that there is a minimum time for the sensors to complete the measurement and that is about 0.5 seconds so arranging the code so that the start measurement command is sent near the top of the Loop, then all the rest of the code not related to the temp sensors, then at the bottom of the Loop reading in the values and doing whatever is needed with that data before starting the loop over again.
So, again, any pointers to better code would be appreciated.
Raptor1956:
The other thing is that I've seen other code that refers to the sensors actual 64 bit address and not by index and I have to wonder if the direct address method is faster.
I believe that is correct, but I don't think there is much in it, and it probably isn't the real problem anyway. The real issue is the conversion time, about which you say nothing in your secret code, but is determined by the resolution. The highest resolution, which is 12 bit by default, requires 750 msec. This is the minimum time of the loop, irrespective of the number of sensors, and the position of the commands therein is immaterial. If you specify a lower resolution, you can greatly reduce the conversion time. Check the data sheets but, before you do, you might consider the practicalities of all this, rather than blindly racing off in pursuit of "faster" code. If you really need lightning fast readings, you are probably using the wrong sensor.
If you drop resolution from 12-bit (0.0625C resolution) to 9-bit (0.5C resolution), conversion time drops from 750mSec to 94mSec.
I suppose temp can be read in the background while the main loop is running.
No experience there. Maybe someone else can chime in.
Leo..
Wawa:
If you drop resolution from 12-bit (0.0625C resolution) to 9-bit (0.5C resolution), conversion time drops from 750mSec to 94mSec.
I suppose temp can be read in the background while the main loop is running.
No experience there. Maybe someone else can chime in.
Leo..
OK, lowering the resolution might be a reasonable trade-off and I think I can live with 0.5C resolution though perhaps 10-bit would split the difference a bit at what should be about 0.25C resolution at 10-bit. I'd further guess the time would about double to 188mSec or there abouts. I'll have to look for the actual data sheet and see if I can make sense of it to get a better understanding of it.
One thing I seem to remember reading about with the code method I posted above is that the sequence using 'index' may not be the same upon power-up. That is, it might one time go for '0' at the top and '4' at the bottom of an array of five and the next time the various index numbers may not point to the same sensor -- I don't know for sure if that's true but if it is then the direct address method would seem to solve that problem.
The time of conversion should not be a problem (if you are not using parasitic power). You may ask all devices to make conversion, do other things for the needed time and then collect results. There is worse problem - Arduino does not have hardware support for 1-wire. It is emulated by bit banging but it consumes lot of processor time. I don't know how it is implemented in your library but probably the communication is blocking code. 1 byte ~ 1 ms, reading results/sending command is ~ 10 bytes. With multiple thermometers you will quickly run out of time. If you want to measure the temperature so often on so many thermometers it may be worth to get standalone chip for handling the communication. Maybe another MCU sending only the interesting data to the main Arduino via SPI/I2C...
That is, it might one time go for '0' at the top and '4' at the bottom of an array of five and the next time the various index numbers may not point to the same sensor -- I don't know for sure if that's true ...
It's not true. The sequence will always be the same. The index numbers are based on the unique internal addresses as explained here.
How much speed do you need? Or put another way - what are you doing?
As noted, you can request that the sensors gather temperature data and go about your business for 750ms and then collect it.
There is an issue with using the index values to read sensors. The values do remain constant between power cycles, but if you swap out one of them, you will need to find out which is which again - all may have changed.
wildbill:
How much speed do you need? Or put another way - what are you doing?
As noted, you can request that the sensors gather temperature data and go about your business for 750ms and then collect it.
There is an issue with using the index values to read sensors. The values do remain constant between power cycles, but if you swap out one of them, you will need to find out which is which again - all may have changed.
I'm just starting with the Arduino and guessing just how complex the code will be well all is said and done is a bit tough to say at this point but keeping an eye on execution speed now means not getting blind-sided later -- maybe. I'm not going to get to specific as to the final product idea just now but if I guesstimate the final parts cost is likely to be over $225 before assembly so there are going to be a fair number of things to look at and control. If the DS18B20 is too CPU hungry I may have to go a different route, perhaps thermistors. The advantage of the DS18B20 is good accuracy and reasonable cost but if using them, at least 6 of them that is, eats up too much time then perhaps thermistors is the better option...
I'd suggest that you worry about it later. At most, I'd hide the temperature reading behind a generic ReadTemp routine to act as a facade so you can switch sensors more easily if you have to. I doubt the DS18B20s will give you any trouble as long as you don't wait for them to get the data - request it and read it later when it's ready. Unless that is, you need very tight time/temperature control for your project.
Remember too that there are a multiplicity of Arduino models now. You can get a lot more processing power if you need it. Or look at a Pi.