软硬件开发面试问题大汇总篇——针对非常规八股问题的提问与应答(代码规范与生态管理)

软硬件开发，对于编码规范、生态管理等等综合问题的考察尤为重要。

阐述下环形缓冲区的用途

环形缓冲区（Ring Buffer）是一种固定大小的数据结构，常用于实现数据的流式传输或临时存储。在环形缓冲区中，当到达缓冲区的末尾时，它会回绕到开始部分，从而形成一个“环”。

用途总结

数据流处理：在实时数据流（如音频或视频）的处理中，可以使用环形缓冲区来平滑数据输入和输出。例如，在数字音频工作站中，可以用它来存储录制的音轨。

生产者-消费者模型：在多线程程序中，生产者将数据放入缓冲区，而消费者从中取出。环形缓冲区提供了一种简单且高效的方法来处理这种并发访问。

网络包缓存：在网络编程中，尤其是当接收速度不均匀时，环形缓冲可以作为暂存区域，用于缓存收到的数据包。

任务调度：一些调度系统可以利用环形缓冲机制管理等待队列，实现任务间轮转。

阐述下DMA和FIFO的区别

DMA（直接内存访问）和FIFO（先进先出）是两种用于数据传输的不同机制

定义

DMA（Direct Memory Access）:DMA 是一种允许外部设备（如硬盘、网络适配器等）直接访问主内存而不通过 CPU 的技术。这样可以在数据传输时释放 CPU，让其处理其他任务，提高系统效率。

FIFO（First In, First Out）:FIFO 是一种数据结构，用于缓存数据。按照“先进先出”的原则，最早进入缓冲区的数据会最先被读取。FIFO 通常用于实现队列或缓冲区。

工作原理

DMA:在 DMA 模式下，外部设备发起一个请求给 DMA 控制器，DMA 控制器获得总线控制权后，将数据从外设转移到内存中。在这个过程中，CPU 不需要参与数据传输，从而降低了 CPU 的负载。

FIFO:FIFO 存储器是一个特殊类型的缓冲区，它按照顺序存储和检索数据。当新数据写入 FIFO 时，它会被添加到队尾，而读取操作会从队首删除并返回该元素。这种机制确保了数据的顺序性。

应用场景

DMA:常用于高带宽需求的应用，如音频、视频流、网络通讯、磁盘 I/O 等，可以有效减少 CPU 的干预，使得系统性能更佳。

FIFO:常用于实现消息队列、事件调度、异步通信等场合，例如多线程程序中的生产者-消费者问题，以及实时信号处理中的输入输出缓存。

性能影响

DMA:使用 DMA 可以显著提高系统性能，因为它减少了 CPU 在数据传输过程中的干预，并允许同时进行其他计算任务。

FIFO:FIFO 本身并不会影响性能，但在设计良好的系统中，它可以帮助保持稳定的数据流和高效的数据处理，尤其是在多任务或多线程环境下。

如何做到统一API对接不同外设驱动

统一API对接不同外设驱动的关键在于设计一个抽象层，使得上层应用能够以一致的方式与各种外设进行交互，而不需要关心底层具体驱动的实现细节。

抽象接口设计

定义统一接口：首先，确定需要支持的功能（如读、写、初始化等），然后为这些功能定义一组标准化的接口。这些接口应具有通用性，以适用于所有类型的外设。

class IDevice {
public:
    virtual void init() = 0;
    virtual int read(void* buffer, size_t size) = 0;
    virtual int write(const void* buffer, size_t size) = 0;
    virtual ~IDevice() {}
};

驱动适配器

实现具体驱动类：为每种外设编写相应的类，继承自上述统一接口，并实现具体驱动相关的方法。这些类将负责处理特定设备的逻辑。

class SerialDevice : public IDevice {
public:
    void init() override {
        // 初始化串口设备
    }
    
    int read(void* buffer, size_t size) override {
        // 从串口读取数据
        return bytesRead; // 返回实际读取字节数
    }

    int write(const void* buffer, size_t size) override {
        // 向串口写入数据
        return bytesWritten; // 返回实际写入字节数
    }
};

class USBDevice : public IDevice {
public:
    void init() override {
        // 初始化USB设备
    }
    
    int read(void* buffer, size_t size) override {
        // 从USB读取数据
        return bytesRead; 
    }

    int write(const void* buffer, size_t size) override {
        // 向USB写入数据
        return bytesWritten; 
    }
};

工厂模式

工厂方法：使用工厂模式来创建不同类型的设备对象，从而简化客户端代码中的实例化过程。

