00:01 <re_irc> <@dirbaio:matrix.org> iirc the discussion was settled, we were OK with it being "implementable enough"

00:01 <cr1901> Btw, I don't think an Interrupt trait will help actually- HALs own their peripherals, I don't have access to the peripherals if I'm implementing the trait on a HAL struct in my crate

00:02 <cr1901> unless the hal lets you borrow them

00:02 <cr1901> and/or peripherals are public for some reason ._.

00:04 <re_irc> <@adamgreig:matrix.org> all we have to do is scroll back in matrix chat far enough to find where we agreed the solution

00:04 <re_irc> <@adamgreig:matrix.org> and then implement it

00:04 <re_irc> <@adamgreig:matrix.org> which one will take longer :P

00:08 <re_irc> <@dirbaio:matrix.org> plus you CAN implement the full SpiDevice if you manage CS yourself instead of letting the kernel do ti

00:09 <re_irc> <@adamgreig:matrix.org> can you? I think that was plan A but there were still some issues around timing of events inside the closure then

00:09 <re_irc> <@dirbaio:matrix.org> that was solved as well

00:10 <re_irc> <@dirbaio:matrix.org> mandating SpiBus can pipeline/buffer operations, but flush() must wait until all are done

00:10 <re_irc> <@dirbaio:matrix.org> so you can assert CS, do reads/writes, flush, deassert CS

00:11 <re_irc> <@dkhayes117:matrix.org> A little late to the party, but I've been learning Rust and embedded in parallel without having a CS/SE background.

00:11 <re_irc> It's challenging because of all the rabbit holes one can go down.

00:11 <re_irc> I find myself learning top down with intermittent "dig all the way down" moment's when something doesn't make sense to me.

00:12 <re_irc> <@dkhayes117:matrix.org> I learn a lot sometimes by just following conversations here without "participating" 🙂

01:05 <re_irc> <@firefrommoonlight:matrix.org> cr1901: You don't need the traits to write firmware

01:21 <cr1901> firefrommoonlight: No, you don't, but you can't take advantage of other ppl's work if you don't. This isn't C world where you pass structs w/ callbacks in them into functions that do the work (and just completely disregard data races :P)

01:21 <re_irc> <@jamesmunns:beeper.com> (fwiw: he deleted the message on the matrix side)

01:29 <cr1901> ahhhh

01:37 <re_irc> <@firefrommoonlight:matrix.org> My bad!

01:37 <re_irc> <@firefrommoonlight:matrix.org> (Msg was something to the effect of you can write firmware without traits)

01:38 <re_irc> <@firefrommoonlight:matrix.org> Yea true re not taking adv

01:39 <re_irc> <@firefrommoonlight:matrix.org> I don't find the things you brought up limiting

01:39 <re_irc> <@firefrommoonlight:matrix.org> I did

01:40 <re_irc> <@firefrommoonlight:matrix.org> Until I realized I could just ignore the messy parts

01:40 <re_irc> <@firefrommoonlight:matrix.org> Sounds trite, but I have learned to stop worrying and love the embedded Rust

01:40 <re_irc> <@firefrommoonlight:matrix.org> It's MIMO register writes and reads at the bottom

01:41 <re_irc> <@firefrommoonlight:matrix.org> Rust is good at both the low level MIMO, and the high level abstracting over it to make various types of APIs

01:42 <re_irc> <@firefrommoonlight:matrix.org> And, I think you can take adv of other people's work without the traits

01:42 <re_irc> <@firefrommoonlight:matrix.org> I lean heavily on Adam Greig+team's SVD2-RUST PAC libs, and Knurling's defmt/probe-run

01:43 <re_irc> <@firefrommoonlight:matrix.org> As well as some non-trait-based libs like the STM32 USB libs

01:47 <re_irc> <@firefrommoonlight:matrix.org> And a good range of no-std deps in general

01:48 <re_irc> <@firefrommoonlight:matrix.org> Since interaction with SPI devices was the initial lead-in to this: What SPI device do you have in mind?

01:56 <cr1901> Oh I wasn't targeting a specific SPI device, but if I had to think of one, I would _probably_ write a bare-metal SD card library where sending/receiving buffers is interrupt-driven. I don't mind implementing the functionality myself, but I'd like to reuse the "is this a valid buffer/is the filesystem valid/file pointer management/etc" code

