Skip to content

Embedded Linux - Design Workflow

· 14 min

特别感谢

本文翻译自 jaycarlson 的 blog: So you want to build an embedded Linux system?

The first step is to architect your system. This is hard to do unless what you’re building is trivial or you have a lot of experience, so you’ll probably start by buying some reference hardware, trying it out to see if it can do what you’re trying to do (both in terms of hardware and software) , and then using that as a jumping-off point for your own designs.

第一步是设计你的系统. 除非你设计的东西非常简单或者你有大量的经验, 否则这是一件很难的事情, 所以你可能首先会购买一些参考硬件, 尝试看看它是否能完成你想要做的事情 (无论是硬件还是软件), 然后以此为起点进行你自己的设计.

I want to note that many designers focus too heavily on the hardware peripheral selection of the reference platform when architecting their system, and don’t spend enough time thinking about software early on. Just because your 500 MHz Cortex-A5 supports a parallel camera sensor interface doesn’t mean you’ll be able to forward-prop images through your custom SegNet implementation at 30 fps, and many parts reviewed here with dual Ethernet MACs would struggle to run even a modest web app.

我想指出的是, 许多设计人员在构建系统时过于关注参考平台的硬件外围选择, 而没有在早期花足够的时间考虑软件. 仅仅因为你的 500 MHz Cortex-A5 支持并行摄像头传感器接口, 并不意味着你能够以 30 fps 的速度通过定制的 SegNet 实现前向传播图像, 而且这里许多带有双以太网 MAC 的部件甚至难以运行一个简单的 Web 应用.

Figuring out system requirements for your software frameworks can be rather unintuitive. For example, doing a multi-touch-capable finger-painting app in Qt 5 is actually much less of a resource hog than running a simple backend server for a web app written in a modern stack using a JIT-compiled language. Many developers familiar with traditional Linux server/desktop development assume they’ll just throw a .NET Core web app on their rootfs and call it a day — only to discover that they’ve completely run out of RAM, or their app takes more than five minutes to launch, or they discover that Node.js can’t even be compiled for the ARM9 processor they’ve been designing around.

确定软件框架的系统需求可能相当不直观. 例如, 在 Qt 5 中实现一个支持多点触控的手绘应用程序实际上比运行一个用现代堆栈和 JIT 编译 (即时编译) 语言编写的简单后端服务器更节省资源. 许多熟悉传统 Linux 服务器/桌面开发的开发人员认为他们只需在 rootfs 上扔一个.NET Core Web 应用程序就万事大吉——结果却发现他们的 RAM 已经完全耗尽, 或者他们的应用程序启动时间超过五分钟, 或者他们发现 Node.js 甚至无法针对他们一直在使用的 ARM9 处理器进行编译 .

The best advice I have is to simply try to run the software you’re interested in using on target hardware and try to characterize the performance as much as possible. Here are some guidelines for where to begin:

我最好的建议就是简单地尝试在目标硬件上运行你感兴趣的软件, 并尽可能多地表征其性能. 以下是一些从选型的指南:

  • Slower ARM9 cores are for simple headless gadgets written in C/C++. Yes, you can run basic, animation-free low-resolution touch linuxfb apps with these, but blending and other advanced 2D graphics technology can really bog things down. And yes, you can run very simple Python scripts, but in my testing, even a “Hello, World!” Flask app took 38 seconds from launch to actually spitting out a web page to my browser on a 300 MHz ARM9. Yes, obviously once the Python file was compiled, it was much faster, but you should primarily be serving up static content using lightweight HTTP servers whenever possible. And, no, you can’t even compile Node.JS or .NET Core for these architectures. These also tend to boot from small-capacity SPI flash chips, which limits your framework choices.
  • Mid-range 500-1000 MHz Cortex-A-series systems can start to support interpreted / JIT-compiled languages better, but make sure you have plenty of RAM — 128 MB is really the bare minimum to consider. These have no issues running simple C/C++ touch-based GUIs running directly on a framebuffer but can stumble if you want to do lots of SVG rendering, pinch/zoom gestures, and any other canvas work.
  • Multi-core 1+ GHz Cortex-A parts with 256 MB of RAM or more will begin to support desktop/server-like deployments. With large eMMC storage (4 GB or more) , decent 2D graphics acceleration (or even 3D acceleration on some parts) , you can build up complex interactive touchscreen apps using native C/C++ programming, and if the app is simple enough and you have sufficient RAM, potentially using an HTML/JS/CSS-based rendering engine. If you’re building an Internet-enabled device, you should have no issues doing the bulk of your development in Node.js, .NET Core, or Python if you prefer that over C/C++.

What about a Raspberry Pi?#

用树莓派怎么样？

