triggering but not outputting ?

[davidwf]

I am using an 08M2+ chip to operate a small geared 10 RPM 12V motor to lock and unlock a door....
Operation is basically a pushbutton toggle switch indoors which causes the motor to rotate 90 degrees to either lock or unlock a door .......at the desired point a microswitch operates via a cam in a plastic wheel which signals the cct. to disconnect power and apply a short to the motor so it stops dead.

The mechanical design and parts all work fine, the problem being that on occasions it doesnt trigger motor movement and/or the reverse relay and so next time the switch is operated the motor goes the "wrong" way causing mechanical damage - the motors I am using are mini geared 12V @ 10rpm and have monumental torque whilst only consuming around 300mA.

When bench testing it worked 99.9% of the time then although it didnt operate the motor it DID appear to change state as, on the next operation of the switch the motor moved the wrong way which is the problem experienced in situ

We cannot get it to go wrong enough to investigate further......it usually (although not always) does it when unlocking with the relay not operating and also no o/p on the motor run pin, I thought it might be contact bounce in the switch so my son added a de-bounce check in the "main" section, sometimes the motor also stops mid-way as if the microswitch had operated

I have replaced the PIC with a brand new never used one and that does the same
Any guidance appreciated
Thanks

 

[The bear]

Hi,
Interesting project.
Can you copy and post your code please.
I appreciate that you have included your code, but people are reluctant to open attachments.
Good luck............

 

[davidwf]

Not sure what format you prefer the code....so here's both






#simspeed 10
#picaxe 08m2
' sliding carport door lock
' operates via indoor switch
'pin i/o function
'1 pwr V+
'2 i/p c.4 serial data in (for programming)
'3 c.4 in from open/close
'4 c.3 in from motor cam
'5 c.2 out to motor run
'6 in from RF600D pin 1 (channel 3)
'7 c.0 serial data out (for programming) shared with direction relay
'8 pwr 0V
'variables
'w0 = (b0,b1)used
'w1 = (b2,b3)
'w2 = (b4,b5)
'w3 = (b6,b7)
'w4 = (b8,b9)
'w5 = (b10,b11)
'w6 = (b12,b13)
'w7 = (b14,b15)
'w8 = (b16,b17)
'w9 = (b18,b19)
'w9 = (b20,b21)
'w10 = (b22,b23)
'w11 = (b24,b25)
'w12 = (b16,b17)
'w13 = (b26,b27)
'b0 = (w0)curr_in_wants_lock
'b1 = (w0)prev_in_wants_lock
'b2 = (w1)is_unlocking
'b3 = (w1)
'b4 = (w2)
'b5 = (w2)
'b6 = (w3)
'b7 = (w3)
'b8 = (w4)
'b9 = (w4)
'b10 = (w5)
'b11 = (w5)
'b12 = (w6)
'b13 = (w6)
'b14 = (w7)
'b15 = (w7)
'b16 = (w8)
'b17 = (w8)
'b18 = (w9)
'b19 = (w9)
'b20 = (w10)
'b21 = (w10)
'b22 = (w11)
'b23 = (w11)
'b24 = (w12)
'b25 = (w12)
'b26 = (w13)
'b27 = (w13)
'************************************************** This part only runs once, when powered up**********************************************
setfreq mdefault
symbol in_wants_lock = pinC.4 ' pin 3 : input: hi = lock, lo = unlock
symbol in_cam_switch = pinC.3' pin 4 : input: hi = motor moving, lo = motor cam reached hole, stop motor
symbol out_power = C.2 ' pin 5 : output: hi = apply power to motor through Q5
symbol out_short = C.1 ' pin 6 : output: hi = apply short circuit to instantly stop motor via Q4 (after C.2 lo)
symbol out_direction = C.0' pin 7 : output: hi = motor A direction relay (unlock)
symbol curr_in_wants_lock = b0' check if the desired position has changed, and take action only when it changes
symbol prev_in_wants_lock = b1
symbol is_unlocking = b2
symbol relay_allowance_time = 250' wait after switching relay
symbol cam_read_delay = 500' wait after starting motor before reading state of cam input to allow the microswitch to move
symbol motor_short_time = 500' apply short to motor to stop it quickly
symbol motor_lock_stop_delay = 75' motor wants to run a tiny bit longer after switch is lo to stop proerly in cam when locking
symbol motor_unlock_stop_delay = 75' motor wants to run a tiny bit longer after switch is high to stop proerly in cam when unlocking
pause 2000' allow time after powering up to reprogram before reaching disconnect
'disconnect' allows use of pin 7 as an o/p....possibly not needed if selectable link used on pin 7
' if used, PIC requires a hard reset (i.e. power disconnect) before re-programming
prev_in_wants_lock = in_wants_lock
'************************************************** This part only runs once, when powered up**********************************************
main:
curr_in_wants_lock = in_wants_lock
if curr_in_wants_lock = 0 and prev_in_wants_lock = 1 then
gosub unlock
end if
if curr_in_wants_lock = 1 and prev_in_wants_lock = 0 then
gosub lock
end if
prev_in_wants_lock = curr_in_wants_lock
goto main
end
unlock:
high out_direction' set relay to unlock position
pause relay_allowance_time' wait for relay to move
is_unlocking = 1
gosub run_motor' run motors until cam switch is low
low out_direction' put realy back to low position
pause relay_allowance_time
return
lock:
low out_direction' make sure relay is in correct position for locking
pause relay_allowance_time
is_unlocking = 0
gosub run_motor' run the motors until cam switch is low
return
run_motor:
high out_power' start running the motor
pause cam_read_delay' wait a bit for cam switch to be pressed before checking for it to go low again
do while in_cam_switch = 1' wait for cam switch to change
loop
if is_unlocking = 1 then
pause motor_unlock_stop_delay
else
pause motor_lock_stop_delay
end if
low out_power' remove motor power
high out_short' apply short to motor to stop it quickly
pause motor_short_time' wait for motor to stop
low out_short' remove short
return
'#terminal 4800' opens terminal window after download

 