01:57 <cr1901> Now for the record, I _believe_ theJPster's SD crate provides a trait and doesn't depend on the HAL, so I could do what I just described

01:57 <cr1901> So maybe I need to think of an example that strengthens my point :P

04:42 <re_irc> <@jaxter184:matrix.org> the stm32 has a peripheral for I2S (and other protocols) called SAI, and there's HAL-level support for the stm32h7, but not the stm32g4. I believe (perhaps arrogantly) that I can get it working with the PAC on the g4, and I feel like once I do, it wouldn't be too much extra trouble to adapt the stm32h7 HAL SAI to the stm32g4 HAL. Is there any reason I shouldn't consider this? or any resources for knowing what to do here?...

04:42 <re_irc> ... I've seen the crate for the stm32 bxCAN peripheral, and that seems to be a similar situation (a custom/proprietary peripheral built on a standardized protocol). Would that type of approach be the route to go?

07:29 <re_irc> doesn't that describe most peripherals?

07:29 <re_irc> <@9names:matrix.org> > (a custom/proprietary peripheral built on a standardized protocol)

09:06 <re_irc> <@adamgreig:matrix.org> : Yea, sounds good!

10:25 <re_irc> <@tembel96:matrix.org> Dear all,

10:25 <re_irc> After using nrf-rs and the hal for quite some time now, I was searching for a way to get BLE working. I came across embassy-nrf (and nrf-softdevice) which seem to be the only way to get a proper BLE stack working using Rust. However, it seems as embassy-nrf is not built on the embedded-hal traits, so I want to ask if it is possible to use drivers listed here https://github.com/rust-embedded/awesome-embedded-rust#driver-crates ?

10:29 <re_irc> <@ryan-summers:matrix.org> There is no existing BLE stack written in Rust. There's an expirmental (discontinued dev) project called rubble that you could look at, but the current approach is to use the nordic softdevice and call into it. This isn't really a normal rust approach, it's an nRF approach

10:30 <re_irc> <@ryan-summers:matrix.org> * experimental

11:42 <re_irc> <@dkhayes117:matrix.org> tembel96: I'm not sure what your project situation is, but diondokter: was looking for a sponsor to develop a pure Rust BLE stack a while back.

12:09 <re_irc> <@firefrommoonlight:matrix.org> : My B. I'll take a look today

12:09 <re_irc> <@firefrommoonlight:matrix.org> I don't remember why

12:10 <re_irc> <@henrik_alser:matrix.org> : embassy-nrf is for sure implementing the embedded hal traits (and embedded hal async)

12:15 <re_irc> <@firefrommoonlight:matrix.org> OK now supported. Turns out there was no good reason

12:19 <re_irc> <@firefrommoonlight:matrix.org> https://docs.rs/stm32-hal2/latest/stm32_hal2/sai/index.html

12:19 <re_irc> <@firefrommoonlight:matrix.org> Version 1.6.1

12:51 <re_irc> <@iamnesia:matrix.org> I've searched forever for some examples of configuring DMA with "esp-idf-hal"

12:51 <re_irc> after digging into the source, it seems that it's not even implemented yet?

12:51 <re_irc> or did I get something wrong?

12:51 <re_irc> it seems all related implementations lead back to https://esp-rs.github.io/esp-idf-hal/embedded_hal/spi/index.html but i see no mention of DMA anywhere

12:51 <re_irc> I was expecting to find APIs to configure and assign a channel to an SPI connection?

12:51 <re_irc> <@ryan-summers:matrix.org> Most things don't use DMA by default. DMA is _much_ more complex to work with

12:52 <re_irc> <@ryan-summers:matrix.org> And the e-h traits indeed generally do not consider DMA, although a DMA engine could be used to implement them

12:54 <re_irc> <@ryan-summers:matrix.org> But generally, there's a lot of careful memory considerations in Rust when using DMA, because the DMA engine has to logically"own" the memory because of rust's ownership model guarantees. If both you and DMA had mutable access to the same memory, you have UB

12:54 <re_irc> <@ryan-summers:matrix.org> embedded-dma is a crate designed to help a bit with that issue

12:54 <re_irc> <@ryan-summers:matrix.org> https://docs.rs/embedded-dma/0.2.0/embedded_dma/ - some HALs, like the H7, have some support for DMA, but I do not believe they do it for things like SPI

