Floating inputs...

G

Grogster

Senior Member
Question: Can floating inputs cause wierd things to happen?

I have a system which I have already built and supplied several units, all of which work fine, but the last one I have just built, does uncommanded things.

Everything is fine until button1 is pressed, then the chip takes it apon itself to loop and execute loops for other inputs which ARE NOT active.

The used inputs are tied to ground via 1k/10k resistors, and active-high operation.(with no 5v input, the input pin is tied to deck via the 1k/10k - this is the idle state)

I'm just curious if unterminated(floating) inputs can cause this kind of thing.
My logic says NO, simply because you are using if/then on the required input, and so the code totally ignores unuses inputs, and thus they should have no bearing on the outcome of the code anyway - perhaps this is false logic?

EDIT: Oh yes, it really DOES matter - even if the input is not referenced in the code...
I pulled the misbehaving one to bits, and put a 10k to deck on the only unused(floating) input pin, and the problem has VANISHED - it works just like all the others now. Resistor not put on by defualt, as it was going to be a pain to fit it into the PCB layout, as things are a bit "Tight" component layout wise - guess I will do it now - where there is a will, there is a way.

Would not have thought that would be an issue though, if you are not addressing that input pin in the code; IE: the "floating" inputs can do whatever they like, as they are not being referenced in the code, so I did not think it would matter - live and learn. Only about 6 units in place so far, so will arm myself with some 10k's and a soldering iron, and modify the others, I think, just to be safe(as they are all still floating on that pin).
 
Last edited:
W

westaust55

Moderator
While it is not mandatory to tie unused inputs to ground, it is often recommended by experienced forum members.

While I personally have never tied unused inputs to ground and not experienced problems, I am aware from reading past threads that there are issues with the 28X1 and 40X1 where port A which is normally assigned as analogue inputs have some port A pins used for digital (which is possible) and others still used as analogue inputs.

More information will help you get a better response.
Which PICAXE chip are you using?
(ie Are you trying to do something like convert an 18X output to be an input?)Which pins are you using for the inputs in your program?

Please post your code and schematic of the circuit.

A photo of your circuit may also help.

Does the problem go away if you do ground unused inputs?
 
Last edited:
hippy

hippy

Ex-Staff (retired)
I'm not aware of any issues caused by floating pins which are not referenced in the code causing incorrect code operation. As westaust55 asks; which PICAXE, and can you post your code and schematic ?
 
B

BeanieBots

Moderator
Whilst floating inputs are not advised for a mutitude of reasons, they should NOT cause any erratic behaviour of code which does not address them.

Your symptoms are of a bug within the code which is inadvertantly referencing what is believed to be an unused input.

Please post code and circuit.
 
G

Grogster

Senior Member
I don't have a circuit yet.
Beleive it or not, I design the PCB right out of my head, get the units working(whatever the project), and once I have a working system, then I draw the schematic.

Somewhat unconventional, perhaps, but it works for me!!! :D
I will have to draw the circuit(or at least the relevant parts of it), and upload later.

Chip is 18X.

The units are mounted in stables, and any stable-hand who needs help, can press the help button and a message is sent to the other staff to assist. It also monitors a smoke-detector circuit.

I've made a mistake - I was sure it was an input, but it is actually an output - output7, leg 13.

Code: 
'==================================================================
'                MAIN PROCESSING & MESSAGE CONTROL:
'==================================================================

start:
  high 4							'Disable RF module
  gosub checkbatt						'Check condition of battery
  if pin1 = 1 then goto help_trp			'Look and see if HELP button pressed
  if pin7 = 1 and u=0 then gosub smoke_on		'Look and see if smoke detector tripped.
  if pin7 = 0 and u=1 then gosub smoke_off	'Look and see if smoke detector clear.
  goto start

help_trp:
  pause 200							'Button de-bounce delay
  if pin1 = 1 then goto help_msg			'Loop if button still pressed
  goto start						'Ignore if button released

