New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running out of space, anything I can delete to make more room? #3224

Closed
BeatVids opened this Issue Jun 24, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@BeatVids
Copy link
Contributor

BeatVids commented Jun 24, 2018

My apologies if this is in the wrong place, but I like to update my keyboard's firmware every so often to keep up with your hard work on QMK.

Unfortunately, every time I update, I have to disable 2-3 macros from my leader dictionary.

Is there anything I can delete/disable to make room for my Ergodox EZ keymap? (Which is already at 100%!)

@drashna

This comment has been minimized.

Copy link
Collaborator

drashna commented Jun 24, 2018

It's a great place to ask. You should check out my userspace, since I've ran into this, as well.

That said, there are a few things you can do.
First, remove the fn_action and action_get_macro stuff from your code, and then add this to your rules.mk file:

EXTRAFLAGS        += -flto

This enables Link Time Optimization. This can save a good chunk of space (several KB for me), but the macro and function ... functions cause it to error out.

And since you won't be using those, you can add these defines to your config.h to save some additional space.

#define NO_ACTION_MACRO
#define NO_ACTION_FUNCTION

This disables those functions globally.

If you're not using leader keys, you can add this too:

#define DISABLE_LEADER

And it may be worth adding:

#ifndef NO_DEBUG
#define NO_DEBUG
#endif // !NO_DEBUG
#if !defined(NO_PRINT) && !defined(CONSOLE_ENABLE)
#define NO_PRINT
#endif // !NO_PRINT

If you're not doing debugging, then no need to have these on.

Also, depending on what features you're using, you could probably add this to your rules.mk file:

COMMAND_ENABLE   = no # Commands for debug and configuration
UNICODE_ENABLE   = no# Unicode
MOUSEKEY_ENABLE  = no # Mouse keys(+4700)

If you're using mouse keys, then don't enable the last one. But if you're not, it's a good chunk of space.

And with most of these optimizations and a bunch of additional stuff, my firmware compiles to about 29428 bytes, and fits well within the teensy's firmware size (91% capacity)

@BeatVids

This comment has been minimized.

Copy link
Contributor Author

BeatVids commented Jun 24, 2018

Hey @drashna, thank you for your great advice!
Unfortunately, I do use macros, the leader key, and mousekey functions.
But I don't use unicode (I think), swap hands, and debugging, and was able to reduce my firmware from 99.9% to 93.1% with:

COMMAND_ENABLE   = no  # Commands for debug and configuration
UNICODE_ENABLE   = no  # Unicode
SWAP_HANDS_ENABLE= no  # Allow swapping hands of keyboard

Thanks again for your great advice, it was painless to get me an extra 7%! If there are any more ideas, I'll be sure to share!

@drashna

This comment has been minimized.

Copy link
Collaborator

drashna commented Jun 24, 2018

Well, if you convert your macros to process_record_user, then you should be good. Most of the macro stuff should be relatively easy to migrate over though. And process_record_user doesn't have the issue that I mentioned.

It's specifically the action_get_macro and fn_action functions that are the problem.

@BeatVids

This comment has been minimized.

Copy link
Contributor Author

BeatVids commented Jun 25, 2018

I do use those macros, what is the problem? They aren't optimal?

@drashna

This comment has been minimized.

Copy link
Collaborator

drashna commented Jun 25, 2018

I don't know if there are any issues with them, but they're depreciated:
https://docs.qmk.fm/#/feature_macros

I think the process_record_user and SEND_STRING method is more flexible, and is better optimized. Also... functionally, the way it's called, you can do a hell of a lot more. For instance, I use process_record_user to modify a couple of keystrokes, so they work differently or add additional functionality. Also, I use it to create "twinkling" effects on my board (rgb underglow) when typing. Which you can't use the other methods for.

Also, ... the process_record_user has no issue when you use the extra flags thing. :)

@drashna drashna closed this Oct 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment