嵌入式软件开发 软件开发-c#软件嵌入谷歌地图

嵌入式开发可能面临的问题1 并发问题

程序并发效率低 在编写裸机软件时，难免会在主程序中出现一个超大的while(1)循环，它包含了整个项目几乎所有的业务逻辑。 因为每个业务逻辑都会有延迟等循环等待功能，导致几乎所有的业务逻辑都是串行工作的。 这时候CPU就会在延时函数中浪费大量的时间，一直在闲置，导致软件的并发效率非常差。

2 模块化：高内聚低耦合原则

从软件工程的角度来看，我们在做软件开发的时候，会强调高内聚、低耦合的原则。 裸机的模块化开发难度很大，模块之间的耦合度很重，这也导致在大型项目中无法使用裸机进行开发。

还是刚才main函数中的big while(1)的例子。 可想而知，这么多功能紧紧挤在一个功能里，不可分割，模块化开发困难重重。

举个很贴切的例子，在一些用到watchdog的项目中，如果使用了delay功能，一定要注意。 如果延迟时间过长，主函数来不及喂狗，就会触发看门狗。 到头来会有这样一种感觉，简单的延迟还要考虑喂狗功能，裸机开发过于用心，自然无法应用于大型项目。

3 生态：很多高级软件组件必须依赖操作系统来实现

比如我几年前开源了一个基于FreeModbus的Modbus主机协议栈。 因为需要考虑各种平台的适配，本来打算支持各种操作系统，甚至是裸机平台。 在各个操作系统上的适配都非常容易，但是在尝试裸机适配时，却发现困难重重。 有些功能在裸机上实现起来非常复杂，对于不同的裸机环境几乎没有普适性。 说，这需要太多的能量。 所以最终放弃了裸机适配，直到现在，还是无法在裸机上使用这个Modbus主机协议栈。

还有一些软件是不能在裸机上运行的，比如：乐鑫、Realtek、ti 和联发科提供的WIFi SOC SDK，还有一些蓝牙SOC SDK只支持操作系统，所以如果不了解或者知道如何使用操作系统系统，这些芯片就不会工作。

4 实时性：在功能复杂的情况下，无法保证实时性

一些领域对软件的实时性有一定的要求，软件的每一步都必须在指定的时间触发。 工控领域是最常见的场景。 如果不能保证实时性，机械设备可能无法按规定的定时要求运行，从而可能发生机械事故，甚至危及人的生命安全。 回过头来看裸机软件，如果软件变得庞大，可以想象主程序中这么大的while(1)循环，代码耦合严重，到处都是延迟。 几乎不可能保证实时性。 的。

5 Reusability：软件可重用性差，总是要重新发明轮子

可重用性与模块化程度直接相关。 相信每个人都不想在工作中做很多重复性的工作。 同样，在写代码的时候，也希望功能相似的代码尽量少写。 但在这个嵌入式碎片化极其严重的时代，各种芯片在裸机环境下同时适配同一代码到不同的硬件是非常困难的。 这也导致了裸机的代码过于依赖底层硬件，重复造轮子的过程在所难免。

RTOS带来的优势

第一次接触操作系统是在2010年左右，那时候STM32已经火了。 很多人在这么强大的单片机上运行操作系统。 我也移植了ucos，在上面跑ucgui。 这时候写应用是一种全新的体验，非常爽。 ucos玩了一年，才接触到我们国产的RT-Thread。 上面有很多现成的、可以使用的组件。 试用后发现，更好的是，一直用到今天，大概8年了。 也跟大家说说操作系统的优点：

基于线程的并发任务处理，在保证实时性的同时，解决了模块化问题

1 模块化

使用操作系统后，整个软件的工作被分成多个任务（也叫线程）。 每个线程都有自己独立的运行空间，即线程栈。 这时候，每个线程你玩你的，我做我的嵌入式软件开发 软件开发，大家相得益彰，模块化程度有了很大的提高。

2 并发

从并发的角度来看，每个线程在使用delay/event waiting这样的函数时，都会自动把CPU让给其他有需要的线程。 它也得到了改进，最终提高了并发性。

3实时