12:54 <re_irc> <@ryan-summers:matrix.org> * STM32H7,

13:48 <re_irc> <@firefrommoonlight:matrix.org> I dunno

13:48 <re_irc> <@firefrommoonlight:matrix.org> DMA is great

13:49 <re_irc> <@firefrommoonlight:matrix.org> Disagree on much more complex

13:50 <re_irc> <@firefrommoonlight:matrix.org> When on doubt, use a static buf so it doesn't get dropped

13:50 <re_irc> <@firefrommoonlight:matrix.org> Good primary API for when the program's running for a number of perupherals

13:51 <re_irc> <@halfbit:matrix.org> DMA isn't that much more complex for sure, with Rust it means you need to structure your API as if the call takes ownership and returns it later or never

13:52 <re_irc> <@firefrommoonlight:matrix.org> SPI and SAI, which I bring up since they came up most recently in this channel, are both suitable for multi-byte and/or repeated transfers. You likely don't want to use the CPU to facilitate each word

14:26 <re_irc> <@ryan-summers:matrix.org> I'd argue anyone saying DMA is simple has never fought DMA bugs :'). The concept is simple, yes, implementation and safety, not so much

15:09 <re_irc> <@firefrommoonlight:matrix.org> I disagree

15:10 <re_irc> <@dirbaio:matrix.org> stm32 does have many cursed DMA bugs/gotchas

15:11 <re_irc> <@dirbaio:matrix.org> for example the super-precise and non-obvious order of operations you have to set things up to do SPI DMA

15:31 <re_irc> <@halfbit:matrix.org> well there's your problem

15:32 <re_irc> <@halfbit:matrix.org> * problem, can't blame the concept for a buggy/errata filled implementation. The whole circular buffer with a watermark mode is a footgun

15:33 <re_irc> <@halfbit:matrix.org> * footgun, and last I looked ST loved that mode. Compared to the scatter gather list simplicity of nxp's edma or sam's xdmac

16:04 <re_irc> <@dirbaio:matrix.org> fwiw, stm32u5 switched to a scatter-gather DMA!

16:04 <re_irc> <@dirbaio:matrix.org> GPDMA

16:39 <re_irc> <@diondokter:matrix.org> Does anybody know of a mini-rtos crate for cortex-m that I can run next to my main application?

16:39 <re_irc> There is this C library (nrf7002) that really wants threads and spinlocks. I think I could build a work queue of some sorts that would work, but a system with pre-emptive threads would save me some work

16:40 <re_irc> <@mabez:matrix.org> : Doesn't look particularly active but https://github.com/n-k/cortexm-threads

16:42 <re_irc> <@mabez:matrix.org> FYI whilst not arm, we basically done the same thing for the Espressif wifi/ble blobs (which also want threads): https://github.com/esp-rs/esp-wifi/tree/main/esp-wifi/src feel free to lift anything useful from there

16:42 <re_irc> <@mabez:matrix.org> compat and preempt modules are probably most interesting to you

16:43 <re_irc> <@mabez:matrix.org> FYI whilst not arm, we've basically done the same thing for the Espressif wifi/ble blobs (which also want threads): https://github.com/esp-rs/esp-wifi/tree/main/esp-wifi/src feel free to lift anything useful from there

16:54 <re_irc> <@diondokter:matrix.org> Cool! Thanks for the info!

17:10 <re_irc> <@diondokter:matrix.org> https://github.com/cbiffle/lilos

17:10 <re_irc> This is also a nice one. But it too 'takes over' your processor. So this is only really useful in a binary and not in a library.

17:10 <re_irc> It's a pretty weird use case though. I want the executor to be async pollable haha

17:19 <re_irc> <@firefrommoonlight:matrix.org> : Good call. You helped me with that at one point

17:19 <re_irc> <@firefrommoonlight:matrix.org> I think the best way to mitigate that is with example code

17:19 <re_irc> <@firefrommoonlight:matrix.org> And Rust doc comments

18:24 <re_irc> <@dngrs:matrix.org> : I think I did some DMA using esp-idf, lemme check

18:25 <re_irc> <@dngrs:matrix.org> yeah I did

18:26 <re_irc> <@dngrs:matrix.org> https://github.com/spookyvision/espidf-apa102

18:26 <re_irc> <@dngrs:matrix.org> driver for APA102/SK9822 ("clock + data") LEDs

