cutie-club/cfw-core

Custom computer keyboard firmware using FreeRTOS™.

cfw-core's Issues

Choose a lang

Currently we have been writing cfw-core in C, C can be deceptively simple leading to common undiagnosed and difficult to debug problems

Going forward we should at least evaluate the possibilities of writing in different languages, here are our current options:

• C
• C++
• Rust
• Zig

Tasks:

• Come up with list of pros & cons for each
• Come up with list of currently targetable architectures for each, most should be ok because llvm iirc
• Check how well the language interfaces with C as we currently rely on FreeRTOS and and vendor/community provided HAL's are also likely to be written in C
• Write a little helloworld type thing in each, ideally interfacing with some C code
• Flesh out C library we are interfacing with to be a more worthwhile example
• Present ur findings and together come to a decision

Dropped Keypresses

Occasionally, the firmware incorrectly reports keypresses to the host. There doesn't seem to be a pattern - apart from noticing it the most on spacebar, but I'd wager this a red herring, as the spacebar is the most pressed key on the keyboard.

Project Structure: Firmware Source Code

Currently we have a loose structure in our firmware files, including header files for drivers inside of src/drivers. Is this a good way to structure the project?

As part of this card, we should come up with a solid project structure that gives us room to grow and add more drivers and features to the project without confusion. We should consider the following hypotheticals, as well as everything already supported including matrix scanning, USB communication:

• we want to support multiple MCU architectures such as STM32, AVR32, SAMD21, NRF52, etc.
• we want to support RGB LEDs, for example WS2812 (or compatibles).
• we want to support an OLED screen (using, for example, an SSD1306 IC).
• we want to support multiple IO expanders.
• we want to support Bluetooth as a communication protocol.

Outcomes:

• a new folder structure for header files and source files
• a summary of choices made and how this supports the requirements, and explanations of compromises or changes

Blocked by #7

FreeRTOS yay or nay

Currently we have been making use of FreeRTOS, it has been serving us well, however we are considering not relying on an RTOS or maybe a different RTOS, as some overhead will always tend to be introduced when using an RTOS and we do not want to impact typing experience for our users

Tasks:

• Come up with pros & cons for RTOS
• Why would/wouldnt an RTOS make sense for a keyboard firmware
• Compare performance of simple project with & without FreeRTOS, doesnt need to be mega accurate, can just compare the assembly and see what it gets up too

Investigate templating as a way to generate C files

Currently, to generate C code, we would need to use string concatenation in our Typescript tool and write the result to a file. As a cleaner alternative, we should look into the ways to implement templating in a C file.

Some options could include:

• the standard C preprocessor
• a pre-preprocessor i.e. how mustache templating works
• using our Typescript tool to generate the entire C file

Feel free to add more options and ideas as this evolves.

The outcome of this card would be a way (or multiple ways) to generate C files dynamically using templates.

Blocked by #7

Design full journey from YAML to compiled firmware

Currently we use a Typescript tool to convert YAML configuration files into CMake compilation options, and then build the firmware using this. This is not scalable as we have to include options for every driver and architecture and feature, etc. This is OK for some options, but for a highly configurable system, it is cumbersome and error-prone.

We need feedback on the following:

• should the Typescript tool (y2kParser) be a hard dependency for firmware generation?
• should the build tool be able to load arbitrary YAML, from any location, or must it be in the keyboard config repository?
• should the Typescript tool handle generating intermediate files only, or also firmware compilation, etc?

The outcome of this card should be a design document for the journey of building firmware from config files. The design document should cover:

• answers to the questions posed above, in this card
• example scenarios
• inputs and outputs of the y2kparser including any generated files
• how our build tool for firmware will be configured and executed
• a diagram showing a high-level overview of how components interact

Blocked by #2 and #3

Project Structure: Keymaps & Layouts

A keymap is a way to map physical switch positions into a standardised grouping
A layout is a way to populate a keymap with keycodes

Currently layouts are unsupported. Before implementing them, we would like to design (from the user perspective) how keymaps and layouts will be specified in our YAML configuration files, and how they will be linked to keyboards.

The outcome of this card should be:

• example YAML for a layout
• example YAML for a keymap implementing a layout
• updated example YAML for a keyboard showing how a keyboard implements a layout
• seek feedback on the following:
  • should all layouts be publicly available to prevent duplicate layouts?
  • is this layout and keymap model suitable for the end user? is it too complex? what problem is it solving?

Investigate Premake

Currently CMake is the build tool for cfw. CMake is clunky and doesn't fit our workflow very well - it's not nice to use.

Does Premake fit our workflow better? Is it more extensible? Can it be used to build our project?

As an outcome of this card, we should have a working branch of cfw-core that builds with Premake.

Blocked by #7