从实时性能来看，ucos/RT-Thread等RTOS被设计为实时操作系统。 每个线程都有不同的优先级。 重要的线程可以设置为高优先级，不重要的线程可以降低。 整体统筹做好后，整个软件的实时性也能得到保证。

4 开发效率

由于操作系统提供了统一的抽象接口层，方便了可复用组件的积累，提高了开发效率

操作系统其实是一群软件专家智慧的结晶。 它们从应用软件和底层驱动开发的角度，封装和抽象了很多常用的软件功能，如信号量、事件通知、邮箱、环形缓冲区等。 ，单向链表/双向链表等，这些函数都是现成的，对开发者来说非常方便

还有一些操作系统，比如：Linux和我们国产的RT-Thread。 这些系统针对零散的硬件统一封装了一套标准的硬件操作接口，一般称为设备驱动框架。 这样，我们的应用软件工程师就可以专攻应用工作，再也不用害怕更换硬件、重新发明轮子了。

5 软件生态

生态的丰富带来了量变到质变的过程：

从一个人玩到和大家一起玩。

使用操作系统带来的软件模块化和复用性的提高，也使我们在进行软件开发时，能够封装出一套基于操作系统的、适合嵌入式的可复用组件。 这些组件不仅可以用在我们自己的项目当中，还可以开源共享给更多有需要的嵌入式开发者，让软件的价值最大化。

我个人觉得这是一件很有意义的事情。 我自己也是一个开源极客，也在GitHub上开源了一些嵌入式软件。 说实话，在做开源软件之前，能深入交流嵌入式软件的地方很少。 毕竟每个人的代码都是不一样的芯片，或者硬件不一样。 如果你给他你的代码，它可能无法运行。 但是自从使用了操作系统之后，软件的复用性提高了，让更多的人可以快速的使用我的开源软件。 这个时候可以有更多的人一起交流，也接触到了很多大金牛座，甚至是国外的朋友。 俗话说：水涨船高，我的能力也从此飞速提升。 所以综上所述，有个能互相交流的嵌入式软件圈子还是挺重要的。 如果你闭门造车，你可能是在重新发明轮子。

常见RTOS比较

ucos/freertos/RT-Thread，之所以选择这三个OS，是因为它们的寿命都比较长，在市场上的知名度也比较高，用的人也比较多，比较有说服力。 值得一提的是，CubeMX工具中有FreeRTOS，支持非常方便。 如果是STM32开发，FreeRTOS基本是入门级RTOS的首选。

1 各种RTOS的基本功能和性能差异很大，可比性不是很大。 2 Ease of use/readability 这块FreeRTOS应该说是最差的嵌入式软件开发 软件开发，怪异的匈牙利命名法，代码实现大量使用宏，可读性很差。 ucos的可读性还不错，评论也很全面。 这个最好用RT-Thread来做，它是类Linux的代码风格，面向对象的设计模式，代码简洁易懂。 在保证体积（最小ROM：3K RAM：1.5K）的同时，还借鉴了Linux的设备驱动框架、虚拟文件系统、Shell等功能，使设计更加优雅。 3 组件丰富度 相比传统的UCOS和FreeRTOS，RT-Thread不仅拥有更多的基础功能，而且拥有超过50个可复用的软件组件，物联网组件也非常多。 它几乎是开箱即用的物联网产品。 RT-Thread还可以运行Python、Java、Lua等高级语言的脚本，进一步降低开发难度。 4 开发资料 ucos最好，还有相关书籍。 FreeRTOS是后起之秀，网上有很多相关资料。 之前RT-Thread还是有点薄弱，现在RT-Thread非常重视这方面。 最直观的就是看到官网上的应用笔记越来越多，还有一些配套的教学视频。 5 版权 ucos 业务是收费的，FreeRTOS 和RT-Thread 版权很松，尤其是RT-Thread 刚刚使用了Apache 许可协议。 6 社区生态 这三款RTOS的社区都比较活跃。 现在我们可以感觉到使用ucos的人数在逐渐减少，而使用RT-Thread和FreeRTOS的人数在增加。 RT-Thread也是国内开发者最多的RTOS，也拥有国内最大的嵌入式开源软件社区。相关建议