search

rgoulter / keyboard-labs

Repo with my PCB designs and keyboard firmware
121 stars 11 forks source link

Question about bm40hsrgb #1

Closed atanasj closed 3 years ago

atanasj commented 3 years ago

Hi,

Sorry to post an issue here, but really just wanted to ask you a question about the bm40hsrgb and didn't know how else to get in touch with you.

I've been working on transferring some of my config from another keyboard, which includes tap dance and combos. I haven't actually got the keyboard yet, but when I test the firmware build by running make, it tells me that the firmware is too big. And even the default firmware is pretty big, and there is not a whole lot of features there...

 * The firmware size is fine - 24762/28672 (86%, 3910 bytes free)

Is this right? I only ask, because I'm keen to work with an ortho, but if I cannot have the other features I know rely on (combo, tap dance), I might just send it straight back as soon as it arrives.

rgoulter commented 3 years ago

Ah, sorry; just saw this.

It would've been fine to tag my GitHub username & file this is the qmk/qmk_firmware repository, too. - Better chance someone else would've seen it.

Unfortunately, yeah, the BM40HSRGB uses the atmega32u4 which doesn't allow for all that much firmware space. Any keyboard using a pro micro will face the same issue.

One thing which mitigates this is adding LTO_ENABLE = yes to the rules.mk (e.g. for a keymap, or for the keyboard directly). This wins a few thousand bytes more.

Another is to try and disable e.g. some RGB animation effects, or RGB matrix altogether

atanasj commented 3 years ago

Great, yes. Thanks for that. I actually stumbled upon exactly those things and it's made it a very usable board... The. LTO_ENABLE setting definitely won the most.

Thanks again.

Cheers, Atanas

On Mon, 10 May 2021 at 2:45 am, Richard Goulter @.***> wrote:

Ah, sorry; just saw this.

It would've been fine to tag my GitHub username & file this is the qmk/qmk_firmware repository, too. - Better chance someone else would've seen it.

Unfortunately, yeah, the BM40HSRGB uses the atmega32u4 which doesn't allow for all that much firmware space. Any keyboard using a pro micro will face the same issue.

One thing which mitigates this is adding LTO_ENABLE = yes to the rules.mk (e.g. for a keymap, or for the keyboard directly). This wins a few thousand bytes more.

Another is to try and disable e.g. some RGB animation effects, or RGB matrix altogether

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/rgoulter/keyboard-labs/issues/1#issuecomment-835841698, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGPUGIPNHAYLXQRDOUWX6ATTM233HANCNFSM434IRXPQ .

-- Atanas