(对于设计模式的考察，这个是比较普遍的)

class DeviceFactory {
public:
    // 使用智能指针管理
    static std::unique_ptr<IDevice> createDevice(DeviceType type) {
        switch (type) {
            case DeviceType::SERIAL: 
                return std::make_unique<SerialDevice>();
            case DeviceType::USB: 
                return std::make_unique<USBDevice>();
            default: 
                throw std::invalid_argument("Unknown device type");
        }
    }
};

使用统一API

通过统一接口调用：在上层应用中，通过统一的 IDevice 接口与具体设备交互，而不需考虑底层实现细节。(使用工厂模式的创建设备方式)

void performOperations(DeviceType type) {
    auto device = DeviceFactory::createDevice(type);
    device->init();

    char data[100];
    device->read(data, sizeof(data));
    device->write(data, sizeof(data));
}

测试与验证

针对不同外设驱动，进行单元测试和集成测试，确保通过统一API调用能正常工作，同时满足性能要求。在各个驱动实现中，添加错误处理机制和日志记录功能，以便于调试和监控操作状态。

如何合理设计flash分区表

合理设计 Flash 分区表是确保嵌入式系统可靠性、可扩展性和性能的重要步骤。

确定需求

存储需求：首先，明确每个分区的用途（如固件、数据存储、配置等）以及需要多少存储空间。

读写特性：了解不同数据的读写频率，避免将高频操作的数据与低频操作的数据放在同一块区域，以提高性能和寿命。

确定分区类型

根据使用场景和需求，确定以下几种分区：

引导程序 (Bootloader): 存放启动代码，用于初始化系统并加载主应用程序。

主应用 (Application): 存放主要的应用程序代码。

文件系统 (File System): 用于存储用户数据或日志文件，比如 FAT 或其他轻量级文件系统。

配置信息 (Configuration): 保存设备的配置信息，如网络设置、用户参数等。

保留区域 (Reserved Area): 为未来可能需要的功能预留空间。

设置分区大小

根据需求设置合理的分区大小。一般情况下，应该为引导程序、主应用和文件系统预留足够空间，并考虑到未来升级或功能扩展所需的额外空间。

考虑冗余与备份

在某些情况下，可以设置冗余分区，例如双启动镜像。这可以增强系统的可靠性，因为即使一个分区损坏，另一个仍然可用。

避免碎片化

使用相对较大的连续块来减少内存碎片。在设计时，应尽量保持相邻逻辑块之间具有一定的物理位置关系。

定义访问策略

为了确保安全性和效率，可以为每个分区定义访问权限。例如：只读/可写：对于固件区域，可设为只读；而数据区域则应支持读取与写入。

制定错误处理策略

在设计阶段就要考虑如何处理坏块、擦除失败等问题。建议采取如下措施：实施坏块管理机制，通过重映射来管理损坏的物理块。

确定地址映射方式

清晰地定义逻辑地址到物理地址的映射规则，以便在运行过程中能够高效地访问各个分区。可以考虑使用线性映射或页表等方式来简化这一过程。

文档记录与版本控制

将 Flash 分区表设计文档化，包括每个分区的位置、大小及其目的。同时，为了便于以后的维护，应对设计进行版本控制，以追踪变更历史。

非掉电异常如何处理

非掉电异常（如操作系统崩溃、程序异常终止或其他硬件故障等）对系统的影响可能与掉电关机类似，但可以采取一些措施来缓解这些问题。

异常捕获和处理

使用异常处理机制：在编程语言中，利用try-catch块（或相似机制）来捕获运行时错误，防止程序崩溃。通过适当的错误处理，可以执行清理任务，比如释放资源、记录日志等。

全局异常处理：对于未捕获的异常，可以设置全局异常处理器，这样即使个别部分出现问题，也能保证程序不会立即崩溃，并能够执行某些清理操作。

定期保存状态

自动保存功能：对于用户交互性较强的应用，提供定期自动保存功能，以减少数据丢失的风险。例如，在文本编辑器中，每隔一定时间保存当前文档的副本。

检查点机制：在长时间运行的进程中，可以引入检查点机制定期保存状态，当程序发生异常时可以从最近一次检查点恢复，而不必从头开始。

日志记录(重点)

详细日志记录：实现全面的日志记录，包括正常操作日志和错误日志。在应用出现故障后，通过分析日志帮助开发人员快速定位问题根源。

监控工具：使用监控工具实时跟踪系统性能和状态，及时发现潜在的问题并进行预警。

