两种硬件编程的风格：离线下载和在线交互

文章来源：乐聚机器人王松博士的《两种硬件编程的风格：离线下载和在线交互》

少儿编程教育+智能硬件似乎是天生的一对，二者的结合很容易产生1 + 1 > 2 的双赢局面。不管是在线编程教育企业，还是智能硬件企业，在接下来的发展中，都纷纷把目光聚焦在教育领域。

针对硬件编程的模式，在文杰的这篇《两种硬件编程的风格》（https://blog.just4fun.site/Hardware-Programming-style.html）中提到了 交互式与灌入式两种硬件编程风格，并且详细分析了二者之间的优劣。

离线下载运行

离线下载运行，使用一个 IDE 或者代码生成器生成一份代码(可能需要编译器编译)，然后烧写到硬件设备上运行这一段生成的代码。

生成代码的方式多种多样，这其中有文本编辑器编辑，或者少儿编程以积木块形式“拼搭”出一份代码。再通过拷贝、烧录等方式把代码下载到硬件 ROM、SD 卡或者其他存储介质中。硬件中的解释器根据下载的代码进行地址跳转，转译一行程序就立刻运行，然后再转译下一行，如此不停地进行下去。

目前图形化项目生成代码的项目比较多，大多数采用了 Google 的 Blockly 方案，这里列举部分

micro:bit MakeCode Editor（https://microbit.org/code/）

PiBakery: The easiest way to setup a Raspberry Pi（https://www.pibakery.org/）

BlocklyDuino is a web-based visual programming editor for arduino.（https://github.com/BlocklyDuino/BlocklyDuino）

还有市面上大多数的带教育属性的编程硬件产品；

如果使用过上面这些工具的话，会发现有一个共同点，那就是 UI 界面上一定会有个大大醒目的 下载(上传) 按钮，时刻提醒用户程序必须下载到硬件中，才能成功运行。

这种离线下载再运行的硬件编程风格也许是微控制器时代的产物，出于成本和功耗的考虑，从最经典的 C51 单片机到 ARM Cortex-M 系列的芯片的智能硬件产品，如果一个嵌入式工程师看到这套可能再熟悉不过了。在如 Keil、IAR、Arudino IDE 中编辑程序，语法检查和编译没有问题之后，烧录到单片机 ROM 当中。

那么基于微控制器开发出的可编程硬件产品自然而然就会遵循这样的传统。

在线交互运行

在线运行式的硬件编程，代码解释器运行在单独的环境中，硬件提供 API 接口供解释器运行代码时调用。没有代码下载这个过程。代码运行在 PC、Pad 或者手机上，程序运行过程中硬件始终需要与解释器保持连接(蓝牙、Wi-Fi 等)，随时准备响应解释器的请求。

在线运行图形化的项目有许多

Etoys（http://www.squeakland.org/）

Scratch3（https://scratch.mit.edu/）

codelab-scratch3（https://scratch3.codelab.club/）

codelab-adapter（https://codelab-adapter-docs.codelab.club/）

在交互式环境中，每个设备都是一个独立的插件，彼此之间互不干扰，需要设计好每个插件的消息格式。在类似 Scratch 的环境中彼此相遇组合，程序在 Scratch 里运行时动态获取或者控制每个插件设备的状态。以一种比较有趣且优雅的方式实现万物互联。

二者对比

关于二者的对比，在两种硬件编程风格的比较（https://blog.just4fun.site/Hardware-Programming-style.html）中已经有非常详细的对比。引用如下

1. 灌入式可以离线运行，只需要将代码烧入进去，即可脱离编程工具

2. 灌入式将带来优于交互式的实时性

3. 灌入式因为需要 Generate 代码，学生可以查看代码

作者站在编程教育是否真的需要离线运行？角度来看待离线离线烧录，同时交互式也可以做好实时性与代码生成。

离线下载编程与在线交互运行相比，代码运行在 MCU 上，这是优点也是缺点。首先这带来的好处就是轻量，程序运行时没有额外的依赖。但是缺点也很明显，那就是功能很单一，做不了复杂的运算。

举个例子， 现在有一个 Robot，程序脱机离线运行，它可以唱、跳、RAP和篮球，那如果想为机器人增加视觉能力怎么办？在 ARM Cortex-M 系列芯片上做图像处理目前实在是太勉强，因为它光是跑起来一个代码解释器都已经捉襟见肘。为了弥补这种缺憾，那就是再外接一块类似 Raspberry Pi 的板子或者 ESP8266 Wi-Fi 板用于简单的图像处理或请求云端 API。对价格敏感的硬件产品来说，这无疑又增加了不少时间和物料成本。

如果换一种思路，程序如果运行在 PC 上，所有与待编程设备之间的通信都是消息 (Message)，PC 的性能相较于 MCU，可以做任何复杂的任务和逻辑。这样其实让 MCU 的肩上的担子轻了很多，MCU 只需要做好外围控制，暴露接口即可。以 Scratch3 为例，如果 Robot 想获得视觉能力怎么办呢？非常简单，只需要提交一个视觉积木插件即可，代码检查，不同程序块之间的兼容性统统不需要考虑。在这样的交互式环境中，硬件设备可以轻松获取各种扩展能力。

兼顾？

那么有没有可以同时兼顾在线交互和离线下载的解决方案呢？似乎是可以做到的。

程序仍然是离线运行在 Robot 上，参考交互式的消息机制，只不过消息的发起方由 PC 转至 Robot，当 Robot 程序运行时，如果需要做图像识别，Robot 向 PC 发送请求，PC 将识别结果再返回给 Robot。这种方式看起来能够解决离线下载运行的痛点，将 PC 看做 Robot 的扩展外设。

但是如果 PC 上的消息接收进程被关闭，Robot 里的程序就无法正常运行。就会对用户出现一个困扰，PC 开启与否，会让同样的 Robot 程序呈现了不同的运行结果。当然作为弥补，可以跟用户解释这背后的逻辑……

结语

离线式受限于性能和成本，没有办法像在线式这么灵活和扩展，如果为了同时满足程序可以脱机运行又要扩展丰富，又要做不少的妥协。但是

• 编程教育是否真的需要离线运行？
  

• 就算脱机运行，真的就离得开 PC 吗？

参考链接

• 两种硬件编程风格的比较.（https://blog.just4fun.site/Hardware-Programming-style.html）

• A JavaScript library for building visual programming editors: Try Blockly（https://developers.google.com/blockly/）

• Arduino IDE（https://www.arduino.cc/en/Main/Software）