[The bear]

Thank you for the code.
It's too involved for me.
I did notice that you have 4 Gosubs and 3 Returns
Also an End on line 90

On a brighter note, I'm sure help will arrive soon.

 

[davidwf]

indeed....but two of the gosubs are to the same place..... line 110 & 115 both go to run motor line 126.....

 

[Buzby]

4 gosubs and 3 returns is no problem, because one sub is called twice, quite a normal use of subs.

From your description it's unclear what the trigger switch is. Is it a toggle switch with defined on/off positions, or is it a momentary pushbutton that only 'makes' when pressed ?

If it is a pushbutton, then the first change I would make to the code is to replace the 'curr_in_wants_lock = in_wants_lock' with some 1-Shot edge-triggered code. This would ensure no funnies happen if the pushbutton is held in too long.

Regarding the motor stopping between cam slots, this reason for this is more tricky to deduce without the actual hardware. This condition could easily be detected by a timer and the state of the cam switch. I would expect to flag some error if this happens.

While the code is quite well structured and appears to work perfectly as long as all the I/O does the right thing at the right time. However, years of industrial programming has taught me that nasties will occur when the I/O dosen't follow the rules 100% of the time. I've run your code in the simulator. I triggered C.4 and the code ran through without any confirmation that the cam switch had actually changed in any way. Again, this condition should trigger an alarm of some kind.

The sign of good industrial programming is that it runs the plant, but also tells you when the plant is not behaving as expected, and then does its best to prevent damage.

Personally I would use a 14M chip, just so I had more I/O to drive status and alarm LEDs. Then I would write the code as a state-machine which only moves from state-to-state at well defined conditions. This technique makes debugging, and display of runtime status and faults, so much easier.

 

[davidwf]

Thank you.....
the switch is a pushbutton rocker switch like this and I am using the n.o. contact to trigger it...i.e. when the switch OPENS, R3 pulls the input high (PIC pin 3) this, along with the de-bounce code in "main" I felt would alleviate any switch bounce problems
The thing I cant get my head around is how it APPEARS to change state correctly and therefore is detecting the change to the input/trigger but there is no o/p on pins 5 and/or 6.....how can that be.......

Is there any preference in the way I attached the code - screen dump or copy/paste ?

 

[administrator]

Erratic behaviour is often electrical noise or power supply collapses - is the regulator powerful enough for the job?

Shorting the motor will put quite some noise on the power rails which could be causing an erratic restart, despite the capacitors you have (correctly) already added. As a test rig you could try a bicolour LED in place of the motor to remove the motor from the system - does it then work 100%?

