rust 是否可以用于8051单片机开发工作？ （*）

目录

rust 是否可以用于8051单片机开发工作？ （*）
https://blog.csdn.net/ken2232/article/details/130665002

思考：在纷纷嚷嚷的喧哗中，选择适合自己的计算机语言 （*****）
https://blog.csdn.net/ken2232/article/details/130753427

世界是不断变化的，现代 MCU技术的不断发展，使得 MCU的能力越来越趋近于早期的电脑，并且，还会越来越趋向于现代的电脑。

----------------------------------------------------------

Debian 12 + NVIDIA驱动：给人工智能爱好者的安装指南 
  https://blog.csdn.net/CanvaChen/article/details/131254870

Linux内核6.1带来了一些新的特性和改进，例如：

    支持Rust语言编写内核代码，提高内核的安全性和可靠性。
    引入MG-LRU算法，优化内存回收和提高系统性能。
    改进Btrfs文件系统的性能。

说明：看来，未来 rust 会成为新的趋势 ？

==================================

8051 的编程模型和 x86、arm 区别相当大。就算标准 C 语言也难以表达，于是 Keil 给 C 加了一堆语言扩展，搞出了一个keil C 语言。

如果 Rust 要支持 8051，首先 LLVM 要有相应后端，要能自定义 8051 专用的编译链接选项，然后 Rust 核心库要提供对应的类型属性、内置函数等基础设施，最后才是外围生态。

总结：工作量大、实现麻烦、被 LLVM 卡住，大概率吃力不讨好。

现在 Rust 对 AVR 已经有了一些支持，至少能在 Arduino 上点灯了。

嵌入式 Rust 资料最多的领域应该是 STM32 和 RISC-V，欢迎踩坑。

发布于 2021-12-13 19:29

目前现状是LLVM官方8bit后端只支持avr，所以Rust唯一的8bit target也只有avr。很久以前LLVM有一个C backend，可以配合SDCC生成51代码，不过这个C backend被干掉了，目前有一些第三方的项目还在继续维护这个cbe，但想要Rust支持还得自己改改Rust那头的target。发布于

2021-12-18 01:04

这活不是rust负责的，是llvm负责的，需要llvm实现一个8051指令集的后端。

发布于 2021-12-13 18:24

MCU不建议使用rust,因为几乎不使用动态内存分配.

全局变量满天飞、其实也很方便.

不存在内存泄漏的问题.

都是静态变量.

发布于 2022-10-22 13:06

cpp都未舍得用,内存少,其实更需要c能支持到c20的常数及常量声明优化

发布于 2022-12-14 23:00

不支持。

> rustup target list
aarch64-apple-darwin
aarch64-apple-ios
aarch64-apple-ios-sim
aarch64-fuchsia
aarch64-linux-android
aarch64-pc-windows-msvc
aarch64-unknown-linux-gnu
aarch64-unknown-linux-musl
aarch64-unknown-none
aarch64-unknown-none-softfloat
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armebv7r-none-eabi

armebv7r-none-eabihf
armv5te-unknown-linux-gnueabi
armv5te-unknown-linux-musleabi
armv7-linux-androideabi
armv7-unknown-linux-gnueabi
armv7-unknown-linux-gnueabihf
armv7-unknown-linux-musleabi
armv7-unknown-linux-musleabihf
armv7a

-none-eabi
armv7r-none-eabi
armv7r-none-eabihf
asmjs-unknown-emscripten
i586-pc-windows-msvc
i586-unknown-linux-gnu
i586-unknown-linux-musl
i686-linux-android
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-freebsd
i686-unknown-linux-gnu
i686-unknown-linux-musl
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips64-unknown-linux-gnuabi64
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-gnuabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
nvptx64-nvidia-cuda
powerpc-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
riscv32i-unknown-none-elf
riscv32imac-unknown-none-elf
riscv32imc-unknown-none-elf
riscv64gc-unknown-linux-gnu
riscv64gc-unknown-none-elf
riscv64imac-unknown-none-elf
s390x-unknown-linux-gnu
sparc64-unknown-linux-gnu
sparcv9-sun-solaris
thumbv6m-none-eabi
thumbv7em-none-eabi
thumbv7em-none-eabihf
thumbv7m-none-eabi
thumbv7neon-linux-androideabi
thumbv7neon-unknown-linux-gnueabihf
thumbv8m.base-none-eabi
thumbv8m.main-none-eabi
thumbv8m.main-none-eabihf
wasm32-unknown-emscripten
wasm32-unknown-unknown (installed)
wasm32-wasi
x86_64-apple-darwin
x86_64-apple-ios
x86_64-fortanix-unknown-sgx
x86_64-fuchsia
x86_64-linux-android
x86_64-pc-solaris
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc (installed)
x86_64-sun-solaris
x86_64-unknown-freebsd
x86_64-unknown-illumos
x86_64-unknown-linux-gnu
x86_64-unknown-linux-gnux32
x86_64-unknown-linux-musl
x86_64-unknown-netbsd
x86_64-unknown-redox

          

