i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
sugoi has quit [Ping timeout: 245 seconds]
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 255 seconds]
anton_star has joined #rust-embedded
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
trnila[m] has quit [Quit: Idle timeout reached: 172800s]
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
inara has quit [Quit: Leaving]
inara has joined #rust-embedded
anton_star has quit [Quit: Client closed]
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 245 seconds]
danielb[m] has joined #rust-embedded
<danielb[m]>
SpiBus::read has the following note: Implementations are allowed to return before the operation is complete. In what situation can a read of known size continue return before it's complete, and how is one expected to handle this case?
<danielb[m]>
* SpiBus::read has the following note: Implementations are allowed to return before the operation is complete. In what situation can a read of known size return before it's complete, and how is one expected to handle this case?
<danielb[m]>
* embedded-hal's SpiBus::read has the following note: Implementations are allowed to return before the operation is complete. In what situation can a read of known size return before it's complete, and how is one expected to handle this case?
<diondokter[m]>
danielb[m]: For write it makes sense... For read?
<diondokter[m]>
I think this is probably about when an error is detected or something like that
<danielb[m]>
I think this is just some copy-paste carried over from the other methods 😅 but just in case someone knows...
<danielb[m]>
I understand that for writes, the implementation can fill a FIFO, start the transfer and return, that's what we also do in esp-hal
<danielb[m]>
the error case is obvious, but I'd put that under the "operation is complete" category
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<danielb[m]>
<GrantM11235[m]> "IIRC it's because of this https:..." <- that's a very interesting issue, I also never considered the last half bit time to be a problem :D
<diondokter[m]>
TomB[m]: Not yet! The ideas are still the same. You can maybe look at the few integration tests there are currently in the device-driver subfolder
<danielb[m]>
can device-driver define/use enums as register fields?
<diondokter[m]>
danielb[m]: Yes! You can bring your own types or let it generate enums for you
<diondokter[m]>
No integration tests for that yet. But it's already implemented
<danielb[m]>
nice, I'll try and redo the drivers in my EKG sometime, I had an ad-hoc lib that did similar things as device-driver, just probably worse :)
<diondokter[m]>
Though my crate does more. Command and buffer interfaces and it's opinionated about talking to devices
<diondokter[m]>
Right, it seems it doesn't have big endian support, no external file definition support and generates a struct that is meant for mmio
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
So the intention of that crate is to generate code for devices that might be external and might have a command and memory interfacr? (the example I can think of is nrf70)
sugoi has quit [Ping timeout: 276 seconds]
cinemaSundays has joined #rust-embedded
<diondokter[m]>
Well yeah, any device driver.
<diondokter[m]>
It's not really meant for mmio on device, though in theory it could
<danielb[m]>
so how do I specify what interface I actually want? I2C/SPI/both/whether I want async/etc? :D
<diondokter[m]>
The chip that prompted me to add commands and buffers is the S2-LP radio chip from STM
<diondokter[m]>
danielb[m]: You provide it the interface. It's generic. See the traits in the device-driver subfolder.
<diondokter[m]>
You just tell me how to dispatch a command or read/write a register and I'll do the rest
<diondokter[m]>
If you use the async version of the trait you'll get access to the async functions in the generated code
<diondokter[m]>
Or both!
<i509vcb[m]>
nrf70 is kind of similar in that you either use spi or qspi and you either send commands or access a queue of packet data (might be some finer details I am missing)
<i509vcb[m]>
Although the device really does need you to bindgen a lot of structs since that is how the command interface is defined
<i509vcb[m]>
(I like the idea of yaml for the definitions of buffers, registers, etc but nrfwifi is too unstable with its firmware interface currently)
<vollbrecht[m]>
in a funny way it kinda reminds me of (modbus - the nice grouping of things). E.g you are generic over your transport interface, but still act on fields in some random external localtion.
<vollbrecht[m]>
and its irrelevant if its a local or remote device.
<vollbrecht[m]>
* in a funny way it kinda reminds me of (modbus + the nice grouping of things that modubus lag). E.g you are generic over your transport interface, but still act on fields in some random external localtion.
<diondokter[m]>
Yeah modbus is nice
<vollbrecht[m]>
* in a funny way it kinda reminds me of (modbus + the nice grouping of things that modbus lag). E.g you are generic over your transport interface, but still act on fields in some random external localtion.
cr1901_ is now known as cr1901
gmarull[m] has quit [Quit: Idle timeout reached: 172800s]
<jomaway[m]>
Probably need to change something in this line: `ws.write(brightness(leds.iter().copied(), strip_brightness)).unwrap();`
<jomaway[m]>
I tried to change `iter()` to `into_iter()` but that did not work.
<jomaway[m]>
So i am not sure if the rp_pico crate needs to change versions first that this works?
<JomerDev[m]>
<JamesMunns[m]> "Dunno!" <- I just checked with the official pico (and removed the generic driver feature) but it didn't help at all
<JomerDev[m]>
(After a cargo clean I additionally get ERROR probe_rs::util::rtt: Error reading from RTT: The control block has been corrupted. write pointer is 268475633 while buffer size is 1024 for up channel 0 (defmt) multiple times before the core locks up)
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
<danielb[m]>
in general I don't think probe-rs and rp2040 are good friends, for example I couldn't get embedded-test working on it...
<JomerDev[m]>
I got an endless loop going without noticing it
<danielb[m]>
recurson: see recursion
<danielb[m]>
s/recurson/recursion/
<JomerDev[m]>
Exactly. For whatever reason I thought that I would get the inner type with x instead of self
<danielb[m]>
i guess your cpu really locked up when the stack overflowed? :D
Artea has joined #rust-embedded
<thejpster[m]1>
My brain is failing me. Is there a no-std Sync RefCell that uses CAS instead of disabling all interrupts? I’m fine if it only has failable methods because for my use case re-entry is a programming bug
<JomerDev[m]>
<danielb[m]> "i guess your cpu really locked..." <- Seems like it, yes. Which of course makes it very hard to understand what is going on
<GrantM11235[m]>
<thejpster[m]1> "My brain is failing me. Is there..." <- That sounds almost like a spinlock
<JamesMunns[m]>
<thejpster[m]1> "My brain is failing me. Is there..." <- That'd just be an atomic Mutex, right?
<JamesMunns[m]>
oh yeah, and they are cortex-m coherent
<JamesMunns[m]>
right
<JamesMunns[m]>
> In any case, nostd_async IMHO isn't a good choice, as it may look like it's usable for real (non-example) code, while in fact it has severe issues.
<JamesMunns[m]>
+1
<thejpster[m]1>
You call Xh3irq::meinext() from the MachineExternal handler and it tells you which ISR to run next.
<thejpster[m]1>
Simple as that
voidwalker09[m] has joined #rust-embedded
<voidwalker09[m]>
I got a nrf52840 board, new to embedded development. I'm a bit confused about the info I found regarding bluetooth support in rust. There's nrf-softdevice bindings for the closed source C binary, not sure what's missing from it or how usable it is. Are there any alternatives? Ideally with some examples
<JamesMunns[m]>
nrf-softdevice is the only "production quality" stack for the nrf52840 I'm aware of. I think `trouble` is in development? but I don't know how fit for purpose it is
<JamesMunns[m]>
in general, nrf-softdevice is pretty fully featured (at least for BLE and BLE mesh stuff?), for both blocking and async usage, AFAIK. Folks are using it in production.
n3t has joined #rust-embedded
AtleoS has quit [Ping timeout: 246 seconds]
AtleoS has joined #rust-embedded
jduck[m] has joined #rust-embedded
<jduck[m]>
I don't trust the nrf stuff really. It would be nice to skip the soft device and go straight to the hardware in Rust.
<JamesMunns[m]>
<jduck[m]> "I don't trust the nrf stuff..." <- That's up to you, and for hobby stuff, might be reasonable! Using qualified stacks is less than optional as far as I know for Bluetooth certification, and the softdevice is qualified, for all its issues!
<JamesMunns[m]>
<JomerDev[m]> "Exactly. For whatever reason I..." <- by the way, did you get a warning for that on the CLI? I *think* either rustc or clippy will usually give a "this is a bad idea" warning in many cases like this.
<JamesMunns[m]>
(I have rust analyzer to do cargo clippy instead of cargo check, so I get yellow squigglies for both check and clippy errors)
<JamesMunns[m]>
* (I have rust analyzer configured to do cargo clippy instead of cargo check, so I get yellow squigglies for both check and clippy errors)
<JomerDev[m]>
No, no warning at all either in the cli or with rust-analyzer
<JamesMunns[m]>
can you revert and see if clippy gives you a warning? not a big deal I was just pretty sure I had seen warnings for that before
<JomerDev[m]>
cargo clippy also doesn't show anything for that
<JamesMunns[m]>
huh! Fun :D
<JamesMunns[m]>
(thanks for testing!)
<JomerDev[m]>
No worries, I was already trying it out even before you asked :D
<JamesMunns[m]>
I think I've seen it fire for a circular trait method
<JamesMunns[m]>
like, calling a trait method which actually loops, instead of calling an inherent method or something
<JamesMunns[m]>
that's a sneaky
<JamesMunns[m]>
Maybe open a diagnostics issue?
<JamesMunns[m]>
I had to read it a couple time to figure out what was going on
<JamesMunns[m]>
s/time/times/
<JomerDev[m]>
Fair enough. It took me two days to find, but that was in part because I thought I had messed up the static strings I originally wanted to return
<jduck[m]>
<JamesMunns[m]> "That's up to you, and for..." <- Fair enough. I definitely don't think the qualification means much beyond something appears to interoperate successfully during the evaluation.
<JamesMunns[m]>
The qualification means you don't get sued by the Bluetooth association for using their logo, as far as I know!
<i509vcb[m]>
I am not sure why I'd be getting an error like this for just a test example just just uses defmt_rtt:
<i509vcb[m]>
For context I am trying to test the probe-rs target I added for the MSPM0C1104. The only thing I could think of being a barrier is the fact that it has literally 1K of ram
<i509vcb[m]>
Is something like build-std going to help maybe?
<i509vcb[m]>
Slapping a --target thumbv6m-none-eabi -Z build-std=core on the end with a cargo +nightly run didn't change anything
<JamesMunns[m]>
defmt-rtt uses 1K for the RTT buffer by default