tudattr
/
qmk_firmware
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[Docs] fix typo and remove trailing whitespace (#15842)

master
JayceFayne 2022-01-12 01:07:24 +00:00 committed by GitHub
parent 1f618c8302
commit 93e55605d9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
docs/squeezing_avr.md
View File

@ -1,16 +1,16 @@
# Squeezing the most out of AVR # Squeezing the most out of AVR
AVR is severely resource-constrained, and as QMK continues to grow, it is approaching a point where support for AVR may need to be moved to legacy status as newer development is unable to fit into those constraints. AVR is severely resource-constrained, and as QMK continues to grow, it is approaching a point where support for AVR may need to be moved to legacy status as newer development is unable to fit into those constraints.
However, if you need to reduce the compiled size of your firmware, there are a number of options to do so. However, if you need to reduce the compiled size of your firmware, there are a number of options to do so.
## `rules.mk` Settings ## `rules.mk` Settings
First and foremost is enabling link time optimization. To do so, add this to your rules.mk: First and foremost is enabling link time optimization. To do so, add this to your rules.mk:
```make ```make
LTO_ENABLE = yes LTO_ENABLE = yes
``` ```
This will cause the final step to take longer, but should get you a smaller compiled size. This also disables Action Functions, and Action Macros, both of which are deprecated. This will cause the final step to take longer, but should get you a smaller compiled size. This also disables Action Functions, and Action Macros, both of which are deprecated.
This will get you the most savings, in most situations. This will get you the most savings, in most situations.
From there, disabling extraneous systems will help -- e.g.: From there, disabling extraneous systems will help -- e.g.:
```make ```make
@ -19,7 +19,7 @@ COMMAND_ENABLE = no
MOUSEKEY_ENABLE = no MOUSEKEY_ENABLE = no
EXTRAKEY_ENABLE = no EXTRAKEY_ENABLE = no
``` ```
This disables some of the functionality that you may not need. But note that extrakeys disables stuff like the media keys and system volume control. This disables some of the functionality that you may not need. But note that extrakeys disables stuff like the media keys and system volume control.
If that isn't enough to get your firmware down to size, then there are some additional features that you can disable: If that isn't enough to get your firmware down to size, then there are some additional features that you can disable:
```make ```make
@ -27,19 +27,19 @@ SPACE_CADET_ENABLE = no
GRAVE_ESC_ENABLE = no GRAVE_ESC_ENABLE = no
MAGIC_ENABLE = no MAGIC_ENABLE = no
``` ```
These features are enabled by default, but may not be needed. Double check to make sure, though. These features are enabled by default, but may not be needed. Double check to make sure, though.
Largest in size is "magic" -- the QMK magic keycodes -- which control things like NKRO toggling, GUI and ALT/CTRL swapping, etc. Disabling it will disable those functions. Largest in size is "magic" -- the QMK magic keycodes -- which control things like NKRO toggling, GUI and ALT/CTRL swapping, etc. Disabling it will disable those functions.
## `config.h` Settings ## `config.h` Settings
If you've done all of that, and you don't want to disable features like RGB, Audio, OLEDs, etc, there are some additional options that you can add to your config.h that can help. If you've done all of that, and you don't want to disable features like RGB, Audio, OLEDs, etc, there are some additional options that you can add to your config.h that can help.
Starting with Lock Key support. If you have an Cherry MX Lock switch (lucky you!), you don't want to do this. But chances are, you don't. In that case, add this to your `config.h`: Starting with Lock Key support. If you have an Cherry MX Lock switch (lucky you!), you don't want to do this. But chances are, you don't. In that case, add this to your `config.h`:
```c ```c
#undef LOCKING_SUPPORT_ENABLE #undef LOCKING_SUPPORT_ENABLE
#undef LOCKING_RESYNC_ENABLE #undef LOCKING_RESYNC_ENABLE
``` ```
Oneshots. If you're not using these, you can disable the feature by adding this to your `config.h`: Oneshots. If you're not using these, you can disable the feature by adding this to your `config.h`:
```c ```c
#define NO_ACTION_ONESHOT #define NO_ACTION_ONESHOT
``` ```
@ -49,7 +49,7 @@ The same with tapping keys (mod tap, layer tap, etc)
``` ```
## Audio Settings ## Audio Settings
If you're using the Audio feature, by default that includes the music mode feature. This tranlates matrix positions into notes. It's neat for sure, but most likely, you're not using it. You can disable it by adding this to your `config.h`: If you're using the Audio feature, by default that includes the music mode feature. This tranlates matrix positions into notes. It's neat for sure, but most likely, you're not using it. You can disable it by adding this to your `config.h`:
```c ```c
#define NO_MUSIC_MODE #define NO_MUSIC_MODE
``` ```
@ -60,7 +60,7 @@ MUSIC_ENABLE = no
## Layers ## Layers
There are also some options for layers, that can reduce the firmware size. All of these settngs are for your `config.h`. There are also some options for layers, that can reduce the firmware size. All of these settings are for your `config.h`.
You can limit the number of layers that the firmware uses -- if you're using less than 8 layers in total: You can limit the number of layers that the firmware uses -- if you're using less than 8 layers in total:
```c ```c
@ -93,7 +93,7 @@ into this:
oled_write_P(PSTR("WPM: "), false); oled_write_P(PSTR("WPM: "), false);
oled_write(get_u8_str(get_current_wpm(), ' '), false); oled_write(get_u8_str(get_current_wpm(), ' '), false);
``` ```
which outputs `WPM: 5`. Or this: which outputs `WPM: 5`. Or this:
```c ```c
// NEW CODE // NEW CODE
oled_write_P(PSTR("WPM: "), false); oled_write_P(PSTR("WPM: "), false);
@ -103,7 +103,7 @@ which outputs `WPM: 005`.
## RGB Settings ## RGB Settings
If you're using RGB on your board, both RGB Light (Underglow) and RGB Matrix (per key RGB) now require defines to enable different animations -- some keyboards enable a lot of animations by default, so you can generally gain back some space by disabling specific animations if you don't use them.. For RGB Light you can disable these in your keymap's `config.h`: If you're using RGB on your board, both RGB Light (Underglow) and RGB Matrix (per key RGB) now require defines to enable different animations -- some keyboards enable a lot of animations by default, so you can generally gain back some space by disabling specific animations if you don't use them. For RGB Light you can disable these in your keymap's `config.h`:
```c ```c
#undef RGBLIGHT_ANIMATIONS #undef RGBLIGHT_ANIMATIONS
#undef RGBLIGHT_EFFECT_BREATHING #undef RGBLIGHT_EFFECT_BREATHING
@ -118,7 +118,7 @@ If you're using RGB on your board, both RGB Light (Underglow) and RGB Matrix (pe
#undef RGBLIGHT_EFFECT_TWINKLE #undef RGBLIGHT_EFFECT_TWINKLE
``` ```
For RGB Matrix, these need to be explicitly enabled as well. To disable any that were enabled by the keyboard, add one or more of these to your keymap's `config.h`: For RGB Matrix, these need to be explicitly enabled as well. To disable any that were enabled by the keyboard, add one or more of these to your keymap's `config.h`:
```c ```c
#undef ENABLE_RGB_MATRIX_ALPHAS_MODS #undef ENABLE_RGB_MATRIX_ALPHAS_MODS
#undef ENABLE_RGB_MATRIX_GRADIENT_UP_DOWN #undef ENABLE_RGB_MATRIX_GRADIENT_UP_DOWN
@ -168,7 +168,7 @@ For RGB Matrix, these need to be explicitly enabled as well. To disable any that
# Final Thoughts # Final Thoughts
If you've done all of this, and your firmware is still too large, then it's time. It's time to consider making the switch to ARM. Unfortunately, right now is the worst possible time for that, due to the silicon shortage, and supply chain issues. Getting an ARM chip is difficult, at best, and significantly overpriced, at worst. If you've done all of this, and your firmware is still too large, then it's time. It's time to consider making the switch to ARM. Unfortunately, right now is the worst possible time for that, due to the silicon shortage, and supply chain issues. Getting an ARM chip is difficult, at best, and significantly overpriced, at worst.
-- Drashna -- Drashna
That said, there are a number of Pro Micro replacements with ARM controllers: That said, there are a number of Pro Micro replacements with ARM controllers:
@ -176,5 +176,5 @@ That said, there are a number of Pro Micro replacements with ARM controllers:
* [Bonsai C](https://github.com/customMK/Bonsai-C) (Open Source, DIY/PCBA) * [Bonsai C](https://github.com/customMK/Bonsai-C) (Open Source, DIY/PCBA)
* [Raspberry Pi 2040](https://www.sparkfun.com/products/18288) (not currently supported, no ETA) * [Raspberry Pi 2040](https://www.sparkfun.com/products/18288) (not currently supported, no ETA)
There are other, non-Pro Micro compatible boards out there. The most popular being: There are other, non-Pro Micro compatible boards out there. The most popular being:
* [WeAct Blackpill F411](https://www.aliexpress.com/item/1005001456186625.html) (~$6 USD) * [WeAct Blackpill F411](https://www.aliexpress.com/item/1005001456186625.html) (~$6 USD)