Arduino-like pin definitions in C++

Work in Progress This page describes a work in progress. All specifications may change and the final product may significantly deviate from what we describe here. It is very well possible that there will be no final product at all.

[[Revision timestamp::20140727195625|]]

We regularly design "bare" AVR devices (meaning: non-Arduino). While we're doing that, we often need to do some of the following:

• When designing a single-sided PCB, completely re-assign many pins in order to avoid bridges.
• Create a library for commonly used components like a hd44780 LCD display, or NRF24L01+ transceiver, making the pins that connect to these devices configurable.
• Implement non-trivial signaling protocols while keeping the source code readable.

All of these scenarios require us to allocate pins or groups of pins to functions in such a way that we don't have to re-write our code when that allocation changes for some reason. At the same time we need to keep the code that actually uses these pins as clean as possible.

In AVR-land, there are two main schools of defining your pins:

• The C-style way, using #defines for the register and bit positions of a pin, which results in code that performs well, but can be somewhat combersome and does not score high on readability.
• The Arduino way, using digitalWrite( pin, value) and a single integer to designate a pin, which is arguably easier to read and easier to re-allocate, but can take many clock cycles to do something simple like setting a single bit.

This page describes our pin-definition library. This library allows for Arduino-like syntax for pin usage, while keeping the performance of 'manual' pin manipulations in C.

TL;DR

Pin-definitions is a header-only library, you can find the sources on GitHub, in file pin_definitions.hpp. This library is intended to declare AVR pins for functions in an intuitive way. Typical usage is as follows:

<source lang='cpp'>

1. include "avr_utilities/pin_definitions.hpp"

// declare a single pin DECLARE_PIN( led1, D, 6); DECLARE_PIN( led2, B, 0);

// declare a consecutive range of pins in a single register DECLARE_PIN_GROUP( counter, D, 2, 3); // D2, D3 and D4 are a counter DECLARE_PIN_GROUP( rotary_encoder, D, 5, 2); // D5, D6 are some inpt, e.g. from a quadrature rotary encoder

