与嵌入式系统无关的硬件C ++ HAL

问题描述 投票：0回答：2

我正在研究如何实现定制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这样的类，但是对于其他非端口相关的外设集合，如时钟，硬件定时器。

我确信在上述概念中存在一些漏洞，任何人都可以建议从经验中避免使用或者是否有更好的抽象方法？

c++ embedded hal
2个回答
4
投票

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

首先，假设一个平台上的外设有一些配置选项，对于其他平台上的等效外设来说根本不存在。有一些选项可以解决这个问题，例如：

  • 硬编码该选项的特定值
  • 包含提供该选项的配置值的文件，但不要为该文件提供hal。使用hal的每个项目也必须提供此文件。
  • 扩展SerialPort以配置选项（额外功能？某种回调？）。

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

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

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

至于我的建议：

找到合适的接口。尝试为硬件可以做什么创建一个接口是一种诱惑 - 它是一个硬件抽象层吗？但是，我发现从界面客户端的角度来看它更好--HAL的用例是什么。如果您找到一个可以满足大多数或所有用例的简单界面，那么它可能是一个很好的界面。

（我想，这可能与你对时钟和硬件定时器的观点最相关。问问自己：你的用例是什么？）

这里一个很好的例子是I2C。根据我的经验，大多数情况下，特定的I2C外设永远是主设备或永久性的从设备。我经常不需要在主服务器和从服务器之间交换。考虑到这一点，最好提供一个I2CDriver，试图封装任何平台上的“典型”I2C外设能够，或提供一对接口I2CMasterDriver和I2CSlaveDriver，每个接口只提供一个用例I2C事务结束。

我认为后者是最好的起点。典型的用例是主服务器或从服务器，用例在编译时是已知的。

将接口限制为“普遍常见”。某些平台可能提供单个外设执行SPI / I2C，其他平台提供单独的外设。如上所述，相同的外围设备可以在平台之间具有不同的配置选项。

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

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

我认为这样做 - 将'普遍共同'和特定硬件分开 - 使接口更小更简单。这样可以更容易地发现它何时开始变得混乱。

这是我如何解决这个问题的一个例子。首先，为通用函数定义一个抽象接口。

/* 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 );
}

最后，让我们把它们放在一个人为的例子里。请注意，特别是硬件特定的配置，因为客户端无法访问它。

/* main.cpp */
void main()
{
    hal::avr::Uart gps_uart( Uart1 );
    gps_uart.configure(); /* do the hardware-specific config here */
    MaestroA5135Driver gps( gps_uart ); /* can do the generic UART config */

    hal::avr::Uart bluetooth_uart( Uart2 );
    bluetooth_uart.configure(); /* do the hardware-specific config here */
    MicrochipRN4871Driver bluetooth( bluetooth_uart ); /* can do the generic UART config */

    ContrivedPositionAdvertiser cpa( gps, bluetooth );
    for(;;)
    {
        /* do something */
    }
}

这种方法也有一些缺点。例如，将实例传递给更高级别类的构造函数可以快速增长。因此需要管理所有实例。但总的来说，我认为缺点是优势超过了 - 例如，易于添加另一个平台，易于使用测试双打单元测试hal客户端。

0
投票

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

就接口的实际情况而言，我同意@Sigve认为用例是最好的设计工具。只需暴露一些参数，许多低级外设接口可以减少到init \ read\ write。许多更高级别的“HAL”任务通常可以完全与硬件分离，并且仅操作数据流。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.