<re_irc>
<@newam:matrix.org> irc_libera_cr1901:psion.agg.io: 1. There are attributes which are not easily discoverable when you need to boot with some cores powered down.
<re_irc>
<@newam:matrix.org> 2. If you have a unique entry point for each CPU you cannot load firmware as an ELF file which means you don't get debug symbols when doing emulator-level instruction debugging (GDB still works fine of course)
<re_irc>
<@newam:matrix.org> 3. QEMU does not support heterogeneous SoCs at all. There are many different custom implementations for this, none of which are great.
<re_irc>
<@newam:matrix.org> 4. The command line options for booting an embedded system are not intuitive when you need to load multiple memory regions (e.g. an external SPI flash and a ROM).
<re_irc>
<@newam:matrix.org> 5. The command line argument parsing has poor validation and when using low-level boot options and you can pass multiple incompatible boot options without a warning.
<cr1901>
Hmmm, interesting
<re_irc>
<@cryptollision:matrix.org> jacobrosenthal: renode is probably good on Windows. From *nix, you get to deal with the extra mono overhead
<re_irc>
<@newam:matrix.org> In terms of emulators there is also google's cross VM which is essential QEMU but for chromebooks only, and written in rust: https://opensource.google/projects/crosvm
<re_irc>
<@newam:matrix.org> Not very extensible, but it is neat to look at.
fabic has joined #rust-embedded
starblue1 has quit [Ping timeout: 268 seconds]
starblue1 has joined #rust-embedded
DepthDeluxe has quit [Quit: Leaving]
fabic has quit [Ping timeout: 268 seconds]
GenTooMan has quit [Ping timeout: 268 seconds]
GenTooMan has joined #rust-embedded
PyroPeter has quit [Ping timeout: 252 seconds]
PyroPeter has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
emerent is now known as Guest6736
Guest6736 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
emerent has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> Is there an accepted trait in embedded that is the "embedded equivalent" of `std::io:Write`? I'm thinking a trait that does `write(buf: &[u8])` and `write_byte(byte: u8)`.
<re_irc>
<@korken89:matrix.org> I'd like to abstract an RF chip RX/TX buffer so it can be written to directly without the need for an intermediary buffer, which is required if I would choose an `&[u8]` interface.
<re_irc>
<@korken89:matrix.org> But I'd also not want this trait to be my project only as I'd like to implement this trait in different supporting crates used with radio ICs.
<re_irc>
<@korken89:matrix.org> So we get a "zero copy" API from serialization of message to the RF chips buffer
starblue1 has quit [Ping timeout: 252 seconds]
<re_irc>
<@jordens:matrix.org> Yay zero copy! That trait should probably then also be **the** trait for SPI, UART etc. instead of what is currently in `embedded_hal::spi` etc.
<re_irc>
<@jordens:matrix.org> I.e. why are there multiple different "write" traits in `embedded-hal`?
starblue1 has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> Ah right, they have their own trait per peripheral type
<re_irc>
<@korken89:matrix.org> Is everyone rooting for `std::io::Write` eventually becoming `no_std`?
<re_irc>
<@korken89:matrix.org> Seems like there is space for an `embedded-write` crate :P
<re_irc>
<@korken89:matrix.org> How do people achieve zero copy interoperability with ICs that has buffers without a trait for it?
<re_irc>
<@korken89:matrix.org> Maybe there is a usage pattern I have missed?
<re_irc>
<@korken89:matrix.org> Or do people not do zero copy and simply accept the use of intermediary buffers?
<Lumpio->
Zero copy is overrated
<Lumpio->
But a lot of crates use the curious write callback pattern.
<Lumpio->
This works if a hardware or library internal buffer exists and can be written to normally
<re_irc>
<@korken89:matrix.org> Ah right, the first one makes a lot of sense
<Lumpio->
jordens: fwiw most microcontrollers don't have a hardware buffer for SPI and UART or whatnot, so I'm not sure if having a trait like that is so useful for that
<Lumpio->
If you want to write a buffer efficiently you have to put it in memory and use DMA
<re_irc>
<@korken89:matrix.org> This is the one I'd like a trait for more or less
<Lumpio->
And the buffer allocation usually comes down to user code.
<Lumpio->
And the write trait ends up being very similar, except that it takes some kind of magical DMA safe buffer instead of just &[u8]
<re_irc>
<@jordens:matrix.org> Sure. Mostly DMA. But also stm32h7 qspi has a decent FIFO for example. In any case, even if your HW does only small xfers (uart, SPI), you probably still want to expose a slice based API. Because that's what people need.
<re_irc>
<@korken89:matrix.org> I'm not really interested in all the different usage patterns of DMA vs not using DMA, I simply want a trait to express the possibility of a write API. And then if it's used for DMA, zero copy writes to chips or writes to buffers is an orthogonal discussion.
<re_irc>
<@jordens:matrix.org> And SPI v2 on stm32 generally has FIFOs. So this is not only about DMA. korken89 Right. The need for a good API is orthogonal to the capabilities of the various peripherals.
<re_irc>
<@therealprof:matrix.org> irc_libera_lumpio-:psion.agg.io: That is not correct. Quite a few STM32 chips have a transmit buffer for SPI (which bit me quite well when trying to make use of it due to software CS) and I've definitely seen some 16550 compatible UARTs out there (though I can't recall exactly where).
<re_irc>
<@9names:matrix.org> most microcontrollers aren't quite a few STM32s, so maybe it's true?
<re_irc>
<@9names:matrix.org> most of the micros i deal with these days do but i know the future isn't evenly distributed
<re_irc>
<@therealprof:matrix.org> Maybe, maybe not. I don't think anyone here has the quantitive data to say for sure.
<re_irc>
<@therealprof:matrix.org> Allow me to correct myself then: That is likely not correct.
mbuhl has joined #rust-embedded
mbuhl has left #rust-embedded [bye]
fabic has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> Is it worth adding a `std::io::Write` like trait to `embedded-hal` or some other place so drivers can depend on write APIs?
<re_irc>
<@eldruin:matrix.org> I have not followed the discussion but if the use case is there and drivers would benefit, sure.
starblue1 has quit [Ping timeout: 260 seconds]
starblue1 has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
Obiwankenobi has joined #rust-embedded
Obiwankenobi has left #rust-embedded [#rust-embedded]
<re_irc>
<@korken89:matrix.org> Yeah, I mean maybe I've been working too much with RF chips but my "dream" to e.g. serialize directly to the chip without intermediary buffers being copied all over the place. The thing is that generally there are like 3-5 crates of `&(mut) [u8]` APIs to go through (serde lib, add header lib for your IEEE 802.15.4, rf lib tx buffer, send to spi) which often copy the entire buffers around as none of the...
<re_irc>
... stages understood how data should be in the end. So you get alignment issues and it's solved with copying the buffer to correct alignment. Or in some cases, lifetime problems, so the drivers duplicate a slice to a buffer to get ownership. Where one should just be able to chain a `write` like API like:
<re_irc>
<@korken89:matrix.org> I think I'll make a proper port of a few libs to use a trait to have as a case-study in a way
<Lumpio->
therealprof: How do you write into the transmit buffer?
<Lumpio->
Is it a memory region you can write into in whatever order you want like &mut [u8]
<re_irc>
<@therealprof:matrix.org> Nope, it's just a single MMIO register you write your "word" into and there's a watermark in another register allowing you to figure out how full the buffer is.
<re_irc>
<@therealprof:matrix.org> For STM32 SPIv2, that is. 😉
<Lumpio->
This was related to whether you can just have something write directly into memory to transmit
<Lumpio->
So yes there's a hardware buffer but it's not a memory region you can just write to normally.
<re_irc>
<@therealprof:matrix.org> Yes. You have to spoonfeed the data in.
<Lumpio->
My wording wasn't the best but read it as "hardware memory buffer" or something
<Lumpio->
jordens: Does the QSPI also have just one FIFO register you repeatedly write to in order or does it expose something you can cast into &mut [u8
<Lumpio->
]
<re_irc>
<@therealprof:matrix.org> And the buffer is not big for this specific case, only 32bit so at usual 8bit transfer size it's only 4 words.
<Lumpio->
At any rate I do know some hardware that has an actual memory buffer for data, like some USB peripherals
<re_irc>
<@jordens:matrix.org> one address, deep fifo behind, plus level registers, all for rx and tx.
<Lumpio->
...but even them some of them are bizarre, there's some STM32 ones where the memory is u16's laid out ever 4 bytes, with two bytes of padding inbetween due to how the bus works
<re_irc>
<@therealprof:matrix.org> irc_libera_lumpio-:psion.agg.io: Yes, USB is a good example for a dedicated buffer in memory.
<Lumpio->
Anyways for those the "write callback" style trait would get you truly zero-copy, but otherwise it will still need to write into memory somewhere.
<re_irc>
<@therealprof:matrix.org> I guess the problem with the dedicated memory is going to be that your "here's a slice of data" won't work without copying it there.
<Lumpio->
That is, normal allocated memory
fabic has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> korken89: What is the specific use case you have in mind?
fabic has quit [Ping timeout: 260 seconds]
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> firefrommoonlight:matrix.org: I wrote a bit up about how I'd like to interact with RF chips
<re_irc>
<@firefrommoonlight:matrix.org> Will dive in later today
<re_irc>
<@oddstr13:matrix.org> korken89:matrix.org: Do you mind sharing which RF chips you are working with?
<re_irc>
<@firefrommoonlight:matrix.org> As in faster? More functionality? Obv being native Rust reduces some complexity over compiling C and FFI wrapping
<re_irc>
<@yatekii:matrix.org> (guess it should be FIR)
<re_irc>
<@jordens:matrix.org> Oops. Forget about the FIR. That's an accidental copy pasta commit.
<re_irc>
<@yatekii:matrix.org> I see =)
<re_irc>
<@jordens:matrix.org> If somebody is interested in giving API advice, that's certainly welcome! Certainly w.r.t. inter-crate questions like `num`, `micromath`, `sdr-rs` etc.
<re_irc>
<@firefrommoonlight:matrix.org> Awesome. Looking forward to using it
<re_irc>
<@firefrommoonlight:matrix.org> API is probably my biggest strength, but I'm not proficient enough with DSP to comment at this time. I'll send suggestions/issues/PRs your way as required later
<re_irc>
<@almindor:matrix.org> does anyone know what `.option` is in assembly (riscv) and where I can find the docs for that?
<re_irc>
<@almindor:matrix.org> AFAIK Risc-v has no built in push so I'm guessing it's a meta instruction? but I have no idea where it's from
<re_irc>
<@korken89:matrix.org> oddstr13:matrix.org: Sure DW1000 and SR1000
<re_irc>
<@korken89:matrix.org> firefrommoonlight:matrix.org: Reduced memory footprint and faster. I need to give this a try and see where I land.
<re_irc>
<@korken89:matrix.org> Though API as well, working with slice APIs really don't map well to the operations causing the need for multiple intermediary buffers
<re_irc>
<@firefrommoonlight:matrix.org> Great!
<re_irc>
<@firefrommoonlight:matrix.org> And re functionality - we can always add PRs with new functions as required. Translating CMSIS as a start
<re_irc>
<@come.allart:emse.fr> almindor: > Modifies RISC-V specific assembler options inline with the assembly code. This is used when particular instruction sequences must be assembled with a specific set of options. For example, since we relax addressing sequences to shorter GP-relative sequences when possible the initial load of GP must not be relaxed and should be emitted as something like
<re_irc>
<@come.allart:emse.fr> .option push
<re_irc>
<@come.allart:emse.fr> la gp, __global_pointer$
<re_irc>
<@come.allart:emse.fr> almindor: (The keyword to look for is "directive")
<re_irc>
<@almindor:matrix.org> yeah, I tried option heh. I was like "never seen this in the riscv simulator before" :D
<re_irc>
<@almindor:matrix.org> it's funny the deeper I go, I always think "this is the bottom of the stack surely", there's always some tool specific thing
<re_irc>
<@come.allart:emse.fr> almindor: Yeha, too general word. Like when I struggle with matrix/element end to end encryption and I can just find things related to maths…
<re_irc>
<@yatekii:matrix.org> has anyone got an idea how I can debug "called `Option::unwrap()` on a `None` value rust-analyzer(macro-error)"? I cannot find anything in the output tabs of vscode and the proc_macro also compiles just fine when I run cargo build. Like can I get a complete stacktrace somehow?
<re_irc>
<@dirbaio:matrix.org> if it builds fine then it's probably a RA bug... it probably refers to an unwrap inside RA's code :S
<re_irc>
<@yatekii:matrix.org> hmm that's really sad because it kills all other analytics in my code
<re_irc>
<@yatekii:matrix.org> it will do autocompletions and hotfix suggestions with "ctrl + ." just fine, but it wont show any errors in my code :/ sadge
<re_irc>
<@dirbaio:matrix.org> or maybe the env is different or something so your proc macro does crash
<re_irc>
<@yatekii:matrix.org> I believe it's the env because I feel like I had exactly this error during development of the proc_macro sometimes too when run from the wrong directory or the likes
<re_irc>
<@yatekii:matrix.org> the problem is that I can't really see where it dies
<re_irc>
<@dirbaio:matrix.org> maybe wrap your entire macro with a catch_unwind
<re_irc>
<@yatekii:matrix.org> hmm
<re_irc>
<@yatekii:matrix.org> but how would I propagate that into rustanalyzer
<re_irc>
<@yatekii:matrix.org> hmm maybe with a compiler_error!
<re_irc>
<@dirbaio:matrix.org> or another panic!, but with the info you want
<re_irc>
<@yatekii:matrix.org> fair point
<re_irc>
<@yatekii:matrix.org> proc_macros are the best and the worst feature of rust simultaneously XD
<re_irc>
<@yatekii:matrix.org> awesome when it works, terrible when you have to debug/write it :D
<re_irc>
<@dirbaio:matrix.org> debugging them SUCKS
<re_irc>
<@yatekii:matrix.org> hard agree! whats worse is if 6 different git repos are involved ...
<re_irc>
<@dirbaio:matrix.org> anyone know a way to not have to list ALL GHA checks in bors?
<re_irc>
<@dirbaio:matrix.org> and it works for both declarative and proc macros :D :D
<re_irc>
<@dirbaio:matrix.org> not attribute macros though
<re_irc>
<@dirbaio:matrix.org> but still awesome
<re_irc>
<@yatekii:matrix.org> yup, found the panic :D
<re_irc>
<@yatekii:matrix.org> now I need to figure why it fails :D
<re_irc>
<@yatekii:matrix.org> Note: The observable result of a macro should only rely on the tokens and not on this source text. The result of this function is a best effort to be used for diagnostics only.
<re_irc>
<@yatekii:matrix.org> that's not good; I am violating this :/
<re_irc>
<@yatekii:matrix.org> something is seriously wrong :/
<re_irc>
<@yatekii:matrix.org> does r-a use rustc to resolve the proc_macros or does it do it itself somehow?
<re_irc>
<@yatekii:matrix.org> printing the spans inside vscode/r-a results in "4294967295 ----- 26". printing them with cargo build results in "#0 bytes(6374..6382) ----- #0 bytes(6476..6783)" XD
<re_irc>
<@yatekii:matrix.org> like wtf?
<re_irc>
<@yatekii:matrix.org> seems like r-a does this REAL different
<re_irc>
<@yatekii:matrix.org> like as if it replaces the entire token primitives and spans emitted
<re_irc>
<@dirbaio:matrix.org> spans are cursed, just treat them like black boxes...
<re_irc>
<@yatekii:matrix.org> I know but I NEED them for diagnostics :/
<re_irc>
<@yatekii:matrix.org> grrr
<re_irc>
<@yatekii:matrix.org> and for parsing of source
<re_irc>
<@yatekii:matrix.org> all of the things one should NOT do but I want to :/
<re_irc>
<@dirbaio:matrix.org> why to parse? you need some info that's not on the token list?
<re_irc>
<@yatekii:matrix.org> the parser operates on strings and not rust tokens. so you somehow need to convert the tokens into a string OR make the parser take rust tokens (this leads to other problems; the most prominent being that you have to write and test the parser twice, but also many technical ones).
<re_irc>
<@yatekii:matrix.org> you can convert the tokens into a string without spans. but that leads to code that is not identical to the source (formatting), which makes rustc annotations impossible.
<re_irc>
<@yatekii:matrix.org> guess r-a's backend is just so different
<re_irc>
<@yatekii:matrix.org> :(
<re_irc>
<@dirbaio:matrix.org> stringify each token, glue them with spaces, parse that?
<re_irc>
<@dirbaio:matrix.org> parse that "reconstructed" string
<re_irc>
<@dirbaio:matrix.org> if the gives you a span on that string, work "backwards" to check which tokens are in that reconstructed-string span
<re_irc>
<@dirbaio:matrix.org> then back to rust spans?
<re_irc>
<@dirbaio:matrix.org> :S
<re_irc>
<@yatekii:matrix.org> dirbaio:matrix.org: that still does not necessairly represent the source exactly, unfortunately
<re_irc>
<@yatekii:matrix.org> I tried, believe me :D
<re_irc>
<@yatekii:matrix.org> because that stuff is what forces me into nightly, basically
<re_irc>
<@dirbaio:matrix.org> the issue is that it doesn't parse?
<re_irc>
<@dirbaio:matrix.org> or it does parse but then you can't report errors on the right line:column?
<re_irc>
<@yatekii:matrix.org> no the issue is that you cannever get the exact source from the tokens
<re_irc>
<@yatekii:matrix.org> because a tokentree does not have notion of source formatting
<re_irc>
<@yatekii:matrix.org> no spaces, no comments, etc.
<re_irc>
<@yatekii:matrix.org> kind of sad
<re_irc>
<@dirbaio:matrix.org> the thing you're parsing cares about newlines/spaces?
<re_irc>
<@yatekii:matrix.org> I tried using a string as the proc_macro input to fix this. but rustc cannot generate arbitrary spans m(
<re_irc>
<@yatekii:matrix.org> so you cannot point to the location in string
<re_irc>
<@yatekii:matrix.org> and I like to
<re_irc>
<@yatekii:matrix.org> dirbaio:matrix.org: no, the diagnostics when there is an error do
<re_irc>
<@dirbaio:matrix.org> you can do that with the "working backwards" thing
<re_irc>
<@yatekii:matrix.org> I want to say e.g. "variable with name `hehexd` on line 3 character 5 through to character 11 does not exist" and have rustc annotate that
<re_irc>
<@dirbaio:matrix.org> if your macro gets called with tokens `a`, `b`, `c`
<re_irc>
<@dirbaio:matrix.org> with spans spanA, spanB, spanC (black boxes)
<re_irc>
<@yatekii:matrix.org> not sure I understand you right but if I do: I do that already
<re_irc>
<@dirbaio:matrix.org> glue them into a string "a b c"
<re_irc>
<@dirbaio:matrix.org> that string will not match the original Rust source, but it doesn't matter
<re_irc>
<@dirbaio:matrix.org> when gluing, keep the info of: