嵌入式最简 IO 模型“最简 IO 模型”自然是输入直接输出,比如房间里的照明灯给电就亮,这是不需要嵌入式的。按现在的潮流说法,加嵌入式进去那得叫智能硬件。因此,嵌入式的最简 IO 模型就是在输入和输出之间加入“嵌入式运算平台”,如“图1”。 图1. 嵌入式最简 IO 模型 在嵌入式最简 IO 模型下的产品功能大多都相对简单,有明确的输入和明确的输出,也就是说嵌入式软件的运算过程是明确的。这是自然“面向过程”的情况,这种情况下选 举个例子来说就是现在小孩子都玩儿腻了的“巡线小车”,上电就跟着线跑。这个用 Arduino C 来实现就可以了,其实 Arduino 是 嵌入式受控 IO 模型所谓“嵌入式受控 IO 模型”可以认为是一个遥控智能车一样的设备。在受控模型下,嵌入式硬件平台多了一路“指令”输入。这时候不妨再加个显示器,用于显示当前处于“受控模式”还是“自动模式”,如“图2”。 图2. 嵌入式受控 IO 模型 这里引入的“模式”是一个软件概念,软件是有无限可能的,能加一个模式进去就有可能再加很多个模式。模式在软件流程上是一个环节,但这个环节如上所述有多种不同的可能,这种情况最适合用 即:软件上“单点多样”的情况下用 嵌入式终级 IO 模型随着人工智能的逐步发展,越来越多的算法需要强劲的 CPU 甚至 GPU,这都不是嵌入式平台能做的。嵌入式平台长于实时控制而非快速大量运算,因此需要与机载 PC 配合工作。这样种情况下的模型如“图3”。 图3. 嵌入式终级 IO 模型 这样的模型毫无疑问用 嵌入式软件的语言选择下面基于“嵌入式终极 IO 模型”展开说嵌入式软件的语言选择。在嵌软部分从前往后展开,首先是传感器输入数据。 传感器输入部分的语言选择图4. 传感器输入部分语言选择
上表根据软件的运行平台差异直接给出了选择建议,平台差异也决定了软件特性的不同。 对于医疗、工业、运输/铁路、航空航天设备、汽车、核应用、家电系列产品,一般生产出来之后嵌入式硬件将不再改变,这类产品开发就适合选择 C 语言。在这些产品上 C 语言占用资源相对少、较率相对高。因为硬件固定所以软件源文件数量也是明确的,源码文件管理的负担也不重。另外传感器驱动开发这件事本身就是“面向过程”的,开发经验是决定开发效率的关键,“面向对象”在开发效率上的优势于这种情况下很难体现出来。 对于玩具、教具类产品或者是开源软件,灵活适配同类硬件是基本要求。这类嵌软的特点是同一种硬件需要适配不同厂家、不同型号的“同功能设备”,这就符合“面向对象”的思想。就以 GPS 来说,不论哪个厂家都要输出经纬度、速度、时间戳这些数据,我们可以把这些共性数据做成 嵌入式运算部分的语言选择图5. 嵌入式运算部分语言选择 这一部分的软件特性是:算法与硬件平台无关。算法本身是数学和逻辑,平台提供运算能力,因此运算部分理应在任何运算能力达到要求的平台上都能够运行。另外算法本身具有多样性,一个目标往往不只一种算法可以达到。 “单点多样”、“跨平台”这两点对软件代码的文件管理都有比较高的要求,这些要求用 协议数据部分的语言选择图6. 协议数据部分语言选择 协议本质是对传输数据的打包和解包,这是一个面向过程的事,所以用 从数据传输方面考虑,在把数据送给协议代码打包前,最好将数据分类,以明确数据是“给谁”和“干什么”的,这些事 Sugar 统称为“协议数据管理”。从嵌入式软件整体来看“协议数据管理”就是整体中的“一个点”,而嵌入式平台的通信对象可能不唯一,比如“图6”中就有给显示器的和给机载 PC 的,也就是说管理起来是“多样的”。这从软件整体来看也是一个典型的“单点多样”,所以协议数据管理这部分选 |
|
来自: 新用户0118F7lQ > 《文件夹1》