- 主题:51不出门瞎逛,在家看了一遍rust,感觉不可能替代C吧
直接导入svd这个好,rust的宏是真的强
【 在 lvsoft 的大作中提到: 】
: rust其中的一个目标是跟c同等地位,也即c能做的rust一定能做。
: 就说指针好了,mcu里的寄存器全部都是定义一串地址偏移量的指针。c里面都是一个头文件里面裸地址直接写在上面然后强制转换成指针。
: rust当然也可以这么写,但给rust做hal库的人每这么做。他们的做法要安全并且严格的多。它利用rust的宏特性直接导入mcu厂方给出的svd文件。除非你去改svd,否则压根不存在改错的可能。当然,厂方也是会犯错的,所以这个导入svd文件的功能还有patch能力,可以按需要导入base svd,patch svd等等。
: ...................
--
FROM 111.198.57.*
仅就你举的例子,发送f32或者f64非常简单,f64有个函数to_le_bytes/to_be_bytes,
然后发送就可以了,还可以避免经常忘记大小端的问题
【 在 dismoon 的大作中提到: 】
: 什么高端3D打印机还有上位机?
: 现在的3D打印机不都是直接弄个TF卡上面拷了STL或者STEP就能打印的么
: 说到rust的指针,我就举个例子
: ...................
--
FROM 111.199.187.*
赞!理解的很透彻!表达的也很有条理,我要存下来学习学习 :P
【 在 lvsoft 的大作中提到: 】
: 我51第三天装了台3d打印机...
: 然后发现丫自带的上位机貌似挂了,
: 然后我本来就对他的上位机不太满意,准备直接上红米手机刷机klipper的方案。
: ...................
--
FROM 111.199.187.*
rust代码密度如何?
【 在 lvsoft 的大作中提到: 】
: rust其中的一个目标是跟c同等地位,也即c能做的rust一定能做。
: 就说指针好了,mcu里的寄存器全部都是定义一串地址偏移量的指针。c里面都是一个头文件里面裸地址直接写在上面然后强制转换成指针。
: rust当然也可以这么写,但给rust做hal库的人每这么做。他们的做法要安全并且严格的多。它利用rust的宏特性直接导入mcu厂方给出的svd文件。除非你去改svd,否则压根不存在改错的可能。当然,厂方也是会犯错的,所以这个导入svd文件的功能还有patch能力,可以按需要导入base sv
: ...................
--
FROM 222.90.82.*
都说了好多遍了,rust和c在指针方面没任何区别。
你要把地址cast成指针,最简单比如这样就行了:
static mut SCREEN: *mut [[u16; 80]; 25] = 0xB8000 as _;
严谨一点可以封装下,比如这个看起来复杂是因为还定义了生命周期:
fn from_addr<'b>(address: usize) -> &'b Name<'a> {
unsafe { &*(address as *const Self) }
}
至于java也有指针...你是认真的么?rust和java的重大区别就是rust和c一样直接面向实际硬件体系架构。而java多了一层jvm。java别说直接访问内存了,连off heap这么naive的事情都可以当成黑科技。
最后,所有语言都是等价的,你当然可以在c层面做到和rust一样只输入svd来定义整个寄存器的内存映射。但如果不依赖meta programming,只靠c的macro,肯定做不到zero cost。而依赖meta programming,那我随便拿什么语言都行,比如我用python都是可以的。这本质上就是回到了c++的错误路线上(把一个template整成图灵完备,which我认为是个十分sb的决策)
以外,尽管语言都是等价的,但不同的语言的style很重要。我们选择一门语言,选的就是它的style,也即它在设计之初定下的优点/缺点组合的倾向性。比如rust的stm-hal,人家选择直接导入svd,而不是c style式的写个头文件嵌入进去。就是因为选择rust的人会更看重安全性,所以他们也会天然的选择更安全的实现方案。这些东西比各种具体的feature,诸如指针是否直观易用写起来是否方便什么的要重要得多。
最后,还是回到我前面的观点,直观易用=简陋=镰刀割麦子。当你想要追求生产力,开始追求现代化工具带来的高效率的同时,你就必须抛弃掉刀耕火种的手工风格。简单易用(C style)和复杂完美(C++ style)都不是优点,作为工程师,能否做出恰到好处的取舍,选中最完美的那个平衡点,才是定义一个好的工程师的标准。
【 在 Oriphia 的大作中提到: 】
: C的显性指针明显更加直观易用,如果rust算有指针,那JAVA也有指针,这些隐性的指针对寄存器操作没有何任的易用性可言,如果我没记错,ESP32的SVD文件就有高达4万行,本质上是一本字典。我觉得在C语言环境做这种字典也是可以的,但既然C有显性的指针,svd就变成画蛇添足。
: 安全特性对于多任务系统中,不同程序之间的内存管理的确更安全,问题MCU的ROM本身只是一个程序,MCU的程序开发多数情况又是一个人完成。安全性就相当于偷窃我的人是我自己,没有半点意义。
:
--
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.*
其实这个和编译器密切相关,比如cortex-m上,gcc的代码密度就赶不上armcc和armclang
【 在 lvsoft 的大作中提到: 】
: 基本上可以认为和c差不多吧。
: 当然这里所谓的差不多是指0.5-2倍的波动。
: 包括性能,代码密度,运行时内存占用等各方面指标。
: ...................
--
FROM 222.90.82.*
不小心用了个printf...结果,哈哈
【 在 lvsoft 的大作中提到: 】
: 基本上可以认为和c差不多吧。
: 当然这里所谓的差不多是指0.5-2倍的波动。
: 包括性能,代码密度,运行时内存占用等各方面指标。
: ...................
--
FROM 111.193.144.*
对啊,开源就是llvm和gcc两个选择。具体到rust这里其实只有llvm一个选择,因为丫不支持gcc前端。
你说的是商业编译器和开源编译器的差别。这点很正常,毕竟是专门养了一群人针对自己平台优化的。
比如icc团队,700多号人呢,而且都是猛人,还不是随便能找到的那种烂大街码农。
【 在 spadger 的大作中提到: 】
: 其实这个和编译器密切相关,比如cortex-m上,gcc的代码密度就赶不上armcc和armclang
:
--
FROM 180.111.26.*
你把C和rust都等价到汇编,你会发现,只要你用函数,就免不了push pop,而C,就是简单粗暴的一条赋值汇编,我的MCU场合,的确一个时钟脉冲都要掰两半用的
【 在 gameplayer 的大作中提到: 】
: 仅就你举的例子,发送f32或者f64非常简单,f64有个函数to_le_bytes/to_be_bytes,
: 然后发送就可以了,还可以避免经常忘记大小端的问题
:
--
FROM 180.116.135.*