Pic 16F628A Output being an Input

[@rt]

Hi Guys
The last couple of days I completed a project with two microcontrollers, one of which is to send a signal to the other,
which is simply a high or low state from one IO pin to another. Both chips happen to use PortA, bit 0 for the communication.

All code was working properly except I had mistakenly left the input pin on one chip as output.
The chip that was supposed to receive on PortA, bit 0 has it’s TrisA register cleared to set all eight bits as outputs.

When testing the chip that receives on PortA, bit 0, I wired a SPDT switch to send the IO pin hard high or low.
The chip still received the input correctly and could change state in real time depending on the input state of PortA, bit 0.
The output did not work as input if I tied it high with a 10K resistor and tried to control it with a SPST momentary switch,
it had to be alternately tied to Vcc or Vdd to switch. I did not try timing low with 10K resistor and sending a high signal.

Can someone explain internally what is happening there?
Cheers, Brek.

[mikerj]

When you read the PORTx register on a PIC, you are reading the logic level on the pins, not the logic levels that the data latch is set to.  By using a switch tied to ground/5v, you are sinking and sourcing far more current than the output latch can handle and forcing the voltage high or low.  This is not a good idea in general.  Note that this is why setting pins using read-modify-write instructions (e.g. BCF or BSF) can cause odd things to happen such as other pins changing state unexpectedly; the pin values get read, one bit is modified and the resulting value is written back to the data latch.

The pins on PICs can actualy source and sink a reasonable amount of current (~20mA).  If the pin was set as an output, and set to a logic 0 state then a 10k pull-up resistor won't source enough current (5/10000=0.5mA) to change the voltage on the pin by any significant amount, so the pin remains at a logic 0 state.

Pull-up/pull-down resistors are only of use when the circuit they are pulling up/down is a high impedance one (e.g. the PIC pin is configured as an input).

[Ian.M]

Overloading an I/O pin configured as an output is *NOT* a good idea.  PICs are fairly forgiving, and under most circumstances the Rds_on of the pin driver MOSFETs will limit the current to less than the abs. max. ratings, but that's far from guaranteed and even if it does no immediate damage, it stresses the chip, reducing reliability.   The only time the fact that it actually reads the pin level can be useful is reading back the PORT bit for the pin to detect an overloaded output so it can be quickly disabled to protect it.

[Bruce Abbott]

When testing the chip that receives on PortA, bit 0, I wired a SPDT switch to send the IO pin hard high or low.
The chip still received the input correctly and could change state in real time depending on the input state of PortA, bit 0.
The output did not work as input if I tied it high with a 10K resistor and tried to control it with a SPST momentary switch,
it had to be alternately tied to Vcc or Vdd to switch. I did not try timing low with 10K resistor and sending a high signal.

So you have the pin configured as an input, but it won't see a high signal unless it is connected directly to Vdd?

Perhaps the pin is partially shorted to Vss internally, causing it to be pulled down. Have you measured  the voltage on the pin with just a pullup resistor? (should be close to Vdd). Which port pin are you using, and what happens if you use a different pin?
   

[mikerj]

So you have the pin configured as an input, but it won't see a high signal unless it is connected directly to Vdd?

The OP said he had mistakenly configured a pin as an output when it should have been an input.

[@rt]

Yes that’s right and I think I understand. I never knew that’s why RWM errors happen...
always thought the value from reading the port was from the latch memory your program set it to.

Obviously once correcting the error of setting an input to an output, I can now do it a more traditional way.
Thanks for the replies

[@rt]

Dave’s last video powering a microcontroller with other pins has some uncanny timing for me
It’s not exactly a trap for young players in this case, if I were weary the whole time what I’m doing.


I have the supply of each chip connected to a single computer’s mouse and keyboard power supply.
If I started the other computer first, it would try to power the micro, and the mouse and keyboard,
all through it’s cock and data pins that usually connect to a keyboard and mouse.
So that’s why I have to turn one computer on first, and not use the second computer without the first being powered.

Just being aware of the issue doesn’t mean I think I have an ideal solution (aside from adding a power supply for the chips).
One thought I had was using extra hardware such as a 4066 to switch out the inactive computer’s IO pins,
but adding more ICs to load the keyboard and mouse ports doesn’t sound like a great idea either.

[FrankBuss]

Note that this is why setting pins using read-modify-write instructions (e.g. BCF or BSF) can cause odd things to happen such as other pins changing state unexpectedly; the pin values get read, one bit is modified and the resulting value is written back to the data latch.

This is the reason modern PICs have a latch register, like LATA for the PIC12F1840. It reads always what you've written to it, not the voltage level of the output pins. Good idea to use these registers for read-modify-write instructions.

[Ian.M]

I have the supply of each chip connected to a single computer’s mouse and keyboard power supply.
If I started the other computer first, it would try to power the micro, and the mouse and keyboard,
all through it’s cock and data pins that usually connect to a keyboard and mouse.
So that’s why I have to turn one computer on first, and not use the second computer without the first being powered.

Just being aware of the issue doesn’t mean I think I have an ideal solution (aside from adding a power supply for the chips).
One thought I had was using extra hardware such as a 4066 to switch out the inactive computer’s IO pins,
but adding more ICs to load the keyboard and mouse ports doesn’t sound like a great idea either.

If your keyboard and mouse ports cant stand the extra 6mA or so draw from the 5V line that powering both PICs would require, then you really have got a problem.  However, if each port can supply 6mA extra without harm, then simply power the PICs by four Schottky diodes, one from each port combining the 5V supplies such that the PICs are always powered if either computer is on, and the keyboard from two more diodes combining the keyboard ports and so on for the mouse.  Add pullup resistors from each computer's 5V line to input pins on one of the PICs.  That PIC then can detect whether either computer isn't powered and tristate the I/Os going to the unpowered computer + signal the other PIC to do the same.