I know that there are lots of people — especially hobbyists but even professional engineers — who have gotten to this point in the article and are thinking, “I do all my embedded Linux development with Raspberry Pi boards — why do I need to read this?” Yes, Raspberry Pi single-board computers, on the surface, look similar to some of these parts : they run Linux, you can attach displays to them, do networking, and they have USB, GPIO, I2C, and SPI signals available.

我知道很多人——尤其是爱好者, 甚至专业工程师——在阅读到这里时可能会想, “我所有的嵌入式 Linux 开发都是用树莓派进行的——为什么我还需要阅读这篇文章?” 是的, 树莓派单板计算机从表面上看与这些部件相似 : 它们运行 Linux, 可以连接显示器, 进行网络操作, 并且提供 USB、GPIO、I2C 和 SPI 接口.

And for what it’s worth, the BCM2711 mounted on the Pi 4 is a beast of a processor and would easily best any part in this review on that measure. Dig a bit deeper, though : this processor has video decoding and graphics acceleration, but not even a single ADC input. It has built-in HDMI transmitters that can drive dual 4k displays, but just two PWM channels. This is a processor that was custom-made, from the ground up, to go into smart TVs and set-top boxes — it’s not a general-purpose embedded Linux application processor, so it isn’t generally suited for embedded Linux work.

并且就其价值而言, 安装在 Pi 4 上的 BCM2711 是一款强大的处理器, 在这方面它比本评测中的任何一个都要强大. 然而, 深入挖掘一下 : 这款处理器具有视频解码和图形加速功能, 但没有单个 ADC 输入. 它内置了可以驱动双 4k 显示器的 HDMI 发射器, 但仅有两个 PWM 通道. 这是一款从头开始定制的处理器, 专为智能电视和机顶盒设计——它不是通用嵌入式 Linux 应用处理器, 因此通常不适合嵌入式 Linux 工作.

It might be the perfect processor for your particular project, but it probably isn’t; forcing yourself to use a Pi early in the design process will over-constrain things. Yes, there are always workarounds to the aforementioned shortcomings — like I2C-interfaced PWM chips, SPI-interfaced ADCs, or LCD modules with HDMI receivers — but they involve external hardware that adds power, bulk, and cost. If you’re building a quantity-of-one project and you don’t care about these things, then maybe the Pi is the right choice for the job, but if you’re prototyping a real product that’s going to go into production someday, you’ll want to look at the entire landscape before deciding what’s best.

它可能是你特定项目的完美处理器, 但很多情况下并非如此；在设计初期就强迫自己使用树莓派会过度限制事物. 是的, 对于上述缺点始终有解决方案——比如 I2C 接口的 PWM 芯片、SPI 接口的 ADC 或带有 HDMI 接收器的 LCD 模块——但它们涉及外部硬件, 这会增加功耗、体积和成本. 如果你正在构建一个单件项目且不关心这些事情, 那么树莓派可能适合这项工作, 但如果你正在原型设计一个将来要投入生产的真实产品, 你在决定最佳方案之前应该审视整个市场.

A note about peripherals#

关于外设的说明

This article is all about getting an embedded application processor booting Linux — not building an entire embedded system. If you’re considering running Linux in an embedded design, you likely have some combination of Bluetooth, WiFi, Ethernet, TFT touch screen, audio, camera, or low-power RF transceiver work going on.

这篇文章主要讲述如何让嵌入式应用处理器启动 Linux——而不是构建一个完整的嵌入式系统. 如果你正在考虑在嵌入式设计中运行 Linux, 你很可能正在使用蓝牙、WiFi、以太网、TFT 触摸屏、音频、摄像头或 RF (radio-frequency, 射频) 收发器等技术的某种组合.

If you’re coming from the MCU world, you’ll have a lot of catching up to do in these areas, since the interfaces (and even architectural strategies) are quite different. For example, while single-chip WiFi/BT MCUs are common, very few application processors have integrated WiFi/BT, so you’ll typically use external SDIO- or USB-interfaced chipsets. Your SPI-interfaced ILI9341 TFTs will often be replaced with parallel RGB or MIPI models. And instead of burping out tones with your MCU’s 12-bit DAC, you’ll be wiring up I2S audio CODECs to your processor.

如果你来自 MCU 世界, 在这些领域你还需要学习很多, 因为它们的接口 (甚至架构策略) 相当不同. 例如, 虽然单芯片 WiFi/BT MCU 很常见, 但非常少的应用处理器集成了 WiFi/BT, 所以你通常会使用外部 SDIO 或 USB 接口的芯片组. 你的 SPI 接口 ILI9341 TFT 通常会被并行 RGB 或 MIPI 型号所取代. 而且, 你不会用 MCU 的 12 位 DAC 输出音调, 而是将 I2S 音频 CODEC 连接到你的处理器上.