控制器|嵌入式开发:开发伟大API的7个提示

控制器|嵌入式开发:开发伟大API的7个提示

嵌入式软件开发人员已经习惯于在基于微控制器的系统中工作在最低的、基本的硬件级别 。 摆弄和操纵位和字节是嵌入式软件开发人员天生要做的事情 。 嵌入式软件行业正在发生变化 , 这种变化要求嵌入式开发人员开始在更高的抽象层次上工作 , 这需要设计和创建 API(应用程序编程接口)来允许软件被重用 。 让我们来看看开发优秀 API 的七个技巧 。

1. 让它成为一个迭代过程
在设计 API 或 HAL(硬件抽象层)时 , 不要假设第一次一切都会顺利 。 没有一个 API 可以统治所有这些 , 并且期望创建这样的 API , 尤其是在一次尝试时 , 是一种失败的设置 。 相反 , 从一个 API 草案开始 , 期望它在未来的迭代中会略有改变 。 通常在三个或四个项目的过程中 , API 将稳定到进一步变化很小甚至不存在的程度 。
2. 检查多个微控制器数据表
如果计划是创建一个可在多个微控制器供应商之间使用的 API , 开发人员必须查看的不仅仅是一个微控制器数据表 。 开发人员应该为多个微控制器检查相同的外设 , 并列出所有常见和不常见的功能 。 通用功能应该被汇总到 API 中 , 因为它们无疑是行业标准功能 , 而不常见的功能只有在需要这些功能时才能在 API 扩展中实现 。
3. 每个模块使用不超过 10 个接口
人类的大脑只能始终如一地记住大约 10 到 12 条属于一起的信息 。 嵌入式开发人员的目标应该是保持他们的 API 不超过大约 10 个接口 。 远远超出这个数字会让人难以记住调用 , 还会使界面看起来很复杂 , 甚至可能会混淆理解 。 寻找使用控制和配置结构重构接口的方法 。

4. 测试前置条件和后置条件
一个出色的 API 实现不会假设调用函数或应用程序已经完成了它应该为函数正常工作的所有事情 。 开发人员应在 API 中使用断言来测试是否满足所有前置条件 , 甚至测试后置条件以确保 API 已成功执行其功能 。 不要像许多开发人员那样假设一切都已正确设置并且将正确执行 。 防御性地设计和实现接口 。
5. 逻辑命名约定
一个优秀的 API 将具有逻辑命名约定 , 使开发人员能够轻松识别和调用 API 接口 。 在 API 的前面使用神秘的字母通常会让开发人员摸不着头脑并质疑该符号的含义 。 在命名约定中明确并遵循最佳实践建议 , 例如从通用开始命名约定并朝着特定方向努力 。
6.提供扩展接口的方法
目标是创建一个易于理解和使用的简洁界面 , 同时包含开发人员在开发过程中需要的最常见元素 。 有时 , 嵌入式开发人员可能希望在微控制器中使用一些不常见的功能 , 例如每个微控制器可能没有的 GPIO 硬件去抖动 。 在这些情况下 , 开发人员将希望确保他们的 API 中内置了一种机制 , 允许扩展接口 。 这可以通过允许指向新接口结构的指针或通过创建对 API 的寄存器访问来实现 , 以允许创建低级操作和更高级别的接口 。
7. 在 API 中构建中断处理
为了确保正确处理中断 , API 开发人员可以更轻松地处理 API 内部的中断 , 从而使中断对 API 用户来说是一个黑匣子 。 这意味着需要有一种机制用于将函数分配给更高级别的应用程序代码中的中断处理程序 。 一种方法是将回调注册添加到 API 中 , 以便可以在应用程序代码中为中断分配其可执行代码 。 这允许 API 确保正确处理中断 , 但也允许开发人员使用他们自己的自定义代码覆盖这些默认值 。
【控制器|嵌入式开发:开发伟大API的7个提示】结论
如果开发人员想要降低成本和缩短上市时间 , 现在几乎需要开发 API 和 HAL 。 微控制器已达到与早期 x86 微处理器相当的复杂性、性能和功能水平 。 在当今系统如此复杂的情况下 , 必须设计 API 以最大限度地重用代码 。 这七个技巧应该可以帮助希望重用自己的代码的嵌入式开发人员更有能力开发自己的 API 和 HAL 。