!WqsLCItsZbJGhRjnxP:matrix.org

stm32-rs

485 Members
Discussion and support for stm32-rs projects. History is publicly viewable. Bridged to #stm32-rs on Libera IRC. Code of conduct: https://www.rust-lang.org/conduct.html. Public logs: https://libera.irclog.whitequark.org/stm32-rs54 Servers

Load older messages


SenderMessageTime
18 Jun 2024
@jamesmunns:beeper.comJames Munnsnot sure if I understand11:32:39
@jamesmunns:beeper.comJames Munnsif you unsafely make a slice, you must ensure that slice can never be corrupted for the lifetime of the slice11:33:00
@ryan-summers:matrix.orgryan-summers So the way the HAL handles it is by having a dma::Transfer struct that owns buf1: &mut [u8], buf2: &mut [u8] 11:33:17
@jamesmunns:beeper.comJames Munnse.g. once "handed out", it should impossible for DMA to ever touch that range of memory until the slice is dropped, usually with a guard of some kind11:33:28
@ryan-summers:matrix.orgryan-summers So they exist in that dma::Transfer struct while it is handed over to the DMA module 11:33:35
@ryan-summers:matrix.orgryan-summers * So they exist in that dma::Transfer struct while it is handed over to the DMA peripheral 11:33:48
@ryan-summers:matrix.orgryan-summers * So they exist in that dma::Transfer struct while it is handed over to the DMA peripheral, but they are never accessed 11:33:55
@jamesmunns:beeper.comJames Munnsah, that's fine, if the DMA has "exclusive access" to the slice while it is messing with them11:34:04
@jamesmunns:beeper.comJames Munnsit's the "concurrent access" that is the bad part.11:34:17
@ryan-summers:matrix.orgryan-summersYeah, that we guarantee11:34:23
@jamesmunns:beeper.comJames Munnsif you take the ptr+len of the slice, then that pointer has the provenance of the slice until the next time the slice or pointer is re-accessed by rust code11:34:48
@jamesmunns:beeper.comJames Munnsyou still want to fence after the DMA completes, but that's fine.11:35:05
@ryan-summers:matrix.orgryan-summersWhat I'm saying is that the slice is still alive while DMA has access to it, but the code never actually uses the slice until DMA is done11:35:12
@ryan-summers:matrix.orgryan-summersBut yeah, there's fences. That should stop rustc optimizing across the fence, yes?11:35:35
@ryan-summers:matrix.orgryan-summers * But yeah, there's fences. That should stop rustc optimizing across the fence, yes? I.e. ensure that the compiler will use the post-DMA'd data11:35:50
@jamesmunns:beeper.comJames MunnsI'd have to look, that could be fine without unsafecell, but I'd probably make the Transfer struct just hold pointers not slices11:36:13
@ryan-summers:matrix.orgryan-summersYeah, I might make a PR11:36:30
@jamesmunns:beeper.comJames MunnsIMO: you never want to mix pointers and slices (or do it as little as possible), and when doing unsafe, keep it pointers, and make slice access as short as possible11:36:39
@jamesmunns:beeper.comJames Munnsthis is because it is very easy to accidentally invalidate provenance with slices, as they assert certain "exclusivity" rights that pointers don't.11:37:22
@ryan-summers:matrix.orgryan-summersYup, makes sense. No real reason for the slices anyways since we just need the pointe r+ length for DMA11:38:03
@jamesmunns:beeper.comJames Munnsessentially, slices "proactively" assert their rights: as long as the slices exist, rules must be followed. pointers "reactively" assert their rights: the rules must be followed WHEN you access them (and sometimes for the duration of access) (this is sort of a simplification)11:38:26
@jamesmunns:beeper.comJames Munns * essentially, slices/references "proactively" assert their rights: as long as the slice/references exist, rules must be followed. pointers "reactively" assert their rights: the rules must be followed WHEN you access them (and sometimes for the duration of access) (this is sort of a simplification)11:38:52
@firefrommoonlight:matrix.orgfirefrommoonlightI tend to prefer slices in anything that is used by firmware directly, and keep the pointers in hardware interaction or FFI libs called by the firmware 15:59:19
@simsek:matrix.orgsimsek 🦀 changed their display name from Simsek to simsek 🦀.21:45:34
19 Jun 2024
@762spr:matrix.org762spris there a some configuration setting that would make USART1 on a STM32H7A3 only work when the debugger is attached?18:48:13
@762spr:matrix.org762sproh that's weird it's a ground problem 🤦‍♂️😂 my ground pin for the ftdi cable slipped off and I didn't notice. it would work when another USB device was plugged in (programmer) and everything was grounded through the pc18:54:06
@762spr:matrix.org762sprI was combing through the datasheet trying to figure out wtf was going on 🤡18:55:07
20 Jun 2024
@firefrommoonlight:matrix.orgfirefrommoonlightDon't you love Heisenbugs00:49:13
@hardy_tom:matrix.org@hardy_tom:matrix.org left the room.09:35:17
@farooqkz:mozilla.orgFarooq [MR. Potato] changed their display name from Farooq [Potato] to Farooq [MR. Potato].14:18:47

There are no newer messages yet.


Back to Room ListRoom Version: 5