Question

我正在研究如何实现针对多个微控制器的自定义C ++ HAL，这些微控制器可能具有不同的体系结构（ARM，AVR，PIC等），同时保持正常运行。

我继承了几个大型的，混乱的代码库，这些代码库在当前状态下无法维护，因此需要更结构化的东西。

在阅读了许多好的文章和设计指南之后，我正在考虑实现PIMPL。

请考虑以下UART /串行端口示例：

// -----------------------------
// High-level HAL
// -----------------------------

// serialport.h
class SerialPortPrivate;

class SerialPort {

public:
    SerialPort(uint8_t portNumber);
    ~SerialPort();

    bool open();
    void close();

    void setBaudRate(uint32_t baudRate = 115200);

private:
    SerialPortPrivate *_impl;
};

// serialport_p.h
class SerialPort;

class SerialPortPrivate {

public:
    SerialPortPrivate(uint8_t portNumber, SerialPort *parent) {
        // Store the parent (q_ptr)
        _parent = parent;

        // Store the port number, this is used to access UART
        // specific registers UART->D[portNumber] = 0x10;
        _portNumber = portNumber;
    }
    ~SerialPortPrivate();

    bool open() = 0;
    void close() = 0;

    void setBaudRate(uint32_t baudRate) = 0;

protected:
    uint8_t _portNumber;

private:
    SerialPort *_parent;

};

// serialport.cpp
#include "serialport.h"
#include "serialport_p.h"    

#include "stm32serialport_p.h"
#include "avr32serialport_p.h"
#include "nrf52serialport_p.h"
#include "kinetisserialport_p.h"

SerialPort::SerialPort(uint8_t portNumber) {
#if MCU_STM32
    _impl = new Stm32SerialPortPrivate(portNumber, this);
#elif MCU_AVR32
    _impl = new Avr32SerialPortPrivate(portNumber, this);
#elif MCU_NRF52
    _impl = new Nrf52SerialPortPrivate(portNumber, this);
#elif MCU_KINETIS
    _impl = new KinetisSerialPortPrivate(portNumber, this);
#endif
}

void SerialPort::setBaudRate(uint32_t baudRate) {
    _impl->setBaudRate(baudRate);
}

// -----------------------------
// Low-level BSP
// Hardware-specific overrides
// -----------------------------

// stm32serialport_p.h
class Stm32SerialPortPrivate : public SerialPortPrivate {

};

// nrf52serialport_p.h
class Nrf52SerialPortPrivate : public SerialPortPrivate {

};

// kinetisserialport_p.h
class KinetisSerialPortPrivate : public SerialPortPrivate {

};

以上代码在高级接口（#if/#endif）的构造函数中只有一组SerialPort语句，而特定于硬件的代码（寄存器访问等）是在私有内部完成的实施。

更进一步，我可以看到上面的实现对于I2cPort，SpiPort，UsbSerialPort之类的类来说是很好的，但是对于其他与端口无关的外设集，如时钟，硬件定时器

我肯定上述概念中存在一些漏洞，有人可以从经验中建议避免的事情，或者是否有更好的抽象方法？

Answer 1

以下是我对您的方法存在的一些担忧：

首先，假设一个平台上的外围设备具有一些配置选项，而对于其他平台上的等效外围设备则根本不存在。有关如何处理此问题的选项，例如：

硬编码该选项的特定值
包括一个文件，该文件提供该选项的配置值，但不向该文件提供hal。每个使用hal的项目也必须提供此文件。
扩展SerialPort来配置选项（附加功能？某种回调？）。

前两个不是很灵活（无法在运行时更改），第三个破坏了抽象-平台必须提供配置可能不存在的选项的功能，或者SerialPort用户必须知道底层平台的详细信息。我认为所有这些都是混乱的代码库的组成部分。

其次，假设一个平台具有可以提供相同功能的多个不同外围设备。例如，我目前正在使用具有USART和LPUART外设的STM32，它们都可以提供UART功能。要解决此问题，您将需要在运行时根据端口实例化不同的pimpl，或者为可处理的平台提供一个。可行，但会变得凌乱。

