不高端。我本来想收台工业级的3d打印机回来改造的。好不容易有台看中的聊了半天人家又不卖了。
一怒之下找个比较好的开源方案先搭起来后面再改造。

你这个学了一天也没法多要求你什么...rust确实学习曲线还是比较陡的...
但你想下，这么典型的需求，怎么可能支持不了...

我先贴段代码：
#[derive(Debug)]
enum SafeIntOrFloat {
    Float(f32, f32),
    Integer(i32, i32),
}

union IntOrFloat {
    i: u32,
    f: f32,
}

fn main() {
    let mut a: SafeIntOrFloat = SafeIntOrFloat::Float(0.1, 0.2);
    println!("enum: {:?}", a);
    a = SafeIntOrFloat::Integer(2, 3);
    println!("enum: {:?}", a);

    let mut b: IntOrFloat = IntOrFloat { i: 1 };
    b.i = 2;
    let i = unsafe { b.i };
    let f = unsafe { b.f };
    println!("union: {} {}", i, f);
}

这段代码要讲2个事情，首先rust可以随时用unsafe退回到c状态，比如c版本的union在rust里面也叫union，只不过是unsafe的，需要封装一下把unsafe包起来，如这段代码所演示的。你要是嫌封装unsafe是脱裤子放屁，那可以直接把所有代码都用unsafe来写，只不过这样用rust是为了图啥呢...

其次rust里更好的做法是不要用union这么原始的（直接操作内存的）东西，而是应该用enum。enum的作用和union本质上是一样的，也是同一块内存，记录不同类型的数据。但它已经封装好了不需要你去考虑具体的内存问题。当你需要把enum转换成数据流发出去的时候，你给他整一个serializer/deserializer。这才是更为通行的做法。

当然这个做法性能是有损失的，serdes一般来说会有协议结构，会有内存复制。而c下面的做法其实本质上就是个dummy serdes，也即直接把内存指针指向的内容丢出去。但这个方法本身就是诸多问题的根源，诸如alignment，big/little endian等等。rust里面理论上也可以做个类似的dummy serdes，但enum是有额外的内存占用来记录更多的meta信息，我相当怀疑这么搞的通用性。

总的来说，田园时代就是眉毛胡子一把抓，而现在系统复杂了之后是很讲抽象和设计的。好的设计可以把问题消灭于无形。比如你用c处理网络数据的时候要手动做big/little endian转换，这个本质上就是人肉实现的serdes，这种东西本身就不应该让人去操心。


【 在 dismoon 的大作中提到: 】
: 什么高端3D打印机还有上位机？
: 现在的3D打印机不都是直接弄个TF卡上面拷了STL或者STEP就能打印的么
: 说到rust的指针，我就举个例子
: ...................
--
修改:lvsoft FROM 180.111.26.*
FROM 180.111.26.*

【 在 dismoon 的大作中提到: 】
: 你这段代码的局限就是你还是认为我在发送一串“数据”
: 可能我的场景的确很小众
: 本来我是用一块Si24R连在UART上收发我一台机器的运行数据，现场工人就不用拆机器盖，连上线，导出数据了（场景特殊，不能在机器上开个口子做个USB或者其他接口，必须经常性密封）
: ...................
--
FROM 180.111.26.*

mcu场合rust的工具链没啥不好的啊。我之前就介绍过，
比如st那个用c写的跟shit一样的hal库...跟rust对比就是天上地下。
只有具备rust这样强大的抽象能力之后，才有可能写出真正有价值的hal库。

比如你看看这里的example：
https://github.com/stm32-rs/stm32f4xx-hal/tree/master/examples

我贴个pwm的：
#![deny(unsafe_code)]
#![no_main]
#![no_std]

// Halt on panic
use panic_halt as _;

use cortex_m_rt::entry;
use stm32f4xx_hal::{
    pac,
    prelude::*,
    timer::{Channel1, Channel2},
};

