<re_irc> <@a​lmindor:m​atrix.org> how are you supposed to use multiple SPI devices with an MCU (that has single SPI interface + additional SS pins)? Do you need a "hardware switch" that depends on the SS pins being pulled and time share?
<re_irc> <@g​rantm11235:m​atrix.org> The spi devices have that "hardware switch" built in, that is what the SS pin does
<re_irc> <@a​lmindor:m​atrix.org> so you wire them on all on the same pins in series and put the individual SS connections on the CS on the devices
<re_irc> <@g​rantm11235:m​atrix.org> When SS (AKA chipselect or CS) is activated, the device disconnects its MISO an MOSI pins
<re_irc> <@a​lmindor:m​atrix.org> right, and to make matters more complex some devices lack the CS pin :D I guess those would have to be wired off when "their" CS is pulled
<re_irc> <@g​rantm11235:m​atrix.org> Actually I think you need to disconnect MISO and SCK, you can probably leave MOSI connected
<re_irc> <@a​lmindor:m​atrix.org> ok and on the Rust side.. how does this work? I mean the SPI consumes all the pins, there's no way to construct 2 of them to give to separate drivers...
<re_irc> <@g​rantm11235:m​atrix.org> On the rust side it... doesn't work. See https://github.com/rust-embedded/embedded-hal/issues/299
<re_irc> <@a​lmindor:m​atrix.org> that description still doesn't solve the driver consumes issue
<re_irc> <@a​lmindor:m​atrix.org> even if we were to not use the CS in the implementation of the SPI, how would you share the interface itself to 2 drivers?
<re_irc> <@a​lmindor:m​atrix.org> we'd need something like a BusBag with BusBag::acquire() and a whole bunch of critical section like stuff no?
<re_irc> <@g​rantm11235:m​atrix.org> The HAL would need to use some kind of mutex
<re_irc> <@a​lmindor:m​atrix.org> ah I see in the examples
<re_irc> <@a​lmindor:m​atrix.org> I found a nice USB host -> SPI tiny adapter board that I can use to get that gamepad dream going but then started thinking hmm.. how would this really work with the display on the SPI bus as well
<re_irc> <@a​lmindor:m​atrix.org> might be a good reason to implement this for the e310
<re_irc> <@g​rantm11235:m​atrix.org> If you do, let me know how it goes. I haven't actually implemented it beyond my simplified example.
<re_irc> <@a​lmindor:m​atrix.org> ooh seems like embedded-hal has a lot of SPI related problems
fabic has quit [Ping timeout: 276 seconds]
mrkajetanp has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
mrkajetanp has joined #rust-embedded
<re_irc> <@9​names:m​atrix.org> yruama_lairba: The write lambda starts with an initial value for w (the reset value of the register) and the value for those will not change unless modified by the builder.
<re_irc> <@9​names:m​atrix.org> I do not think you can replicate this behaviour with a function call unless you pass in both the mask of what has changed and the new value
mellowmoonling has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
<re_irc> <@m​riise:m​atrix.org> is cortex-m `Nr` trait supposed to mean something different from `Interrupt Number`? the only difference i see is that one returns u8 and the other u16
<re_irc> <@9​names:m​atrix.org> dcz_: Please don't. r0 is the start-up portion of the language's runtime library. Reducing it to just "runtime" confuses people who are familiar with the more common usage of that term.
<re_irc> <@9​names:m​atrix.org> I'd prefer if we used embedded loader/chainloader, since that is very close as far as behaviour is concerned - though it is a bit of a stretch from the official meaning of those terms as well.
<re_irc> <@m​riise:m​atrix.org> wait Interrupt number says its for external interrupts...
dcz has joined #rust-embedded
dcz_ has quit [Ping timeout: 258 seconds]
tokomak has joined #rust-embedded
<re_irc> <@a​lmindor:m​atrix.org> > If you do, let me know how it goes. I haven't actually implemented it beyond my simplified example.
<re_irc> <@a​lmindor:m​atrix.org> here's a draft that probably doesn't work https://github.com/riscv-rust/e310x-hal/pull/37 :D
<re_irc> <@j​duchniewicz:m​atrix.org> jhbruhn: did not know about the accelerometer.rs crate (awesome work!) It would be great to maintain a single place where we can collect all sensors. Right now it seems we have to interact with them in a non-uniform way
<re_irc> <@j​duchniewicz:m​atrix.org> you can post here once you create the repository so we can follow/contribute to it :)
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
neceve has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
<re_irc> <@e​ldruin:m​atrix.org> often times the problem with different sensors is that they have very different behavior. Maybe you get to a point where you have a trait like
<re_irc> <@e​ldruin:m​atrix.org> ```rust
<re_irc> <@e​ldruin:m​atrix.org> which is like, is it really useful?
<re_irc> <@e​ldruin:m​atrix.org> even defining a fixed T type is problematic because maybe you think f32 celsius would be great
<re_irc> <@e​ldruin:m​atrix.org> but then you want to use it in a cortex-m0, which has no FPU and you would prefer not having to deal with f32s and rather use something like i16 in celsius decimals
fabic has joined #rust-embedded
<re_irc> <@e​ldruin:m​atrix.org> then for chips that operate in one-shot mode to save power, especially if you have a long integration time, you would want that the return type is rather something like `nb::Result`
<re_irc> <@e​ldruin:m​atrix.org> not to mention that it will be very tricky to come up with some traits for common configuration like setting the full scale range or integration time
<re_irc> <@j​duchniewicz:m​atrix.org> And maybe they have different prerequisites to collect measurements (e.g. wait some time etc.)
<re_irc> <@e​ldruin:m​atrix.org> that's why I have not done something like common traits so far. Even if you agree upon something, it kind of falls appart or is not really useful
<re_irc> <@e​ldruin:m​atrix.org> accelerometer.rs also has this kind of problems
<re_irc> <@e​ldruin:m​atrix.org> It would be great to be proven wrong, though. by all means
<re_irc> <@e​ldruin:m​atrix.org> my experience though is that it does not fit very well for every case, which is what the purpose was
fabic has quit [Ping timeout: 240 seconds]
crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <@h​uegene:m​atrix.org> eldruin: that all reminds me of the fixed point data type in ada. I wonder if there is a rust library for that or whether adas integer type definitions can be integrated in rust. (https://www.adaic.org/resources/add_content/standards/05rm/html/RM-3-5-9.html)
<re_irc> <@h​uegene:m​atrix.org> huegene: I take that back I just found https://docs.rs/fixed/1.9.0/fixed/
<re_irc> <@b​radleyharden:m​atrix.org> fixed is great. I would recommend it.
<dcz> this is awesome, thanks
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 250 seconds]
<re_irc> <@f​irefrommoonlight:m​atrix.org> I agree with eldruin on generic sensors; I think the use cases would be far few inbetween
<re_irc> <@m​riise:m​atrix.org> `impl<C> Sensor for C where C: Code {}`
<re_irc> <@f​irefrommoonlight:m​atrix.org> Here are some examples from my recent use:
<re_irc> <@f​irefrommoonlight:m​atrix.org> - Max31865 RTD sensor: Relatively straightforward, but has several control bits for managing connection type, how it saves power etc. And in power-down cycles, there are a sequence of steps you need to follow, including delays.
<re_irc> <@f​irefrommoonlight:m​atrix.org> - MLX90614 RTD sensor: Basic operation is straightforward, but has a number of control setting, alternate things it can measure (different zones, ambient vs IR temp etc), emissivity settings, optional PWM output, a sleep procedure that requires changing pin typeetc
<re_irc> <@f​irefrommoonlight:m​atrix.org> - Ion-selective measuring circuits, with a digital interface of an ADC. The ADC in question seems straightforward, but still has concerns like low-power modes, selecting channels, delays etc, and interacts with a temperature sensor for compensation.
<re_irc> <@f​irefrommoonlight:m​atrix.org> It begs the question of *What does this accomplish?*, and will almost expose limitations
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think a basic interface would work in a "Look what I did with my arduino!" sense, but the the limitations would become visible immediately after trying something beyond that.
mellowmoonling has joined #rust-embedded
tokomak has quit [Read error: Connection reset by peer]
fabic has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> The seal, it has been broken: https://twitter.com/bitshiftmask/status/1421127820596682753
<re_irc> <@n​ihal.pasham:m​atrix.org> Have a few questions about `defmt`, figured I'd start by asking here. If this is not the right place, it'd be nice if you could point me in the right direction.
<re_irc> <@n​ihal.pasham:m​atrix.org> **Context**: I've only ever used defmt in the past as a quick and easy way to do some printf-style debugging but I happen to have some time and figured now would be as good a time as any to dive deeper.
<re_irc> <@n​ihal.pasham:m​atrix.org> _Note: I've never actually delved deep into debuggers or debugging. So far, I've been able to get away with just the basics - so, I may be totally off the mark here but would like some confirmation._
<re_irc> <@n​ihal.pasham:m​atrix.org> I'm walking through defmt's impl and here's what I understand.
<re_irc> <@j​amesmunns:m​atrix.org> Yup, this is pretty accurate!
<re_irc> <@j​amesmunns:m​atrix.org> We added a diagram of how these parts relate, btw: https://github.com/knurling-rs/defmt/#defmt-ecosystem
<re_irc> <@j​amesmunns:m​atrix.org> There's nothing "hardwired" between defmt and RTT, in practice. You totally could write a UART or SPI or BTLE or USB-CDC-ACM serial port drain for the stream of messages.
<re_irc> <@j​amesmunns:m​atrix.org> there's a trait (somewhere? I forget the name) or macro or something you need to provide as the "logging backend", which is usually fulfilled by defmt-rtt, but you can implement it any way you want. BUT it needs to be global (and therefore thread safe).
<re_irc> <@j​hbruhn:j​hbruhn.de> eldruin firefrommoonlight you bring good points which I have also thought about. What if we have a sensor which measures multiple values at once (e.g. temperature and humidity)? All of these bring me to the conclusion that it does not really make sense for those.
<re_irc> <@j​hbruhn:j​hbruhn.de> The question then is, if I want to abstract the sensors behind a trait for use in the "business logic", should I pollute my driver code with those interfaces? Or should it be placed into a glue layer of the specific firmware?
<re_irc> <@n​ihal.pasham:m​atrix.org> > We added a diagram of how these parts relate, btw: https://github.com/knurling-rs/defmt/#defmt-ecosystem
<re_irc> <@n​ihal.pasham:m​atrix.org> Thank you, that was quick! A follow-up : How is the `Formatter` wired/linked to the `global-logger` i.e. how does the formatter pass encoded bytes to the logger? This was just my assumption
<re_irc> <@d​irbaio:m​atrix.org> for a custom backend, you have to impl `Logger` and `Write`. `Logger::acquire()` returns a `dyn Write`, the generated code uses that to write encoded bytes
<re_irc> <@e​ldruin:m​atrix.org> jhbruhn: Yes, I think defining your own interfaces and implementing them on top of the device driver would be the best. With this you can abstract about stuff that the business logic does not need to know about, and also include stuff that is a bit different for different devices like some configuration. You...
<re_irc> ... could have a trait like this:
<re_irc> <@e​ldruin:m​atrix.org> ```rust
<re_irc> <@e​ldruin:m​atrix.org> pub trait TempHumiditySensor {
<re_irc> <@j​hbruhn:j​hbruhn.de> It does make sense like that, yeah. And at least nowadays, every sensor has some specific functionalities (alarms, "choreographies" on accelerometers, with or without interrupts etc) which differ just enough to not permit a generic interface for _all_ devices (which should be the case if we wanted to define some...
<re_irc> ... generic traits)
<re_irc> <@j​hbruhn:j​hbruhn.de> Thanks for your input everyone!
<re_irc> <@j​amesmunns:m​atrix.org> Listen to dirbaio for the tech details, I'm mostly just a user of defmt these days (and official hype man)
<re_irc> <@d​irbaio:m​atrix.org> hype man 🤣
<re_irc> <@j​amesmunns:m​atrix.org> Also, we do have official impl/design docs, as well: https://defmt.ferrous-systems.com/design.html
<re_irc> <@n​ihal.pasham:m​atrix.org> dirbaio: that makes sense but I'm thinking of the prior-step i.e. before the logger writes bytes out to a buffer or a serial connection, how is it handed the encoded bytes. I presume that `Formatter` does this am wondering where's the code for this in the impl?
<re_irc> <@j​amesmunns:m​atrix.org> And honestly, if you find your notes are better than any of those, please PR them! I'd love for it to be as clear as possible.
<re_irc> <@j​amesmunns:m​atrix.org> dirbaio: This is like 90% of my work for both Ferrous and the embedded wg :)
<re_irc> <@j​amesmunns:m​atrix.org> It's just fun to be excited about fun things, and to get other people excited about them too.
<re_irc> <@d​irbaio:m​atrix.org> nihal.pasham: every little "thing" is written by itself. For example a u8 is encoded as 1 byte, so it'll call `write` with a 1-byte slice. a u16 is encoded as 2 bytes, etcetc
<re_irc> <@d​irbaio:m​atrix.org> so defmt generates code that does acquire, write, write, ..., write, release
<re_irc> <@n​ihal.pasham:m​atrix.org> ohhh, that makes sense. cool
<re_irc> <@d​irbaio:m​atrix.org> btw this will change a bit in defmt 0.3: the Logger and Write traits have been merged, `write` is now a method in Logger
<re_irc> <@d​irbaio:m​atrix.org> this gives better codesize by avoiding dyn calls
<re_irc> <@n​ihal.pasham:m​atrix.org> noted.
<re_irc> <@n​ihal.pasham:m​atrix.org> this is quite interesting. I also noticed, in the original blog post, that the ultimate plan is to enable `visualization and analytics` at some point. Do we still have some time to go for this to happen or are we pretty close?
<re_irc> <@j​amesmunns:m​atrix.org> So, you CAN do this yourself at the moment, but we don't have any official specs for that at the moment
<re_irc> <@j​amesmunns:m​atrix.org> I use defmt for this: https://www.youtube.com/watch?v=BZqt187RWTw
<re_irc> <@j​amesmunns:m​atrix.org> (and that was WAY back in the day).
<re_irc> <@j​amesmunns:m​atrix.org> I actually cheated, and used defmt to make "fake" JSON messages, and then fed that into another tool.
<re_irc> <@j​amesmunns:m​atrix.org> so like:
<re_irc> <@j​amesmunns:m​atrix.org> `defmt::info!(r#"{{ "color": {{ "red": {u8:}, "green": {u8:}, "blue": {u8:} }}"#, pix.r, pix.g, pix.b);`
<re_irc> <@j​amesmunns:m​atrix.org> long term, we want to have sort of "automagical" graphing for that, but recently we've also been busy with some other (non-Knurling) stuff at the moment, so most of the effort is going towards the 0.3 release improvements.
<re_irc> <@j​amesmunns:m​atrix.org> Speaking unofficially, I could see something like:
<re_irc> <@j​amesmunns:m​atrix.org> defmt::scatterplot!("Temp over time", x: timer.now(), y: temp.celcius());
<re_irc> <@j​amesmunns:m​atrix.org> ```rust
<re_irc> <@j​amesmunns:m​atrix.org> or something like that (that basically just tags that message with a certain title, or something like that in the line format.
<re_irc> <@j​amesmunns:m​atrix.org> and have defmt host-side collect those all into an autoranging graph through a web interface, vscode plugin, etc.
<re_irc> <@j​amesmunns:m​atrix.org> but yeah, no official commitment (or design even really) yet.
<re_irc> <@d​irbaio:m​atrix.org> oh yup I did the "pipe into anohter tool" thing too haha
<re_irc> <@n​ihal.pasham:m​atrix.org> jamesmunns: that would be really cool!
<re_irc> <@d​irbaio:m​atrix.org> not even json 🙈 python script scanning stdin for lines like `plot 5 2`
<re_irc> <@a​lmindor:m​atrix.org> GrantM11235 disasm updated https://github.com/riscv-rust/e310x-hal/pull/37 with all traits and config checks, note that the bus.rs is almost a carbon copy of the original module so the diff looks scary but it's mostly just the device.rs stuff
<re_irc> <@a​lmindor:m​atrix.org> sadly I don't have 2 SPI devices to test with :( the only thing I have is a display without CS pin to make it even worse
<re_irc> <@d​isasm-ewg:m​atrix.org> almindor: And onboard WiFi, no?
<re_irc> <@d​isasm-ewg:m​atrix.org> svd2rust output is a little bit funny nowadays:
<re_irc> <@d​isasm-ewg:m​atrix.org> `Peripheral access API for FREEDOM U740-C000 microcontrollers (generated using svd2rust v0.19.0 ( ))`
<re_irc> <@d​isasm-ewg:m​atrix.org> microcontrollers, indeed
<re_irc> <@a​lmindor:m​atrix.org> not on the red-v I'm afraid. My old hifive1 board got wacky and disconnects randomly. Tried JLINK direct and that fails too I think the JLINK chip borked
<re_irc> <@d​isasm-ewg:m​atrix.org> Oh, I see
<re_irc> <@d​isasm-ewg:m​atrix.org> Do you have a logic analyzer?
<re_irc> <@a​lmindor:m​atrix.org> yup
<re_irc> <@d​isasm-ewg:m​atrix.org> You can check the transfers with it
<re_irc> <@a​lmindor:m​atrix.org> yeah, i'll set it up with a fake additional SS pin
<re_irc> <@a​lmindor:m​atrix.org> hmm, would I need to close the circuit on the SS pin to see it work tho?
<re_irc> <@a​lmindor:m​atrix.org> i'm also unsure if the reconfigure() call needs to set all of the things it does, i just kinda took that from the contstructor
<re_irc> <@a​lmindor:m​atrix.org> I suspect only a few need to be reset between the transfers from different devices
<re_irc> <@a​lmindor:m​atrix.org> well using SpiSharedDevice has no detrimental effect on the single display test at least, so no breakage there. I'll try to get a measurement later today with the 2 spi pins on the side pretending I have 2 displays
fabic has quit [Ping timeout: 272 seconds]
mellowmoonling has quit [Remote host closed the connection]
<re_irc> <@s​prt:m​atrix.org> Hey folks - any Cross contributors here? I'm using both cross and bindgen, and cross isn't able to find my header files at compile-time (even though I specify a volume in my Cross.toml). Not sure how to start debugging this. `docker run -v` works fine and I'm able to see the wanted files.
<re_irc> <@s​prt:m​atrix.org> This is my Cross.toml:
<re_irc> <@s​prt:m​atrix.org> [target.aarch64-unknown-linux-gnu]
<re_irc> <@s​prt:m​atrix.org> image = "aurelien/custom-cross-image:latest"
<re_irc> <@s​prt:m​atrix.org> The above command outputs errors like:
<re_irc> <@s​prt:m​atrix.org> wrapper.h:5:10: fatal error: '/home/aurelien/ZTS-Sandbox/deps/Attestation-SDK-for-Linux-based-OS/include/external/AttestationErrors.h' file not found, err: true
<re_irc> <@s​prt:m​atrix.org> Although if I run the container manually I'm able to see those files. Am I missing something obvious here?
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
neceve has quit [Ping timeout: 268 seconds]
<re_irc> <@a​lmindor:m​atrix.org> am I missing something obvious here, how am I to get to a `&mut T` of `bare_metal::Mutex` ? is `lock` implemented somehow downstream?
<re_irc> <@d​irbaio:m​atrix.org> Use Mutex<RefCell<X>>
<re_irc> <@a​lmindor:m​atrix.org> ah hmm, why the diff from std::Mutex ?
<re_irc> <@d​irbaio:m​atrix.org> It's somewhat more low level
<re_irc> <@d​irbaio:m​atrix.org> All it does is "convert something Send into something Sync"
<re_irc> <@d​irbaio:m​atrix.org> So the "interior mutablity" part is up to you
<re_irc> <@d​irbaio:m​atrix.org> For example if it works for you you can do Mutex<Cell<X>> which is a bit more efficient
<re_irc> <@d​irbaio:m​atrix.org> That one doesn't waste bytes for "locked" flags at all, it's exactly the same size as X which is super cool
<re_irc> <@a​lmindor:m​atrix.org> ahh I see, that works. Thanks!
<re_irc> <@a​lmindor:m​atrix.org> hmm, shouldn't Cell itself be Clone by default?
<re_irc> <@a​lmindor:m​atrix.org> this is giving me a headache, I mean `Mutex::borrow(cs)` gives a `&Cell` which means I can't do a `cell.get_mut()` on it.
<re_irc> <@d​irbaio:m​atrix.org> It is if the contents is clone (?)
<re_irc> <@d​irbaio:m​atrix.org> Yeah with Cell you can't get a &mut
<re_irc> <@d​irbaio:m​atrix.org> You need RefCell for that
<re_irc> <@a​lmindor:m​atrix.org> so what's the use of a cell then? this is the part of Rust I always found confusing
<re_irc> <@a​lmindor:m​atrix.org> is it just to do full move-out?
<re_irc> <@d​irbaio:m​atrix.org> With Cell you can only get/set the entire value at once
<re_irc> <@d​irbaio:m​atrix.org> The problem with getting a &mut is it is Ub to have two at the same Time
<re_irc> <@a​lmindor:m​atrix.org> yeah but I need one at a time :D
<re_irc> <@a​lmindor:m​atrix.org> basically I'm trying to do a timeshare across two holders (or more)
<re_irc> <@d​irbaio:m​atrix.org> So RefCell has to store "locked" flag, so it can panic if you try to borrow_mut a second Time
<re_irc> <@a​lmindor:m​atrix.org> RefCell::get_mut is also `&mut self` no? how does it differ then, I still can't do `mutex.borrow(cs).get_mut()`
<re_irc> <@d​irbaio:m​atrix.org> You need borrow_mut, not get_mut
<re_irc> <@a​lmindor:m​atrix.org> oh and it's Deref
<re_irc> <@a​lmindor:m​atrix.org> ugh sometimes these implicit tricks make Rust quite painful to follow
<re_irc> <@a​lmindor:m​atrix.org> ok now https://github.com/riscv-rust/e310x-hal/pull/37 is finally able to construct all 3 devices on top of SPI1 :D
<re_irc> <@a​lmindor:m​atrix.org> i'll need to measure some dummy outputs to see if it actually performs the SS lines correctly tho
dcz has quit [Ping timeout: 256 seconds]