I'm creating GPIO abstraction driver for stm32. There should be a class with register accesses and another class that holds a reference to it. In that way the class holding a reference has no idea about what is happening under the hood and doesn't care if i want to switch to a completely different mcu.

It is fine to make a class that keeps Port and Pin variables in Ram and inlines register calls, but it becomes problematic on low memory devices, such as f0.

The plan is to write a register accessing class as a template that takes Port and Pin as arguments. This way compiler will generate inline functions for each object created with a pair of <Port, Pin> and not keep them in Ram. Port and Pin are predefined Macros from CMSIS header.

Please ignore struct instead of class. Here is the simplified non template version:

struct Hal_Gpio
{
    GPIO_TypeDef* port;
    uint16_t pin;

    Hal_Gpio(GPIO_TypeDef* port, uint16_t pin) : port(port), pin(pin)
    {
    }

    bool read(void)
    {
        return port->IDR & pin;
    }
};

struct Interface_Gpio
{

    Hal_Gpio& pin;

    Interface_Gpio(Hal_Gpio& pin) : pin(pin)
    {
    }

    bool read(void)
    {
        return pin.read();
    }
};

I've tried this template version. It works and uses 8 bytes less of Ram:

template<uint32_t port, uint32_t pin>
struct Hal_Gpio_template
{

    bool read(void)
    {
        return reinterpret_cast<GPIO_TypeDef*>(port)->IDR & pin;
    }
};

I've also tried this version, works.

template<class Port, Port port, class Pin, Pin pin>
struct Hal_Gpio_template
{

    bool read(void)
    {
        return reinterpret_cast<GPIO_TypeDef*>(port)->IDR & pin;
    }
};

I can not figure out a way to put this template class as a reference in a Interface_Gpio class.

Also objects instantiated from the template class cannot be put in the same array. This prevents having a loop that scans through n inputs.

I'm creating GPIO abstraction driver for stm32. There should be a class with register accesses and another class that holds a reference to it. In that way the class holding a reference has no idea about what is happening under the hood and doesn't care if i want to switch to a completely different mcu.

It is fine to make a class that keeps Port and Pin variables in Ram and inlines register calls, but it becomes problematic on low memory devices, such as f0.

The plan is to write a register accessing class as a template that takes Port and Pin as arguments. This way compiler will generate inline functions for each object created with a pair of <Port, Pin> and not keep them in Ram. Port and Pin are predefined Macros from CMSIS header.

Please ignore struct instead of class. Here is the simplified non template version:

struct Hal_Gpio
{
    GPIO_TypeDef* port;
    uint16_t pin;

    Hal_Gpio(GPIO_TypeDef* port, uint16_t pin) : port(port), pin(pin)
    {
    }

    bool read(void)
    {
        return port->IDR & pin;
    }
};

struct Interface_Gpio
{

    Hal_Gpio& pin;

    Interface_Gpio(Hal_Gpio& pin) : pin(pin)
    {
    }

    bool read(void)
    {
        return pin.read();
    }
};

I've tried this template version. It works and uses 8 bytes less of Ram:

template<uint32_t port, uint32_t pin>
struct Hal_Gpio_template
{

    bool read(void)
    {
        return reinterpret_cast<GPIO_TypeDef*>(port)->IDR & pin;
    }
};

I've also tried this version, works.

template<class Port, Port port, class Pin, Pin pin>
struct Hal_Gpio_template
{

    bool read(void)
    {
        return reinterpret_cast<GPIO_TypeDef*>(port)->IDR & pin;
    }
};

I can not figure out a way to put this template class as a reference in a Interface_Gpio class.

Also objects instantiated from the template class cannot be put in the same array. This prevents having a loop that scans through n inputs.

• c++
• templates
• interface
• embedded
• abstraction

• Your second Hal_Gpio_template is syntactically incorrect. Please copy-paste the correct code. – Ted Lyngmo Commented Apr 1 at 19:32
• Are you trying to re-invent CRTP or Policy pattern? – Swift - Friday Pie Commented Apr 1 at 19:36
• @TedLyngmo Corrected and appreciated – Nik Commented Apr 1 at 21:25
• @Swift-FridayPie I am, for the most part, beginner in C++ and this is a creative learning experience. I bet that this idea is heresy for power users and embedded. – Nik Commented Apr 1 at 21:30
• @Nik I wouldn't use term heresy. First thing first, it's a language. As any language it got structure and elements which can represents some ideas and actions. Even if text is broken. Then you have patterns - these are idioms and tropes. Thing is, if it's broken or very non-ideomatic, it's hard to understand what that idea was. A common problem with uncommented legacy code written by interns, in my practice, is to understand what they wanted to do. A good practice is to formulate what you actually want to do, not how, treating resulting code as an essay and initial idea as a plan. – Swift - Friday Pie Commented Apr 1 at 21:36

2 Answers 2

Building on Botje's answer, why not just go with function pointers and explicitly instantiated function templates:

template<uint32_t port, uint32_t pin>
bool Hal_Gpio_Reader()
{
  return reinterpret_cast<GPIO_TypeDef*>(port)->IDR & (pin);
}

struct Interface_Gpio
{
  bool (*pin)();
  Interface_Gpio(bool (*pin)()) : pin(pin)
  {
  }
  bool read(void)
  {
      return pin();
  }
};

Interface_Gpio my_gpio(&Hal_Gpio_Reader<1, 2>);

If you insist on using objects you probably must store some data:

1. In the way you've already tried you have to store port and pin.

2. You can use interface with abstract method and derive empty template class which holds everything in code generated from the template but you incur a cost of virtual method table pointer and a call.

== edit ==

Virtual method approach

class Hal_Gpio_Reader_Interface
{
public:
  virtual bool operator()() = 0;
protected:
  ~Hal_Gpio_Reader_Interface() = default; // or make it public and virtual if there is a need to delete via base class pointer
};

template<uint32_t port, uint32_t pin>
struct Hal_Gpio_Reader : Hal_Gpio_Reader_Interface
{
  bool operator()() final
  {
    return reinterpret_cast<GPIO_TypeDef*>(port)->IDR & pin;
  }
};

struct Interface_Gpio
{
  Hal_Gpio_Reader_Interface &pin; // this may have to be a pointer
  Interface_Gpio(Hal_Gpio_Reader_Interface &pin) : pin(pin)
  {
  }
  bool read(void)
  {
      return pin();
  }
};

Hal_Gpio_Reader<1, 2> pin_1_2; // we need named object to take its reference
Interface_Gpio my_gpio(pin_1_2);

since you don't seem to mind trading a bit of code size for less RAM usage, you can abuse the fact that a no-capture lambda decays to a plain function pointer:

using Reader = bool(*)();
#define make_reader(port, pin) \
  [](){ return reinterpret_cast<GPIO_TypeDef*>(port)->IDR & (pin); }

(it has to be a macro because the equivalent function requires the lambda to capture values)

You can now put a Reader in your Interface_Gpio and it will work. Likewise:

std::array<Reader, 2> readers{ make_reader(1,2), make_reader(1,3) };