#[entry]
fn main() -> ! {
    if let Some(dp) = pac::Peripherals::take() {
        // Set up the system clock.
        let rcc = dp.RCC.constrain();
        let clocks = rcc.cfgr.freeze();

        let gpioa = dp.GPIOA.split();
        let channels = (Channel1::new(gpioa.pa8), Channel2::new(gpioa.pa9));

        let pwm = dp.TIM1.pwm_hz(channels, 20.kHz(), &clocks).split();
        let (mut ch1, _ch2) = pwm;
        let max_duty = ch1.get_max_duty();
        ch1.set_duty(max_duty / 2);
        ch1.enable();
    }

    loop {
        cortex_m::asm::nop();
    }
}
这才是写给人看的代码。

最后，如果你想用新的工具，享受它带来的好处，那首先是你得要用新的姿势去使用新工具。
比如给你一台联合收割机，你非说喜欢用镰刀亲自一茬茬割的感觉，用联合收割机又要加油又要维护启动半天就割一亩地是脱裤子放屁...那这个确实没啥办法，只能说你不需要联合收割机...

【 在 dismoon 的大作中提到: 】
: 最主要是MCU场合rust的工具链不好吧
: 我没说rust不能实现我的需求，我就是说，我本来好好的用一个强制double的地址赋值给char就能得到数据内存所在的指针，rust要绕一大圈脱几条裤子才能实现，unsafe就是那几条裤子
:
--
修改:lvsoft FROM 180.111.26.*
FROM 180.111.26.*

rust其中的一个目标是跟c同等地位，也即c能做的rust一定能做。
就说指针好了，mcu里的寄存器全部都是定义一串地址偏移量的指针。c里面都是一个头文件里面裸地址直接写在上面然后强制转换成指针。

rust当然也可以这么写，但给rust做hal库的人每这么做。他们的做法要安全并且严格的多。它利用rust的宏特性直接导入mcu厂方给出的svd文件。除非你去改svd，否则压根不存在改错的可能。当然，厂方也是会犯错的，所以这个导入svd文件的功能还有patch能力，可以按需要导入base svd，patch svd等等。
然后，因为是svd文件，所以rust对寄存器的操作可以精确到每一个bit的可读写性，以及humanreadable的可读性，和对每一个bit都有注释的完整文档。
比如同一个bit，读出来的值和写入的值的名字都是不一样的。比如读出来叫enabled，写进去得写enable，你如果写enabled直接就一根红线画上去提示你这里不对了。

至于安全特性对mcu是否有用，我只能说这就是嵌入式行业明明发展的时间和软件行业差不多久，应用规模也差不多大，但为啥生态规模相比之下小的可以忽略不计。就是因为大家都缺乏这种合作的思想，都满足于自己的一亩三分地，重复造自己的那个小轮子。自己在家做轮子，当然不需要上下游产业链配套了。而当你需要依赖生态的时候，安全特性就是相当重要的问题。

说到生态的问题，这里一个典型的案例就是arduino。刚出来的时候我也瞧不上arduino。但发展到现在arduino已经有了非常丰富的生态，现在很多时候，我自己都是更倾向于用arduino直接搞定的，这就是生态的威力。

【 在 Oriphia 的大作中提到: 】
: rust就不是给MCU用的，MCU最直接就是用显性指针，而不是隐性指针，安全特性对于MCU完全没有用。
:
--
修改:lvsoft FROM 180.111.26.*
FROM 180.111.26.*

基本上可以认为和c差不多吧。
当然这里所谓的差不多是指0.5-2倍的波动。
包括性能，代码密度，运行时内存占用等各方面指标。
这些其实跟不同的版本，不同的编译器，不同的编译参数都有关系。

具体在嵌入式场合，rust因为有generic特性，不注意的话容易因为一个不起眼的依赖关系最后牵扯出整座森林。
但这种问题c也一样，比如当年我刚写51的时候不小心随手写了个浮点数，结果编译就包含了整个软件浮点库。

关于rust和c的各方面对比，这个blog写的比较全面：
https://kornel.ski/rust-c-speed

【 在 spadger 的大作中提到: 】
: rust代码密度如何？
:
--
FROM 180.111.26.*