恢复策略

重试逻辑：对于可恢复性的操作，如网络请求或数据库事务，可以实现重试机制。如果第一次尝试失败，可以在稍后重新尝试该操作。

回滚策略：对关键交易或变更实施回滚策略，在出现问题时将系统还原到上一个已知良好的状态。这通常在数据库事务中应用广泛。

测试和验证

单元测试和集成测试：确保代码质量，通过持续集成/持续部署（CI/CD）流程自动化测试，提高软件在各种情况下的健壮性。

压力测试：模拟极端负载情况，观察系统行为，以发现潜在瓶颈和脆弱环节，进行改进以提高稳定性。

定期备份

数据备份方案：为重要数据制定定期备份方案，确保即使发生非掉电异常，也能通过备份恢复数据。

非正常掉电如何保护

硬件层面的保护措施

使用 UPS（不间断电源）

UPS 是一种能够在市电断电时，为设备提供临时电力支持的设备。它包含电池、充电器、逆变器等组件。当市电正常时，UPS 对电池进行充电，并将市电稳压后供给设备；当市电断电时，UPS 的逆变器将电池的直流电转换为交流电，继续为设备供电。这样可以为系统提供一定时间的电力，让系统有足够的时间进行正常关机或数据保存操作。UPS 的容量（以伏安或瓦特为单位）决定了它能为设备供电的时长，在选择 UPS 时，需要根据设备的功率和所需的备用时间来确定合适的型号。

添加硬件看门狗电路

硬件看门狗是一个定时器电路，它需要在规定的时间间隔内被复位，否则会产生一个复位信号。在系统正常运行时，软件会定期地复位看门狗。当发生非正常掉电时，如果软件无法正常工作，看门狗定时器会超时并产生复位信号，使系统重新启动。一些复杂的看门狗电路还可以在复位后检测系统状态，例如判断是因为电源故障还是软件故障导致的复位，并且可以采取一些相应的恢复措施，如加载默认配置等。

采用非易失性存储设备备份关键数据

对于一些关键数据，可以使用非易失性存储设备进行备份。例如，EEPROM（电可擦除可编程只读存储器）或闪存（Flash Memory）。在系统运行过程中，定期将重要的数据（如设备的配置参数、运行状态记录等）写入这些非易失性存储设备。当发生掉电后，这些数据不会丢失，在系统重新上电后，可以从这些存储设备中读取数据，恢复系统的部分功能。同时，在向非易失性存储设备写入数据时，要注意数据的完整性和正确性，例如采用校验和或纠错码等方式。

软件层面的保护策略

数据备份与恢复机制

设计合理的数据备份策略，例如，对于数据库系统，可以采用事务日志的方式。在每个事务操作过程中，将操作记录到事务日志中，这些日志存储在非易失性存储介质上。当发生掉电后，在系统重新启动时，可以根据事务日志来恢复数据库的状态，确保数据的一致性。对于其他类型的应用程序，可以定期将数据的关键部分（如内存中的缓存数据、用户的操作记录等）保存到文件中。在恢复时，通过读取这些备份文件来重新构建系统的状态。

还可以采用数据镜像或冗余存储的方式。例如，在分布式系统中，将数据同时存储在多个节点上，当一个节点因掉电而丢失数据时，可以从其他节点获取数据进行恢复。这种方式可以提高系统的可靠性，但也增加了数据管理的复杂性和存储成本。

异常处理与状态记录

在软件中加入完善的异常处理机制，当检测到电源故障信号（如某些硬件平台会提供电源故障中断）时，尽可能地保存当前系统的状态信息。例如，记录正在执行的任务、打开的文件列表、内存中的重要变量值等。这些状态信息可以帮助在系统重新启动后，快速地定位问题并恢复到一个相对合理的工作状态。同时，对于一些无法完成的操作（如正在进行的文件写入操作），要进行适当的回滚或标记，避免数据损坏。

可以利用日志系统来记录系统的运行状态和重要事件。在发生掉电后，通过分析日志来了解系统在掉电前的状态，判断是否有数据丢失或系统损坏的风险。日志可以存储在本地的非易失性存储设备上，也可以发送到远程服务器进行存储，以提高日志的安全性。

系统检查点机制

建立系统检查点是一种有效的保护方法。在系统运行过程中，定期设置检查点，将系统的关键状态（包括内存数据、进程状态、设备状态等）保存到非易失性存储介质中。当发生掉电后，系统可以从最近的检查点恢复。这种机制类似于游戏中的存档功能，通过合理设置检查点的间隔和内容，可以在保证系统性能的前提下，最大程度地减少掉电造成的损失。在实现检查点机制时，需要考虑数据的一致性和完整性，避免在保存检查点数据的过程中出现新的问题。