Also try a flashing LED sequence or similar at the start of the code so you can easily visually tell when a reset occurs.

 

[Buzby]

Here is my take on the code. It's not really a state machine, it's a sequencer.

Because the code moves from step to step on simple conditions, it's easy to add debug code or drive status LEDs, if you had more I/O pins !.

The error detecting can be done by counting loop executions of the relevant steps, with errors if the count is too high or too low for the expected value.

#simspeed 100
#picaxe 08m2

'  +++++++++++++++++++++++++++++++
'  ++++ State machine version ++++
'  ++++       by Buzby        ++++
'  +++++++++++++++++++++++++++++++

' sliding carport door lock
' operates via indoor switch
'pin i/o function
'1  pwr V+
'2  c.5 serial data in (for programming)
'3  c.4 in from open/close switch (lo unlock, hi lock)
'4  c.3 in from motor cam positioning switch (hi out of position, lo in position)
'5  c.2 out to motor run
'6  c.1 hi to stop motor by shorting it out via Q4
'7  c.0 serial data out (for programming) shared with direction relay
'8  pwr 0V

' I/O
symbol control_switch = pinC.4     ' pin 3 : input: hi = lock, lo = unlock
symbol cam_switch     = pinC.3    ' pin 4 : input: hi = motor moving, lo = motor cam reached hole, stop motor
symbol out_power = C.2              ' pin 5 : output: hi = apply power to motor through Q5
symbol out_short = C.1              ' pin 6 : output: hi = apply short circuit to instantly stop motor via Q4 (after C.2 lo)
symbol out_direction = C.0        ' pin 7 : output: hi = motor A direction relay (unlock)

' Variables
symbol cam_drop_error   = bit29
symbol cam_lift_error   = bit30
symbol cam_state_error     = bit31

' Constants
symbol relay_allowance_time = 25        ' wait after switching relay
symbol cam_read_delay = 500            ' wait after starting motor before reading state of cam input to ensure microswitch has operated
symbol motor_short_time = 500            ' apply short to motor to stop it quickly
symbol motor_lock_stop_delay = 45        ' runs motor a tiny bit longer after switch is lo to stop properly in cam when locking
symbol motor_unlock_stop_delay = 75        ' runs motor a tiny bit longer after switch is high to stop properly in cam when unlocking

' -----------------
' Code starts here
' -----------------
setfreq mdefault    ' Not sure what mdefault is, its not in the manual.
pause 2000                ' allow time after powering up to reprogram before reaching disconnect
disconnect                ' allows use of pin 7 as an o/p....possibly not needed if selectable link used on pin 7
' if used, PIC requires a hard reset (i.e. power disconnect) before re-programming

' Main loop
do
State_0: ' Cam in slot, door unlocked. Wait for switch
    do
        if cam_switch = 1 then : cam_state_error = 1 : gosub error_handler :endif   
    loop until control_switch = 1 ' Switched to 'lock'

State_1: ' Cam in slot, locking started. Wait for cam lifted   
        high out_direction ' Lock direction
        pause relay_allowance_time
       
        high out_power    ' Start motor
        pause cam_read_delay
    do
       
    '   
    ' put some code here to detect cam lift taking too long    
    '   
   
loop until cam_switch = 1 ' Rotor has moved, cam is lifted
   
    '
    ' put some code here to detect cam lifted too soon
    '
   
State_2: ' Motor running locking. Wait for cam in slot   
    do
       
    ' put some code here to detect cam drop taking too long   
           
    loop until cam_switch = 0 ' Cam in slot

State_3: ' Motor running locking, cam in slot. Delay to allow cam to settle
    pause motor_lock_stop_delay
   
    '
    ' put some code here to detect cam dropped too soon
    '
   
State_4: ' Stopping lock
    low out_power            ' remove motor power
    high out_short            ' apply short to motor to stop it quickly
    pause motor_short_time        ' wait for motor to stop
    low out_short            ' remove short
    low out_direction            ' reset direction

State_5: ' Cam in slot, door locked. Wait for switch
    do
        if cam_switch = 1 then : cam_state_error = 1 : gosub error_handler :endif   
    loop until control_switch = 0 ' Switched to 'unlock'

State_6: ' Cam in slot, unlocking started. Wait for cam lifted   
        low out_direction ' Lock direction
        pause relay_allowance_time
       
        high out_power    ' Start motor
        pause cam_read_delay
    do   
        '
        ' put some code here to detect cam lift taking too long
        '
       
    loop until cam_switch = 1 ' Rotor has moved, cam lifted

