Kinetis Microcontrollers中的主题 Re: Delay after PSOR/PCOR?

Delay after PSOR/PCOR?

joeygouly — Thu, 29 Sep 2016 20:15:42 GMT

Hi,

I'm scanning a matrix, and my code looks like:

for (c = 0; c < columns; ++c) {
columns[c].set_high(); // PSOR
for (r = 0; r < rows; ++r) {
int x = rows[r].read();
}
columns[c].set_low(); // PCOR
}

However, I've found that I needed a few ms delay after 'set_low', otherwise it looks like 2 columns can be on at once.

Is there a 'proper' way to accomplish this? The ms delay feels very hacky.

I'm using the MKL27Z.

Thanks,

Joey

Re: Delay after PSOR/PCOR?

mjbcswitzerland — Thu, 29 Sep 2016 20:48:05 GMT

Hi Joey

See: http://www.utasker.com/docs/uTasker/uTaskerKeypad.PDF

You can check the HW that you have against its reference, and also note that in order to reduce/erradicate the effects of RC charge times on the lines it is recommended to briefly "drive" the input (set as output state and back to input) to set/discharge the 'open' state, Then there will be no need for delays.

Regards

Mark
Kinetis for professionals: http://www.utasker.com/kinetis.html

Re: Delay after PSOR/PCOR?

joeygouly — Thu, 29 Sep 2016 22:58:48 GMT

Thanks Mark!

I'll take a further look at your document.

Can you, in simple terms, explain the difference between driving the columns high (like I do) or driving it low (like you do)? (In a keyboard matrix scanning context)

Re: Delay after PSOR/PCOR?

mjbcswitzerland — Thu, 29 Sep 2016 23:22:14 GMT

Joey

I thnk that it is just a polarity thing - if you have pull-downs on inputs the 'floating' state is '0' so to discharge, one drives (very briefly) to '0'. If the pull-ups are to '1' (as in my reference) the opposite is true. Both are correct...one detects '1' as 'preseed and the other '0' as pressed.

Regards

Mark