Hey folks, I have a quick question regarding a sensor choice, and how I can optimize speed on a arduino mega 2560.
I currently have a small project that is running on a nano, but I have run out of I/O space, and am doing a redesign with a mega. Simply put it reads temperature, displays it on a LCD, and provides an output. I also have a pot to control a temp setpoint.
I fell into the issues with the dallas and onewire libraries slowing down the overall code execution of the arduino like has been mentioned here multiple times on the forum. And on the Nano I was planning to have 3-4 temp sensors on one digital pin. I figured out how to change the temp read resolution to my liking, to help speed up the process. In my case, the "delay" time to wait and read the temp is really noticeable when you are playing with the adjustment pot to set a temp setpoint on the display and it in return gives the HMI a very sluggish feedback and feel.
So heres my question....
Going with the MEGA gives me a lot more spare digital pins, would it make sense to (in my case), to allot individual DS18B20 sensors to individual digital pins? This helps me in a few ways, (ie, if I swap out sensors, I don't need to reteach in the code that the individual chip id "XXXXXX" is for this reading. I know D2 reads "air temp" D3 reads "water temp" etc... and I should in theory be able to speed up the code and read speeds because there is only one sensor per digital pin..
I am still very amateur with these type of more "advanced" arduino coding, so let me know if my thinking logic is right.
I would like to stick with the DS18B20 because I don't really need to do any calibration compared to an analogue sensor, and if im not mistaken, temp readings should not change with varying source voltage. IE if the 5v bus has sags or such when loads are switched on/off.
Powering the sensors directly (3 wire connection) allows them to work faster.
I modified my copy of the library to allow an option of waiting for the "conversion" or starting the conversion without blocking and then pick up the results later.
Put them all on one pin so that you can use a single start-conversion command.
I am powering the chips via the 3 wire connection method, ive seen folks have issues with the parasitic mode. And the 3 wire is IMO a more reliable power type.
With that said, I would prefer to use a single sensor per input, just that if I swap sensors out I will not have to either reteach the ID, or have issue with it choosing the wrong sensor for the wrong reading if they are unplugged and plugged in. I realize that these work great on a single bus and I was initially planning to use that method, but now with the mega I have a lot more digital pins, I would prefer to separate them
Staying away from parasitic power is a really good idea.
I don't think your anticipated problems with DS18B20 are likely to be borne out but, with all those pins presumably available, I'm not going to argue for using the sensors on one wire and here is a method I used for individual pins which you might find comforting.
You will probably find that changing the resolution to speed the conversion time is all you need or can justify, and if you have good reason to be in a serious hurry, you have probably chosen the wrong sensor. So how much change in air and water temperature can you reasonably expect in less than one second anyway?
Nick_Pyner:
You will probably find that changing the resolution to speed the conversion time is all you need or can justify, and if you have good reason to be in a serious hurry, you have probably chosen the wrong sensor. So how much change in air and water temperature can you reasonably expect in less than one second anyway?
The actual temperature poll speed isn't an issue to me, I can live with it being 1-2 seconds between readings, the issue I was having (maybe by my own fault) is that when the arduino is executing the temp read, the entire program stops, and other "analog input/TX/RX" commands/reads are halted during the read. Maybe this is a syntax issue in how I organized the code, or an inherent issue with the DS18B20 libraries??
I would like to have the rest of the program to run as quickly as possible while the temp read aspect runs and doesn't slow down the rest of the code while causing a visible sluggishness on the display.
Very probably. Indeed I don't know how you can do that. The reading retrieval takes 750ms at most, and Arduino can get on with other things in the meantime anyway. What this means is that, if you just ask the sensors in a one second loop, you should have no problems, and any that you do have are caused by something else that you are not talking about. It might be time to post your code.
Take another look at reply #2. You can issue a request to the sensors to get temperatures and carry on being responsive to other inputs. You'll need to keep track of time to know when the temperatures are ready for you to extract.
Raptorex:
Hey folks, I have a quick question regarding a sensor choice, and how I can optimize speed on a arduino mega 2560.
Mostly: don't bother, other than not waiting for the conversion to complete but tell the sensor to start the conversion and when enough time has passed for it to complete go and read it. Using a single or multiple buses doesn't make a difference in that.
The reading speed of the sensor is no doubt much faster than the change of temperature they can follow. The bulk of the sensor slows down its reaction to a change in ambient temperature, especially in air, to a lesser extent in water (more efficient transfer of heat between the sensor and the water). Still you can expect a reaction time of the sensor itself in the tens of seconds. Even at the 12-bit resolution (and the sensor taking 0.75s for a conversion) it's likely still fast enough to follow your environment.
If you're looking for much faster temperature changes, look for a different sensor. A small thermistor (NTC) reacts much faster already due to the much smaller bulk of the sensor itself, a thermocouple is the smallest and therefore the fastest of all. Note that those are also analog sensors, that do not do any "conversion" or so by themselves, instead you do that on the Arduino, a much faster microcontroller than one could ever build into a sensor that small/cheap.