help_msg:
  high 6							'Switch on flashing LED
  high 0							'Play reassurance sound
  wait 2							'Time for sounder
  low 0							'Ensure sound output is OFF
  gosub cap_code						'Send pager cap-code and pre-amble
  serout 5,T2400,("[*HELP!*] ")			'Send main help message
  gosub msg_dta						'Send stable-specific data
  high 4							'Disable RF module
  pause 500
  for x = 1 to 240					'Begin 2-minute delay
    pause 250						'Quarter a second delay
    if pin6 = 1 then goto reset_msg			'Look and see if RESET button pressed
    if pin7 = 1 and u=0 then gosub smoke_on	'Send smoke-alarm ONLY if not sent already during this loop
    if pin7 = 0 and u=1 then gosub smoke_off	'Send smoke-alarm clear ONLY if not sent already during this loop
    pause 250						'Quarter a second delay
    if pin6 = 1 then goto reset_msg			'Look and see if RESET button pressed
    if pin7 = 1 and u=0 then gosub smoke_on	'Send smoke-alarm ONLY if not sent already during this loop
    if pin7 = 0 and u=1 then gosub smoke_off	'Send smoke-alarm clear ONLY if not sent already during this loop
    next x							'Loop...
  goto help_msg


reset_msg:
  low 6							'Switch off flashing LED
  gosub cap_code						'Send pager cap-code and pre-amble
  serout 5,T2400,("[*RESET*] ")			'Send main reset message
  gosub msg_dta						'Send stable-specifc data
  goto start

batt_msg:
  let y = 1							'Set battery message flag
  gosub cap_code						'Send pager cap-code and pre-amble
  serout 5,T2400,("[*BATTERY WEAK*] ")		'Weak battery message
  gosub msg_dta						'Send stable specific data
  goto start

crit_bat:
  let w = 1							'Set critical message flag
  'pause 500						'Hald a second delay
  gosub cap_code						'Send pager cap-code and pre-amble
  serout 5,T2400,("[*BATTERY CRITICAL!*] ")	'Critical battery message
  gosub msg_dta						'Send stable-specific data
  goto start

'===========================================================
'                       SUB-ROUTINES:
'===========================================================  

checkbatt:							'BATTERY CHECK SUB
  if y = 1 then goto pop_ret				'If battery message sent already, don't send again
  if w = 1 then goto pop_ret				'If critical battery message sent already, don't send
  readadc 2,z						'Read battery voltage
  if z >=100 and z <= 122 then goto batt_msg	'If battery voltage less then 7v, send message
  if z <=99 then goto crit_bat			'If battery voltage less then 6v, send critical
  return


pop_ret:							'GOSUB STACK POP SUB
  return


cap_code:							'PAGER CAP-CODE SUB
  low 4							'Enable RF module.
  pause 250							'Allow RF module to wake up.
  serout 5,T2400,("CA16024551",CR)			'Pager transmitter pre-amble & cap-code
  pause 250							'Allow pager transmitter to acknowledge
  return


smoke_on:							'SMOKE DETECTOR TRIP SUB
  pause 500							'Debounce delay
  if pin7 = 0 then goto pop_ret  			'If smoke detector no active, exit
  gosub cap_code						'Send pager cap-code and pre-amble
  pause 250
  serout 5,T2400,("[*SMOKE ALARM!*] ")		'Smoke alarm tripped message
  gosub msg_dta						'Send stable-specific data
  let u = 1							'Set detector tripped flag
  return

  
smoke_off:							'SMOKE DETECTOR CLEAR SUB
  gosub cap_code						'Send pager cap-code and pre-amble
  serout 5,T2400,("[*SMOKE ALARM CLEAR*] ")	'Smoke alarm clear message
  gosub msg_dta						'Send stable-specific data
  let u = 0							'Set detector clear flag.
  return
  

'===========================================================
'                    MESSAGE DATA SUB:
'===========================================================

msg_dta:
  serout 5,T2400,("STABLE 1 - Assistance required.",CR)
  return
When first fired up, the unit sits in standby correctly.
When testing the unit, I simulate a smoke-detector trip, and the unit correcly loops and sends the smoke-alarm, then comes back to start where is proceeds to loop to help_trp even with no high on that input...

If leg13/output7 is left unterminated, the code auto-loops to help_trp then help_msg as soon as the smoke_on routine has run and the code comes back to start- even though input1 IS NOT in a high state watching it with a multimeter. I put a delay at the start of start of 500ms or so, but it still loops without the input pin being high.

