M0e4ef622[m] has quit [Quit: Idle timeout reached: 172800s]
_whitelogger has joined #rust-embedded
<dngrs[m]>
xtensa, still? Sheesh
exark has quit [Quit: quit]
exark has joined #rust-embedded
sroemer has joined #rust-embedded
ivmarkov[m] has quit [Quit: Idle timeout reached: 172800s]
m5zs7k_ has joined #rust-embedded
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k_ is now known as m5zs7k
<thejpster[m]>
I need a USB-UART interface with RTS/CTS lines ... and I don't have one.
<thejpster[m]>
I do have an nRF52840-DK, but I don't know how to steal the VCOM lines away from the on-board nRF52. I have a J-Link which does VCOM but not with RTS/CTS. I have a couple of CP2102 dongles, and they are the same. I have one FT232 cable, but the RTS/CTS drivers are blown (scope shows signals just wandering around).
<thejpster[m]>
I have a Pi Pico, but writing some USB CDC firmware and wiring it up to a UART feels like quite a bit of work. Ideally someone would just have some firmware, but I can't find anything.
<JamesMunns[m]>
uhhh I think it's grounding the DETECT signal on the 52840dk? lemme look at the schematic
<JamesMunns[m]>
do you know what revision of the 840dk you have?
<thejpster[m]>
3.0.0
<thejpster[m]>
i'm looking at the 3.0.3 schematic and ... I'm not finding it easy to read
<thejpster[m]>
the little blue funnels are nice in theory, but I can't work out what is going where
<JamesMunns[m]>
yeah, it's a little tricky. you'd have to make sure the signals ARE routed to the target, but also make sure you are leaving the signals hi-z on the target, and connect to headers of those pins
<JamesMunns[m]>
because otherwise the muxes ISOLATE the debugger's connections to those pins, and im not sure the debugger's nets get connected to a header (only test points) if the mux is isolated
<thejpster[m]>
OK, I've wired P0.06 to P0.08 and it's working as a loopback device
<thejpster[m]>
I erased the nRF52 so the pins should be in reset
<JamesMunns[m]>
using the debugger as a usb-uart?
<thejpster[m]>
yes
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
The USB-uart on the nrf dks does some super weird autodetection for whether to use rts/cts or not
<dirbaio[m]>
It doesn't honor the setting you set via USB iirc
<dirbaio[m]>
Check the dk manual
<dirbaio[m]>
I remember having looooots of trouble with it
<thejpster[m]>
ok, well it seems to be working - with flow control
<thejpster[m]>
P0.08 is your TXO, P0.06 is RXI, P0.05 is CTS and P0.07 is RTS
KevinPFleming[m] has quit [Quit: Idle timeout reached: 172800s]
DuanJR[m] has joined #rust-embedded
<DuanJR[m]>
Hello everyone! I've started a discussion on the littlefs GitHub about a potential pure Rust port and would love to get this group's expert opinion. Is there a real-world need, or is it more of a "Rewrite It In Rust" endeavor? Any feedback in the GitHub issue or direct reply would be amazing. Thanks!
<whitequark[cis]>
personally, i would expect (2) to be the most compelling part. mature C projects usually don't have many memory safety issues (most memory safety issues are in newly added or replaced code), and i understand littlefs to be a mature project. (also Rust projects can introduce their own memory safety issues)
<whitequark[cis]>
but not needing a C compiler in addition to a Rust compiler could very much tip the scales in favor of a Rust port
<Ralph[m]>
<DuanJR[m]> "Hello everyone! I've started a..." <- i have no stake in this, but: you may want to add links to the various crates you mention to your issue. since you've raised this in a non-rust repo chances are that their developers are not familiar with things like embassy and don't know what or where to search for it.
<DuanJR[m]>
<Ralph[m]> "i have no stake in this, but..." <- Thanks for your suggestion, I have updated the links.
<firefrommoonligh>
<GuineaWheek[m]> "ime it has the best tradeoff..." <- I like that breakdown
<DuanJR[m]>
<whitequark[cis]> "personally, i would expect (2..." <- Acknowledged. My primary focus in the issue was on the theoretical benefits of a Rust implementation versus the C version. As you pointed out, these advantages are not always guaranteed in practice.
<DuanJR[m]>
That said, there appears to be a lack of a pure Rust filesystem specifically designed for embedded development. Based on my preliminary assessment, a truly suitable pure Rust embedded filesystem doesn't seem to exist in the ecosystem (embedded-fat is based on a general-purpose filesystem, and tickv is not a complete filesystem).
<DuanJR[m]>
This leads me to question if such a project would be meaningful to the Rust ecosystem in its own right—simply for the sake of having a native option—regardless of whether it's demonstrably superior to the C implementation.
<Ralph[m]>
<DuanJR[m]> "Thanks for your suggestion, I..." <- maybe add the link for embassy (probably point to https://embassy.dev rather than the GH repo) as well? it's the last one missing
<whitequark[cis]>
DuanJR[m]: i would prefer a pure-Rust option for tooling reasons, personally
<whitequark[cis]>
in the past I maintained a Rust embedded project with a homegrown embedded FS (a very simple one)
<JamesMunns[m]>
Currently writing a not-quite-a-fs as well, though it's for a specific use case (lots of small records, relatively low total volume of records when serialized, forward/back compat is required, it's okay to write all records whenever one changes).
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
I did look at the littlefs2 bindings, but the way the current high level operations are done, they are very much not easy to convert to async compatibility (which was also a requirement)
jf-uu[m] has quit [Quit: Idle timeout reached: 172800s]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
i'm curious, why do people often want an embedded fs?
<dirbaio[m]>
it seems to me if you want write access you're usually doing some kind of logging/config for which something like ekv or sequential-storage performs better
<dirbaio[m]>
and for readonly fs use cases like assets for an embedded web server you can just bake them into the firmware image as blobs+pointers
<dirbaio[m]>
* as blobs+pointers, you don't need a "real" fs
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
dirbaio[m]: My only use-case: external SD card
<JamesMunns[m]>
yeah, that's where I ended up, we split logging and put it in s-s::Queue, and config parameters, we're not terribly far off of ekv, but optimized for the case where you want to store your data in a "distributed" fashion, and separate control between "when a new value is stored" and "when i/o operations occur"
<dirbaio[m]>
that's a "regular" fs, not an embedded fs, tho :P
<ivmarkov[m]>
What is the difference? The purpose of this SD card is not to unplug it from the embedded device and plug it into a PC, but to serve as a transient queue before a telemetry is sent to the cloud. That is, if connectivity is lost.
<ivmarkov[m]>
I could do it on the internal flash, but I would rather not. Each packet is ~ 16KB
<dirbaio[m]>
ah right then i'd say it's "embedded" yep :D
<dirbaio[m]>
you're using fat32 tho? :P
<dirbaio[m]>
sd cards free you up to many of the nor flash annoyances tho
<ivmarkov[m]>
Unfortunately, yes :(. With "checkdsk" sorta at mount time, and counter which counts CRC failures, and if these are above a limit ... re-format and lose all data
<dirbaio[m]>
lol
<ivmarkov[m]>
I need LittleFS but with support for > 2GB or else most of the storage on the sdcard is a waste
<ivmarkov[m]>
or
<ivmarkov[m]>
A just need a fifo + lifo queue for blobs. But did not want to implement it myself on a sd-card sector level (time constraints, impossible to review the sd card contents on a PC, etc.)
<ivmarkov[m]>
s/A/I/
<ivmarkov[m]>
So I have a fifo + lifo except it is modeled on top of a "regular" FS atm
<JamesMunns[m]>
IMO one of the hard problems with fs and net stacks is "how do I handle a variable number of files/sockets". The techniques I use in cfg-noodle/ergot I think actually would scale really well
<ivmarkov[m]>
deqye
<ivmarkov[m]>
* deque
<dirbaio[m]>
a flifo
<JamesMunns[m]>
it tends to separate the "objects" from the "resource", in a way that makes it easier to handle an arbitrary number of "objects" (by putting them all in an intrusive list)
<ivmarkov[m]>
dirbaio[m]: Yeah yeah you get the idea let's not nitpick :p. Basically I need to either fetch the oldest, or the newest blob, for sending
<JamesMunns[m]>
that way you can store your "object"s in the tasks that use them, and they can be ephemeral, rather than trying to limit to only one, or trying to share an &mut Resource between multiple File/Socket objects
<JamesMunns[m]>
but this is more "how I would implement an async rust fs" than "should you actually want a fs"
<dirbaio[m]>
for an fs you can just make the user own the memory for the file buffers
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
If only intrusive lists were easier to setup in Rust
<dirbaio[m]>
an open file will not "spontaneously" do anything if the user doesn't touch it
<dirbaio[m]>
unlike in a network stack, where a packet can come in for a socket at any time
<JamesMunns[m]>
dirbaio[m]: yeah, the separation is still nice tho for not needing explicit borrows of the fs
<DominicFischer[m>
JamesMunns[m]: Had a hard time understanding the safety requirements of the Linked trait there tbh
<JamesMunns[m]>
s/fs/"disk"/
<JamesMunns[m]>
JamesMunns[m]: Please do open an issue and @ me if you want! if the docs don't make it clear, I'd be happy to improve them.
<dirbaio[m]>
fs borrows &mut (or owns) the disK
<dirbaio[m]>
files borrow & the fs
<JamesMunns[m]>
like, very honestly: intrusive linked lists are unsafe and require some understanding to get right, I wouldn't recommend them for every problem. but they do make solving some problems a lot easier, once you get your head around them.
<JamesMunns[m]>
I do think the cordyceps Linked trait is a good distillation for single/doubly linked lists though, and a reasonable library to build on top of.
<DominicFischer[m>
JamesMunns[m]: Agreed, I just wish there was simpler utilities around/wrapping it.
<DominicFischer[m>
Like, I'd love to have a simple `BasicNode<T>` that already implements the `Linked` trait, which would just help setup a basic doubly-linked list.
<JamesMunns[m]>
Yeah, the issue is guaranteed lifetimes.
<JamesMunns[m]>
I'll see if I can make something out of what I built for ergot and noodle tho
<JamesMunns[m]>
If you are willing to have pinned nodes and a static "anchor" (the list itself), it's pretty reasonable to have an API around that
<dirbaio[m]>
yeah the Linked trait scares me as well :D
<dirbaio[m]>
feels quite subtle
<JamesMunns[m]>
Please open issues with what confuses you!
<dirbaio[m]>
(will review your executor pr soon btw. looks much nicer now that you unified the queues)
<JamesMunns[m]>
I'll ping Eliza to get that cordyceps pr merged and released.
<dirbaio[m]>
i'm not sure what could be imporved in its docs tbh
<dirbaio[m]>
it's just .. incredibly subtle
<DominicFischer[m>
JamesMunns[m]: My use case is to put them into `core::future::Future`s so pinning is no problem-o.
<dirbaio[m]>
last time I looked at it I had to sit down and think hard for a bit, after that I did manage to get enlightened :D
<DominicFischer[m>
I'm just trying to build a half decent USB host scheduler and I'm trying to avoid the "how many sockets/file do I need" problem too
<dirbaio[m]>
but when I have to look at it again e.g. in that re-review i'll have to sit down and think hard for a bit again 🤣
<JamesMunns[m]>
I'd say look at ergot/noodle, though they ALSO do some fancy type erasure that makes them a bit more complicated than you might need
<JamesMunns[m]>
Like I said, I'll see if I can make a safe and simple api for intrusive lists that is easier to Just Use if you don't need trickery like that
WSalmon__ has joined #rust-embedded
WSalmon__ has quit [Client Quit]
<whitequark[cis]>
"cordyceps" is an incredible name for that crate
<dngrs[m]>
Rust is a fungus based language #neverforget
KevinPFleming[m] has joined #rust-embedded
<KevinPFleming[m]>
<whitequark[cis]> "personally, i would expect (2..." <- Talk to Daniel Stenberg about 'mature C projects' and memory safety issues... his reports of changes in the `curl` project always include that categorization, and fairly frequently the bugs had been present for many years. It's so hard to find them all.
<JamesMunns[m]>
KevinPFleming[m]: Curl is one of the few projects where memory safety issues are _only_ 40-50% of cves instead of 70ish percent
<JamesMunns[m]>
The Google presentation from rustweek is a very good framing of this tho, imo
<whitequark[cis]>
KevinPFleming[m]: i'm basing my statement on what i recall reading about Google's Project Zero
<whitequark[cis]>
and the decision of the Android team to write new code in Rust rather than rewrite old code
<JamesMunns[m]>
Bugs are most common in new code, and using rust typically leads to fewer new bugs
<therealprof[m]>
<BradleyNelson[m]> "Hello everyone - I've written..." <- I guess I'm lucky that I didn't pick one up, otherwise I'd need to carve out some time to give it a go. 😬 Good work, though.
Hallo124 has quit [Remote host closed the connection]
Hallo124 has joined #rust-embedded
<jason-kairos[m]>
<JamesMunns[m]> "https://youtu.be/2Pm8l5O26ds..."; <- after having done some android work for a year or two, them encountering "challenges" doesn't surprise me
sroemer has quit [Quit: WeeChat 4.5.2]
<jason-kairos[m]>
Is it possible that industry players like ARM puts less work into making LLVM compilation "good" for Cortex-M0/+ in order to prioritize more profitable higher performance cores and CPUs?
<jason-kairos[m]>
I feel like it might be really suboptimal, even with the limited instruction set
<jason-kairos[m]>
Also not sure how much of it is a "Rust thing" vs a "LLVM thing"
<whitequark[cis]>
i think not a lot of people care about code size these days, what with storage being cheaper than ever
<jason-kairos[m]>
I've used 512kb of Flash on my project
<KevinPFleming[m]>
Meanwhile some of us are building firmware for MCUs with 128KB of RAM that has to be split into two regions and also host a bootloader
<KevinPFleming[m]>
s/RAM/flash/
<jason-kairos[m]>
* my project - that is a lot for a Cortex-M0 core
<jason-kairos[m]>
KevinPFleming[m]: been there, done that on an Ethernet product. Never again.
<KevinPFleming[m]>
jason-kairos[m]: Mine has a fairly small and simple protocol stack, so 48KB of binary size will be plenty (I say, having not finished the firmware yet...)
<jason-kairos[m]>
* I've used 512kb of Flash on my project - that is a lot for a Cortex-M0 core
<jason-kairos[m]>
and it's not even doing anything complicated - 70kb lost to a 2000 line kernel, etc. etc.
<jason-kairos[m]>
Heh.. Optimism is an engineer's friend even if it might not seem like it
<jason-kairos[m]>
I've spent a lot of my career mopping up the aftermath of optimism
<jason-kairos[m]>
* of optimism (yet I fall into the same traps myself)
<jason-kairos[m]>
* of optimism (yet I still fall into the same traps myself)
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
Maybe one of you Cargo gurus can help with a question.
<vollbrecht[m]>
If i run `cargo clean -p crate_a` then everything up to create a will be removed from the build artifacts. The problem here is that the "build.rs" artifacts are not cleaned up associated to that crate_a. Anybody an idea? :D
<jason-kairos[m]>
weird... I wish the cargo team would add a cleanup hook to build.rs
<vollbrecht[m]>
cargo clean would work but that nukes everything and i want lots of different target rebuilds only up to crate_a
<thejpster[m]>
<jason-kairos[m]> "Is it possible that industry..." <- Arm say if you want good code size for Cortex-M, use the Arm Compiler they sell.
TomB[m] has joined #rust-embedded
<TomB[m]>
So typical
<jason-kairos[m]>
If only the sold a rust compiler
<jason-kairos[m]>
s/the/they/
JamesSizeland[m] has joined #rust-embedded
<JamesSizeland[m]>
Off topic, but I think relevant to you folks. Have you ever been annoyed reading coding ebooks and the code snippets are monotone? I've added syntax highlighting into open source e-reader Readest for that. https://github.com/readest/readest/releases/tag/v0.9.56
<firefrommoonligh>
Has anyone here interfaced with ESP-Hosted-MCU, or a similar RPC structure? I think I have the payload and TLV part working, but keep getting the RPC part (with the payload and message type) kicked back. Of note, the wire protocol is undocumented; they expect you to use their host drivers. I am almost there, but not quite...
<firefrommoonligh>
I'm writing the wire protocol down explicitly as I go, but it's not right. Can share if anyone's interested
Hallo124 has quit [Remote host closed the connection]
Hallo124 has joined #rust-embedded
<dirbaio[m]>
of course you're rewriting it from scratch :D
<dirbaio[m]>
yeah the protocol is super weird, have fun
<dirbaio[m]>
it is sort of documented in the esp-hosted-fg repo though. the esp-hosted-mcu repo seems to be an evolution of that
<thejpster[m]>
Tested my new USB HID decoder with actual reports from an actual keyboard and it seems to work ok. Probably missing some more exotic keys, but good enough.
<firefrommoonligh>
<dirbaio[m]> "of course you're rewriting it..." <- Hah, I really tried not to!
<firefrommoonligh>
But I am doing this as a last resort
<firefrommoonligh>
So, in theory, this firmware sounds exquisite, especially given there are not many Wi-Fi ICs, and for example, the nRF one requires nRF connect nominally, and ST is just announcing one a few days ago. ESp-Hosted is unfortunately expected to (I'm reading between lines) run using their own drivers, which are currently for ESP only, and branching out to STM32 C soon. So, not for rust.
<i509vcb[m]>
nrf_wifi is a bit of a pain to slodge through and it's liberal use of uint8_t extra[0]; in structs means you effectively have to hand write or parse headers into a form that is not misery to use from Rust
<firefrommoonligh>
I went over your code base for ESP-Hosted. Great work! Unfortunately here, it seems that the differences between the -MCU and -NG/-FG are subtle and confusing enough to make it tough to base things on. There is much in common, but I don't know what's in common and what's not.
<firefrommoonligh>
i509vcb[m]: Good to know you could avoid it. Think it would be a tough lift to make it work with Rust at a high-level? (70002)
<firefrommoonligh>
* high-level? (70002). I'm reasonably committed to ESP for this proj though. Either hosted, or custom firmware, but hosted is too perfect since I'm just using it as a radio. (STM32 main; need lots of IO)
<dirbaio[m]>
firefrommoonligh: Yean but why do you insist on using -mcu? -fg works fine, we're shipping it in production (thousands of devices)
<i509vcb[m]>
The other pain point of nrf_wifi is you need to write a wifi stack
<i509vcb[m]>
Zephyr does this with a port of wpa_supplicant
<firefrommoonligh>
That's certainly an option, and owuld let me use your embassy version! But, from the descriptions of the 3 listed on the main esp-hosted repo, it seems that -MCU is clearly the one for htis use, and the other two are designed for Linux. So, if I see 3 options, and my use case falls clearly into one of them most neatly, I will try to make it work there. (Of course if I hit a wall, I can always try -FG). Also, it seems -FG is
<firefrommoonligh>
maybe being eclipsed by -NG, so that's another vote for MCU.
<firefrommoonligh>
So, no right answer, but I think -MCU is the move.
<dirbaio[m]>
No, -NG is what's for Linux because it leaves the 802.11 stack up to the host
<firefrommoonligh>
dirbaio[m]: Suspected that might be the case. FG can work on MCUs, but NG probably not
<dirbaio[m]>
No idea why they say fg is for Linux, it does all the wifi parts itself and gives you "send/receive ethernet frame"
<dirbaio[m]>
Basically the same as -mcu
<firefrommoonligh>
Does the wire protocol I posted above seem consistent with embassy-net/FG's? Mainly the RPC part; I think from injecting logs into the slave firmware and using idf.py monitor, I'm getting past the PlHeader and TLV, then failing at RPC.
<firefrommoonligh>
I suspect some combo of the tag, and payload length is what's wrong
<firefrommoonligh>
(i.e. chatGPT tells me sometimes I need to duplicate the tag and data len in the RPC header and right after it, sometimes only once...)
<dirbaio[m]>
Yeah seems similar
<dirbaio[m]>
A lot of what you've written is describing how protobuf works tho :p
<firefrommoonligh>
Thx! This all new to me
<firefrommoonligh>
I speculate the protobuf users don't think in terms of bytes and indices the way we do. More about using a lib that already handles that. Or I wouldn't be describing the wire protocol myself!
<dirbaio[m]>
Yeah you use a tool that translates the .proto file to your favorite language
<JamesMunns[m]>
@Dominic Fischer do you think an API like this would be useful to you?
<JamesMunns[m]>
JamesMunns[m]: This is a basic API that lets you add nodes that are pinned, and either iterate over the nodes using the anchor, or accessing the node via the pinned handle
<JamesMunns[m]>
JamesMunns[m]: It currently uses a scoped blocking mutex, I can make it use an async mutex instead, but that requires that the nodes are `'static` so they never get dropped.
<JamesMunns[m]>
JamesMunns[m]: At least until we have AsyncDrop :)
<JamesMunns[m]>
<JamesMunns[m]> "@Dominic Fischer do you think an..." <- (nodes are automatically dropped from the list when their handle is dropped, since the nodes are pinned you can't `forget` them)
<dngrs[m]>
<firefrommoonligh> "Has anyone here interfaced..." <- I've ported the example to stm32
<dngrs[m]>
* ported the embassy example to
<JamesMunns[m]>
<JamesMunns[m]> "@Dominic Fischer do you think an..." <- If this looks like something folks would use I can flesh out the docs and tests and examples and such, but I had time to extract some of the simpler bits of Ergot to give an idea of the kind of APIs I use for this.
<JamesMunns[m]>
I'd imagine inside a data structure you'd pin an element onto a list. You could for example pin a WaitQueue onto the list with a buffer, then have a sender that puts stuff in that buffer and wakes a receiver's Waker.
<dngrs[m]>
(as in, using -fg)
<dngrs[m]>
got bitten by the default slew rate being set way too fast, otherwise it was pretty straightforward
<DominicFischer[m>
Was just staring at the code for a bit and it looks like it'll work quite nicely for my use case, thanks!
<DominicFischer[m>
Only thing I'm trying to figure out is how I would potentially reorder nodes in the list. (According to which USB frame I want a packet to go in)
<JamesMunns[m]>
Nice! It's definitely missing some must have bits like unsafe impl Sync for T: Send, but I can keep poking at it, or feel free to open issues/prs
<JamesMunns[m]>
ah, you'd probably want something like cordyceps' cursor API for that, not sure if that would require unsafe
<JamesMunns[m]>
we might want to make the handles check if they are still chained to the list, so you can unchain them as well
<JamesMunns[m]>
you can do anything that cordyceps::List can do, but you have to guarantee you are holding the mutex for as long as access to the list is occuring. This INCLUDES if you are accessing a node directly (because it's on the list)
<DominicFischer[m>
Ahhh got it
<DominicFischer[m>
Thanks for this, I'll give it some use this weekend
<JamesMunns[m]>
and for the async version, you get ~exactly the same API, except the nodes MUST be static to prevent them from being dropped, which buys you an async mutex in exchange. But you can still potentially "reuse" nodes if you unlink + relink them (would probably need some kind of `::take()` interface that only works if the node is unlinked or something, not sure
<DominicFischer[m>
I intend to store wakers in the nodes directly to do async things anyway, the blocking version would be just fine for that
<JamesMunns[m]>
yep, most of the time you are okay with quick blocking access to the nodes for stuff like that
<DominicFischer[m>
I did see that but I wasn't sure if I could pull of a tidy enough comparator
<DominicFischer[m>
s/of/off/
<JamesMunns[m]>
Oh sorry, SortedList is more like Stack, it should mostly work the same but it's singly linked instead of doubly linked
<JamesMunns[m]>
that may not work because nodes can't remove themselves from the list
<DominicFischer[m>
Ah rip, that's practically a requirement for my use case
<JamesMunns[m]>
or, they could, but it would be trickier
<JamesMunns[m]>
(you'd have to re-insert everything to the "right" of you back into the queue with the lock... idk, I haven't tried that)
<JamesMunns[m]>
but you could probably implement a `sort` for a list. I'd have to look. The `Linked` impl right now doesn't really give you a nice API, we could provide a better impl that doesn't make you use `NonNull<Node<T>>`
<JamesMunns[m]>
This was definitely just slapped together, when in doubt, things are probably not missing on purpose :D
<JamesMunns[m]>
(this is like half of how cfg-noodle and ergot work tho, so the concept is sound, this impl is just a little lazy on a Friday night lol)