State_7: ' Motor running unlocking. Wait for cam in slot   
    do   
        '
        ' put some code here to detect cam drop taking too long
        '
       
    loop until cam_switch = 0 ' Cam in slot

State_8: ' Motor running unlocking, cam in slot. Delay to allow cam to settle
    pause motor_unlock_stop_delay

        '
        ' put some code here to detect cam dropped too soon
        '
   
State_9: ' Stopping unlock
    low out_power            ' remove motor power
    high out_short            ' apply short to motor to stop it quickly
    pause motor_short_time        ' wait for motor to stop
    low out_short            ' remove short
    low out_direction            ' reset direction
   
loop
' -------------------------------
error_handler:
' Put stuff here to handle errors
return

 

[davidwf]

thanks..... the motor isnt reaching the stop state when it fails, also the "stopping" arrangement is working perfectly well in another lock and I have pretty much isolated the motor supply.....the problem seems to be that although the input is clearly triggering the PIC, it is not outputting that to the rest of the circuit

 

[inglewoodpete]

A few thoughts.

The wiring for the motor and its controlling MOSFETs needs to come directly from the power source and a separate pair of power wires provided from the power source for the 5 volt regulator and the associated 5v circuitry. Current surges in the microcontroller's power feed wires can introduce poth positive and negative spikes to the chip, causing unwanted resets.

As far as I can see, you have not specified which MOSFETs you are using. Many will not turn on fully (Ie RDS will still be quite high) with just 4.5 volts (from the PICAXE output) on their gate. If that is the problem, you will need to change them to logic-level MOSFETs. Check the VDS across each MOSFET when the PICAXE tries to turn them on.

To debug your hardware (if this is the problem), write a short piece of code to turn each output on and off in a loop for, lets say, 5 seconds on and 5 seconds off.

 

[AllyCat]

Hi,

Is there any preference in the way I attached the code - screen dump or copy/paste ?

Preferably, IMHO as a "Plain Text" copy listing of the full program (i.e. from the PE) within [code ] [/code] tags (no spaces inside the [ ] ), which may also prevent the indentation vanishing. Then we can quickly "scan" the program structure, or ignore it, or cut and paste it into a PE window (and PE5 can be very quick ), to run in the Simulator.

Personally, I've not looked at your problem in detail, but agree with Buzby, Admin (Technical) and Pete that the Program should monitor what the external hardware is actually doing (not what you think or hope it is) and be prepared for random voltage (or current) "spikes" to appear anywhere in the system. If necessary, there are several tricks to squeeze more digital inputs into a humble 08M2, for example using the Programming input pin (C.5), or combining several digital signals with resistors (of different values) to drive an ADC input (which can include C.0).

Cheers, Alan.

 

[davidwf]

Thanks...
as per the diagram, Q1 and Q5 are STPNF5506L which are logic level MOSFETS, Q2 and 3 are ZVN3306A with gate voltage of around 3V, Q4 is IRF9530 / 4PP04L03 P chan with 5 to 12V conversion via Q3
The actual motor drive / reverse / stop circuitry has been in use in 2 similar projects for over 3 years with no issues whatsoever, the only difference being that it uses an 18M2+ PIC running at 3.3V .....which of course shouldnt make any difference.
The 5V reg is rated at 100mA, well within the PIC demands I feel

 

[Technical]

Actually 18M2 versus 08M2 can make a difference if erratic motor noise is involved (as we still suspect from 'motor stopping halfway' comment) as all i/o are now on one port (instead of 2 ports with 18M2).

In particular the cam switch is on C.3, and, if we understand correctly, is high (electrically connected) when motor is moving, so providing a noise path. First thing we would add is a diode between the C.3 pin and 5V (pointing to 5V) as this is the silicon MCLR pin that does not have this diode internal to the silicon (as with other i/o).

 

[davidwf]

ooooerrrr....whilst I highly respect your help and advice this is getting complicated....

although not wishing to ditch the PICAXE method, I do need a reliable one so maybe the attached would be better in this instance.....it still uses the all important 3 wire connection with the switch internally and RL1 will trigger for a short period (values may need tweaking slightly) at either polarity of the direction switch.... I used a relay RL2 instead of a DPCO switch so we can keep the same toggle switch that we have.....
I THINK this would work

 