如何用一套代码支持不同硬件

抽象硬件接口

定义抽象层：创建一个抽象接口（API），通过该接口与底层硬件进行交互。每个硬件实现都将实现这个接口。

// 示例抽象层
class HardwareInterface {
public:
    virtual void initialize() = 0;
    virtual void readData() = 0;
    virtual ~HardwareInterface() {}
};

具体实现：针对不同的硬件，创建具体类来实现该接口。

class HardwareA : public HardwareInterface {
public:
    void initialize() override { /* A 硬件初始化代码 */ }
    void readData() override { /* 从 A 硬件读取数据 */ }
};

class HardwareB : public HardwareInterface {
public:
    void initialize() override { /* B 硬件初始化代码 */ }
    void readData() override { /* 从 B 硬件读取数据 */ }
};

配置文件和动态加载

使用配置文件（如 JSON、XML 或 INI 文件）指定当前运行时使用的硬件类型，并在运行时动态加载对应的实现。这可以通过工厂模式来实现。

std::unique_ptr<HardwareInterface> createHardware(const std::string& type) {
    if (type == "A") return std::make_unique<HardwareA>();
    else if (type == "B") return std::make_unique<HardwareB>();
    
    return nullptr; // 错误处理
}

编译条件和预处理器指令

在 C/C++ 中，可以使用预处理器指令来根据目标硬件选择编译的部分。这可以让你在编译时选择不同的源文件或模块以支持不同的硬件。

#ifdef HARDWARE_A
#include "hardware_a.h"
#elif defined(HARDWARE_B)
#include "hardware_b.h"
#endif

插件架构

考虑将各个硬件驱动或适配器封装为插件，这样主程序在启动时会加载相应的插件。这需要设计好插件机制，一般可通过动态链接库（DLLs 或 SO 文件）来实现。

使用跨平台框架

如果可能，考虑使用一些现成的跨平台框架，如 Qt、SDL 等，它们本身就提供了对多种硬件和操作系统平台的支持。这些框架会为常见任务提供统一的 API，使得开发者不必关注底层差异。

不同代码编译后的存放区域有何不同

不同代码编译后的存放区域通常取决于编译器、构建系统、以及项目的配置设置。

源代码目录

描述：包含所有源文件，通常是 .c, .cpp, .h, .java 等格式。
示例路径：src/, include/

编译输出目录

描述：编译后生成的中间文件和最终可执行文件或库。这个目录可以分为几个部分：
中间文件（Object Files）：存放以 .o 或 .obj 后缀的对象文件，这些是编译阶段生成的，通常位于 build/ 或类似目录。
可执行文件：最终生成的可执行程序，可能位于 bin/、dist/ 或其他指定输出目录。
静态库与动态库：静态库（.a 或 .lib 文件）和动态库（.so, .dll, .dylib 文件）也会在特定目录下存放，通常在 lib/ 目录。

测试输出目录

描述：用于存放测试相关的构建输出，比如测试用例生成的二进制文件和报告。
示例路径：tests/output/

临时或缓存文件

描述：某些构建系统会产生临时或缓存文件，以加速编译过程。这些通常不需要版本控制，可以存放在一个单独的临时目录中。
示例路径：.tmp/, cache/

文档生成输出

描述：如果项目包含文档生成过程（例如使用 Doxygen），则文档将被存储在一个专门的文档输出目录。
示例路径：docs/output/

编译工具与构建系统对存放区域的影响；不同的工具链和构建系统可能有各自约定的存放区域。

例如：

Makefile：通常用户手动定义源代码、对象、可执行目标及其对应路径。
CMake：使用 CMake 的项目可以通过 CMakeLists.txt 定义多个输出路径，并支持多种构建类型（Debug、Release）。

阐述下release和debug编译的区别

Release 和 Debug 是两种常见的编译配置，它们之间有几个关键的区别，主要体现在编译选项、优化级别和调试信息等方面。

优化级别

Debug：通常不进行任何或极少的代码优化，以便在调试时可以保留源代码中的结构。有助于开发人员查看变量的真实值以及调用栈的信息。

Release：启用多种优化选项，可能包括循环展开、内联扩展、死代码消除等，这些优化能显著提高程序的执行效率。编译器会尽可能地重排指令和省略无用代码，以达到更高性能。

调试信息

