Direction Of Ports. Can they be changed on the fly?

[mkstevo]

Hello. In a program I have the following code:

    Dir     Up_Sw         In
    Dir     Dn_Sw         In
    Dir     L_Sw          In
    Dir     R_Sw          In
    Dir     OK_Sw         In

I'm running short of pins and I thought I could reuse some of the switch inputs as data outputs.

    Dir     OK_Sw         Out 'Now send data
    Let Ok_Sw = 1
    Wait 500mS
    Let Ok_Sw = 0
    Wait 500mS

Could I re-declare the inputs as outputs in code, send some data out, then re-declare them again as inputs again to read the state of the switches again?

    Dir     OK_Sw         In 'Read Switch
    If Ok_Sw = 1 Then
        Let SwitchPressed = 1
    End If

[Anobium]

You can set the direction as you need. The compiler will handle the changes.

[mkstevo]

Thanks. It was changing them as the program ran that concerned me, I was more concerned that the processor wouldn't be able to handle ports changing between inputs and outputs repeatedly than I was about the compiler.

Didn't want to try in case the magic smoke escaped...

[Anobium]

oh. that depends on input protection etc... I will let others advise on input protection.

[William Roth]

Consider that a port is an INPUT and a "high" is applied to the port. Then the port is changed to output .... The port will then sink as much current as sourced by the applied High signal. If the applied high signal is VDD with no current limit there could be smoke or damage.

Therefore make sure that there is current limiting to prevent smoke or damage. A 200R to 1K resistor in series with the pin will usually work ok

[mkstevo]

Thanks for the suggestions. I try to ensure that all output pins have a series resistor of at least 100R if they interface directly to the 'outside world', for disaster prevention. Especially where an end user is expected to connect things up, or make interfacing wires. I've seen too many devices damaged beyond repair by the lack of any consideration to current limiting.

I meant to say that I didn't want to try assigning a port that had previously had it's direction set as 'In' into an 'Out' in the event that the processor itself became unhappy at switching between one and the other.

I can let the magic smoke out all by myself, never mind having the processor do it all by itself. Where's the fun in that? Mind you, I wonder how environmentally 'unfriendly' that smoke is? Best to try to keep it in. Don't want to cause a hole in the ozone layer...

[mkstevo]

I was thinking of possibly using some 74HC595 serial in/parallel out shift registers in conjunction with some 74HC165 parallel in/serial out shift registers. I had the idea that I could use one data line for the data out (to the 74HC595) while using the same line for the data in (from the 74HC165). Using the Chip Enable line with an inverter that would alternate between enabling the two devices when the CE line is driven High or Low.

I use some cascaded 595's to drive some seven segment displays and I'd like to add some input devices to this so came up with the idea of using the 165's. I then began to wonder if I could use the same Clk, Data and Latch lines for both, saving significant pins on the processor. I could drive four seven segment displays and read the state of eight inputs with no additional overhead on ports. If it works...

I'll give it a try when I get the time to experiment.

[stan cartwright]

mkstevo. There's serial to parallel chips but obviously slower but useful. some have interrupt pins to say if a data line has changed. http://uk.farnell.com/microchip/mcp23017-e-sp/ic-io-expander-16bit-i2c-28dip/dp/1332088?mckv=5JqcDtNx_dc|pcrid|78108376749|&gross_price=true&CATCI=pla-131222015829&CAAGID=14983511589&CMP=KNC-GUK-GEN-SHOPPING-MICROCHIP&CAGPSPN=pla&gclid=CjwKCAjwssvPBRBBEiwASFoVd-0r4IrH8hYp_kSCztYIRoK2lrrPYSSbjzj76lrsl71VjoBZ9el5NhoCD5wQAvD_BwE&DM_PersistentCookieCreated=true&CAWELAID=120173390001317605
I bought some but haven't used them yet.

[mkstevo]

That might be useful, but the interrupt might need another input pin on the PIC? Plus, I'm a fan of simplicity. It took me all day to correctly decode the data from the 74HC165...

[mkstevo]

So, to summarise, I have been able to utilise a port as both input and output.

I have four 74HC595's connected to a 12F675, the first serial data in (Pin 14 of the 595) connects to Pin 3 of the PIC [the rest of the 595's are cascaded from this one by connecting Pin 9 of number one to Pin 14 of number two, then 9 of two to 14 of three, finally 9 of three to 14 of four), the clock (Pin 11 of all 595's) connects to Pin 2 of the PIC, the RCK (Pin 12 of all 595's) connects to Pin 5 of the PIC. I also have one 74HC165 connected to the 12F675, data out (Pin 7 of the 165) connects to Pin 3 of the PIC with a 1K series resistor in the 165 'end' of the connection to prevent the PIC from being overloaded when driven as an output, the load pin (Pin 1 of the 165) connects to Pin 5 of the PIC, Clock (Pin 2 of the 165) connects to Pin 6 of the PIC.

This gives me a four element, seven segmant, LED display, driven by the four 595's and an eight line input port connected to the 165, all driven from just four pins of the PIC. I was going to gate the data line feeding the 595's to prevent data being read from the 165 being loaded into the 595's but realised it would be much easier to use separate clock lines.

My displays are updated segment by segment, during the 'gap' between segment updates, I can change the data line to an input, read the state of the input port then return the data line to an output to send the next segment to the display.

This is just what I wanted.