[The bear]

Hi David,
I'm very pleased that help has arrived in abundance.
Apologies for the gosub - return incorrect statement.
Good luck......

 

[Bill.b]

Hi All.

I built a similar locked several years ago. I used a 12V Linear Actuator same as this one. It has built in limit switched on both extend and retract cycle. No need for DC breaking or any fancy electronic to drive it. I used a picaxe 08m2 and a H bridge driver (here) to control the motor, the logic is very simple.

Bill

 

[davidwf]

thanks....I have looked at those but discounted their use as they are just too slow (you have to hold the door whilst they operate)...and quite pricey !

 

[AllyCat]

Hi,

Sorry for a very late response, but looking at the hardware diagram in #1, there is a dotted line between "Indoors" and "Carport" with connections labelled Brn, Grn and Blu. That looks suspiciously like a mains-type connecting cable (if so, how long is it?) which might be an issue because there will be some "stray" capacitance between its wires, and maybe significant inductance as well. In particular, the Grn wire is shown to go directly to a pin on the PICaxe, with a terminating (pullup) resistance as high as 10 kohms (when the switch is open). It's generally recommended to put a resistor (typically 100 ohms - 10k) in series with any signal path entering a circuit/PCB from the "outside world". This resistor should be located near to the PICaxe pin (as should be D101, not essentially a Schottky type) with ideally a capacitor (of some nF) to ground, to create a low-pass filter.

Admittedly in this application, there don't seem to be any particular reasons for "spikes" of voltage (or current) to appear on the cable, but large components like the battery and 1000 uF capacitor are not going to suppress any high frequency interference. In principle, any "long" wire should be considered as a potential antenna (aerial), and also it can be significant whether one or both ends of the "0v" cable are (or are NOT) connected to "Earth/Ground" (which can include stray capacitance of a metal enclosure, or a human being, etc.).

In principle, the program does the "right thing" by copying the input (lock/unlock) signal into a "flag" register and processing that within main: . However, when that loop is "idle" (i.e. no changes in its working status) the loop cycles in around 5 ms, so there could be around 200 "opportunities" every second for a "spike" (disturbance) to enter the system. If you can't (or don't want to) make any changes to the hardware, you could simply see if a PAUSE 50 in the main loop helps, or better, add a "Majority Decision" to the external "Lock/Unlock" signal: For example changing the curr_in_wants_lock = in_wants_lock" to : b0 = pinC.4 + pinC.4 + pinC.4 / 2 ; Majority Decision for "Want Lock". For clarity/compactness I've omitted the (IMHO overly-long) symbol names, but the line could be split into separate instructions (with the option of PAUSEs in between) to give lower-frequency filtering. Note that a majority decision must be made on independent data (here separated in time), so changing it to b0 = pinC.4 * 3 / 2 would NOT be a simplification/improvement.

If building that circuit design myself, I would move the "Request In" (C.4) signal to C.5, that with a few tricks can avoid the need for any "Programming Configuration" switch-links*. Then, the motor control output can be moved from C.0 to C.4, avoiding the need for a pin-switch header there, and releasing C.0 for debugging signals (e.g. sending SERTXD data to the PE), or simply a couple of signal LEDs. Also, C.0 can be used as an analogue input, particularly convenient for making current measurements (e.g. from the motor), by monitoring the voltage across a low-valued resistor connected to ground. This need not disturb the SERTXD output idle logic level, and can even monitor bi-directional current flows, by introducing a "bias" current from the PICaxe's high impedance internal "DAC" on that pin.

* Note that the comment in the program to a DISCONNECT affecting the C.0 Programming Output is a mistake. That instruction causes any Programming Input request (on pinC.5) to be Ignored, but a well-designed program could have the capability of executing a RECONNECT before terminating.

Cheers, Alan.

 

[davidwf]

Thank you for your detailed response.....
unfortunately and because I couldnt get it to work as desired I have decided to go with a more simplistic approach which seems to be working OK and attached FYI
The connections are indeed a piece of 3 core mains cable but only around 3m in length, the motors taking only around 300mA
Your comments and advice are however gratefully received and will certainly help in any future designs.....what was the reasoning behind moving the connections on the PIC - are there differences / preferences ?

 

[AllyCat]

Hi,

