ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <adamgreig> omg
<re_irc> <dirbaio> with non-svg images it's trickier https://github.com/rust-lang/rust/issues/32104
<re_irc> <adamgreig> just included as a string, wow
<re_irc> <dirbaio> SVG is valid HTML! :D
<re_irc> <justinrestivo> that is very cool!
<re_irc> <dirbaio> it still pastes the xml and doctype declarations which is theoretically wrong
<re_irc> <?xml version="1.0" encoding="UTF-8"?>
<re_irc> <!DOCTYPE svg ...
<re_irc> <dirbaio> but browsers don't care, yolo
<re_irc> <adamgreig> you could always remove those
<re_irc> <dirbaio> but then it's the .svg file what's technically broken
<re_irc> <dirbaio> hmm browsers still display it and diagrams.net imports it just fine
<re_irc> <dirbaio> so yeah, better remove them
<re_irc> <dirbaio> * them, I guess :D
<re_irc> <dirbaio> so yeah, better remove them, I guess :D
<re_irc> <adamgreig> i love diagrams.net, i use their desktop version all the time
<re_irc> <adamgreig> are you using the svg export or the version that has the diagram data embedded in it too?
<re_irc> <dirbaio> yup
<re_irc> <dirbaio> ugh embedded-hal MSRV is 1.46+ and "#[doc = include_str!(...)]" is 1.54+
<cr1901> therealprof: Oh yea, that works too. It's not how I've been writing HAL code personally, but I'm a bit too scatterbrained rn to go into detail
<Darius> adamgrieg: I wrote an addon for our work wiki to support that, it's pretty neat to be able to edit diagrams with a few clicks
jackneilll has joined #rust-embedded
jackneill has quit [Ping timeout: 250 seconds]
jackneilll has quit [Quit: Leaving]
<re_irc> <chrysn (@chrysn:matrix.org)> Hmpf, missed the meeting (holidays between terms still mess with one's schedule when not having time off). Thanks for taking down some points and pointers!
<re_irc> <eldruin> we got carried away with sharing buses :D
<re_irc> <chrysn (@chrysn:matrix.org)> Yeah, just finished skimming the SPI sharing thread, looks like good change.
<re_irc> <chrysn (@chrysn:matrix.org)> (I can totally see how one gets carried away there)
<re_irc> <ryan-summers> That's been a problem for years though, so it definitely needs to change
<re_irc> <ryan-summers> Even solutions like "shared-bus" for SPI were potentially unsound because of it
Amadiro has joined #rust-embedded
Socke has quit [Ping timeout: 272 seconds]
Socke has joined #rust-embedded
starblue1 has quit [Ping timeout: 252 seconds]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
starblue1 has joined #rust-embedded
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
<re_irc> <thejpster> Doing a panel session shortly for Embedded Innovation Week on the Evolution of Security of Connected Devices. No prizes for guessing which programming language I think might have some uses here...
<re_irc> <thejpster> Hint: It's not COBOL.
<re_irc> <d3zd3z> thejpster: COBOL, right?
<re_irc> <burrbull> no ideas
<re_irc> <dalepsmith> thejpster: You are the ferrous systems guy on the panel?
<re_irc> <thejpster> y
jackneill has joined #rust-embedded
<re_irc> <barafael> so there are a number of kalman, madgwick, ahrs crates. "rudie" is no_std but predates const-generics, uses typenum. There is "madgwick", that one is marked read-only on GH. Then there are a number of WIP or empty crates. And there is "adskalman", which looks fairly nice actually.
<re_irc> <firefrommoonlight> No EKF though!
<re_irc> <firefrommoonlight> Or unscented etc
<re_irc> <firefrommoonlight> I'm going to have to build one from scratch or port from C etc
<re_irc> <firefrommoonlight> The linear ones look poorly documented
<re_irc> <barafael> I just need it for IMU data, don't know much about these filters actually.
<re_irc> <firefrommoonlight> I think we're on our own here
<re_irc> <firefrommoonlight> Fusing accel and gryos to estimate attitude?
<re_irc> <barafael> exactly
<re_irc> <barafael> would prefer to use madgwick actually
<re_irc> <barafael> if possible, would like to use magnetometer data as well :D high expectations I guess
<re_irc> <firefrommoonlight> You could try translating this, but I can't vouch for it: https://github.com/Mayitzin/ahrs/blob/master/ahrs/filters/madgwick.py
<re_irc> <firefrommoonlight> I'm going to have a go at EKF
<re_irc> <firefrommoonlight> More complex, but better and more versatile when adding other sensors too
<re_irc> <barafael> yes, EKF is great
<re_irc> <barafael> micromath has quaternions, hmm
<re_irc> <firefrommoonlight> So does CMSIS-DSP
<re_irc> <barafael> i think this might be best to port to no_std: https://github.com/jmagnuson/ahrs-rs/blob/master/src/madgwick.rs
<re_irc> <thejpster> panel session over. That was fun!
<re_irc> <thejpster> Did I mention I like Rust? I feel like I might not have said it enough.
<re_irc> <ryan-summers> there-be-dragons trying to do your own sensor fusion btw. Expensive IMUs are well worth the money to give you simple, reliable data
<re_irc> <ryan-summers> I fought sensor fusion for years on one project and eventually solved it by just throwing more money to get a solution that gave us the fusion results
<re_irc> <thejpster> I wrote the sensehat-rs crate for the Raspberry Pi Sensehat. I looked at it for a while, then just used the same IMU C library that the Python library used.
<re_irc> <firefrommoonlight> It's unavoidable in many cases
<re_irc> <firefrommoonlight> Even for fusing gyro + accels into attitude platform, none of it could output attitude from hardware. Do you know of any that do?
<re_irc> <firefrommoonlight> Plus when you throw other sensors in there, there's no hardware that will do it
<re_irc> <firefrommoonlight> Even for fusing gyro + accels into attitude platform, no IMU I looked at could output attitude from hardware. Do you know of any that do?
<re_irc> <firefrommoonlight> Is it tough? Yes. Is it useful and/or a project requirement in some cases? Yes.
starblue1 has quit [Ping timeout: 240 seconds]
<re_irc> <barafael> firefrommoonlight: well there is this: https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-mpu9250/
<re_irc> <barafael> i've used this, it's good
<re_irc> <firefrommoonlight> Nice
<re_irc> <firefrommoonlight> I'll post what I come up with re EKF when I get to it. Days to weeks; have some other things on the list first
<re_irc> <firefrommoonlight> Going to start with just accel+gyro, but plan to bake a whole lot of other things into it later
starblue1 has joined #rust-embedded
<re_irc> <firefrommoonlight> -a whole lot of
<re_irc> <firefrommoonlight> Eg GPS, compass, optical flow, TOF
unknown__ has quit [Quit: Leaving]
creich has joined #rust-embedded
rektide has quit [Ping timeout: 256 seconds]
gpanders_ has quit [Remote host closed the connection]
gpanders_ has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
gpanders_ has quit [Remote host closed the connection]
gpanders_ has joined #rust-embedded
<re_irc> <vdkj> Hi there,
<re_irc> I'm trying to use QeiManager like so:
<re_irc> [...]
<re_irc> use stm32f1xx_hal::{
<re_irc> <henrik_alser> vdkj: Hmm, how do you mean? The "qei" as in "use qei::QeiManager;" is just the name of an external crate, while the one inside the hal is a module that contains the helper functionality for the peripheral that happens to have the same name... Since they are not part of the same crate i don't know how it could have been avoided?
<re_irc> <henrik_alser> Best way to avoid confusion is to add some aliases in your project
<re_irc> <vdkj> henrik_alser: Makes sense.
<re_irc> <henrik_alser> like "use qei as qeimanager;" or so
<re_irc> <vdkj> +I did not understand that structure.
gpanders_ has left #rust-embedded [#rust-embedded]
vancz has quit [Quit: vancz]
vancz has joined #rust-embedded
<re_irc> <barafael> All those drivers using blocking embedded hal interfaces are hard to use with interrupts/DMA-based interfaces. Is there a plan or a way forward here? I guess with a preemptive OS blocking calls can be handled. But with bare metal or RTIC it seems way harder to handle
<re_irc> <pinealservo> It's that or manually-managed state machines, the old-fashioned way. ;)
<cr1901_> How about with async :)?
cr1901_ is now known as cr1901
<re_irc> <barafael> Ok, I suspected so :) but still means our drivers have to be adapted right?
<re_irc> <pinealservo> I haven't tried async rust in embedded yet, but I'm really interested to see how it plays out.
<re_irc> <GrantM11235> dirbaio: Is "ExclusiveDeviceError" needed? It looks like only the "Cs" variant is ever used
<re_irc> <dirbaio> flush uses the other one :)
<re_irc> <dirbaio> I don't like the enum is needed either though..
<re_irc> <dirbaio> +that
* cr1901 needs to eventually port embassy to msp430, but is also wondering the true min size cost for an async runtime in code space
<re_irc> <dirbaio> but can't think of a way to do without
<re_irc> <GrantM11235> Ah, I hadn't looked at 365 yet
<re_irc> <dirbaio> Oooh, hmm... the "transaction" docs say CS is toggled for each one, so I'd say it isn't
<re_irc> <dirbaio> some spi chips need you to toggle CS for each "command"
<re_irc> <dirbaio> a driver relying on that would break if you give it a LazyExclusiveDevice
<re_irc> <dirbaio> what's the use case? faster for devices that don't need the toggling?
<re_irc> <GrantM11235> Does that mean that you couldn't have a SpiDevice with a hardwired cs pin either?
<re_irc> <dirbaio> if you know your chip doesn't care if you permanently tie CS low, nothing stops you from doing that impl in your own code and it'll work
<re_irc> <dirbaio> but as it's documented now, that impl is "wrong"
<re_irc> <dirbaio> maybe there could be a marker trait for drivers to say "I need the SpiDevice impl to actually toggle CS every time"
<re_irc> <dirbaio> but I'm not sure if it's worth it, it would create more confusion I think..
<re_irc> <GrantM11235> "ManagedCS" is back 🤣
<re_irc> <dirbaio> you can use the official ExclusiveDevice with a dummy no-op OutputPin as well
<re_irc> <GrantM11235> I think that most devices don't care when CS is toggled, as long as it is active while data is being transfered
<re_irc> <dirbaio> hmm are you sure? I think most that do "read register, write register" do care
<re_irc> <dirbaio> so that they know what's address and what's data
<re_irc> <GrantM11235> I guess I haven't read that many spi device data sheets, so you could be right
<re_irc> <dirbaio> SPI displays don't care (the one I've played with, at least)
<re_irc> <GrantM11235> I don't think the ili lcd drivers care, but they have seperate read/write and address/data pins
<re_irc> <dirbaio> display_interface already has SpiInterface, SpiInterfaceNoCs
<re_irc> <dirbaio> so in eh1.0 SpiInterface would use SpiDevice, SpiInterfaceNoCs would use SpiBus
<re_irc> <dirbaio> if you want to keep allowing tying CS permanently low'
<re_irc> <dirbaio> * low
SanchayanMaity has quit [Ping timeout: 250 seconds]
darknighte has quit [Read error: Connection reset by peer]
darknighte has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
<re_irc> <GrantM11235> Would there be any benefit to requiring the closure to return "Result<T, Self::Bus::Error>"?
<re_irc> <GrantM11235> I'm pretty sure that will be the case 99% of the time (and 90% of the time, "T" will be "()")
<re_irc> <dirbaio> so that ExclusiveDevice wraps the inner error into the ExclusiveDeviceError, for example?
<re_irc> <dirbaio> the problem is if you do want to return another error
<re_irc> <GrantM11235> Maybe, or perhaps "transaction" would return "Result<Result<T, Self::Bus::Error>, Self::Error>"
<re_irc> <dirbaio> you'll have to return "Result<Result<(), MyError>, Self::Bus::Error>"
<re_irc> <dirbaio> for example if you receive invalid data
<re_irc> <dirbaio> SPI itself didn't fail, but you received nonsense
<re_irc> <GrantM11235> dirbaio: That would get pretty awkward, especially if it would then be wrapped in "Result<_, Self::Error>" lol
<re_irc> <dirbaio> yeah lol
<re_irc> <dirbaio> maybe arguably it's a good practice to only read/write the data inside the transaction, parse it outside?
<re_irc> <dirbaio> +and
<re_irc> <dirbaio> so you shouldn't need to return custom errors from inside the transaction often..?
<re_irc> <GrantM11235> I think you can still smuggle a result out of the closure if you do "let mut res: Result<(), MyError> = Ok();" before the closure and modify it inside
<re_irc> <dirbaio> oof :D
<re_irc> <dirbaio> seems cleaner to make "T=Result<...>", even if there's nested results
<re_irc> <GrantM11235> dirbaio: You might want to stop the transaction early if you detect bad data
<re_irc> <dirbaio> yeah
<re_irc> <dirbaio> ugh D:
<re_irc> <dirbaio> that's rare though?