I recently had the itch to work on setting up a better template system or in this case repo for doing a lot of my C development work.

This Post is the result of a coulple of hours hacking together the features I find most useful into a single place.

TLDR; Check out the repo here: ULTIMATE_C_TEMPLATE

Requirements

So what makes me more efficient when working on C code? What allows me to write better code faster?

  • Has a LSP server availble.
  • Tracks the source changes over time.
  • automates the repetative stuff.
  • Test harness as part of the repo.
  • Adding new modules is fast.
  • Can handle multiple OSs
  • Can build for multiple targets.
  • checks for common errors.
  • Tuned for safety standards

Parts

The Build System

CMake

The build system selected is CMake. It’s well known, maintained and allows using toolchain files which make re-targeting easy.

It can also help reduce build times with other kinds of make systems like ninja, make, qmake, gmake, pmake etc.

The LSP

Clangd

I could write an entire book on my love of clangd as an LSP.

It’s your auto complete on steroids. It’s the guiding light before your last edit at 3AM in the morning when the client needs the software ASAP.

Automation

SH

When I say shell script most people think of bash or zsh or maybe even fish. But being the somewhat stubbern individual I am I try to maintain POSIX complience with all my shell scripts.

It may or may not have to do with me using FreeBSD where the default shell is sh or csh.

Things to automate:

  • Adding new modules/drivers
  • Auto adding new modules to vcs.
  • removing modules/drivers
  • running tests
  • building for another target
  • Installing needed dependencies
  • Isolating system wide changes.
  • Adding new taregt’s
  • Adding new toolchain files.

This list is continuously evolving; as I learn new concepts/tools and methodologies for code creation.

Multitarget

For embedded use specifically often you’ll find you need to use a seperate toolchain. For instance when I’m writing firmware for an STM32 I need to use an entirely seperate toolchain.

This also happens when working with AVR, ESP and WCH firmware development.

To handle the need to build or cross-compile the code it’s added into our shell scripts, where some sed/awk magic can customize template files to generate the needed toolchain files.

Version Control

GIT

There isn’t a whole lot to say on this front. GIT is pretty much the gold standard at the moment for version control.

NIX

I can almost hear someone yelling at me that NIX isn’t a VCS….they aren’t wrong.

But it’s semi-tangential to version control.

This lets us manage dependencies of the project’s code itself without cluttering the development system with them.

TO BE CONTINUED