Printable View
In TTL logic an input lower than 0.8 volts is seen as logic zero. Does this apply to pic inputs ports as well ? In the data sheet, I could not find any information regarding the voltage threshold level needed to trigger the high logic state on the input port.
I need to know which is the minimum voltage level capable to trigger an interrupt.
Thanks for the answer.
Al.
It depends on which interrupt you are triggering.
For INT on PORTB.0, it's a schmitt trigger input.
For PORTB change on RB4-7, they are TTL levels.
Levels for both types are listed in table 17.2 DC Characteristics as VIL and VIH
And yes, TTL low is .8v, high is 2v (assuming 5V VDD).
Schmitt trigger is 0.2 * VDD (1v) and 0.8 * VDD (4v).
hth,
Thank you Darel for your prompt answer, very kind as usual.
At present, I am almost ready to publish the 60 keys keypad with interrupts (as promised) using your nice routine.
I am studing the way to avoid the encoding problem arising when two columns keys are pressed at the same time, using the low level logic as a selector.
In other words, I am trying to balance the current in every column in such a way that if more then one key is pressed at the same time, then the extra load will drop the voltage to a value that does not trigger the interrupt.
If it will turn out to be a reliable solution, then this keypad project will be a real success!
Al.
Thats Great Al! Love the follow thru!
I've been trying to figure out how that might work with the TTL levels.
I keep coming up with Butkis. But I could be missing the point.
The main problem I get hung up on it that pressing keys 1,1 and 1,2 at the same time, is electrically identical to pressing 1,3. And the problem repeats throughout the rest of the keypad.
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3073" /><!-- Attachment 3073 -->
So I figured they had to be different somehow, and that difference has to be readable on chips that don't have A/D. Like the 16F628 already in play.
I never like adding more parts, but I think they may help to decide if a keypress is valid or not in this case.
If the schematic looked something like this ...
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3077" /><!-- attach]3077[/attach] -->
Then all the rows can be set HIGH and when any key is pressed it should get a PORTB change interrupt as expected. And the key can also be read as planned.
But then, it can do some additional testing to look for double keypresses, by measuring RCTIME or equivalent capacitor discharge times.
The resistor R1 - R4 values would indicate how many diodes (bits) should have been read. Columns with 1 diode have the lowest value and should discharge fast. Columns with 2 diodes have a resistor that increases the RCTIME to indicate 2 bits. 3 diodes and 4 diodes per column have progressively larger resistors.
The idea is that if you receive a key with 3 bits = 1, then the RCTIME should also indicate 3-bits as a check/balance. Pressing any other keys simultaneously will give an incorrect "Check".
I haven't figured out any part values or code snippets since I'm not sure if the concept will work.
Maybe someone can see why it won't work, and we won't have to. :o
Darel, the approch I am investigating is different. I am working on the possibility to have voltage to drop below the VIL when two or more column keys are pressed at the same time.
The branch with one diode work fine with Ra and Rb = 10K and R1=4.7K (one key = 1.06 Volts - two keys yield 0.5 Volts which should not trigger the interrupt) but naturally branches with more diodes in parallel will behave differently because partition Ra - Rb will be different and I need to find out which is the best compromise (if exists and if it works) for Ra Rb R1 R2 R3 and R4. ( See the attached diagram)
One way which protect only for two adiacent keypress is given in the second diagram where before decoding the key I could check if odd and even logic are high and invalidate the reading but is not enough
The very last solution is to use an additional component (a pretty old one) Cd4067 ( 4 to 16 line decoder) which solve definitly the problem and is working pretty well. (see 3rd diagram. This option suggested to me to use a pic 16F873 to avoid to use the additional CD4067).
I will investigate also your suggestion.
Al.