第三，要添加对另一个平台的支持，您现在需要修改许多其他代码以添加新的#elif子句。此外，#if-#elif-#endif使得代码的可读性较差，尽管良好的语法高亮会遮盖代码的非活动部分。

根据我的建议

找到正确的界面。尝试为硬件可以创建接口很容易被诱惑-这是硬件抽象层吧？但是，我发现最好从接口客户端的角度来看它-HAL的用例是什么。如果您发现一个可以满足大多数或所有用例的简单界面，则可能是一个很好的界面。

（我认为，这可能与您有关时钟和硬件计时器的观点最相关。问问自己：您的用例是什么？）

I2C是一个很好的例子。以我的经验，大多数时候，特定的I2C外设永久是主机或从机。我很少碰到需要在运行时在主从之间交换。考虑到这一点，最好提供一个I2CDriver来尝试封装任何平台上的“典型” I2C外设能够提供的功能，或者提供一对接口I2CMasterDriver和{{1} }，每个都只提供I2C交易一端的用例。

我认为后者是最好的起点。典型的用例是主用例或从属用例，并且在编译时就知道用例。

Limit接口与“普遍通用”的接口。一些平台可能会提供执行SPI / I2C的单个外设，而另一些平台会提供单独的外设。如上所述，相同的外围设备在平台之间可能具有不同的配置选项。

为“通用”功能提供抽象接口。

提供该接口的特定于平台的实现。这些还可以提供任何所需的特定于平台的配置。

我认为这样做-将“通用”和特定于硬件分开-使接口更小，更简单。这样一来，当开始变得凌乱时，就更容易发现它。

这是我将如何处理的示例。首先，为通用功能定义一个抽象接口。

I2CSlaveDriver

接下来，创建此接口的实现，其中可以包括特定于平台的详细信息-配置选项，资源管理。配置您的工具链，使其仅包含特定平台的这些

/* hal/uart.h */
namespace hal
{
    struct Uart
    {
        virtual ~Uart() {};
        virtual void configure( baud_rate, framing_spec ) = 0;
        /* further universally common functions */
    };
}

为完整起见，让我们在上面的界面中添加一些更高级别的“客户端”。请注意，它们通过引用采用抽象接口（可以是指针，但不能按值，因为它将对对象进行切片）。我在这里省略了名称空间和基类，因为我认为它们可以更好地说明问题。

/* hal/avr32/uart.h */
namespace hal::avr
{
    struct Uart : public hal::Uart
    {
        Uart( port_id );
        ~Uart();
        void configure( /*platform-specific options */ );
        virtual void configure( baud_rate, framing_spec );
        /* the rest of the pure virtual functions required by hal::Uart */
    };
}

最后，我们将其放在一个人为的示例中。注意，特定于硬件的配置已完成，因为客户端无法访问它。

/* elsewhere */
struct MaestroA5135Driver : public GPSDriver
{
    MaestroA5135Driver( hal::Uart& uart );
}
struct MicrochipRN4871Driver : public BluetoothDriver
{
    MicrochipRN4871Driver( hal::Uart& uart );
}
struct ContrivedPositionAdvertiser
{
     ContrivedPositionAdvertiser( GPSDriver& gps, BluetoothDriver& bluetooth );
}

这种方法也有一些缺点。例如，将实例传递给更高级别的类的构造函数可以快速增长。因此，所有实例都需要进行管理。但是总的来说，我认为缺点不能弥补缺点-例如，易于添加另一个平台，易于使用测试倍数对Hal客户端进行单元测试。

Answer 2

要提供跨平台接口，我喜欢使用“ platform.h”文件，该文件将所有#defines排除在源代码之外，同时还避免了大型继承树可能产生的代码膨胀。有关详细信息，请参见this answer或this one。

就实际的接口而言，我同意@Sigve的观点，即查看用例是最好的设计工具。仅暴露了一些参数，许多低级外围设备接口可能被简化为init \ read\ write。许多更高级别的“ HAL”任务通常可以与硬件完全分离，并且仅操作数据流。

嵌入式系统的独立于硬件的C ++ HAL

2 个答案: