Delay after PSOR/PCOR?

[joeygouly]

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

[mjbcswitzerland]

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

[joeygouly]

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)

[mjbcswitzerland]

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