Put the 10k pull-down on leg13 to deck, and the problem vanishes and the system works correctly, and does not loop to help_trp or help_msg once returning from the smoke_on subroutine.

This is somewhat academic(but rather curious) now, so long as the problem is fixed(which it seems to be), but I would still like to understand why this is happening...
 
Last edited:
lbenson

lbenson

Senior Member
Didn't really look to see if this is your problem, but you have a "gosub checkbatt" which has a "goto batt_msg" which ends with "goto start". Not good, and will eventually cause stack overflows. Other similar problems exist.

Also, when you use subroutines, they should have a single return point. Using the "pop_ret" subroutine as a way to jump out and execute a return is at the very least confusing. Better to restructure checkbatt.
Code: 
checkbatt:
  if y <> 1 then                      'If battery message not sent already
    if w <> 1 then                    'If critical battery message not sent already
      readadc 2,z                     'Read battery voltage
      if z >=100 and z <= 122 then 
        gosub batt_msg                'If battery voltage less then 7v, send message
      elseif z <=99 then 
        gosub crit_bat                'If battery voltage less then 6v, send critical
      endif
    endif
  endif
  return
It will be easier for people to help with problems if the code structure is straightforward.
 
Last edited:
G

Grogster

Senior Member
Also, when you use subroutines, they should have a single return point. Using the "pop_ret" subroutine as a way to jump out and execute a return is at the very least confusing. Better to restructure checkbatt.
Click to expand...
Not confusing to pop the return stack from when I leart BASIC programming, we used to do it all the time:

50 If A=1 THEN POP:GOTO 10

But Picaxe syntax will not let me simply exit at any given point and return, hense the pop_ret routine.

Often, it is required to be able to exit from a gosub with a return if a certain case is true, without running any more of the code from that routine, but the PICAXE language won't easily let me do that. I don't understand the elseif and endif idea at all. :(

I guess I need to study those commands... ;)

Why are elseif and endif commands not in the manual?
Pages 27/28 about if/then, if/and/then, if/or/then make no mention of elseif and endif commands, and they are not listed in the list of commands on pages 1 & 2. This could have saved me writing the pop thing the way I did, if I knew there was a more efficient alternative...

It will be easier for people to help with problems if the code structure is straightforward.
Click to expand...
Hah hah - problem is, your version is more confusing to me then what I have written ;) :p. We are not all master programmers, some of us just write what works. It may not, strictly speaking, be the best way, but so long as it works... Guess I am going to have to study these commands, if I can find any information on them.
 
Last edited:
G

Grogster

Senior Member
BCJKiwi said:
Check out Manual2 page 84 (ver 6.9)
if..then \ elsif...then \ else \ endif
Click to expand...
Cheers - you mentioned the verson number of the manual, and that was a light going on in my head - current manual I am using is version 5.1, 25/04/2004 - my bad... :(

Will download the latest and re-print so I have an up to date reference, and have a read.
 
B

BCJKiwi

Senior Member
April 2004! - a lifetime ago in electronics!

You might want to wait on the printing as a new version of PE is overdue and often comes with an updated manual.
 
hippy

hippy

Ex-Staff (retired)
On program design; all fancy high-level commands ( IF-ELSE-ENDIF, ELSEIF, DO-LOOP, SELECT-CASE etc ) can be achieved using only IF-GOTO, just that it's not so easy to read, the commands are primarily there to make coding easier and the code itself easier to follow or to debug. Truth is that, if you could look behind the scenes, you'd see these are implemented with IF-GOTO and GOTO whch is why it was possible to add these commands without having to update firmware.

On the 'floating output' issue; this is perhaps indicative of a hardware problem with the board, maybe solder shorts. An unused output should have been set to low when the PICAXE is reset so needing a pull-down shouldn't be required and adding it shouldn't affect anything.

I've no real idea how one would go about debugging such a fault without a circuit diagram and without physical access to the board. The only think I would say is that this seems much more likely a hardware or software problem than a fault with the PICAXE itself.
 
B

BeanieBots

Moderator
I agree that this sounds like a hardware fault.
The first thing I'd try for debugging (besides having a circuit diagram) would be to pull the 'floating' inputs low and test.
Then repeat with the inputs pulled high.
There should be no change in program execution.
 
You must log in or register to reply here.
Top