onnx2c

Onnx2c是一个将ONNX转换为C代码的编译器。它可以读取ONNX文件，并生成可以包含在项目中的C代码。

Onnx2c的目标是"微型机器学习"，即在微控制器上运行推理。为了使这一过程更简单，生成的代码具有以下特点：

不包含#include <stdio.h>（即没有printf()函数）
在编译时分配缓冲区。不使用动态内存分配或（大量的）栈内存
除标准C数学库外没有其他库依赖。（建议使用浮点硬件！）
对编译器友好，允许C编译器尽可能地优化输出
所有内容都包含在一个C文件中，便于项目管理

Onnx2c的设计理念是成为一个易于使用且无学习曲线的工具。如果你可以将训练好的神经网络导出为ONNX文件（例如PyTorch和Tensorflow都可以），并且你有一个可运行的微控制器项目，那么使用onnx2c将两者结合应该很容易。

为了更容易实现上述目标，onnx2c有一些非目标：

ONNX规范的完整覆盖。（目前，166个ONNX操作中有91个至少部分实现）
加速器支持
反向传播（即训练）

构建

确保已安装ProtocolBuffers库，例如：

Ubuntu: apt install libprotobuf-dev protobuf-compiler
MacOS: brew install protobuf

获取源代码：

git clone https://github.com/kraiskil/onnx2c.git
cd onnx2c
git submodule update --init

然后运行标准的CMake构建

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make onnx2c

常见问题

遇到`error: 'class onnx::ModelProto' has no member named 'ParseFromIstream';`错误？

如果你使用的是ProtoBuf 3.6或更早版本，需要对onnx/onnx/onnx.proto进行以下修改：

删除最后一行（即选项optimize_for = LITE_RUNTIME;）

使用ProtoBuf 3.12（例如Ubuntu 20.10及以后版本）则不需要进行此修改。

3.6到3.12之间的版本尚未经过调查。

遇到构建错误`void* __builtin_memset ... is out of the bounds ...`？

在（至少）protobuf 3.6版本上，该版本是Ubuntu 20.04的默认版本，当onnx2c以Release模式构建时会失败。

将上述构建步骤更改为cmake -DCMAKE_BUILD_TYPE=Debug .. 或者更新你的protobuf版本。参见kraiskil/onnx2c#39和onnx/onnx#4756。

使用方法

构建过程会创建onnx2c可执行文件。运行

./onnx2c [你的ONNX模型文件] > model.c

在model.c的末尾有一个名为'void entry(...)'的函数。在你的主程序中调用该函数来运行推理。函数参数名称与ONNX模型中的名称相同。

在编译onnx2c生成的代码时使用编译器选项-ffast-math（或类似选项）可以提高计算速度。详情请参阅GCC wiki关于浮点数学。

Onnx2c有几个优化过程来修改生成的输出：

张量联合优化，将中间张量包装在联合体中，以帮助编译器重用堆内存。
通过修改前置节点的输出张量来移除Cast节点。
针对AVR处理器的优化，将常量放入指令内存。
实验性量化选项，将浮点计算转换为整数计算。

./onnx2c -h可以打印出所有可用的命令行选项。

onnx2c在stdout上打印日志。可以使用-l N命令行选项设置日志级别。日志级别包括：

0 仅致命错误
1 onnx2c可能未正确实现的警告
2 通用信息（Release版本的默认级别）
3 调试：onnx2c执行过程的高级跟踪，用于调试模型
4 跟踪：用于调试onnx2c的详细信息

有一个辅助脚本可以在MCU开发板上初步运行任何.onnx文件。这个脚本旨在作为设计网络时的工具，用于查看网络是否适合目标设备，然后再开始训练网络。使用说明请参见脚本源代码和onnx2c开发文档。

开发

关于onnx2c开发的提示，包括测试，在单独的文件中有描述。

目标设备性能

或者说，如何从不完整的数据中进行推断。

在撰写本文时，只有一个ONNX神经网络使用onnx2c进行了基准测试 - TensorFlow Lite micro的"Hello World"正弦生成示例，并使用keras2onnx编译为ONNX。

该ONNX文件使用STM32CubeAI和onnx2c编译到运行STM32Cube HAL的STM32F411上，时钟速度为84或96MHz。在相同的项目和优化设置（gcc -O4）下，通过切换GPIO引脚测量推理时间，STMCubeAI生成的版本运行时间为490us，而onnx2c版本仅需20us。

请参阅下面的注释，了解RAM优化版本的描述。

内存消耗大致相似：

平台	text	data	bss	运行时间
STM HAL + onnx2c @96MHz	8276	1300	3060	20us
STM HAL + CubeAI @96MHz	14372	1696	2808	490us
OpenCM3 + onnx2c @84MHz	8236	1296	388	25us
--"-- (onnx2c RAM优化)	8236	12	388	29us

比较

同一神经网络模型在Shawn Hymel的YouTube视频中进行了测量，分别通过TFL和STM32CubeAI运行。使用的设备是80MHz的STM32L4。在那里，TFL版本耗时104us，而STM32CubeAI版本耗时74us。

Hymel使用的STM32L4是STM32F4的低功耗版本，因此L4肯定不应该比F4快。使用了相同版本的CubeAI。唯一的区别是Hymel将TFL模型输入给CubeAI，而不是上面测量中使用的ONNX模型。我不确定这是否相关，但到目前为止，这是我能想到的唯一可能解释差异的原因。此外，测量的ONNX模型不是从Hymel使用的TFL模型转换而来，而是使用教程重新训练的。但这很可能不是导致执行速度差异的原因。

确实需要更多的数据点...