18:27 <re_irc> <@dngrs:matrix.org> oh yeah I now remember it required some fun guessing games

18:27 <re_irc> "let freeRTOS_magic_copypasta_portMAX_DELAY = 0xffffffff;"

18:27 <re_irc> <@dngrs:matrix.org> and/or probing C headers

18:29 <re_irc> <@dngrs:matrix.org> in general, when you want to do something with "esp-idf-hal", check out the "esp-idf" C/C++ examples.

18:29 <re_irc> <@dngrs:matrix.org> you should be able to port anything from there, but it does require surgery, it's not straight copy-paste and "translate C to Rust", you'll need to siphon constants and configuration dances from several places

18:32 <re_irc> <@dirbaio:matrix.org> : ahhhh so it requires threads indeed 😭

18:36 <re_irc> <@dngrs:matrix.org> also, reading through my code it seems to essentially operate DMA in a blocking fashion (calls "spi_device_queue_trans" and "spi_device_get_trans_result" in the same function), so there's certainly room for improvement lol. I do remember doing that for a reason, either because the example did it like that or because it would otherwise not work, but it surely sounds suboptimal

18:37 <re_irc> <@dngrs:matrix.org> but maybe it's all okay and the latter call is just "get the result of the _enqueuing_", not sure anymore.

18:48 <re_irc> <@diondokter:matrix.org> : I still think it can be done without. The spinlocks I saw are pretty short locked

18:48 <re_irc> <@dirbaio:matrix.org> but, does it like, blocking-wait for some other thread to do something?

18:59 <re_irc> <@diondokter:matrix.org> Not that I've seen so far

19:04 <re_irc> <@diondokter:matrix.org> The library doesn't have the concept of threads, but it's clear that it was made with threads in mind

20:24 <re_irc> <@halfbit:matrix.org> it was probably made with zephyr in mind given nordic's commitment there

20:25 <re_irc> <@dirbaio:matrix.org> it is, though it has an OSAL where you can supply a bag of function pointers, for alloc, spinlocks, tasklets, qspi...

20:31 <re_irc> <@halfbit:matrix.org> I guess the library provides like a protocol wrapper over qspi/spi for talking to the nrf7002?

20:38 <re_irc> <@diondokter:matrix.org> : More like this:

20:38 <re_irc> <@diondokter:matrix.org> https://psion.agg.io/_matrix/media/r0/download/matrix.org/PJGMKgcrHbwTzkuBdddzIGwW/image.png

20:39 <re_irc> <@diondokter:matrix.org> Though you've got to implement the (Q)SPI yourself too

20:42 <re_irc> <@halfbit:matrix.org> That looks like a bundle of fun

20:44 <re_irc> <@diondokter:matrix.org> Yeah, the C code is also very annoying. So they need all kind of context pointers and stuff, but for the OSAL layer they don't give you a custom context which means that you have to statically allocate everything. That will make it very annoying to make work with a normal Rust API

21:54 <re_irc> <@jaxter184:matrix.org> : oh wait, ive been in and out (mostly out) of the rust embedded space for the last few years, whats hal_2?

21:56 <re_irc> <@jaxter184:matrix.org> is it just an alternate set of traits? I'm assuming its intended to not be used at the same time as the other HAL?

21:56 <re_irc> <@jaxter184:matrix.org> nvm just got to the part where it explains whats different

21:56 <re_irc> <@jaxter184:matrix.org> od

21:56 <re_irc> <@jaxter184:matrix.org> oh wait, so it can be used at the same time as "embedded-hal", interesting

22:59 <re_irc> <@firefrommoonlight:matrix.org> It can. I don't personally, but the option is avail with a feature gate

22:59 <re_irc> <@firefrommoonlight:matrix.org> Not applicable for SAI

23:00 <re_irc> <@firefrommoonlight:matrix.org> I've used it reasonably extensively with SAI on H7, but untested on G4's SAI. Should be the same though

23:00 <re_irc> <@firefrommoonlight:matrix.org> LMK if you need example code etc

23:02 <re_irc> <@firefrommoonlight:matrix.org> The main gotcha is making sure it's configured the same way as the device you're communicating with

23:03 <re_irc> <@firefrommoonlight:matrix.org> There are lots of options! (Those enums in the doc page linked)

23:03 <re_irc> <@firefrommoonlight:matrix.org> And the clock setup. Which side is the master etc