<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>
<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>
<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.
<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>
<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