gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
<re_irc> <> How would y'all integrate a Nordic (or other perhaps) bluetooth module onto a separate MCU? UART?
<re_irc> <> I want to add bluetooth to an H7 audio project
<re_irc> <> Actually, I wonder if the way is to use I2S
<re_irc> <> Program the nRF to process the incoming BT stream. Turn it into I2S. Send to the main MCU's audio peripheral. Would this work?
<re_irc> <> *After some digging, it appears nRF is inappropriate for this since it's BLE, which isn't good for audio
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #rust-embedded
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <> generated by svd2rust, I don't know if there should be a `<dim>` symbol support on peripheral level, as there is already such support on field level :)
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <> What is wrong?
<re_irc> <> I think they're saying that we should probably have it just be `UART` where access of a specific element is `UART[n]`. There's something similar done for the DMA channels of the H7 series
<re_irc> <> But I think in general, if you want the SVD API to generate an array of UARTs, you need to:
<re_irc> <> 1. Ensure that each peripheral is completely identical (they often aren't exactly the same)
<re_irc> <> 2. Patch the SVD file using a tool similar to stm32-rs to group up the UARTs
<re_irc> <> 3. Re-generate the svd2rust crate from the patched SVD
tokomak has joined #rust-embedded
gsalazar has quit [Ping timeout: 265 seconds]
fabic has quit [Ping timeout: 250 seconds]
<re_irc> <> svd2rust doesn't support peripheral arrays
<re_irc> <> The highlighted text above is showing types. Svd2rust can convert peripherals with unique types to be multiple fields of the same type. If they are compatible. You need to look at the fields in RegisterBlock to see the type of each uartX field.
<re_irc> <> But you can make your various functions that take the resource as generic
<re_irc> <> I guess you could make some outer-level `OuterResources<T: Output>` type and then mark `struct OuterResources<LED_TYPE>`? Although I don't think the current RTIC syntax would support that
<re_irc> <> In general, I think it's honestly a good thing that resources are explicitly _not_ generic, since it makes it much clearer to audit used system resources
<re_irc> <> In case of RTIC blinky app like this:
<re_irc> <> Is it possible to pass the LED ressource just as "Output"?
<re_irc> <> Like in any output pin, any output port, any output mode
<re_irc> <> It is a bit of a bother though. If I want to change the pin I need to change it in the init, in the resources section and in the tasks.
<re_irc> <> It builds, so I think so. Thanks!
<re_irc> <> Is there any way to make it less labor intensive and error prone?
fabic has joined #rust-embedded
<re_irc> <> Even more, we can't make them generic as the underlying static storage require fully defined types
<re_irc> <> Yeah, but you could theoretically define it as such:
<re_irc> <> struct OuterStorage<T: Output> {
<re_irc> <> ```rust
<re_irc> <> led: T
<re_irc> <> This is fine
<re_irc> <> And supported
<re_irc> <> But yeah, you _have_ to have concrete types _eventually_, as you mention, to know the compiled resource size
<re_irc> <> Yeah :)
<re_irc> <> Pin struct without the typestates
<re_irc> <> This isn't an RTIC limitation perse; you need an explicit type for `static`s too
<re_irc> <> With that you can use the `replace_with` crate as well, so you can move out of an `&mut` reference and write back a new value without using options
<re_irc> <> Quite nice
<re_irc> <> ```rust
<re_irc> <> struct Shared {
<re_irc> <> #[shared]
<re_irc> <> sda: Pin,
<re_irc> <> Do you happen to have an example?
<re_irc> <> Alright, I'll try it out and see which variant is easiest to use.
<re_irc> <> Thanks!
fabic has quit [Ping timeout: 265 seconds]
tokomak has quit [Read error: Connection reset by peer]
SanchayanMaity has quit [Ping timeout: 264 seconds]
dreamcat4 has quit [Ping timeout: 264 seconds]
nohit has quit [Ping timeout: 265 seconds]
edm has quit [Read error: Connection reset by peer]
edm has joined #rust-embedded
dreamcat4 has joined #rust-embedded
nohit has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <> "Online book:Β The Embedded Rust Book. I haven't actually started this one yet, but a quick flip through it leads me to believe it's as good as The Rust Programming Language. I've ordered the STM32 Discovery kit that it uses so I can follow along hands-on."
<re_irc> <> Shout out to all the book contributors. Your great work is being recognised! πŸ‘
<re_irc> <> James and Emil get a name check too.
<re_irc> <> newam: my wl55 nucleos just arrived and I was trying to get your lightswitch example to run. However, the patched probe-run and the unpatched one as well both error on connect:
<re_irc> <> Caused by:
<re_irc> <> Command failed with status JtagGetIdcodeError
<re_irc> <> Error: An error specific to a probe type occured
<re_irc> <> O_o
<re_irc> <> What OS?
<re_irc> <> ubuntu
<re_irc> <> stlink rules, maybe?
<re_irc> <> Did you add the udev rules?
<re_irc> <> Yeah
<re_irc> <> udev issues would cause "permission denied" errors
<re_irc> <> Example is there
<re_irc> <> Flash write protection?
<re_irc> <> I have seen permission errors present as something else with stlinks specifically
<re_irc> <> huh
<re_irc> <> bad jumper settings in the boards? nucleos usually have jumpers to disconnect swd, or to disconnect the target mcu power
<re_irc> <> If you're using the LORA-E5 module, then its flash is protected by default
<re_irc> <> Nucleos are generally unlocked, never seen one with locked flash before (for any series)
<re_irc> <> nvm I missed the nucleo bit
<re_irc> <> i used stm32cubeprogrammer to erase all flash. Didn't touch the option bytes, but works now anyway
<re_irc> <> that stuff is so funny sometimes...
<re_irc> <> now i do get the binaries running :) however:
<re_irc> <> 17.263811 ERROR server did not respond to time sync request in Duration { secs: 0, nanos: 100000000 }
<re_irc> <> └─ client::locked_radio client/src/
<re_irc> <> JC1 or JC2 nucleos?
troth has quit [Ping timeout: 265 seconds]
troth has joined #rust-embedded
troth has quit [Ping timeout: 268 seconds]
<re_irc> <> Try erasing with STM32CubeProgrammer
<re_irc> <> *NVM alreayd did
<re_irc> <> I run into this pretty regularly
troth has joined #rust-embedded
<re_irc> <> 🀣 I asked for golioth for some docs so I could write a Rust crate. They said, here's a rust crate already. And it uses a bunch of crates I wrote, including my nrf9160 socket wrappers.
<re_irc> <> Damn language getting popular and people doing all my good ideas before I even have them.
<re_irc> <> newam JC1
<re_irc> <> Ah, mine are JC2, that timeout is because of the frequency difference
<re_irc> <> If you change it from 434 to whatever the JC1 runs at it should work
<re_irc> <> I think that is under shared/src/
jackneill has quit [Remote host closed the connection]
jackneill has joined #rust-embedded
<re_irc> <> Does anyone know if there's a shortcut to reduce this DRY when initializing an array?
<re_irc> <> ```rust
<re_irc> <> // static mut INPUT_BUF_L: [u32; BLOCK_SIZE * 2] = [0; BLOCK_SIZE * 2];
<re_irc> <> Pseudocode:
<re_irc> <> ```rust
<re_irc> <> static mut INPUT_BUF_L: [u32; BLOCK_SIZE * 2] = core::array::zeroes;
<re_irc> <> unsafe { mem::zeroed() }
<re_irc> <> Shouldn't `Default::default()` do the same here? Or is it not `const`?
<re_irc> <> hm, seems it is not :/
<re_irc> <> Thanks for the link here!
<re_irc> <> Thanks!
troth has quit [Ping timeout: 268 seconds]
troth has joined #rust-embedded
troth has quit [Ping timeout: 240 seconds]
troth has joined #rust-embedded