<re_irc>
< (@tmgross:matrix.org)> Has the embedded wg or probe-rs ever considered offering to take control of rtt-target? https://github.com/mvirkkunen/rtt-target
<re_irc>
< (@tmgross:matrix.org)> Unfortunately it seems like the maintainer is fairly inactive, and there are a few minor PRs that haven't been acknowledged in 1.5 years
<re_irc>
< (@yatekii:matrix.org)> : I contacted matti :)
<re_irc>
< (@jamesmunns:beeper.com)> It might be worth dropping by the #probe-rs:matrix.org (https://matrix.to/#/#probe-rs:matrix.org) room, I know some RTT stuff has ended up there
<re_irc>
< (@tmgross:matrix.org)> Woohoo! Thanks for the updates
<re_irc>
< (@jamesmunns:beeper.com)> oh, just beat me to it :D
<re_irc>
< (@matt:ucc.asn.au)> what's a good way to hunt down what's pulling in a function that seems like it should be compiled out? my core::fmt::Debug .fmt() methods are still in the --release binary output, even though log crate isn't even used. can't see anything calling it directly in the "objdump -dS" output...
<re_irc>
< (@matt:ucc.asn.au)> * directly used by the binary.
re_irc has quit [Remote host closed the connection]
lehmrob has joined #rust-embedded
re_irc has joined #rust-embedded
<agg>
(testing irc bridge)
<re_irc>
<agg ⚡️> (testing again)
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
lehmrob has quit [Ping timeout: 248 seconds]
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> (hopefully final test of irc bridge)
<agg>
yay, ok, seems to be back in service now. and migrated to a new server, as the old one's shutting down soon
lehmrob has joined #rust-embedded
fabic has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@timbod7:matrix.org> What's considered best practice for sharing spi/i2c buses between embedded-hal drivers? This github issues discussed alternatives:
<re_irc>
though it's 5 years old. There seem to be at least a couple of crates published also.
<re_irc>
<@dirbaio:matrix.org> lol this is scary :D
<re_irc>
<@9names:matrix.org> in response to your question, timbod7: shared_bus works fine.
<re_irc>
<@dirbaio:matrix.org> : sorry for offtopic. to anwer the question: embedded-hal 1.0 has SpiBus/SpiDevice to have first-class support for sharing
<re_irc>
int spim_read_reg(uint32_t reg_addr, uint8_t *reg_value)
<re_irc>
{
<re_irc>
uint8_t tx_buffer[6] = { reg_addr };
<re_irc>
// ...
<re_irc>
}
<re_irc>
// ...
<re_irc>
What's the value of tx_buffer supposed to be here? Is it 6 times "reg_addr as u8" or "reg_addr.to_ne_bytes() + 2 0 bytes"?
<re_irc>
Trying to translate this to Rust haha
<re_irc>
<@9names:matrix.org> the first one
<re_irc>
<@dirbaio:matrix.org> when the bridge "splits" a message into mulitple, seems they get reordered
<re_irc>
<@diondokter:matrix.org> Ah, thanks! People say Rusts syntax is bad, but...
<re_irc>
<@diondokter:matrix.org> * Rust's
<re_irc>
<@timbod7:matrix.org> : So if I'm using a driver that still depends on embedded-hal-0.2, I'm screwed, and have to give it it's own SPI bus?
<re_irc>
<@dirbaio:matrix.org> ah yeah then probably use shared_bus...
<re_irc>
<@9names:matrix.org> hmm. i think I'm wrong, and it sets the first to reg_addr and the rest to 0.
<re_irc>
<@adamgreig:matrix.org> Yea, reg_addr as u8 and then five zeros
<re_irc>
<@timbod7:matrix.org> basically, I've got one of these boards: http://www.lcdwiki.com/2.8inch_SPI_Module_ILI9341_SKU:MSP2807. The display is working ok using an existing embedded-hal driver, and I'd like to write a driver for the touch screen. Would be nice if I could share the spi.
<re_irc>
<@timbod7:matrix.org> Will look at shared_bus.
<re_irc>
<@adamgreig:matrix.org> : huh, ordering looked OK to me. I can change the max lines before it gets pastebinned instead, in the new version of the bot it allows up to 5 before it does so (whereas before I think it was anything multi-line)
<re_irc>
<@adamgreig:matrix.org> I guess irc doesn't provide many guarantees about ordering, heh
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@dirbaio:matrix.org> it's tcp, it should? unless the server is broken heh
<re_irc>
<@adamgreig:matrix.org> 🤔
<re_irc>
<@dirbaio:matrix.org> 🤷
<re_irc>
<@adamgreig:matrix.org> I mean, I'm sure the bot isn't reordering it for fun lol
<re_irc>
<@dirbaio:matrix.org> brought it up just in case it was indeed the bot
lehmrob has quit [Ping timeout: 260 seconds]
lehmrob has joined #rust-embedded
lehmrob has quit [Quit: Konversation terminated!]
wadams has joined #rust-embedded
wadams is now known as wes_
<wes_>
hey guys - i have a very general question: in embedded C, it is very easy to break board/peripheral/module initialization into their own respective files and functions. i have an embedded rust project running on the stm32f3discovery. it is one giant monolithic main function. can i get some pointers on how to break my logic into respective init functions (and ultimately new files)? as soon as
<wes_>
i start to move things around, everything breaks.
<re_irc>
<@k900:0upti.me> Well, why do things break?
<wes_>
because TIM2/SPI1/etc are not globals that can be tossed around my project
<wes_>
does this just boil down to explicitly passing and returning what would normally be globals in C?
<re_irc>
<@k900:0upti.me> Yes
<re_irc>
<@k900:0upti.me> But you might also want to build some sort of abstraction on top
<re_irc>
<@k900:0upti.me> So you put handles to all the related peripherals into a struct and pass that around instead
<wes_>
that sounds promising. do you know of a project that i can reference?
<re_irc>
<@k900:0upti.me> Not really
<re_irc>
<@k900:0upti.me> I'm not sure there's really that much to "reference"
<re_irc>
<@k900:0upti.me> You just declare a "struct YourThing { timer: YourTimerType, spi: YourSPIType }"
<re_irc>
<@k900:0upti.me> And you can declare methods on that to actually do things you need in multiple places
<wes_>
ah. okay
<wes_>
i'll give this a try, and see what happens. thanks for taking the time to help
<re_irc>
<@peter9477:matrix.org> wes_: I recently refactored my awful init code to do this more properly. Here's a heavily stripped version of the relevant code, which might help.
<re_irc>
<@peter9477:matrix.org> The only real downside with that currently is the duplication... pretty much every GPIO or other item has to be mentioned twice, in effect. Fairly small price to pay though, since this is really not something you'd expect to edit frequently in the life of the project... hardware doesn't change that often!
fabic has quit [Ping timeout: 255 seconds]
<wes_>
this is great. thanks for the example. i need all the help i can get. making this shift from embedded C to Rust is a real struggle for me...
<wes_>
feels almost like creating a project-specific BSP
zagura has joined #rust-embedded
<re_irc>
<@peter9477:matrix.org> wes_: Very much so. And I empathize with the struggle... I've been struggling the whole way along for over 6 months, but never stalled. And it's been well worth the effort.
<re_irc>
<@romancardenas:matrix.org> Hi everyone! I'm starting to develop a crate for a RISC-V peripheral based on the cortex-m crate. I've been reading through the NVIC implementation and there is something that I still don't get: what is the criteria to use associated functions instead of methods for the NVIC struct?
<re_irc>
<@dirbaio:matrix.org> it's so you can call them from anywhere, without passing the NVIC instance around
<re_irc>
<@dirbaio:matrix.org> these registers are atomic to write, so that's fine, can't cause data races
<re_irc>
<@dirbaio:matrix.org> as to why some are methods and some are associated fns, no idea.
<re_irc>
<@dirbaio:matrix.org> ah well "set_priority" has to do a read-modify-write, that could race if you don't check exclusive access
<re_irc>
<@dirbaio:matrix.org> "request" could be an associated fn..
<re_irc>
<@romancardenas:matrix.org> Oh, I see. So read/write functions can be associated functions, but read-and-write functions must be methods (provided that your peripheral supports atomic operations)
<re_irc>
<@dirbaio:matrix.org> yea, mostly
<re_irc>
<@romancardenas:matrix.org> Perfect, thank you
brazuca has joined #rust-embedded
brazuca has quit [Quit: Client closed]
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<re_irc>
<@mchodzikiewicz:matrix.org> hello there! I have a problem with generating a valid binary for my cortex-m application with embedded PIC. When calling "llvm-objcopy" (wrapped in "cargo binutils" or standalone) on an elf generated with "-C relocation-model=ropi" I get empty file. Is this a known issue?
<re_irc>
<@dirbaio:matrix.org> empty binary is usually forgetting to add "-Tlink.x"to the linker args
<re_irc>
<@dirbaio:matrix.org> in ".cargo/config.toml" or "build.rs"
<re_irc>
<@mchodzikiewicz:matrix.org> uhm, I have "-Tlink.x" in my config.toml but it is a workspace wide so maybe this is a problem
<re_irc>
<@mchodzikiewicz:matrix.org> I am aware of ropi/rwpi problems but I thought ropi-only is working fine
<re_irc>
<@dirbaio:matrix.org> that issue is ropi only
<re_irc>
<@dirbaio:matrix.org> ".cargo/config.toml" only applies if you run "cargo" from the dir containing ".cargo", or a child
<re_irc>
<@dirbaio:matrix.org> if you have "myworkspace/mycrate/.cargo/config.toml" and run "cargo" from the "myworkspace" dir, it won't apply
<re_irc>
<@dirbaio:matrix.org> the issue I linked is about ropi only
<re_irc>
<@mchodzikiewicz:matrix.org> yes, this I am aware of - I have workspace-wide config
<re_irc>
<@dirbaio:matrix.org> hmm dunno what the issue could be then. i've never personally tried but I think it should be possible to get a nonempty bin with ropi enabled
<re_irc>
<@dirbaio:matrix.org> (a _working_ binary is another story though!)
<re_irc>
<@mchodzikiewicz:matrix.org> for now I just want to write a POC bootloader that jumps into hello world program that can be relocated, no trait objects etc
<re_irc>
<@mchodzikiewicz:matrix.org> but for what I want to eventually achieve it is a bit worrying 😄
<re_irc>
<@dirbaio:matrix.org> it's not just trait objects. any static that is initialized with a pointer to another static or to some function doesn't get relocated
<re_irc>
<@dirbaio:matrix.org> (trait object vtables are just a particular case of that)
<re_irc>
<@mchodzikiewicz:matrix.org> I see
<re_irc>
<@mchodzikiewicz:matrix.org> do you know if there is any progress being made on this topic or is it stuck?
starblue has joined #rust-embedded
brazuca has joined #rust-embedded
<wes_>
if anyone out there is willing to help a noob, i'd very much appreciate it. check out my STM32f3 work: https://github.com/wes-adams/embedded-rust-stm32/tree/spi-timer-led-working. i'd very much like feedback on proper/idomatic/clean initilization. i've been fumbling with it for too long, and making zero progress. i can't find any good examples of mature projects to learn from - only
<wes_>
monolithic main-only one-offs. thanks in advance.
<re_irc>
<@cloufisz:matrix.org> Does it really matter which Programator for debugging purposes I buy?
<re_irc>
For example, I bought ST-LINK V2 Prog for STM32. I suppose that I can't use it for ESP32 SoC, right?
<re_irc>
So then I'd need to buy another ESP32-Prog?
<re_irc>
Is there an all-in-one Programator?
<re_irc>
<@jamesmunns:beeper.com> ESP32s use UART (sometimes over USB) for programming, they don't use SWD like the cortex-m ones.
<re_irc>
<@jamesmunns:beeper.com> wes_ have you seen RTIC or Embassy? you totally can do "wrangle resources on your own", but most people use one of those two.
<re_irc>
<@cloufisz:matrix.org> * meant
<re_irc>
<@cloufisz:matrix.org> : so is getting JTAG debugging pointless? ;o
<re_irc>
<@cloufisz:matrix.org> * ;o. I've seen that not all version of the ESP32 board support this UART Debugging
<re_irc>
<@jamesmunns:beeper.com> Ah, other folks probably know more, I've only used ESP32 chips a little bit so far. There's also #esp-rs:matrix.org (https://matrix.to/#/#esp-rs:matrix.org) for more specific questions :D
<re_irc>
<@cloufisz:matrix.org> * seen/heard
<wes_>
jamesmunns : i've seen them, but have not tried either. i'm trying to stay as close to 'bare metal' as i can for now. i want to understand everything that is happening before implementing any higher-level frameworks.
<re_irc>
<@9names:matrix.org> Can't use RTIC with xtensa or riscv though
<re_irc>
<@jamesmunns:beeper.com> wes_: Fair! That being said - they mostly do exactly what you will do, just with having a lot more review on any necessary unsafe code to make it work.
<re_irc>
Not gunna tell you how to learn though :D
<re_irc>
<@jamesmunns:beeper.com> (I see a lot of people coming from embedded C that think they HAVE to walk uphill both ways in the snow barefoot because that's the REAL way of doing things - using RTIC or embassy isn't really a ton of overhead, like using even a vendor HAL or arduino or similar, which are still valid ways of doing things)
<re_irc>
<@adamgreig:matrix.org> : the stlink v2 can program most cortex-m chips that use swd, not just stm32, but esp32 isn't cortex-m and you either need a probe that can do jtag or to bootload the esp32s directly (or use one of the esp32s that has a built in usb-jtag probe!)
<wes_>
adamgreig: i have. i've read the rust book and the embedded rust book. now i'm trying to put theory into practice.
<wes_>
jamesmunns: busted. i am coming from embedded C, and i AM trying to walk uphill both ways in the snow barefoot. i don't think i'm looking for the REAL way to do it, i guess i just don't like things happening under the hood that i can't easily observe.
<re_irc>
<@jamesmunns:beeper.com> Gotcha! RTIC is nice and actually expands all the macros for you, check out "target/rtic-expansion.rs" if you try it out. You can see everything that it is doing, and use your debugger to step through.
<wes_>
if i had my ah ha! moment, and this stuff clicked into place for me, i'd have no issues stacking up the frameworks.
<re_irc>
<@jamesmunns:beeper.com> "framework" isn't a dirty word, but I understand the need to know how things tick!
<wes_>
i like that idea. if i can see how RTIC is doing things, that will be good enough for me. thanks for the idea.
<re_irc>
<@jamesmunns:beeper.com> This is one of those areas where I don't know the best way to teach. A lot of people push back on "using a framework" like RTIC, and want to do it themselves. BUT, that often means you need to learn a bunch of OTHER rust stuff way earlier than you might need to, like unsafe, or using awkward things like the Mutex Option RefCell etc.
<re_irc>
<@jamesmunns:beeper.com> (I taught rust+embedded rust for a bunch of years, unsafe rust is generally good to avoid until you have a pretty firm grasp on Rust and its rules, there's lots more to learn incrementally until you get there)
<re_irc>
<@jamesmunns:beeper.com> but if we wrapped that all up into something for beginners to avoid... it'd look a lot like a worse version of RTIC or Embassy!
<re_irc>
<@jamesmunns:beeper.com> so, I'm always open to hearing more ideas on how to approach that. You certainly aren't the first to take the "built from scratch" path to learning, and certainly won't be the last!
<cr1901>
The cortex-m-quickstart repo doesn't use frameworks, and gives you the general gist of what frameworks are built on
<wes_>
thanks a lot guys. i'll check out RTIC and cortex-m-quickstart.
<re_irc>
<@jamesmunns:beeper.com> (for my paid trainings, we DID just use RTIC, but mostly because of time limitations - there wasn't enough time to explain all the "resource sharing stuff" from first principles, AND have a meaningful amount of time to learn the tooling, development cycle, etc.)
<wes_>
C devs love unsafe. that's probably the appeal.
<re_irc>
Embedded devs are great because they know how to build the world from scratch (or at least like to think they do). Embedded devs are terrible because they can't stop themselves from inventing every world from scratch :D
<re_irc>
<@jamesmunns:beeper.com> heh, I can't make a joke without sounding like an ass.
<re_irc>
<@jannic:matrix.org> I guess there is no one right way. People learn differently. Some need/prefer to understand the details and build more complex stuff on top, others can live with some magic happening inside black boxes, but want to see results and would hate to dig into the details first.
<re_irc>
<@dirbaio:matrix.org> I think a big reason for the pain is the overzealous "you can't write to a reg if you don't have the peripheral singleton" thing
<re_irc>
It forces you to do weird things to share the singleton with the interrupt, where most of the time all you're doing is doing some atomic register accesses
<cr1901>
Also, embedded HALs owning peripherals makes it difficult to use interrupts (without unsafe)
<cr1901>
embassy solves this (I forget how)
<re_irc>
<@jamesmunns:beeper.com> Yeah, earlier in my teaching career I really wanted to focus on "from first principles" as the way to learn. But after talking to a lot of people who have actual teaching/pedagogical experience, they all pretty much say it's way better to start from the top and work your way down to the details incrementally (that said, this is "big picture approaches", everyone has their own preferences)
<cr1901>
it's way better to start from the top and work your way down to the details incrementally <-- ironically, this is not how things we're discovered :P
<re_irc>
<@jamesmunns:beeper.com> Discovery and teaching established concepts are very different approaches :D
<re_irc>
<@jamesmunns:beeper.com> yeah, I was thinking of you cr1901, I read that post :)
<re_irc>
<@jamesmunns:beeper.com> that's why I qualified my top down statement - for you specifically :)
<cr1901>
heh
<cr1901>
dirbaio: How does embassy solve "sharing interrupts safely with components that own their buffers/peripherals"?
<cr1901>
I asked this before, you told me the answer, I completely forgot
<re_irc>
<@dirbaio:matrix.org> the HAL handles interrupts. As a user you just write code in "main", and await things
<re_irc>
<@dirbaio:matrix.org> so as a user you never have the problem of "how to share something between main and interrupt"
<cr1901>
is there an embassy-specific HAL (i.e. not embedded-hal traits), or are HALs (i.e. embedded-hal trait crates) that support embassy expected to provide a function called during interrupt?
<cr1901>
Possibly owning a Mutex<&'static mut [u8]>
<re_irc>
<@dirbaio:matrix.org> and the HAL itself does it with the usual methods (global atomics or mutexes). and for sharing the peripheral singleton itself, it just steals it in irq if it knows the accessed registers are atomic
<re_irc>
<@dirbaio:matrix.org> for the HAL traits there's "embedded-hal-async", whcih embassy HALs implement
<cr1901>
Well, the HAL traits don't provide interrupt accessing functions
<re_irc>
<@dirbaio:matrix.org> * which
<cr1901>
ahhh
<cr1901>
I'll take a look at embedded-hal-async then.
<re_irc>
<@dirbaio:matrix.org> no, the HAL crate itself (embassy-nrf, embassy-stm32, etc) registers the interrupt handlers
<re_irc>
<@dirbaio:matrix.org> and then has a public API which is just "async fn"s
<re_irc>
<@dirbaio:matrix.org> there's no "please call this on interrupt" function in the hal drivers
<re_irc>
<@jannic:matrix.org> : Personally, the very reason I like to do embedded stuff is because it's reasonably possible to work with the hardware on a register level. So it's only natural that I want to know how it works, down to the assembly level. But then, I didn't try to learn rust and embedded at the same time. I knew both rust and embedded (to some limited extend) first. I guess it's a very different situation if one needs to learn one or both...
<re_irc>
... of those topics without prior knowledge.
<cr1901>
Ooooh, meaning they provide the #[interrupt] attribute stuff?
<re_irc>
<@jamesmunns:beeper.com> I'm not saying "never look behind the curtain", I'm just saying "don't start there" :p
<re_irc>
<@jamesmunns:beeper.com> Learn how to drive the car before you take it to bits and build your own :D
<re_irc>
<@dirbaio:matrix.org> cr1901: yes, the HAL declares the irq handler, not the user
<re_irc>
<@jamesmunns:beeper.com> Or even weaker, "you'll probably have a better time if you don't start there". Not even "don't".
<re_irc>
<@jamesmunns:beeper.com> But, I am taking the approach from a "one to many" perspective, e.g. writing docs or teaching. Individuals who want to learn however they prefer always can!
<re_irc>
<@jannic:matrix.org> Definitely - the 'dig as deep as you want, wherever you want' approach only works for individual learners. Designing a training that way would quickly alienate most students.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> Personally, “top-down” works like 10× better for me.
<re_irc>
<@ilpalazzo-ojiisan:matrix.org> “Bottom-up” is how exercises should be structured, IMO.
<wes_>
i mostly just hate my project being a hideous monolithic monstrosity. i want to be able to break it out into modules, and i'm really struggling with that.
<wes_>
everything is in fn main. it's ugly. but organizing my peripheral initializations into their own init functions is proving to not be exactly intuitive...
<re_irc>
<@dirbaio:matrix.org> why is separating them into fns hard? too many generics?
<re_irc>
<@adamgreig:matrix.org> It might actually be easier to go deeper and not use the hal
<re_irc>
<@dirbaio:matrix.org> so much generics is due to stm32f3xx-hal, it doesn't have to be this way
<re_irc>
<@dirbaio:matrix.org> in the embassy-stm32 hal it's just "Spi<SPI1, NoDma, NoDma>"
<re_irc>
<@adamgreig:matrix.org> Like if you want to be finding out how things work and keep it low level, skip the hal, write to the registers directly as needed, and it should be much easier to split up functions and modules
<re_irc>
<@adamgreig:matrix.org> In stm32-metapac it's just SPI1 right? :P
<re_irc>
<@dirbaio:matrix.org> with the PAC you're stuck with raw reg writes. My point was it is possible to have both a high-level HAL _and_ no generics spam
<re_irc>
<@adamgreig:matrix.org> Oh yea for sure, and you could use rtic and not have to do manual mutex cell unsafe static dances, but if the objective is to learn the low level...
<re_irc>
<@dirbaio:matrix.org> (and there's plans to make it just "Spi" :D)
<re_irc>
<@adamgreig:matrix.org> I like the API provided by the registers well enough 🙈
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@dirbaio:matrix.org> but then you're essentially reinventing the HAL :D
<re_irc>
<@adamgreig:matrix.org> Yea, but it's a mini hal that does exactly what my project needs
<re_irc>
<@adamgreig:matrix.org> For some things that's better off shared because all the projects need the same thing, but for most peripherals I find it ends up special enough. And for the ones that want to be shared it can easily become a shared library
<re_irc>
<@adamgreig:matrix.org> Saves a lot of complexity in the hal trying to cover every use case, or otherwise means you can use hardware in ways that hals might justifiably not bother supporting. Shrug, it's a personal idiosyncrasy and not a popular one :p
<cr1901>
>skip the hal It's not that difficult to write a HAL in-line in your crate
<cr1901>
(I'm all for skipping the HAL lol)
<cr1901>
It's good for demos, I'm not certain I want to make code I deploy _rely_ on a embedded-hal trait. Maybe crate:MyTrait {} impl<T> MyTrait for T where T: EHalTrait {}
<re_irc>
<@dirbaio:matrix.org> you can use a HAL without going through the embedded-hal traits
<re_irc>
<@dirbaio:matrix.org> many provide direct methods in addition to the trait impls
<cr1901>
Doesn't help you if your driver crate owns things that must implement the HAL traits. Anyways I finally have an application besides AT2XT in mind, and I want it to be portable, and I'm considering not relying solely on your microcontroller family having a HAL impl
<re_irc>
<@adamgreig:matrix.org> Making things portable across platforms seems like the best possible place for a hal :p
<cr1901>
I might need an interrupt handler
<re_irc>
<@adamgreig:matrix.org> Wouldn't it be easier to use the embedded-hal traits and then implement them on platforms that don't have them yet?
<cr1901>
HAL punted on interrupt handler functions, so I would have to extend then with a trait anyway
<re_irc>
<@dirbaio:matrix.org> if your driver for some spi chip has a "fn call_this_in_interrupt()", then it's not really portable
<re_irc>
<@dirbaio:matrix.org> you can't port it to "spidev"on Linux for example
<re_irc>
<@dirbaio:matrix.org> interrupts are inherently a hardware implementation detail
<re_irc>
<@dirbaio:matrix.org> you don't have interrupts in Linux userspace
<cr1901>
And most microcontrollers have them. Linux should not monopolize how embedded dev is done
<cr1901>
(As much as some ppl want it to)
<re_irc>
<@dirbaio:matrix.org> same for many embedded RTOSs, you don't handle interrupts, the kernel does it for you and resumes your thread when your spi transfer is done
<re_irc>
<@dirbaio:matrix.org> so, we shouldn't intentionally introduce traits that we know aren't portable to Linux/RTOSs
<cr1901>
(How do I say "I don't care about Linux" without sounding mean?)
<cr1901>
Uhhh... there's enough ppl who care about the Linux use case
<cr1901>
Or RTOS use case
<cr1901>
I don't know what a portable interrupt abstraction would look like, but I'm not convinced the answer is "it's impossible". Even with a fallback layer to the lowest common denominator of having the luxury of multiple OS threads
<re_irc>
<@grantm11235:matrix.org> cr1901: It's just async
<re_irc>
<@dirbaio:matrix.org> I don't think it's impossible
<re_irc>
<@dirbaio:matrix.org> I do think it's _not wanted_
<re_irc>
<@dirbaio:matrix.org> it's the wrong thing to abstract
<re_irc>
<@dirbaio:matrix.org> you want to abstract "do an SPI transfer, wait for it to be done, then do more things"
<cr1901>
Just the HAL traits deliberately didn't consider it to cater to the Linux APIs, and now I'm either stuck not being able to abstract _any_ of the reg read/writes away by virtue of not being able to use an existing HAL
<cr1901>
Or I abstract _all_ of them away by using a driver which owns a HAL type
<cr1901>
Are interrupts just a way for you to "set a flag and then notify the main thread"?
<re_irc>
<@dirbaio:matrix.org> With the async SPI trait, on embedded you can implement that on top of interrupts, and on linux you can implement it on top of epoll/io-uring
<re_irc>
<@wes_:matrix.org> : it's not the generics (even though they are a pain in the ass), it's passing these guys around, and my code breaking when i try to
<re_irc>
let dp = pac::Peripherals::take().unwrap();
<re_irc>
let clocks = rcc.cfgr.freeze(&mut dp.FLASH.constrain().acr);
<re_irc>
let mut rcc = dp.RCC.constrain();
<re_irc>
<@dirbaio:matrix.org> it abstracts away the interrupt, because it's a hardware implementation detail
<cr1901>
Again, are interrupts just a mechanism whose sole purpose is to notify?
<cr1901>
for you*
<re_irc>
<@dirbaio:matrix.org> and yes, this does mean you have to treat interrupts as "notify the main thread"
<cr1901>
If you're fine w/ that, then yea, async SPI is fine
<re_irc>
<@dirbaio:matrix.org> that's the price you have to pay to get a trait that's truly portable to everywhere
<cr1901>
But I don't write applications like that
<re_irc>
<@wes_:matrix.org> i just haven't been able to figure out the correct way to pass and return these 'globals' in the correct way
<re_irc>
<@dirbaio:matrix.org> sure you can do that, but then your application won't be portable
<cr1901>
that's the price you have to pay to get a trait that's truly portable to everywhere <-- then conditional compilation it is. I'm not willing to pay that price
<re_irc>
<@dirbaio:matrix.org> and "I want my application to be portable, but only to bare-metal MCUs that do have interrupts, not to Linux or RTOSs" is a strange thing to want
<re_irc>
<@dirbaio:matrix.org> an interrupt trait would give you that, not real portability
<cr1901>
Not every application needs to run an OS, and I would provide an option for Linux anyway
<cr1901>
Are you defining portability as "no #[cfg()] snippets at all"?
<re_irc>
<@dirbaio:matrix.org> to me "portable" means "driver takes a generic "T: SpiBus", that is implementable on all platforms"
<re_irc>
<@dirbaio:matrix.org> so yes, no cfg's. if you need cfg's, that means the SpiBus trait is not well designed
<re_irc>
<@dirbaio:matrix.org> cfgs to support both interrupt-driven io and blocking io is not "port_able_", it's "port_ed_"
<re_irc>
<@dirbaio:matrix.org> ported to 2 different kinds of hardware, and you'll need to port it again for the 3rd kind
<cr1901>
You start running up against limits real quick when you only have a blocking HAL and no threads (which is "every non OS environment"). And I don't have an opinion on using embassy other than 1. yes I still need to port it to msp430
<cr1901>
2. Even if I absolutely love it I'm not convinced "limited blocking API that can't utilize a bare metal environment's features well" and "async runtime that only uses interrupts as a notification mechanism- akin to an OS" are the Two True Ways to write a microcontroller program
<cr1901>
TL;DR "embedded Rust really wants applications to be Linux or OS-shaped even without an OS"
<re_irc>
<@dirbaio:matrix.org> i'm not saying that's the case. There's the 3rd way, interrupt-driven running things in the irq handler, as you're doing
<re_irc>
<@rjmp:matrix.org> @cr1901 I agree re interrupts. Interrupt driven IO is (often) important and I would not trade them for portability in many cases, and interrupts as main thread notification isnt quite the same
<re_irc>
<@dirbaio:matrix.org> that's a fine way if you're targeting one MCU
<re_irc>
<@adamgreig:matrix.org> rtic's really popular and the complete opposite, it's entirely built on interrupts and running code in interrupts
<re_irc>
<@dirbaio:matrix.org> it's just _not portable_
<re_irc>
<@dirbaio:matrix.org> but it's fine to do not-portable stuff
<cr1901>
mmmm... I'll have to think about this
<re_irc>
<@adamgreig:matrix.org> loads of embedded rust is bare-metal, uses interrupts, no OS or linux
<cr1901>
I _like_ portability
<re_irc>
<@dirbaio:matrix.org> RTIC v2 is adding async support
<cr1901>
but dirbaio, you're bringing my portability credentials in question :P
<re_irc>
<@dirbaio:matrix.org> perhaps that says something about pure-interrupt-driven's scalability to larger projects :P
<re_irc>
<@adamgreig:matrix.org> embedded-hal excludes interrupts from the traits like spi and i2c because interrupts aren't material to the thing being abstracted (i2c or whatever)
<cr1901>
(joke, not serious)
<re_irc>
<@adamgreig:matrix.org> doesn't embassy support running several executors in different interrupt contexts for priority and pre-empting and so forth?
<cr1901>
Or perhaps that's more of the popularity of async period. Rust has done a good job marketing it, and it's where the funding comes from (AIUI)
<re_irc>
<@adamgreig:matrix.org> both seem a nice example of how you can use async and interrupts together for the different things they're good at
<re_irc>
<@dirbaio:matrix.org> it does (but interrupts are still abstracted away, it's not like you run the executor in the UART interrupt for it to poll the UART task)
<re_irc>
<@adamgreig:matrix.org> right, sure
<cr1901>
I guess "the way I'm used to writing embedded apps requires more granularity/control than the embedded hal traits allow"
<cr1901>
Even HAL traits mutably borrowing means that device drivers that can run in interrupt context require a RefCell
<re_irc>
<@jamesmunns:beeper.com> tbqh, I think HALs (and the e-hal traits) should be a reasonable default case
<cr1901>
compared to doing the writes manually
<re_irc>
<@jamesmunns:beeper.com> they aren't ever going to handle every long tail tunable without becoming monsters
<cr1901>
I think they're too limited for stuff besides demos, and embassy is definitely viable for when you hit those limits
<re_irc>
<@jamesmunns:beeper.com> like, in MOST projects I use "off the shelf", then if I need more perf or some certain different behavior, I just vendor + patch the lib or as often as possible just use a different impl (e.g. give the peripheral to MY driver, not the HAL's driver)
<re_irc>
<@jamesmunns:beeper.com> I'd push back on "just okay for demos"
<re_irc>
<@jamesmunns:beeper.com> usually I have lets say 4-5 actual peripherals I care about
<re_irc>
<@jamesmunns:beeper.com> most of the time, all but one or two I use off-the shelf drivers without touching anything
<re_irc>
<@jamesmunns:beeper.com> there's usually one or two I end up tweaking to get latency/throughput/whatever tuned to my specific needs
<re_irc>
<@jamesmunns:beeper.com> but that's still 60%+ of the project I didn't have to think about, and 100% of the first draft.
<cr1901>
GPIO trait is fine- it can't fail/block. I have also written HALs in-line that use interrupts
<cr1901>
(i.e. not as a crate, but I impl the traits in my own application)
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<cr1901>
I think I need to actually write my application before I comment more and see how it turns out. It's prob simple enough to port to embassy to compare/contrast code size too