Output will not stay on

[moey]

I might have overlooked something pretty basic, but I thought a Picaxe output (18x in this case), once turned ON, stayed ON until told to turn off.
I have a situation where an output turns off while the code is off doing other things.

I have prototyped a thermostat project.
- Reading temperature from a DS18B20.
- Displaying current_temp and setting_temp on an LCD display (Thanks to Hippy's LCD pages).
- Reads 2 pushbuttons (up/down) which set the setting_temp value.
- Turns on the heater output (LED at the moment) when actual_temp < setting_temp, and turns the output off when the reverse is true.
This is all fine. So far everything works as expected, (with unavoidable switch lag while it gosubs to reading the temp sensor).

But... the Picaxe output, if on, turns off when I press either of the pushbuttons to adjust the setting_temp.
Is this right? The Picaxe can't keep an output on and read inputs at the same time?

(On another subject, readtemp12 seems to work fine at 8MHz, contrary to what the manual states).

 

[TEZARM]

No, The Picaxe can turn on an output and stay on and then other input triggers will not interfere with this output unless told to turn off through the program. This problem is one of three things.

1. Power Supply
2. Program Code
3. Reset pin (NOT BEEN TIED HIGH)
Easy way to test, type up a simple program that turns an output or 2 on. Then trigger other inputs and see if the output turns off (SHOULDN'T DO).
Are you using relays. Do they have diodes across the coils. What does your power supply circuit look like?

 

[moey]

Hi Tezarm,
The power supply is a 5v regulator powered by 12v battery.
Reset pin is high via 4k7.
Your suggestion of a test program proved what I should tested first off.
So it's got to be my cock-eyed code.
I'll "think harder Homer."

 

[moey]

Help Hippy!
By process of elimination I finally worked out that the outputs turn off every time the LCD gets sent new commands.
Using your 6 wire LCD schematic, the remaining outputs (0 & 1) seem to get turned off by this bit of your LCD code.

SendDataByte:
pins = byte & %11110000 | rsbit
pins = byte * %00010000 | rsbit

But I don't know enough about the LCD code to modify it. Is it necessary for it to affect the two spare outputs?

 

[hippy]

Hi moey; you beat me to it and identified the problem yourself.

Overcoming the problem is quite simple, using a 'PEEK $30' which recovers what was last written to the output pins before the LCD updates those pins. You'll need to modify the code slightly, as described on the web page ...

<b>Using Output Pins 0 and 1 </b>

A problem which may occur with the use of the above routines is when Output Pins 0 or 1 are used within your program. Because of the use of the 'pins =' assignments, these two bits are always set low whenever the 'SendCmdByte:' or 'SendDataByte:' routines are called.

If it is not desirable to have these two bits cleared while interacting with the LCD, the rouines can be modified as follows ...

SendInitCmdByte:

PAUSE 15 ; Delay 15mS at 4MHz

SendCmdByte:

PEEK $30,rsbit ; Recover Out0 and Out1
rsbit = rsbit &amp; %11 ; Send to Command register
GOTO SendCmdOrDataByte

SendDataByte:

PEEK $30,rsbit ; Recover Out0 and Out1
rsbit = rsbit &amp; %11 | RSDATmask ; Send to Data register

SendCmdOrDataBye:

pins = byte &amp; %11110000 | rsbit ; Put MSB out first
PULSOUT E,1 ; Give a 10uS pulse on E
pins = byte * %00010000 | rsbit ; Put LSB out second
PULSOUT E,1 ; Give a 10uS pulse on E

RETURN

The trick used is to recover the contents of SFR at location $30 which is a copy of the current output pin levels. This allows the levels of Output Pins 0 and 1 to be recovered and then set as they were previously when the 'pins =' assignments are performed.

http://www.hippy.freeserve.co.uk/picaxelc.htm#Using_Output_pins_0_and_1

 

[moey]

Done and fixed.
Thanks Hippy.