Are rows and columns just interchangeable concepts in a keyboard matrix?

[THX1138b]

This is a kind of stupid question but regarding the rows and columns of a keyboard matrix, are the assignments row and column absolute? Like my circuit below; does that have eight rows and 16 columns or 16 rows and eight columns or are they both interchangeable? As far as I can tell they're just interchangeable concepts; neither really rows nor columns; just two different sets that can be conveniently arranged in the form of a table but I wanted to be sure because I want to make a quick YouTube video about a project and I don't want to say something wrong.

" alt="" class="bbc_img" />

[orihalcon]

The terms are interchangeable as far as the controller and functionality goes though usually columns are the larger number on a standard keyboard. Rows usually go horizontally and columns vertically by naming convention.

[TalkingTree]

As far as I can tell they're just interchangeable concepts

They are. You could theoretically call them X and Y axis for example.

[Findecanor]

By some strange reason, within this community there is a convention that "columns" get strobed one at a time and rows get read all at once.
Personally, I prefer the other way around.

[TalkingTree]

By some strange reason, within this community there is a convention that "columns" get strobed one at a time and rows get read all at once.
Personally, I prefer the other way around.

I'm curious about the reason.

[pomk]

Assuming that you have less rows than columns, it’s going to be slightly faster.

[TalkingTree]

Assuming that you have less rows than columns, it’s going to be slightly faster.

And you do that by inverting diodes polarity (other than firmware)?

[pomk]

Assuming that you have less rows than columns, it’s going to be slightly faster.

And you do that by inverting diodes polarity (other than firmware)?

Yeah. The difference is truly minimal though. Just a couple clock cycles per the diffrerence of the size of cols and rows. Just something to think about if you like perfectionism or are infinitely bored.

[TalkingTree]

Yeah. The difference is truly minimal though. Just a couple clock cycles per the diffrerence of the size of cols and rows. Just something to think about if you like perfectionism or are infinitely bored.

Meaning it wouldn't matter and I shouldn't be bothered to invert the whole matrix for a non commercial project with no ambition to be a gaming keyboard?

[joey]

Assuming that you have less rows than columns, it’s going to be slightly faster.

Can you expand on this?

You're saying it's slightly faster to have the columns as input and the rows as output?

[pomk]

Yeah. The difference is truly minimal though. Just a couple clock cycles per the diffrerence of the size of cols and rows. Just something to think about if you like perfectionism or are infinitely bored.

Meaning it wouldn't matter and I shouldn't be bothered to invert the whole matrix for a non commercial project with no ambition to be a gaming keyboard?

Not even in a gaming keyboard.  )
Lets say you have a 19 x 6 tkl, meaning that swapping the rows and cols is going to reduce the amount of polling by 13. That 13 would map to something like 39 to 78 clock cycles depending on the µc used. With some proper 100 MHz arm chip that would be around 0,00039 - 0,00078 ms you could save.

Assuming that you have less rows than columns, it’s going to be slightly faster.

Can you expand on this?

You're saying it's slightly faster to have the columns as input and the rows as output?

I'm saying that reading more values at once is faster. In a 60% you can read 14 cols at the same time, while you can only read 5 rows at the same time. The amount of values to read in total is the same.

[joey]

Yeah. The difference is truly minimal though. Just a couple clock cycles per the diffrerence of the size of cols and rows. Just something to think about if you like perfectionism or are infinitely bored.

Meaning it wouldn't matter and I shouldn't be bothered to invert the whole matrix for a non commercial project with no ambition to be a gaming keyboard?

Not even in a gaming keyboard.  )
Lets say you have a 19 x 6 tkl, meaning that swapping the rows and cols is going to reduce the amount of polling by 13. That 13 would map to something like 39 to 78 clock cycles depending on the µc used. With some proper 100 MHz arm chip that would be around 0,00039 - 0,00078 ms you could save.

Assuming that you have less rows than columns, it’s going to be slightly faster.

Can you expand on this?

You're saying it's slightly faster to have the columns as input and the rows as output?

I'm saying that reading more values at once is faster. In a 60% you can read 14 cols at the same time, while you can only read 5 rows at the same time. The amount of values to read in total is the same.

Ah yes, that makes sense. Negligible, but makes sense

[TalkingTree]

Yeah. The difference is truly minimal though. Just a couple clock cycles per the diffrerence of the size of cols and rows. Just something to think about if you like perfectionism or are infinitely bored.

Meaning it wouldn't matter and I shouldn't be bothered to invert the whole matrix for a non commercial project with no ambition to be a gaming keyboard?

Not even in a gaming keyboard.  )
Lets say you have a 19 x 6 tkl, meaning that swapping the rows and cols is going to reduce the amount of polling by 13. That 13 would map to something like 39 to 78 clock cycles depending on the µc used. With some proper 100 MHz arm chip that would be around 0,00039 - 0,00078 ms you could save.

That's plenty of time to save. Thanks pomk, you're gold.

[JohanAR]

With some proper 100 MHz arm chip that would be around 0,00039 - 0,00078 ms you could save.

I think most projects still use Arduino Pro Micro or Teensy (++) 2.0 which run on 16 MHz, so slightly bigger savings then?

[pomk]

With some proper 100 MHz arm chip that would be around 0,00039 - 0,00078 ms you could save.

I think most projects still use Arduino Pro Micro or Teensy (++) 2.0 which run on 16 MHz, so slightly bigger savings then?

In my opinion, by using such a low end chip you are already choosing not to pursue low latency in the first place. Even with those low end chips the difference is very miniscule and the bottlenecks are bound to be somewhere else.