... a piece of 3 core mains cable but only around 3m in length,

Ah, a little more than the length of a quarter-wave antenna for 27 MHz (CB radio and Remote Controlled toys). And you had a few diodes around to help detect the carrier. I remember the time when I could hear BBC TV (Band 1, 39 MHz) picked up directly on the Loudspeaker cables, with the audio amplifier switched OFF !

...what was the reasoning behind moving the connections on the PIC - are there differences / preferences ?

Basically to enhance the "Diagnostics" capabilities - e.g. Interfacing with the Program Editor, adding Signal LED(s) and continuously monitoring the motor drive current. Any two of these are possible concurrently on pin C.0, whilst none on pin C.5 (no Output nor ADC capabilities).

The 08M2 has 6 "signal" pins (plus supply and ground) but only three (C.1, C.2 and C.4) are "General Purpose I/O" (also with an ADC input capability), so they are usually the first to allocate. But almost all the pins have some "unique" features, so sometimes an application may almost configure itself (some "advanced" features will be shown in italics) :

Pin C.2 is the only pin which supports a PWM output, so is the obvious choice for driving a motor or LED if speed or brightness might need to be controlled. It's also dedicated to some other specific internal hardware facilities.
Pins C.1 and C.2 are the (dedicated) I2C Bus lines, which can interface with many sensors, displays and external memory, etc, potentially all "at the same time" (i.e. within the same application). Thus Pin C.4 may be the first to allocate for any non-dedicated requirement.
Pin C.3 is (Digital) "Input Only" (because it's the Master Reset/Programming pin on the base PIC silicon), so is the obvious choice for any digital input (since it's not much use for anything else). It's the only pin which can be driven higher than the supply rail (with care ! ) because it doesn't have an "electrostatic protection" diode to the supply rail.

The other two pins are nominally for Programming the PICaxe , one "Input Only" (C.5) and one "Output Only" (C.0), but they are also useful for debugging at any time. Specifically the DEBUG instruction, but it's normally far better to use SERTXD (transmit) and SERRXD (receive) signals to/from the Program Editor (Terminal Emulator). A useful trick is to transmit the Program Name, Version Number and Programming Date in ASCII text when the Program boots up.
Pin C.0 is the only pin that is enabled as an Output when the PICaxe starts up, which may be an advantage or a disadvantage. It's the only available option if a fourth "full current" Output pin is required, but the application may need to take precautions (e.g. a header-pin-link switch, or NOT to control a "power" component like a Motor, Relay, Light or Loudspeaker) to tolerate the pulses transmitted during Programming. Actually, it's not strictly (Digital) "Output Only" because it can be allocated to the DAC, which has such a high output impedance that it can be used as a "Tri State", or an Analogue Input (using the READDAC command).
Pin C.5 is physically a digital I/O pin (no ADC), but the PICaxe Operating System will stamp on any attempt to use it as an output, so it is effectively "Input Only". It can be useful if an additional input is required, but some care is needed in preventing the Application and Programming signals interfering with each other (obviously a pin-link/switch is one possibility) :

A trick I have employed, inserts a pull-down diode as shown in your diagram in #1 (in that case, to Leg 3) : To Program the chip the "Want Lock" switch would need to be open (and pulled High) so that the diode is reverse biased, but the (10k) pullup resistor NOT fitted (because it could prevent the PICaxe booting up). For "Application Mode", the Program initiates a DISCONNECT command (to avoid a Programming cycle starting when the input pin is taken high) and then a PULLUP Var (e.g. b1) instruction to enable the internal Weak Pullup resistor on C.5. Var = 32 is necessary to trick the compiler into pulling C.5 high, and it may be necessary to increase the 10k and/or 22k programming resistors, to ensure that the pin voltage is pulled sufficiently high to inject a Logic 1 reliably. Then, the remote switch can pull the input Low, via the diode, when required. Ideally, the Program would command a RECONNECT (for example on receiving a character via SERRXD) to simplify reprogramming (without the need for a Hard Reset).

Thus the 08M2 nominally has up to 4 Outputs (or 3 I/O for applications such as the I2C Bus or READTEMP) and 2 inputs. However, all 6 pins can be used as Inputs or as Outputs (C.3 and C.5 only at low current by activating the internal Pullup resistors), but applications which only "Talk" or only "Listen" are (fortunately) quite rare.

Cheers, Alan.