Debug：会包含丰富的调试信息，使得开发人员能够使用调试器（如 GDB 或 Visual Studio 的调试工具）方便地检查程序运行状态。包括符号表和完整的函数名及变量名信息，可以逐行跟踪源代码。

Release：通常会去掉大部分或全部调试信息，从而减小生成文件的大小，并提升运行效率。调试信息很少或根本不包含，因此难以通过调试工具进行深入分析。

二进制文件大小

Debug：文件通常较大，因为它们包含了大量的调试信息。

Release：文件较小，因为经过了优化，且去除了不必要的调试信息。

性能

Debug：性能通常较低，由于缺乏优化，程序执行速度慢，更适合于开发和测试阶段。

Release：性能较高，适合用于生产环境和发布版本，可以有效利用计算机资源，提高执行效率。

使用场景

Debug ：适用于开发过程中，需要频繁修改和测试代码，以及进行功能验证和错误修复时。

Release ：适用于准备发布最终产品时，确保应用程序具有最佳性能并且没有冗余的信息暴露给最终用户。

ARM多核之间有多少通信机制及优缺点

在ARM多核系统中，核之间的通信机制主要有以下几种，每种机制都有其优缺点。

共享内存（Shared Memory）

优点

高效：由于所有核心可以直接访问同一块内存，不需要额外的数据传输。
易于实现：编程模型简单，可以使用标准的线程库（如POSIX线程）。

缺点

同步问题：需要通过锁、信号量等机制来控制对共享资源的访问，以避免数据竞争和不一致性。
增加复杂性：程序员需要管理同步和死锁等问题。

消息传递（Message Passing）

优点

解耦合：各个核心相互独立，降低了系统复杂度。
更易于扩展：添加或移除处理器不会影响到其他处理器的工作。

缺点

性能开销：涉及到数据拷贝和上下文切换，性能可能较低。
编程复杂度高：需要开发者理解消息队列、事件循环等设计模式。

中断（Interrupts）

优点实时性好：能够及时响应外部事件或任务调度。

缺点

上下文切换成本高，频繁中断会导致性能下降。
中断处理程序设计复杂，需要小心避免竞态条件和保证安全性。

环形缓冲区（Ring Buffer）

优点：高效FIFO结构，非常适合流式数据处理。

缺点：空间管理复杂，当缓冲区满时必须处理溢出情况。

远程过程调用（RPC, Remote Procedure Call）

优点：抽象化程度高，使得不同核心之间的通信像调用本地函数一样简便。

缺点：网络延迟以及序列化/反序列化开销可能影响性能，尤其是在实时系统中。

阐述下代码移植，有什么经验分享

代码移植是将软件代码从一个环境或平台迁移到另一个环境或平台的过程。这个过程可能涉及操作系统、编程语言、硬件架构等方面的变化。

目标平台

文档和规范：仔细阅读目标平台的文档，了解其支持的特性、限制和最佳实践。
工具链：熟悉目标平台上的编译器、构建工具以及调试工具。

保持代码可移植性

避免平台依赖：在设计时尽量减少对特定操作系统或硬件的依赖，比如使用标准库函数而非系统调用。
抽象层：通过接口或抽象类来隐藏具体实现，使得底层细节与业务逻辑分离，从而增强可移植性。

测试用例

在源平台上创建全面的测试用例，以确保功能一致性。测试用例可以帮助发现潜在的问题和差异。
移植后，在新平台上运行这些测试，以验证代码的正确性。

逐步移植

不要一次性迁移所有功能，可以选择从小模块开始逐步进行，逐步修复问题。
对于大型项目，可以考虑采用分支策略，将新版本与旧版本并行开发，以便于比较和回退。

处理第三方库

确认所依赖的第三方库是否支持目标平台。如果不支持，可能需要寻找替代品或者进行相应修改。
检查这些库的许可证，确保合规使用。

性能评估

在新的环境中测试应用程序性能，以识别潜在瓶颈，并根据需要优化。
注意不同平台之间可能存在性能差异，例如内存管理、线程模型等。

文档更新

在移植过程中及时更新相关文档，包括架构图、API 文档和使用说明。这有助于团队成员理解新环境中的变更。

自动化工具

使用静态分析工具检查代码兼容性，可以有效地发现潜在问题。
可以考虑使用跨平台开发框架（如 Qt 或 Xamarin）来简化某些类型的软件移植工作。

社区与资源

加入相关技术社区，与其他开发者分享经验并寻求建议。在网上查找开源项目和示例代码，可以为自己的工作提供启发。