<re_irc>
<@twitchyliquid64:matrix.org> random Q, is anyone working on multirotor/drone fw in embedded rust?
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
troth has quit [Ping timeout: 265 seconds]
aquijoule__ has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> korken89 definitely is, and I believe Mara is as well
aquijoule_ has quit [Ping timeout: 265 seconds]
troth has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> What kind of errors could a `Chipselect` implimentation run into? This is all that I can think of so far, am I missing anything?
<re_irc>
<@grantm11235:matrix.org> 1. Chipselect poisoned (Some device on the bus previously encounterd a cs pin error)
<re_irc>
<@grantm11235:matrix.org> 2. Chipselect pin failed to assert
<re_irc>
<@grantm11235:matrix.org> 3. Chipselect pin failed to deassert
<re_irc>
<@grantm11235:matrix.org> 4. Failed to lock spi bus with `RefCell::try_borrow_mut` (Only for shared spi types that use a `Refcell`)
<re_irc>
<@grantm11235:matrix.org> Number 4 would only be the result of a pretty obvious programming error, so maybe it is fine to just use the infallible/panicking `RefCell::borrow_mut`
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@newam:matrix.org> grantm11235:matrix.org: Permissions errors for CPUs with multiple execution levels and things like embedded linux.
<re_irc>
<@newam:matrix.org> Hmm and maybe meta errors (SPI or I2C) from GPIO expanders
<re_irc>
<@newam:matrix.org> Definitely not a common usecase, I'm just trying to dream up more errors since you asked 😅
<re_irc>
<@grantm11235:matrix.org> newam:matrix.org: You mean when the chipselect pin in on a gpio expander? That would be covered by the cs (de)assert errors
<re_irc>
<@newam:matrix.org> Ah, right.
<re_irc>
<@grantm11235:matrix.org> newam:matrix.org: Would these errors actually come from the `Chipselect` impl, or would they only happen when you try to do an spi operation inside the closure?
<re_irc>
<@newam:matrix.org> grantm11235:matrix.org: For the MMU on Cortex A cores it would occur on a memory read/write to the GPIO peripheral. Embedded linux... Well depends how it is implemented I guess. The raspberry pi HAL probably has an example
<re_irc>
<@grantm11235:matrix.org> That would still just be a cs pin error, right?
<re_irc>
<@newam:matrix.org> I guess it depends on the error handling needed.
<re_irc>
<@newam:matrix.org> Permission errors are usually handled with a halt and catch fire, or retry loop (rare) in my experience
<re_irc>
<@grantm11235:matrix.org> An impl of `Chipselect` doesn't need to try to fix an error, it just needs to return it
<re_irc>
<@grantm11235:matrix.org> This is what my `Chipselect` trait looks like at the moment
<re_irc>
<@twitchyliquid64:matrix.org> jamesmunns:beeper.com: Im super keen on jumping on if theres something already existing? im guessing hacking on an existing stm32-based board but with custom (rust) firmware?
troth has quit [Ping timeout: 256 seconds]
troth has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
troth has quit [Ping timeout: 264 seconds]
troth has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> twitchyliquid64:matrix.org: I made special hardware that I used :)
<re_irc>
<@korken89:matrix.org> I used it as a project when learning Rust, but nothing sane maintained anymore from my side
troth has quit [Ping timeout: 250 seconds]
troth has joined #rust-embedded
<re_irc>
<@matoushybl:matrix.org> twitchyliquid64:matrix.org: What parts of such firmware are you interested in hacking on? Drones are immensely complex and not to mention dangerous. If you’d like to play around with the pixhawk flow camera, there is a Rust firmware for that that should bring the hardware up.
<re_irc>
<@therealprof:matrix.org> I have one of those here. Needless to say I couldn't convince my son to actually do anything with it and even the provided firmware from ST is no good at all.
creich_ has joined #rust-embedded
creich has quit [Ping timeout: 250 seconds]
emerent has quit [Ping timeout: 250 seconds]
creich_ is now known as creich
fabic has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> Idle lunch time thought. BSPs could provide a #[bsp_entry] macro which does what cortex-m-rt [entry] does, but also sets up all the clocks and pins and passes you a Board object.
<Lumpio->
Is it worth adding a magic macro if you can just have a function that does that and return a Board object?
<re_irc>
<@firefrommoonlight:matrix.org> What's the use case for a BSP? Doesn't seem good for either learning or prototyping
<re_irc>
<@firefrommoonlight:matrix.org> Learning since it encourages dependence on a provincial lib. (This bit me with the Disco book when learning; took me a while to figure out how to adapt what I learned to the more general libs)
<re_irc>
<@firefrommoonlight:matrix.org> Prototyping since your project won't be on a dev board
<re_irc>
<@firefrommoonlight:matrix.org> Ie it's useful, and easy to be able to find which pins a dev board's periphs are connected to, and use a more general lib
<re_irc>
<@firefrommoonlight:matrix.org> Let's say your dev board has buttons and LEDs you want to use. I argue it's easier to find the GPIO mapping in the board's DS than to learn a BSP
<re_irc>
<@firefrommoonlight:matrix.org> Once I design the real board, I add a comment with the actual pin to use, above the code that uses the dev board pin
<re_irc>
<@firefrommoonlight:matrix.org> Once on the real board, update the pin number/port etc per the comment
<re_irc>
<@wim:dewith.io> A BSP allows type safety over pin assignments right? I'm not sure how you could achieve this without specific types per pin.
<re_irc>
<@firefrommoonlight:matrix.org> What does that mean?
<re_irc>
<@wim:dewith.io> A driver can be generic over the exact pins where it is connected so when you pass certain pins to that drivers' constructor, you can no longer use them for anything else. This can only be statically determined when you explicitly have different types for every pin, which means you need to define those somewhere.
<re_irc>
<@wim:dewith.io> Besides, for example in the Teensy BSP, the pin numbers are already an abstraction for where they are actually connected to the MCU
<re_irc>
<@dirbaio:matrix.org> > when you pass certain pins to that drivers' constructor, you can no longer use them for anything else
<re_irc>
<@dirbaio:matrix.org> this is already the case with HAL pins (not BSP)
<re_irc>
<@burrbull:matrix.org> typenum ðŸ˜
<re_irc>
<@wim:dewith.io> dirbaio:matrix.org: Ah yes, of course, but then you would need to match the HAL pins to the board pins on your own
<re_irc>
<@dirbaio:matrix.org> many boards simply name their pins after the MCU pins..
<re_irc>
<@dirbaio:matrix.org> in general I'm not a fan of BSPs, it's just a slight convenience increase
<re_irc>
<@dirbaio:matrix.org> and I'm especially *not* a fan of BSPs in learning material, it makes people helpless when they inevitably try to use a board that has no BSP (or worse, a BSP using a 2-year-old HAL)
Foxyloxy has quit [Remote host closed the connection]
Foxyloxy has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> wim:dewith.io: I don't know what that means :(
<re_irc>
<@wim:dewith.io> You can have this:
<re_irc>
<@wim:dewith.io> ```rust
<re_irc>
<@wim:dewith.io> let pins = ...;
<re_irc>
<@wim:dewith.io> let foo: Foo<P1, P2> = Foo::new(pins.p1, pins.p2);
<re_irc>
<@wim:dewith.io> However, as dirbaio said, it's the HAL that actually provides this safety
<re_irc>
<@firefrommoonlight:matrix.org> I assumed BSPs are libs that let you do things like `bsp::LedRed.turn-on` as opposed to `led_pin.set_high`
<re_irc>
<@wim:dewith.io> dirbaio:matrix.org: but many don't as well
<re_irc>
<@wim:dewith.io> Teensy has a IOMUX which makes it way more complicated if there was no BSP, I think
<re_irc>
<@wim:dewith.io> firefrommoonlight:matrix.org: Yeah, generally that is true, I just confused the HAL with the BSP
fabic has quit [Ping timeout: 256 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> Arm's nucleo boards are annoyingly labeled
<re_irc>
<@firefrommoonlight:matrix.org> They double name each pin, and you have to check the DS and count pins
<re_irc>
<@firefrommoonlight:matrix.org> Their Disco boards don't do this
<re_irc>
<@firefrommoonlight:matrix.org> Also, you have to solder some of the nucleo pins
<re_irc>
<@grantm11235:matrix.org> dirbaio: I think I found a potential way to avoid `OptionalPin` shenanigans using the never type. If e-h impl'd all the traits for the never type, you could simply do this
<re_irc>
<@dirbaio:matrix.org> it's a bit strange that you can create a `MyDriver<PA4>` with either `Some(PA4)` or
<re_irc>
<@grantm11235:matrix.org> Actually, you don't even need the never type, you could define your own variantless enum and impl `OutputPin` youself
<re_irc>
<@dirbaio:matrix.org> ideally `MyDriver<PA4>` would always have the pin
<re_irc>
<@dirbaio:matrix.org> like
<re_irc>
<@dirbaio:matrix.org> if you make the optionality both typelevel and at runtme (with `Option`) you get these weird thigns
<re_irc>
<@grantm11235:matrix.org> Yeah, `let foo: MyDriver<PA4> = MyDriver::new(None)` would be pretty weird
GenTooMan has quit [Ping timeout: 264 seconds]
<re_irc>
<@grantm11235:matrix.org> Does `OptionalPin` allow drivers to change their behavior depending on whether a pin is given?
<re_irc>
<@dirbaio:matrix.org> but that only really works for HAL pins and HAL drivers, it's not something that could go in embededd-hal I think
GenTooMan has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Let's say you're doing operations on an array. Eg DSP. Is there a performance penalty for passing the array by ref to a fn, then returning the processed array, as opposed to passing a static mut array as mutable ref, and modifying in place?
<re_irc>
<@firefrommoonlight:matrix.org> Eg, does the first approach use more RAM etc?
<re_irc>
<@dirbaio:matrix.org> not doing it in-place will use 2x ram
<re_irc>
<@firefrommoonlight:matrix.org> (Another variant: modifying the static mut array directly in the fn instead of as an arg)
<re_irc>
<@firefrommoonlight:matrix.org> Thank you
<re_irc>
<@dirbaio:matrix.org> maybe the compiler can optimize it to use only 1x in some cases, but I'd say it's rare
<re_irc>
<@firefrommoonlight:matrix.org> I prefer the code style of passing args and returning things, but not worth the extra ram for code style here :(
<re_irc>
<@firefrommoonlight:matrix.org> Thank you. Not what I wanted to hear :(
<re_irc>
<@korken89:matrix.org> You more or less need NRVO for that optimization to be guaranteed
<re_irc>
<@korken89:matrix.org> And C++ setil has issues getting it to happen
<re_irc>
<@firefrommoonlight:matrix.org> I'll go through the code base in question and change to modify in place
<re_irc>
<@firefrommoonlight:matrix.org> There's no dif between passing the static mut array as a mut ref vice accessing it directly in the modifying fn, right?
<re_irc>
<@korken89:matrix.org> Send lite rust does it partially from old issues I find
<re_irc>
<@korken89:matrix.org> Would be interesting to track down its capabilities today
<re_irc>
<@dirbaio:matrix.org> IME if you assign the return value to its final resting place directly (with no conditionals and no drop of the old thing etc) then NRVO always happens
<re_irc>
<@firefrommoonlight:matrix.org> I could do some testing. I've tried both and they both work, but haven't compared mem use
<re_irc>
<@firefrommoonlight:matrix.org> *all 3 approaches if you count mutable ref and accessing directly separate
<re_irc>
<@korken89:matrix.org> Yeah, this is a nice thing for a good whiskey and an evening of experimentation and assembly inspection
<re_irc>
<@firefrommoonlight:matrix.org> In the case I had in mind, I'm chaining together a set of functions, so it probably can't guarantee that
<re_irc>
<@firefrommoonlight:matrix.org> So I should modify in place
<re_irc>
<@firefrommoonlight:matrix.org> Haha
<re_irc>
<@therdel:matrix.org> Hi everyone!
<re_irc>
<@therdel:matrix.org> Is there someone who I could talk to about open topics I could tackle (~4-5 months part-time work) for my thesis?
<re_irc>
<@therdel:matrix.org> I'm curious about doing my thesis in the realm of open source embedded rust.
<re_irc>
<@therdel:matrix.org> I do my masters in computer science: embedded systems.
<re_irc>
<@jamesmunns:beeper.com> I think the folks working on RTIC (cc per.lindgren) are the most actively involved academic folks
<re_irc>
<@jamesmunns:beeper.com> Ferrous Systems has discussed having masters students before, might be worth shooting an email to contactferrous-systems.com, though I have no idea what their capacity or planning would be
<re_irc>
<@jamesmunns:beeper.com> I'm personally full of crazy ideas, and happy to chat, but I have no idea if that's helpful or relevant :)
<re_irc>
<@jamesmunns:beeper.com> Oh, the folks working on tock-os are also fairly academically involved, but they play sort of separately from the rest of the rust-embedded ecosystem
<re_irc>
<@jamesmunns:beeper.com> Tweede Golf (CC diondokter) might be in a similar position as Ferrous, but I also don't know if they have capacity/interest in masters students at the moment.
<re_irc>
<@jamesmunns:beeper.com> Also, if you happen to have twitter, and tweet your request and mention `rustembedded`, I'm happy to retweet from that account to signal boost.
<re_irc>
<@therdel:matrix.org> The topic doesn't have to be very "academic", it's a university of applied sciences :)
<re_irc>
<@therdel:matrix.org> Thanks for the response!
<re_irc>
<@therdel:matrix.org> It's practical work what I seek, which I intend to approach rigorously for my thesis.
<re_irc>
<@jamesmunns:beeper.com> (there's a fairly active rust+embedded+twitter crowd)
<re_irc>
<@jamesmunns:beeper.com> If you're interested in network protocols, drivers, maybe scripting language runtimes, I'd be more than happy to chat with you about my anachro project, which might be interesting
<re_irc>
<@jamesmunns:beeper.com> I hang out over in #anachro:matrix.org for that
<re_irc>
<@firefrommoonlight:matrix.org> Is your intent to build infrastructure, or make devices?
<re_irc>
<@jamesmunns:beeper.com> Not sure about the difference, I plan to build a protocol and environment that will allow me (or others?) to make a lot of devices.
<re_irc>
<@firefrommoonlight:matrix.org> *Sorry, meant that mainly for therdel
<re_irc>
<@firefrommoonlight:matrix.org> But that sounds like both!
<re_irc>
<@jamesmunns:beeper.com> It's meant to be locally-free-standing, so no IoT, but local APIs for interaction, and probably integration to something else if desired
<re_irc>
<@therdel:matrix.org> Research of status quo, evaluating all options, planning, implementing, testing/evaluation, outlook.
<re_irc>
<@therdel:matrix.org> That's generally how I see it.
tafa has quit [Ping timeout: 245 seconds]
tafama has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> That's broad enough to leave you with many options!
<re_irc>
<@firefrommoonlight:matrix.org> My first thought is to build an RTOS
<re_irc>
<@firefrommoonlight:matrix.org> We don't have one, and that fits your criteria
<re_irc>
<@therdel:matrix.org> James Munns: Thanks a lot for the contacts and pointers, too!
<re_irc>
<@firefrommoonlight:matrix.org> Or perhaps RF infrastructure
<re_irc>
<@firefrommoonlight:matrix.org> Or control system libs
tafama has quit [Ping timeout: 250 seconds]
tafa has joined #rust-embedded
<Lumpio->
Alright so "nb" is rearing its head again
<Lumpio->
Can "nb" be used to write useful composable operations?
<Lumpio->
Like let's say you have a serial port with "fn write(&mut self, b: u8) -> nb::Result<(), E>", can you use it to write "fn write_bytes(port: &mut SerialPort, bytes: &[u8]) -> nb::Result<(), E>"
<Lumpio->
Because I don't see how write_bytes is going to store which byte it's currently writing anywhere.
<Lumpio->
Since it's not like futures where the function returns a value you can poll(), but instead you must poll the function itself.
<re_irc>
<@dirbaio:matrix.org> irc_libera_lumpio-:psion.agg.io: nope, it can't :D
<Lumpio->
I remember you telling me that before but can somebody verify heh
<re_irc>
<@dirbaio:matrix.org> well, you can do this