void do_stuff() { // initialize data direction for the output pins. init_as_output(led1 | led2 | counter);

// start by setting both leds set( led1 | led2);

while (true) { // read the two input bits of the rotary encoder and // output the result to the bits of the counter write( counter, read(rotary_encoder)); if (read(rotary_encoder) == 10) { set( led1); reset( led2); } else { set( led2); reset( led1); } } } </source>

On top of this, the library aims at exactly the same performance as hand-written bit manipulations. This means that the line <source lang="cpp">set( led1 | led2)</source> has the same performance as <source lang="cpp">

   LED_PORT |= ( _BV( LED1_PIN)| _BV(LED2_PIN));

</source> ...if led1 and led2 are on the same port. If the leds are on different ports, it should have performance equivalent to <source lang="cpp">

   LED1_PORT |= _BV( LED1_PIN);
   LED2_PORT |= _BV( LED2_PIN);

</source> It will even go one step further. For a line like <source lang="cpp">set( led1 | led2 | led3)</source> if led1 and led3 are on the same port, but led2 is on a different port, it will generate code equivalent to: <source lang="cpp>

   LED13_PORT |= (_BV( LED1_PIN)| _BV( LED3_PIN));
   LED2_PORT  |= _BV( LED2_PIN);

</source> The library will perform this type of optimization regardless the number of pins or pin groups that are combined in a single call. Of course it will also perform the same optimizations for the functions reset(), make_output() and initialize_as_output(), minimizing the clock ticks for the given arguments.

In order to do this, the library makes heavy use of C++ template metaprogramming. This makes the library itself less readable to those that are not familiar with template metaprogramming, but it sure makes (re-)declaration and usage of pins a lot easier to read...

Defining pins on AVR and Arduino

AVR C style

Take a look at how a randomly chosen library (for driving HD44780 LCD displays) defines which pins have which function: <source lang="cpp">

1. define LCD_PORT PORTA
2. define LCD_DATA0_PORT LCD_PORT
3. define LCD_DATA1_PORT LCD_PORT
4. define LCD_DATA2_PORT LCD_PORT
5. define LCD_DATA3_PORT LCD_PORT
6. define LCD_DATA0_PIN 0
7. define LCD_DATA1_PIN 1
8. define LCD_DATA2_PIN 2
9. define LCD_DATA3_PIN 3
10. define LCD_RS_PORT LCD_PORT
11. define LCD_RS_PIN 4
12. define LCD_RW_PORT LCD_PORT
13. define LCD_RW_PIN 5
14. define LCD_E_PORT LCD_PORT
15. define LCD_E_PIN 6

</source> There's nothing wrong with that library: this is how almost all AVR code defines their pins. Typically, each pin function is defined by using two (sometimes only one) #defines: one to define the port and one to define which bit of the port is being used. For an overly simple example. Suppose we want to use bit 5 of port B to control led1, we'd typically do this:

<source lang="cpp">

1. define LED1_PORT PORTB
2. define LED1_PIN 5

// ...

void f() {

   // ...
   // flash led 1
   LED1_PORT &= ~_BV( LED1_PIN);
   _delay_ms( 50);
   LED1_PORT |= _BV( LED1_PIN);

   // ...

} </source>

Unfortunately, this is not enough if you really want to be able to switch pins without changing the application code. In addition to defining the port, you'd also need to set the data direction (DDRx) bit for the LED to become an output:

<source lang="cpp">

1. define LED1_DDR DDRB
2. define LED1_PORT PORTB
3. define LED1_PIN 5

void initialize() {

   // make the pin for led1 an output
   LED1_DDR |= _BV( LED1_PIN);
   // do other outputs as well...

}

void f() {

   // etc...

} </source>

This is getting cumbersome. In practice, I normally forget about the data direction and completely re-write the init function when I re-assign pins. For the rest, I try to maintain both the port #define and the pin #define for medium to large projects, but for the smaller ones I usually hardcode the pins.

Arduino

On Arduino, defining a pin function becomes a lot easier and more readable:

<source lang="cpp"> int led1 = 13; // LED connected to digital pin 13, port B, pin 5

void setup() {

 // make the pin for led1 an output
 pinMode(led1, OUTPUT);
 // do other outputs as well...

}

void f() {

 // ...
 // flash led 1
 digitalWrite(ledPin, LOW);
 delay(50);
 digitalWrite(ledPin, HIGH);
 // ...

}

</source> Changing the led pin is a matter of just adapting the initialization of led1. At the same time, making the output pin high or low is about as readable as it could get: digitalWrite(ledPin, LOW). You just know what that line does.

However, this readability comes at a significant cost. If we look at the implementation of digitalWrite we can see that cost:

<source lang="cpp"> void digitalWrite(uint8_t pin, uint8_t val) {

       uint8_t timer = digitalPinToTimer(pin);
       uint8_t bit = digitalPinToBitMask(pin);
       uint8_t port = digitalPinToPort(pin);
       volatile uint8_t *out;

       if (port == NOT_A_PIN) return;

       // If the pin that support PWM output, we need to turn it off
       // before doing a digital write.
       if (timer != NOT_ON_TIMER) turnOffPWM(timer);

       out = portOutputRegister(port);

       if (val == LOW) {
               uint8_t oldSREG = SREG;
               cli();
               *out &= ~bit;
               SREG = oldSREG;
       } else {
               uint8_t oldSREG = SREG;
               cli();
               *out |= bit;
               SREG = oldSREG;
       }

}

</source>

This will easily take 50 clock cycles! That's a bit steep, if all we want is to change a single bit value. If we know which pin we're going to set at compile time, changing a single pin value should take at most 2 clock cycles (1 on an Attiny).

Introducing pin_defnitions.hpp

With AVR-GCC we have a fully functional C++ compiler at our disposal. It should be possible to use this fact to create a library that allows Arduino's intuitive digitalWrite function with native C performance. With this in mind, we wrote pin_definitions.hpp. This pin definition library makes extensive use of meta programming. Its implementation may not be easy to read if you're not familiar with C++ template metaprogramming, but if you only use the library, you should find it very intuitive—plus I've done my stinking best to not let any compilation errors end up deep inside the source code of this library...