发布于 2021-12-13 16:34

问题 1：假如目前 Rust语言最先进，那么，它可以运用于自己的工作中吗？

答案：可以，或者不可以。

思考：

最先进的东西，未必适合自己。

假如是做偏重于纯软件的数值运算类开发工作，那么，大概率 Rust语言可以运用于自己的工作中。

假如是做偏重于嵌入式的控制开发类工作，那么，大概率 Rust语言不能运用于自己的工作中。

嵌入式开发所针对的目标式具体厂家的 CPU/MCU芯片，它需要有支持该芯片的相关软件开发工具的支持。

标准 Rust语言未必能够支持到自己所选用的 MCU芯片，嵌入式软件开发工具，往往需要对标准的计算机语言进行修改之后，才能运用、或更好地运用于嵌入式开发。比如：keil C就是对标准 C进行修改，以便适合于具体 MCU的开发。

作为“嵌入式软件开发工具”的厂家，目前最先进的计算机语言（受到商业利益、技术瓶颈、或时间瓶颈等的限制。这点与人类通用语言有着本质的区别）未必适用于用来开发“嵌入式软件开发工具”。

只有当标准 Rust语言大量流行之后，它才有可能被“嵌入式软件开发工具”厂家所考虑，然而，就算 Rust语言先进，也未必会适合运用在“嵌入式软件开发工具”中。移植、适应性修改等等，这些都并不是一件简单的事情。

从通用语言标准的诞生，到通用编译开发工具链的配套，这需要5~10年的时间，参考C++的时间表。

从用编译开发工具的配套，到“嵌入式软件开发工具”的诞生，这也需要以“年”为计算单位的时间长度。

对于嵌入式开发工具而言，一种新的计算机语言是否合适运用于“嵌入式开发”，这是“嵌入式软件开发工具”的厂家所要考虑的问题。

对于嵌入式开发工作者而言，自己所要选择的是具体的 MCU，以及与之配套的“嵌入式软件开发工具”。

一般不应该跳过“嵌入式软件开发工具”的工作，直接去考虑所使用的先进的、标准的计算机语言来进行嵌入式开发；因为这样需要花费大量额外的时间和精力去做本该属于“嵌入式软件开发工具”厂家所要做的事情。

世事没有绝对：：对于有些嵌入式应用场景，是可以考虑直接使用最先进的计算机语言来完成一部分工作的。

比如，在先进的标准语言编译器所已经默认支持的MCU中，可以。

又如：可以将先进的标准语言程序打包成函数库来使用的场景。

人们应该将目光聚焦到创造上，产品上，而不应该聚焦在计算机语言的工具上；

除非这种工具不能满足产品的短期、中期，甚至长期的目标要求，这才需要我们重新选择语言工具，或是需要创造出新的语言工具。（这点与人类通用语言有着本质的区别，人类通用语言的选择和创造，会受到人性等等的影响）。

计算机语言只是工具，创造出优秀的产品才是目的。假如在合理的时间长度之内，由于语言学习难度、工具缺失等等的因素，导致无法满足创造出产品的时间进度要求，那么，再优秀的计算机语言也是白搭。

工具，哪怕是再优秀的工具，也是被利用、被使用的对象而已。当然，优秀的工具，可以加速或更好地实现出产品。需要合理地分配时间的比例。

是因为人类需要不断的创造，才会不断地涌现出各种各样新的计算机语言。各种各样计算机语言的涌现，是人类不断创造的结果。创造产品与计算机语言工具之间，不应本末倒置。

