边界条件之场
66 subscribers
680 photos
4 videos
10 files
1.03K links
Do you hear the sirens sing?

main: @cvf_cha
group: @cvf_gro
forwards: @cvf_for
Download Telegram
边界条件之场
tinyusb 真的让我高血压,host stack 跟 device stack 一样写了一通刷上去一跑不亮 🤷。根本就不知道为什么,只能对着样例把不一样的地方全部复制过来再逐行排查,看看自己原来漏了哪个关键指令……
浪费了非常多时间排查问题,最后干脆直接编译样例,发现样例也跑不起来。

插拔数据线时多看了一眼面包板上的接线,发现用来充当 host 的接口的 vbus 实际上没接电……才突然想起来上周好像临时改了接线,忘记改回来了。

很想扇自己两巴掌 🤡
边界条件之场
确认供电正常了以后样例还是跑不起来 🤔
啊 WTF ……

我可以选择两个版本的 pico-pio-usb:
- 直接从作者 github 上拉取
- pico-sdk 捆绑的 tinyusb 又捆绑的 pico-pio-usb

后者的版本比前者旧。但看在树莓派 pico 官方跟 tinyusb 官方打包的份上我以为它的整合性会更好(经过测试之类的)。

刚才我本来已经要理智丧失了,稍微冷静下来一点去基于两个版本分别编译了样例,发现 github 版能跑而 pico 打包版不能 🫠🫠🫠

原来不是我的软硬件有问题啊 #wtf
边界条件之场
啊 WTF …… 我可以选择两个版本的 pico-pio-usb: - 直接从作者 github 上拉取 - pico-sdk 捆绑的 tinyusb 又捆绑的 pico-pio-usb 后者的版本比前者旧。但看在树莓派 pico 官方跟 tinyusb 官方打包的份上我以为它的整合性会更好(经过测试之类的)。 刚才我本来已经要理智丧失了,稍微冷静下来一点去基于两个版本分别编译了样例,发现 github 版能跑而 pico 打包版不能 🫠🫠🫠 原来不是我的软硬件有问题啊 #wtf
用上了阳间版本的依赖后 host stack 很快就跑通了 😌

测试 hid 键盘报文 Ctrl-Shift-C, Ctrl-Shift-V :

( 0000 0000 ) [ 00 00 00 00 00 00 ]
( 0000 0001 ) [ 00 00 00 00 00 00 ]
( 0000 0011 ) [ 00 00 00 00 00 00 ]
( 0000 0011 ) [ 06 00 00 00 00 00 ]
( 0000 0011 ) [ 00 00 00 00 00 00 ]
( 0000 0011 ) [ 19 00 00 00 00 00 ]
( 0000 0011 ) [ 00 00 00 00 00 00 ]
( 0000 0010 ) [ 00 00 00 00 00 00 ]
( 0000 0000 ) [ 00 00 00 00 00 00 ]
涡糙,小米系统自带时钟应用的倒计时功能,只能设置一个计时器
学 ios 真是学到精髓了啊 💩🖕
#trash #xiaomi #phone
小米随线刷包分发的刷机脚本竟然直接是错的……
(对调了 opcustopconfig

虽然我对中国厂商的软件分发质量没有任何期待,但这也有点太离谱了吧

#trash #xiaomi
边界条件之场
小米随线刷包分发的刷机脚本竟然直接是错的…… (对调了 opcust 跟 opconfig ) 虽然我对中国厂商的软件分发质量没有任何期待,但这也有点太离谱了吧 #trash #xiaomi
小米随包分发两个版本的刷机脚本:
- flash_all
- flash_all_except_storage
(忽略 flash_all_lock ,脑子进屎了才会给用 hyperos 的小米设备重新上锁(

两个脚本均提供 .bat.sh 格式, opcustopconfig 对调的错误仅存在于 flash_all_except_storage.bat 。某种程度上比全错更加离谱……

2024-01-17 构建的包是错的,2024-03-08 构建的包还是错的。我估计能一直错到小米 13 停止支持,不知道其它设备的脚本是不是也是错的。
另:2024-03-08 构建的包直到四月中旬才发出来……
#wtf #trash #xiaomi
🤡1
https://www.reddit.com/r/rust/comments/1cdqdsi/comment/l1e722d/

For instance, the orphan rule is *absolutely* a problem. It affects ecosystem scaling in multiple ways. It means that if you have a library A providing a trait and a library B providing a type, either A has to add optional support for B or B has to add optional support for A, or someone has to hack around that with a newtype wrapper. Usually, whichever library is less popular ends up adding optional support for the more popular library. This is, for instance, one reason why it's *really really hard* to write a replacement for serde: you'd have to get every crate currently providing optional serde support to provide optional support for your library as well.

In other ecosystems, you'd either add quick-and-dirty support in your application, or you'd write (and perhaps publish) an A-B crate that implements support for using A and B together. This should be possible in Rust.

There are a few potential language solutions to that. The simplest, which would likely be fairly easy and would help many applications, would be "there can only be one implementation of a trait for a type", giving a compiler error if there's more than one.
Forwarded from iBug Thought �
Telegram Desktop 更新了 5.0,中文字体又原地寄了
🤡1
边界条件之场
用上了阳间版本的依赖后 host stack 很快就跑通了 😌 测试 hid 键盘报文 Ctrl-Shift-C, Ctrl-Shift-V : ( 0000 0000 ) [ 00 00 00 00 00 00 ] ( 0000 0001 ) [ 00 00 00 00 00 00 ] ( 0000 0011 ) [ 00 00 00 00 00 00 ] ( 0000 0011 ) [ 06 00 00 00 00 00 ] ( 0000 0011 ) [ 00 00 00 00 00 00 ] (…
no_std rust (准确说是 no alloc) 难度比普通 rust 高好多 🫠
没有 VecVecDeque 还行,手动搓个 stack ring buffer 凑合。
没有 Box 就很麻烦了,难以实现 list of owned trait objects 。用 &dyn Trait 的话 ownership 跟 lifetime 让人头大,用 enum 的话灵活性太差。
真的很想依赖个 allocator crate 算了 🫠
边界条件之场
this is doable in safe stable rust?? 👀 https://guiand.xyz/blog-posts/unboxed-trait-objects.html
看了看 dynstack 的源码,虽然 no_std 但是 extern crate alloc; 🥴
我还是用 enum 吧,简单直接,灵活性实际上也没问题(就是麻烦点
这周的大部分时间没网, rustup doc --pathpython -m http.server ... 真是太好用了 🥰