Computing and Asserting Baudrate Settings at Compile Time

Prescaler and baudrate calculations are a tricky topic. I have had many situations where the baudrate turned out to be off by a couple of percent, which was enough to render my serial output streams unreadable. Sure, calculating the baudrate error beforehand would have saved me some hours of useless debugging, however, that would require understanding the often complicated mathematical formula hidden somewhere in the depths of the datasheet describing the prescaler vs. baudrate relationship.

And that seemed to be more work than just using a logic analyzer to measure the resulting error. Of course, this felt like using a sledgehammer to crack a nut and it was neither a fast nor practical solution.

I think there exists a better solution and I think it can be done using pure C++. This solution needs to be able to:

  1. compute the best possible prescaler settings for the desired baudrate, and
  2. notify me when the desired baudrate cannot be achieved without unresonable error.

Continue reading ...

Typesafe Register Access in C++

When you are writing software for microcontrollers, reading and writing hardware registers becomes second nature. Registers and bit mappings are typically “modeled” using C preprocessor defines, and usually provided to you by your cross compiler toolchain in device specific header files.

Setting up and toggling PG13 on the STM32F4 this way looks rather… unreadable:

// set push-pull, output
GPIOG->OSPEEDR = (GPIOG->OSPEEDR & ~(3 << 26)) | (3 << 26);
GPIOG->MODER   = (GPIOG->MODER & ~(3 << 26)) | (1 << 26);
GPIOG->OTYPER &= ~(1 << 13);
GPIOG->PUPDR  &= ~(1 << 13);

    GPIOG->ODR ^= (1 << 13);  // toggle
    // delay

It did not really dawn on me how primitive this concept was until I was forced to model a memory map myself for one of our many device drivers. Since I have never been a friend of using the C preprocessor in C++ unless absolutely necessary, it seemed like a good opportunity to research how best to implement this in pure C++.

Continue reading ...

Why a Blog?

For a long time now we wanted to describe the reasoning behind the xpcc design decisions in detail, and we even started writing a LaTeX document.

We realized, however, that creating these formal documents in LaTeX is just too much work, especially compared to modern markup languages.

So instead this blog (based on Hyde) will feature posts about xpcc features and their conceptions. We hope this acts as a catalyst to getting more ideas in xpcc documented and improving our examples folder.

What to expect

Here are a couple of topics we want to talk about:

  • Typesafe Register Access in C++
  • Computing and Asserting Baudrate Settings at Compile Time
  • Calculating Clock Tree Settings at Compile Time
  • Typesafe Peripheral Connections
  • Generic Keyframe Animation for LEDs
  • Scenario: NRF24 Radio
  • Designing for Multiple Access: SPI
  • Designing for Multiple Access: I2C
  • Designing for Multiple Access: Runtime Bus Configuration
  • Fast Resumable Functions for C++
  • Stackless Protothreads for C++
  • Splitting Data and Implementation in Device Drivers
  • Implementing Device Drivers
  • XPCC – The Communication Protocol
  • Meta-Framework xpcc: Using Code Generation for Multiple Targets