In the event that you cant risk a 6mA load on the 5V line of any of the ports, you'll have to go with your 4066 idea, only again the 4066 must be powered via Schottky diodes by both computers.  The switch control lines would be driven through a 10K resistor from the 5V supply of the associated computer.  As the quiescent current of a 4066 is at the uA level, the extra loading on the ports would be negligible

[@rt]

Thanks for the advice It might be a good idea for me to check in here before I change something.
The mouse port is 100mA, and since the optical mouse is 100mA, adding a pic to that was already pushing it.
The keyboard port, though I can’t find it in writing right now I recall being 200mA, and the keyboard only draws 60mA.
So it already seems it would be good to combine these ports!

[ConKbot]

Yes that’s right and I think I understand. I never knew that’s why RWM errors happen...
always thought the value from reading the port was from the latch memory your program set it to.

Obviously once correcting the error of setting an input to an output, I can now do it a more traditional way.
Thanks for the replies

Yep, but it doesnt have to be something as obvious as overpowering an output by connecting it directly to VDD or VSS.  If you do two quick successive operations on the same port driving a capacitive load, you can get RMW errors.
I.e. if you
BSF PORTA, 1
BSF PORTA, 2
and RA1 hasnt made it above the input high threshold yet, when the micro reads port A for the second BSF operation, it will be re-written as a 0.  As stated, the LATx registers address this problem. Much more convenient then having to manage your own "ghost" register and copying that to the port to avoid doing RMW operations directly on the port.

[SeanB]

Mouse is typically 30mA, it only says 100mA as that is a single USB load, it will draw under 20mA when inactive ( light is dim from not moving for 20 seconds) and will do at most 50mA in pulses. All USB ports will supply 150mA without any issues, simply because they either do not have current limiting, or the limit is set so it does not trip out on a connection. 500mA in theory requires USB enumeration and a request for full power, but most powered hubs will supply 500mA without this, and typically they will be protected ( like the mainboard in non price overoptimised computer mainboards) with a 1A polyfuse.

[Ian.M]

You obviously skipped the video.  This gadget is a custom KM switch for Commodore Amiga computers, not a USB port in sight!   The mouse outputs quadrature X and Y signals on four wires llike an old Microsoft Inport bus mouse, and as early optical mice could be rather power-hungry, the 100mA figure is quite possible.

[@rt]

If you plug a mouse into a serial port where is the modem supposed to go?
I can only come out better off for writing for a computer like Amiga for a while.

The 100mA mouse port I have recently found in the service manual, but what I think is 200mA from the keyboard port
could still only be my imagination. It’s got a pinout in the service manual too, but doesn’t give max current draw from that port.
It’s immediately beneficial to swap the two peripheral’s supply pins powered by the ports (keyboard/mouse) if the 200mA is correct.
The schematic is available, and I will dig into that soon and see if that gives away an answer

Yes the PS/2 keyboard and mouse are both translated, I’m not responsible for that programming,
just duplicating the output ports and switching between them with a bit flag, and handling some silly unexpected stuff.
I understand both mouse protocols now, but not everything about the keyboards.
The idea with the diodes sounds good if the current is there. The pic/s should be able to tell if one of the computers is off,
so the switch should never switch the peripherals to a computer that’s powered off.

[Ian.M]

The case I am concerned about is if the keyboard cable has come loose from one computer and the other is off.  Then the whole load would be on one mouse port 5V line.

I think the best solution for that would be to use a high side P channel MOSFET controlled by the PIC to switch power to the PS2 keyboard and mouse.  That way, if a cable is loose, it can detect the missing supply and shed load to avoid blowing the remaining port.

[@rt]

Ah yes, that is less likely to happen right now with the mouse & keyboard chip almost seperate,
at least with use of current limit resistor for the signal connection between them.
but mixing the supply with the diodes would do that.

I’m up for it though. Using an external supply to fix things seems a copout unless the supply current just isn’t there.
There are ways to find out the keyboard current looking at other Amiga model manuals,
or estimating the requirements of the (Hitachi?) controller in the real keyboards, or looking for a sticker on the bottom of a real keyboard.
I’ll get to that tonight!

[Bruce Abbott]

The CD32 mouse port has a 4.7 Ohm resistor in the +5V line, so voltage will drop as current increases. I would just leave that pin disconnected and get power from the keyboard socket only. Keyboard power is connected directly to +5V inside the CD32, so you shouldn't have any problem drawing 100~200mA from it.  Put a Schottky diode in each keyboard power line to prevent one computer from trying to power the other. Use high current diodes (3A+) for low voltage drop.

Both mouse and keyboard signals lines have pullups and should be used with Open-Collector / Open Drain drivers. To create these outputs, send your data to the TRISIO registers instead of PORT registers. This causes each pin to be an input when the bit is a '1', and an output when it is a '0'. TRISIO bits can be manipulated at will without concern over what voltages are on the port pins. 

Open Collector drivers only pull down, so no current will flow into the Amiga's signal lines when it is switched off and you won't need any extra chips to isolate them.
 

[@rt]

Thanks Bruce How do you know this about CD32?
I suspected the keyboard port might be a better supply as it is designated for “keyboard and other peripherals”.
It still might still be a good idea to investigate a regular Amiga keyboard supply for possible help to others.
I was planning to put it all back in Aminet public domain.

This was to tell you you’re wrong, but it turns out FBxxx is a ferrite bead