Update to xealousbrown.

[alex-ong]

5-13ms Latency decrease, 4x scan rate improvement.
(CUSTOM_MATRIX = lite) is a really great feature!

Updated XealousBrown, various performance improvements.

Description

• Decreased USB polling latency via setting rate from 10ms to 1ms
• Finally incorporated BOOTMAGIC so I can flash without opening the keyboard up.
• Used Eager_PK rather than sym_g which has 5ms lead lag time.
• Used CUSTOM_MATRIX = lite to increase polling rate using optimizations
• Changed pin polling code to pre-compiled scan for entire column.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[zvecr]

While I like to see people using custom matrix lite, you might get the bulk of the performance gains from another solution.

Something like #8216, and setting the new define to 1. While this wont be the same as two noops, it will cut out a significant portion of the idle time without having to jump to custom code.

[alex-ong]

While I like to see people using custom matrix lite, you might get the bulk of the performance gains from another solution.

Something like #8216, and setting the new define to 1. While this wont be the same as two noops, it will cut out a significant portion of the idle time without having to jump to custom code.

Thanks for the feedback! There are actually two parts to this; adding the nops "uncaps" the speed, allowing it to reach 10khz+. However the slow part is still the scanning.

The majority of the speedup is actually from get_cols(). I actually tested this over a year ago. The QMK way, though very modular, spends a lot of time setting rows and polling each column individually. It does quite a bit of lookup to achieve it. The TMK way you hardcode some arbitrary bitbash mask and it does it very quickly.

I haven't tested it thoroughly on qmk recently, since I am just applying all my old hacks together. The net increase is from something like 1900 scanrate to 8000 scanrate.

It's nice that QMK has moved a lot of the hacks i made into core code (for example, setting usb polling rate to 1ms, CUSTOM_MATRIX = lite, Debouncing are all core features now)

[zvecr]

My experience is that the code within get_cols wouldn't give you much more than a 10% increase. And if you were to produce something like a flame chart, most of the time is spent in the waits.

The net increase is good, but my preference is using core code where possible. Any chance you could you provide the perf difference for just the get_cols part of the change?

[alex-ong]

Any easy way to generate such charts? I haven't tested all these speedups part by part recently so Ill try and document the speedups I did, I was going to write a blog post at some point anyway

[alex-ong]

So my optimizations are three things:

1. pin-settle time from wait_us(30) to wait_us(1) or nops or nothing at all
2. select_row() with a bit-bashy implementation
3. read_cols() with a bit-bashy implementation
4. unselect_rows() with a bit-bashy implementation.

First, overall performance compared to qmk matrix.c:

pin-settle	matrix_scan	scan_rate	Notes
wait_us(30)	qmk_default	1900	standard qmk implementation.
wait_us(1)	qmk_default	2635	Changed wait_us by changing quantum/matrix.c
nop; nop;	qmk_default	2590	Replaced wait_us in quantum/matrix.c
(no settle)	qmk_default	2670	Deleted wait_us in quantum/matrix.c
wait_us(30)	bit-bash	3662	custom_matrix = lite
wait_us(1)	bit-bash	7290
nop; nop;	bit-bash	8200
(no settle)	bit-bash	8250

bit-bash means 2,3,4 use the "optimized" version.

Next table shows the performance difference of each part inside the custom_matrix implementation:

pin_settle	select_row	read_cols	unselect_rows	scan_rate
nop; nop;	fast	fast	fast	8250
nop; nop;	"qmk"	fast	"qmk"	5200
nop; nop;	"qmk"	"qmk"	"qmk"	2548

"qmk" represents an almost copy paste from qmk's matrix.c back into custom_matrix_lite, with slight modifications. you can see that the last option (2548) roughly matches qmk's real matrix implementation (2590).

But wait! There's more!
Changing a few compiler options also helps.

1. in TMK's rules.mk, you can enable Optimization level for speed vs size
2. you can enable LINK_TIME_OPTIMIZATION_ENABLE = yes for smaller/slightly faster binaries

TMK's OPT	LINK_TIME_OPTIMIZATION_ENABLE	scan_rate	binary size
3	null (off)	12036	21814
2	null (off)	11963	19488
1	null (off)	11964	20744
0 (off)	null (off)	no_compile	-
s (default)	null (off)	8212	17860
3	yes	13674	20634
2	yes	13655	17324
1	yes	9142	18952
s (default)	yes	8564	15926

Anyway its good that I sat down and did the research.

[stale]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[alex-ong]

Thanks for looking at it!

[noroadsleft]

Thanks!

As an aside, this board is a standard ANSI 60%, correct?

[alex-ong]

Yep, there's something about storing my bindings in user's/key-maps right?

[noroadsleft]

There is, but that wasn't what prompted the question.

I maintain the default keymaps over on QMK Configurator, and every time I pass by this one in my updates there, I'm reminded that your QMK Configurator implementation isn't correct – a user would have to assign the keys like this to get the expected key assignments.

I'd like to fix it, but the correct way to do that per QMK's conventions requires that I edit your keymap.c and xealousbrown.h files, which I didn't want to do without permission.

As far as storing your bindings in users/, that's up to you, and whether that's worth your time really depends on how many QMK keyboards you own and how you use them. I currently only own one assembled QMK keyboard (have three more in various states of non-completion), so I don't use userspace.

[alex-ong]

@noroadsleft Thanks for that.

Feel free to correct it for me (aren't all devs lazy?); otherwise, teach a man to fish... is there a link to qmk conventions so i can correct it myself?

[alex-ong]

My guess is i have to change my keymap to this:

And then correct my pin mappings to suit?

[noroadsleft]

@alex-ong You posted while I was writing a response, but you've got it there. You just need that change to the keymap.c, and then to rearrange

qmk_firmware/keyboards/handwired/xealousbrown/xealousbrown.h

Lines 6 to 12 in ccc8338

	#define LAYOUT( \
	K00, K01, K02, K03, K04, K05, K06, K07, K08, K09, K0A, K0B, K0C, \
	K10, K11, K12, K13, K14, K15, K16, K17, K18, K19, K1A, K1B, K1C, \
	K20, K21, K22, K23, K24, K25, K26, K27, K28, K29, K2A, K2B, K2C, \
	K30, K31, K32, K33, K34, K35, K36, K37, K38, K39, K3A, K3B, K3C, \
	K40, K41, K42, K45, K46, K47, K48, K49, K4C \
	) { \

in the same way, so the keycodes that move are still assigned to the same arguments in the layout macro (Backspace as K4C, Backslash as K3C, etc.).

[alex-ong]

Alright i'll give it a shot tomorrow night, using GH60 layout as a guide to make sure those arrows in that diagram are right and i'm not missing any KC_NO's. Then will PR for someone to check and tell me i did it wrong lmao.