Jeremy Harris
Senior Member
I've been using DS18B20 sensors in lots of projects for a couple of years now, with no problems at all. Suddenly I find myself puzzling over an odd problem that I can't quite understand. I'm currently working on a heating/cooling control system and wish to modify it slightly to use an extra port that I didn't allow for when I made the PCB. This uses a 20M2 Picaxe, driving an LCD display, some thermal actuators (via solid state relays) and controls an air source heat pump (via a couple of normal relays). There's no problem at all with the circuit driving these things, it's been up and running for months without a glitch.
The problem is that I've no spare ports and wanted to add a manual offset adjustment capability, using a pot and a switch. The circuit shares a port that one of the DS18B20 sensors uses, like this:
The DPDT switch uses a spare input only port (C.6) to indicate whether the code should run a short loop to read the pot voltage with an ADC and convert it to a useful numeric value, or run the normal sensing code that I've had running for months. If the switch is sensed as being low then a short loop runs to measure the voltage, and store the set offset as a byte variable. This loop checks to see if the switch has changed state and if so switches the programme back to the proven code that I know works fine (I can't post all the code as it's too long, but it's the standard way of reading DS18B20 sensors and getting numeric data out).
The problem is this. If the switch is in the run mode when the circuit is powered up it works exactly as before, sensing temperatures correctly with all the right outputs happening as they should. When I switch to "set" mode that loop works fine also, and reads the ADC voltage and allows me to store an offset that's used elsewhere in the programme (previously I'd hard coded this offset, this mod was to allow me to adjust it, so the offset code is also well proven).
This is the odd thing. When I switch back to run mode the circuit works exactly as it did before, with the single exception that the output of the switched DS18B20 now always returns zero. I've checked and double checked the wiring, and the only way I can get the code to run properly is to execute a reset command on exiting the set loop. This gets back to everything working as it should, but loses the set offset (at the moment I'm working around that by writing it to EEPROM and recovering it after the reset).
Now, I can work with the circuit doing this, but am puzzled as to why the Picaxe seems unable to switch a port that had been reading a DS18B20 to reading an ADC and then back to reading a DS18B20 again. The odd thing seems to be that it works one way, in that I can switch this port from reading a DS18B20 to reading an ADC, but cannot then switch it back. It's almost as if there's something that prevents the port being reconfigured to read/write to a DS18B20 after the port has been used to read an ADC.
Before anyone asks, there are debounce delays and state checks after the change of state of C.6 is first detected and there is decoupling everywhere. The same behaviour exists when the code is run on a 20M2 in the AXE091 with no relays or external paraphernalia attached, so I am pretty confident it's not related to decoupling, spikes etc.
My best guess is that it has something to do with the way the ADC command leaves the state of port C.1, which then stops that port from working as an in/out port for a DS18B20, but if this is the case then perhaps it's something one of those with in-depth knowledge of what the Picaxe interpreter is really doing at the code level might be best equipped to answer.
The problem is that I've no spare ports and wanted to add a manual offset adjustment capability, using a pot and a switch. The circuit shares a port that one of the DS18B20 sensors uses, like this:
The DPDT switch uses a spare input only port (C.6) to indicate whether the code should run a short loop to read the pot voltage with an ADC and convert it to a useful numeric value, or run the normal sensing code that I've had running for months. If the switch is sensed as being low then a short loop runs to measure the voltage, and store the set offset as a byte variable. This loop checks to see if the switch has changed state and if so switches the programme back to the proven code that I know works fine (I can't post all the code as it's too long, but it's the standard way of reading DS18B20 sensors and getting numeric data out).
The problem is this. If the switch is in the run mode when the circuit is powered up it works exactly as before, sensing temperatures correctly with all the right outputs happening as they should. When I switch to "set" mode that loop works fine also, and reads the ADC voltage and allows me to store an offset that's used elsewhere in the programme (previously I'd hard coded this offset, this mod was to allow me to adjust it, so the offset code is also well proven).
This is the odd thing. When I switch back to run mode the circuit works exactly as it did before, with the single exception that the output of the switched DS18B20 now always returns zero. I've checked and double checked the wiring, and the only way I can get the code to run properly is to execute a reset command on exiting the set loop. This gets back to everything working as it should, but loses the set offset (at the moment I'm working around that by writing it to EEPROM and recovering it after the reset).
Now, I can work with the circuit doing this, but am puzzled as to why the Picaxe seems unable to switch a port that had been reading a DS18B20 to reading an ADC and then back to reading a DS18B20 again. The odd thing seems to be that it works one way, in that I can switch this port from reading a DS18B20 to reading an ADC, but cannot then switch it back. It's almost as if there's something that prevents the port being reconfigured to read/write to a DS18B20 after the port has been used to read an ADC.
Before anyone asks, there are debounce delays and state checks after the change of state of C.6 is first detected and there is decoupling everywhere. The same behaviour exists when the code is run on a 20M2 in the AXE091 with no relays or external paraphernalia attached, so I am pretty confident it's not related to decoupling, spikes etc.
My best guess is that it has something to do with the way the ADC command leaves the state of port C.1, which then stops that port from working as an in/out port for a DS18B20, but if this is the case then perhaps it's something one of those with in-depth knowledge of what the Picaxe interpreter is really doing at the code level might be best equipped to answer.