对于 MCU，以及控制类简单应用的嵌入式开发，可能根本就不需要考虑多线程，以及堆内存的分配，因此，C语言就已经足够啦；

再就是 C++，与C兼容，在简单的嵌入式开发中，就算有多线程和堆内存的应用，也属于简单的应用，使用 C++已经足够满足要求了。

要以人的需求为产品设计的目标：

空掉遥控器其实只需要有限的几个简单的按键，如果使用万能遥控器来遥控普通空调的话，反而会让人难以使用；太多按键，反而使用体验不好了。

在 51系列的 MCU上，根本就不需要考虑线程安全，内存泄漏之类的问题，因此，Rust的优点，在 51MCU看来就是富余的、臃肿的、而外的东西，C才是最佳的语言。

尺有所短，寸有所长。在离开了具体的应用场景之后，将无法选择出所谓的最恰当的计算机语言。这点与人性通用语文不同。

对于 MCU芯片厂家而言，汇编语言才是重要的工具，因为 MCU厂家常常需要堆芯片引脚的时钟周期进行以一个脉冲单位级别的调整。越是高级的语言，可能越是无视 nop()。

在家里洗一个热水澡，搞一个家用热水器就可以了；没有必要弄一个能够满足一千人同时使用的锅炉来烧。由此将会带来硬件成本，或者其他成本的增加。

没有可以包治百病的药，也没有无所不能的计算机语言。所谓的最佳，只不过是一种折中占优的选择结果。

思想斗争与心理建设：“根据用途”来选择“开发工具”。

不应该根据工具来选择工具，而无视用途。

选择鸡刀？还是牛刀？

根据工具来选择工具：鸡刀所用精钢半斤，牛刀所用精钢五斤，精钢型号完全相同；每把的单价竟然是一样的。

顾客A：哇：相同的价钱，买牛刀，多赚到了4斤半的精钢，赚大发了；可惜会造成杀鸡的效率降低了，赚钱的效率也就变低了。。

顾客B：俺是杀鸡的，要买鸡刀。虽然买鸡刀亏了4斤半精钢的钱，但杀鸡的效率提高了，赚钱的效率也就提高了。

道具老板：单纯从金钱的角度而言，买牛刀赚了刀具的钱，却亏了杀鸡赚钱的效率；买鸡刀亏了刀具的钱，却赚了杀鸡赚钱的效率。对于具体的客户而言，在考虑时间成本的前提下，总体而言：这两种做法，其实它们的盈亏总收益，似乎相差无几的。

 旁观者：奸商，绝对是奸商！！

赚了？还是亏了？

时间，是人类个体最为宝贵的不可再生资源！！

 在离开了具体的应用场景之后，其实，都是在扯淡！

有人说：C语言比汇编好。

有人说：C++很烂。

有人说：Rust比 C++更先进。

尺有所短，寸有所长。没有包治百病的药，也不存在无所不能的计算机语言。

在离开了具体的应用场景之后，将无法选择出所谓的最恰当的计算机语言。这点与人性通用语文不同。

再次强调：时间，是人类个体最为宝贵的不可再生资源！！

变是永远的不变。在未来，一定会诞生比 当前C语言更先进的未来C语言，当前C++更先进的未来C++，这是肯定的。

但是，其他配套的支持环境和开发工具链呢？

在某个具体的应用场景里：

如果离开了“时间成本”来考虑问题，那么，当前最先进的计算机语言，就是最好的开发工具。

但是，

时间，是人类个体最为宝贵的不可再生资源！！

因此，

如果考虑到“时间成本”来处理问题，那么，当前最先进的计算机语言，很可能是最糟糕的开发工具。

缺乏足够的生态支持，缺乏a、b、c、d、.......

在时间轴上，计算机语言与人类通用语言有着本质的不同。人类通用语言的寿命远远长于人类个体寿命，因此，所要考虑和关心的焦点，是不一样的。

最终用户，可能并不关心到底是采用什么样的计算机语言来实现的，而是仅仅关心最终产品的外在功能和表现形式。

时间成本，具体应用场景，产品迭代成本：应该作为考量和选择使用哪一种计算机语言的关键要素。

掐头去尾，没头没脑地鼓吹：C语言比汇编好；C++很烂；Rust比 C++更先进。全是扯淡。

注意：以上思考，不再更新。

转移到：

https://blog.csdn.net/ken2232/article/details/130753427