SomeWeirdAnon has quit []
<re_irc> <@j​amesmunns:m​atrix.org> I can kinda see it
<re_irc> <@j​amesmunns:m​atrix.org> as_mut you have to convert then match
<re_irc> <@j​amesmunns:m​atrix.org> iterating just does something zero or one times
<re_irc> <@j​amesmunns:m​atrix.org> how significant is the diff?
fabic has joined #rust-embedded
<re_irc> <@x​obs:m​atrix.org> Hi, I've got an embedded Rust question: How can I ensure a type is aligned? Alternately, how can I troubleshoot a type not being aligned? I'm running into an issue on RISCV-32 where `u64` claims `align_of()` is 8, but it's getting allocated at e.g. `0x8001ff5c`. Rust doesn't like me placing `#[align(8)]` over it.
<re_irc> <@x​obs:m​atrix.org> I did manage to get it to align by sticking it in a newtype that had `#[align(32)]` over it. Any smaller numbers wouldn't work.
<re_irc> <@x​obs:m​atrix.org> Do `u64` values align properly on ARM? Is it just a riscv32i thing? Do `u64` align properly for any other riscv32i users?
starblue1 has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
<re_irc> <@w​illeml:m​atrix.org> firefrommoonlight: https://github.com/willemml/rustworks/pull/8 rfuest got qpi erase/write working
<re_irc> <@f​irefrommoonlight:m​atrix.org> Awesome! Going to try that later this week
<re_irc> <@f​irefrommoonlight:m​atrix.org> And going to compare it to what I've written
<re_irc> <@w​illeml:m​atrix.org> How would I go about implementing flash algorithm or something so that dfu-util and probe-rs can flash stuff onto the QPI external flash?
dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc> <@d​isasm-ewg:m​atrix.org> xobs: I checked with two global statics (one to shift the other) and 64-bit value allocates at the correct address. rustc 1.53.0
<re_irc> <@d​isasm-ewg:m​atrix.org> What allocates the variable at `0x8001ff5c` in your case?
<re_irc> <@x​obs:m​atrix.org> disasm: it's stack-allocated.
<re_irc> <@x​obs:m​atrix.org> ```rust
<re_irc> <@x​obs:m​atrix.org> println!("Alignment of u64: {}", core::mem::align_of::<u64>());
<re_irc> <@x​obs:m​atrix.org> let single_u64 = 443u64;
<re_irc> <@x​obs:m​atrix.org> pub fn alignment_check() {
<re_irc> <@d​isasm-ewg:m​atrix.org> xobs: Hmm, you know what. Maybe sp is not 16-byte from the very begginning
<re_irc> <@x​obs:m​atrix.org> That's a very good thought.
<re_irc> <@x​obs:m​atrix.org> Let me see if that fixes things.
<re_irc> <@d​isasm-ewg:m​atrix.org> I've never thought about this for riscv, so maybe it's also a problem in riscv-rt
<re_irc> <@d​isasm-ewg:m​atrix.org> Anyway, I can't reproduce this on godbolt, and it's clearly seen that sp is modified in 16-byte increments and in all my tests the 64-bit variable is properly aligned assuming sp is 16-byte aligned
<re_irc> <@x​obs:m​atrix.org> Good call about it being in `riscv-rt`. Let me modify the stack to ensure it's 16-byte aligned. Do you think `riscv-rt` will have a similar issue, then?
<re_irc> <@d​isasm-ewg:m​atrix.org> xobs: At least there is no explicit alignment in riscv-rt, it should be added. But looking at the code, I think sp should be aligned in most cases.
<re_irc> <@w​illeml:m​atrix.org> https://github.com/willemml/rustworks is now alloc free!
<re_irc> <@d​isasm-ewg:m​atrix.org> xobs: sp misalignment would also explain why it doesn't work for values less than 32
<re_irc> <@x​obs:m​atrix.org> disasm: That's a very good point. I've gone back and ensured that `sp` is 16-byte aligned, and it does seem to be working now. Thank you for pointing that out.
<re_irc> <@d​isasm-ewg:m​atrix.org> Wow, great!
<re_irc> <@x​obs:m​atrix.org> I guess I didn't realize that was one of the assumptions that is made about stack is that it's aligned that way.
<re_irc> <@x​obs:m​atrix.org> I thought `"e-m:e-p:32:32-i64:64-n32-S128"` indicated that it needed to be 32-bit aligned. My mistake for mis-decoding that.
<re_irc> <@d​isasm-ewg:m​atrix.org> Yeah, I also forgot about this and recalled when I saw a godbolt assembly output
<re_irc> <@d​isasm-ewg:m​atrix.org> I created an issue in riscv-rt
<re_irc> <@x​obs:m​atrix.org> Thanks. And amazing detective work.
<re_irc> <@w​illeml:m​atrix.org> Does anyone know the name of the library that provides flashAlgo traits?
<re_irc> <@d​isasm-ewg:m​atrix.org> willeml: flash-embedded-hal?
<re_irc> <@w​illeml:m​atrix.org> No, it's something different
<re_irc> <@d​isasm-ewg:m​atrix.org> spi-flash?
<re_irc> <@w​illeml:m​atrix.org> I am pretty sure it's not that, flashAlgo is to let you flash external flash chips from a computer
<re_irc> <@d​isasm-ewg:m​atrix.org> spi-memory seems to have this
<re_irc> <@w​illeml:m​atrix.org> Is there an easy way to seach crates.io for a crate containing a trait with a specific name? I had found the crate a while ago, but forgot the name of the crate... Even though I remember the name of the trait
<re_irc> <@d​isasm-ewg:m​atrix.org> You can try searching Github with the trait name in double-quotes
<re_irc> <@w​illeml:m​atrix.org> I wonder if https://github.com/rp-rs/flash-algo/tree/main is it, I thought I saw it on crates.io, but maybe not, anyways, thanks!
fabic has quit [Ping timeout: 246 seconds]
<re_irc> <@t​iwalun:m​atrix.org> The probe-rs flashloaders are based on the ARM spec here: https://arm-software.github.io/CMSIS_5/Pack/html/algorithmFunc.html
<re_irc> <@t​iwalun:m​atrix.org> https://github.com/korken89/stm32l4x2-flashloader and https://github.com/Tiwalun/hifive-flashloader are implementations of flash loaders, I don't know of anything else except of these and the Pico one.
fabic has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> jamesmunns: ```
<re_irc> <@t​herealprof:m​atrix.org> -0.2% 100.0% 824B .text section size, the file size is 323.5KiB
<re_irc> <@t​herealprof:m​atrix.org> +0.2% 100.0% 748B .text section size, the file size is 319.3KiB
<re_irc> <@t​herealprof:m​atrix.org> jamesmunns: But if you look at the implementation...
<re_irc> <@t​herealprof:m​atrix.org> IterMut { inner: Item { opt: self.as_mut() } }
<re_irc> <@t​herealprof:m​atrix.org> }
<re_irc> <@t​herealprof:m​atrix.org> pub fn iter_mut(&mut self) -> IterMut<'_, T> {
neceve has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@j​amesmunns:m​atrix.org> I rescind my "that makes sense"
<re_irc> <@j​amesmunns:m​atrix.org> I'm now down to wild guesses :D
<re_irc> <@w​illeml:m​atrix.org> Finally made a pr of my port of samcrow’s fmc lcd driver from stm32f4 to the stm32f7 repo
<re_irc> <@w​illeml:m​atrix.org> https://github.com/stm32-rs/stm32f7xx-hal/pull/126 I added them as coauthor to the commit because I wasn’t sure how else to credit them in the commit history…
<re_irc> <@w​illeml:m​atrix.org> (All I did was some copy pasting and refactoring)
<re_irc> <@t​herealprof:m​atrix.org> Nice!
<re_irc> <@z​acck:m​atrix.org> Hi people 👋, I wonder if I can get some help with a driver I am trying to build for the St25ru3993 https://www.st.com/en/nfc/st25ru3993.html which is a RFID reader. Communication with the host is done via SPI and I reckon I have all the hardware set up correctly, However whenever I try to read a register from...
<re_irc> ... the device I always receive a static `FF` or 255
<re_irc> <@z​acck:m​atrix.org> Here is how my code for the driver and the application currenly looks like https://gist.github.com/zacck/27caf261bbe54a2eec9300c55ae8c09f
<re_irc> <@z​acck:m​atrix.org> Any sort of help or direction is appreciated.
<re_irc> <@z​acck:m​atrix.org> Thank you! 📿
<re_irc> <@z​acck:m​atrix.org> Thank you! 🙏
<re_irc> <@a​damgreig:m​atrix.org> Zacck Osiemo all FF might indicate a bad connection or the device just not responding or not actually being enabled or selected, so it's hard to know what exactly is going wrong, do you happen to have access to an oscilloscope or logic analyser or anything they would let you see what is happening on the SPI...
<re_irc> ... bus?
<re_irc> <@t​herealprof:m​atrix.org> Zacck Osiemo: A simple thing to check (and often a culprit) is the state of the ~CS line. If you're using some dev board it's almost certainly exposed and you will need to explicitly pull it low.
<re_irc> <@a​damgreig:m​atrix.org> They do pull it low between each transaction
<re_irc> <@t​herealprof:m​atrix.org> Ah, sorry, just noticed the code linked above.
<re_irc> <@t​herealprof:m​atrix.org> Is it the correct GPIO? 😅
<re_irc> <@a​damgreig:m​atrix.org> oh, that DSP example I did earlier can actually be done without unsafe at all, https://rust.godbolt.org/z/5h9d8zsdv
<re_irc> <@a​damgreig:m​atrix.org> that's nice, good job rust
<re_irc> <@a​damgreig:m​atrix.org> even spookier ratio of rust to assembler though lol
<re_irc> <@z​acck:m​atrix.org> adamgreig: None at the moment I can perhaps find ont
<re_irc> <@a​damgreig:m​atrix.org> that can be helpful just to quickly check the pins into the RFID reader are all being driven like they should, but otherwise I would carefully check all the wiring and the pin assignments in your code
<re_irc> <@z​acck:m​atrix.org> Let me recheck my wiring
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Hm, I'm still seeing `unsafe` in `fn qadd16` or do you mean something else?
<re_irc> <@a​damgreig:m​atrix.org> oh, yea, forgot that, I mean the packing into u32 which used to be unsafe { *(self as *const _ as *const u32) }
<re_irc> <@a​damgreig:m​atrix.org> still needs the inline asm and its unsafe
<re_irc> <@a​damgreig:m​atrix.org> it's a bit more fragile though, you need that &0xFFFF or it fails to fully optimise it
<re_irc> <@t​herealprof:m​atrix.org> Yeah, I was actually wondering about how to get to the necessary IR to make that magic happen in LLVM.
tokomak has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> that would be nice, I haven't managed to get it to generate any of the _16 or _8 instructions so far, not sure it knows how
<re_irc> <@z​acck:m​atrix.org> adamgreig: Pin was loose, I get replies now :cele
<re_irc> <@t​herealprof:m​atrix.org> There're basically two ways to success: Either we recombine 2/4 suitable sadd isns into a single operation in LLVM (which looks gnarly) or we get Rust to do generate IR to use `v2i16` instead of 2 `i16` types.
<re_irc> <@t​herealprof:m​atrix.org> There're an unstable `#[repr(simd)]` but it actually pessimizes the code since it's not using registers at all.
<re_irc> <@a​damgreig:m​atrix.org> yea, it has stuff like https://doc.rust-lang.org/core/arch/arm/struct.int16x4_t.html
<re_irc> <@a​damgreig:m​atrix.org> but they're all for 64-bit values that only work on "big arm"
<re_irc> <@a​damgreig:m​atrix.org> maybe core::arch::arm could gain some int16x2 and int8x4 and uint16x2 and uint8x4 types that pack into u32?
<re_irc> <@a​damgreig:m​atrix.org> basically that's a full set of NEON intrinsics and we'd want the same but for the ARMv7-M/ARMv8-M DSP extension
<re_irc> <@t​herealprof:m​atrix.org> That certainly makes sense but I'm a bit cautious about `#[repr(simd)]`. I'm not sure why it would behave differently in those intrinsics than in a custom stuct.
<re_irc> <@a​damgreig:m​atrix.org> there's https://rust-lang.github.io/unsafe-code-guidelines/layout/packed-simd-vectors.html and so on
<re_irc> <@a​damgreig:m​atrix.org> I'm not really sure why you can't just use repr(packed) but I guess the point is all the interior elements are still well-aligned
<re_irc> <@t​herealprof:m​atrix.org> At the moment if you pass a `#[repr(simd)]` type it always seems to go through memory, not via register.
<re_irc> <@a​damgreig:m​atrix.org> and on armv7-m/v8-m the simd instructions use regular general purpose registers, not special dsp registers
<re_irc> <@t​herealprof:m​atrix.org> When the LLVM PR is merged (approved already) I can add the lowering of the `v2i16` and `v4i8` types but we'll still need to figure out how to actually provide them to LLVM.
<re_irc> <@t​herealprof:m​atrix.org> (the absence of all of this is so weird, there's so much low hanging fruit which should provide a noticeable benefit to a lot (dare I say all?) application compiled for ARM)
fabic has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> Embedded coincidentally profits the last due to being Cortex-M4 and up only. 😅
<re_irc> <@a​damgreig:m​atrix.org> does normal ARM include the thumb DSP extensions?
<re_irc> <@a​damgreig:m​atrix.org> plenty of applications using cm4 and cm7!
<re_irc> <@a​damgreig:m​atrix.org> therealprof: nice!! don't forget v2u16 and v4u8 too
<re_irc> <@a​damgreig:m​atrix.org> like, ARMv7-A doesn't have SSUB16 or QADD16 or anything like that, as far as I can tell?
<re_irc> <@l​ulf_:m​atrix.org> cr1901: cr1901: MathiasKoch FYI I've added blocking support to drogue-tls and it should also compile with rust stable (async requires nightly still). Going to publish a 0.2.0 version of the crate later today.
<cr1901> Good stuff (I'm stuck on nightly anyway, don't worry). Thanks for your effort
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: They don't exist in LLVM IR, they only have "integer".
<re_irc> <@a​damgreig:m​atrix.org> I see
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Not sure about ARMv7-A but I'm assuming I do as well since they's no gate in LLVM code as far as I can see. I checked ARMv8-A as I pointed out the other day and they are mandatory instructions (although I haven't checked whether they have all of them).
<re_irc> <@a​damgreig:m​atrix.org> So no uadd8?
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: That's done via the IR mnemonics. The parameters are all 🤷‍♂️.
<re_irc> <@t​herealprof:m​atrix.org> It's `@llvm.usub.sat.i8` vs `@llvm.ssub.sat.i8`
<re_irc> <@a​damgreig:m​atrix.org> aah, I still had case sensitive search turned on 😐️ v7-A does have all the v7E-M DSP instructions
<re_irc> <@a​damgreig:m​atrix.org> so yea, that makes it even weirder that LLVM doesn't...
<re_irc> <@m​athias_koch:m​atrix.org> Ulf Lilleengen: Awesome! Thanks for the update! Now i just need AWS to actually support TLS1.3.. ☹️ Don't suppose you can help with that? :p
<re_irc> <@a​damgreig:m​atrix.org> they were added in ARMv5TE so I think ARMv6-A and ARMv7-A both have them
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: I concur.
<re_irc> <@a​damgreig:m​atrix.org> so, wow, yea, anyone on ARM should expect to benefit, which is also a good reason to get them into core::arch::arm I guess
<re_irc> <@a​damgreig:m​atrix.org> so long as it doesn't try to emit them for thumbv6m-none-eabi, heh
<re_irc> <@t​herealprof:m​atrix.org> That works just fine.
<re_irc> <@t​herealprof:m​atrix.org> For single values the IR is produced correctly which is the reason why were seeing 2 of those instructions in my 2D Coordinate example code.
<re_irc> <@t​herealprof:m​atrix.org> Only for unsigned addition the lowering doesn't exist so it's emulated with regular instructions.
<re_irc> <@t​herealprof:m​atrix.org> But now the question is, how can get Rust to pack the coordinates into a one register of type v2i16 instead of 2 registers of type i16 (and whithout going over memory like `#[repr(simd)]` does).
<re_irc> <@t​herealprof:m​atrix.org> Unfortunately godbolt IR generation is super flaky, sometimes it works, sometimes it doesn't...
_whitelogger has joined #rust-embedded
<re_irc> <@f​irefrommoonlight:m​atrix.org> FYI Digikey just stocked some Stm32s
<re_irc> <@f​irefrommoonlight:m​atrix.org> I just scored some L4s that have been out of stock for months
<re_irc> <@r​yan-summers:m​atrix.org> You should be charging people for that intel ;)
<re_irc> <@a​damgreig:m​atrix.org> I can just imagine the armed guards with a briefcase full of waffle trays
<re_irc> <@f​irefrommoonlight:m​atrix.org> I bought first and am now looking more broadly: it may have just been for the specific model, or a small handful. Most are still 0 stock. L443CCT (L4 with 256k flash in qfp48) has about 1700 left
<re_irc> <@f​irefrommoonlight:m​atrix.org> That happens to be the one I designed for. Not total coincidence since that's the page I've been F5ing most
neceve has quit [Ping timeout: 252 seconds]
dreamcat4 has joined #rust-embedded
SomeWeirdAnon has joined #rust-embedded
<re_irc> <@a​nahata:m​atrix.org> I didn't realize STM32s are in such demand. I have one I'm not using, an STM32F3Discovery, and I'd be happy to send it to someone who's going to make use of it. It's lightly used, mostly I got it to go through the discovery book, but got a bit lost around chapters 6/7 and went off and did my own things
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Hm.... https://github.com/rust-lang/stdarch/tree/master/crates/core_arch/src/arm
<re_irc> <@t​herealprof:m​atrix.org> Not quite sure how that is supposed to work.
<re_irc> <@a​damgreig:m​atrix.org> hmmm
<re_irc> <@a​damgreig:m​atrix.org> dunno, they don't show up on https://doc.rust-lang.org/core/arch/arm/index.html
<re_irc> <@a​damgreig:m​atrix.org> maybe due to https://github.com/rust-lang/stdarch/issues/1055
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@t​herealprof:m​atrix.org> Maybe too new?
<re_irc> <@f​irefrommoonlight:m​atrix.org> anahata: Dev boards are still easy to get. It's bare chips that aren't
<re_irc> <@a​nahata:m​atrix.org> ah, okay, thank you for clarifying
<re_irc> <@f​irefrommoonlight:m​atrix.org> But that's nice of you to offer that!
<re_irc> <@f​irefrommoonlight:m​atrix.org> For some context, [here is the Digikey search page for STM32](https://www.digikey.com/en/products/filter/embedded-microcontrollers/685?s=N4IgTCBcDaIM4BcC2BmCBdANCArFUADlAIzYFGRg4C%2B2AbPiAJYAmUIAtMQAwRkLsQ2BAE8CAU3Ys4AYxDVqQA). The ones available at quantities >100 fill up about 1.5 pages, and there's 0...
<re_irc> ... stock page page 3. This is for a large and diverse product lineup, from the biggest distributor for people who can't buy direct from manufacturer. And most of the available ones are in BGA packages, which are tough to inspect without an X-ray machine
<re_irc> <@t​hejpster:m​atrix.org> Damn. I put in an order on Monday.
<re_irc> <@t​hejpster:m​atrix.org> In the UK you need to get it up to £33 to get free postage
<re_irc> <@t​hejpster:m​atrix.org> I need F031s in a QFP32, which is normally about £1. They only have one QFP32 in stock which is an L071, and they're £4.
<re_irc> <@t​hejpster:m​atrix.org> RS in the UK seem to have some stock
<re_irc> <@a​nahata:m​atrix.org> Still expensive, though, ouch
<re_irc> <@t​hejpster:m​atrix.org> Not as bad as LCSC. They want $7 a piece!
neceve has joined #rust-embedded
<re_irc> <@y​atekii:m​atrix.org> lol
<re_irc> <@y​atekii:m​atrix.org> we have a component in our product that is 10$ instead of 20Cts :D
<re_irc> <@y​atekii:m​atrix.org> fun times
<re_irc> <@y​atekii:m​atrix.org> should have invested in the MCU trade
<re_irc> <@d​irbaio:m​atrix.org> oof 50x? We have one that did a 20x 🤣
<re_irc> <@d​irbaio:m​atrix.org> it's getting the axe in the next revision ☠️
<re_irc> <@f​irefrommoonlight:m​atrix.org> That sucks!
<re_irc> <@f​irefrommoonlight:m​atrix.org> In surprised about LCSC being more expensive. They're generality cheaper for me compared to Digikey, but spottier stock
<re_irc> <@y​atekii:m​atrix.org> dirbaio: yeah x50 was a new record ... I think our record before that was was x18 before that
<re_irc> <@a​damgreig:m​atrix.org> LCSC are _usually_ cheaper but they haven't been afraid to bump prices on the stuff that's out of stock everywhere else
<re_irc> <@n​fd:c​ybre.space> it's so weird to me that no manufacturer seems to want to make those despite the big hobbyist demand
<re_irc> <@t​herealprof:m​atrix.org> nfd: OTOH designing PCBs has become so easy and cheap, that many hobbyists simply have moved over to doing that. Plus the "big" hobbyist market is still a tiny piecemeal business compared to the huge industry business buying magnitudes more units.
<re_irc> <@n​fd:c​ybre.space> yeah, like, tons of hobbyists seem completely happy with Arduino-compatible/RasPi-esque boards because you can go from 0 to blinking an LED in approximately 0.5 A presses. and that's cool and i'm happy to support them in that/those hobbyists in that hobbyisting
<re_irc> <@n​fd:c​ybre.space> it just feels weird to me that there was like *one* nicely breadboardable M0 package and they're just done with it, whether it's huge business or no
<re_irc> <@a​damgreig:m​atrix.org> but also loads of hobbyists these days are designing their own PCBs using the same BGA parts going into phones, how many hobbyists are left needing DIP chips?
<cr1901> Me
<re_irc> <@a​damgreig:m​atrix.org> might be a chicken and egg thing where no one makes DIP-packaged cortex MCUs though....
<cr1901> Because fuck BGA
<re_irc> <@a​damgreig:m​atrix.org> hah, I mean, fair
<re_irc> <@a​damgreig:m​atrix.org> 0.8mm tqfp isn't so bad though
<re_irc> <@a​damgreig:m​atrix.org> do msp430 come in DIP?
<cr1901> yes, the G-series does at least
<re_irc> <@n​fd:c​ybre.space> like, my intro to embedded dev was taking an lpc1114 from cross-compiler/manual to multitasking
<re_irc> <@a​damgreig:m​atrix.org> wow, cool
<re_irc> <@n​fd:c​ybre.space> i don't feel like that's an experience you're likely to *get* when you're baking stuff into chips
<re_irc> <@a​damgreig:m​atrix.org> how do you mean?
<cr1901> Anyways surface mount I can do w/ a toaster oven set to 450F. But BGA is awful for hobbyists
<re_irc> <@a​damgreig:m​atrix.org> you could take an stm32f0 from cross-compiler to multitasking just the same
<re_irc> <@n​fd:c​ybre.space> sure thing
<re_irc> <@a​damgreig:m​atrix.org> cr1901: I bet if you just put a bga on your pcb with some flux and in your toaster oven it would probably be ok
<re_irc> <@t​herealprof:m​atrix.org> Yeah, maybe, but BGA is really extreme.
<re_irc> <@a​damgreig:m​atrix.org> but definitely a lot more work than hand soldering a larger package with exposed leads for sure
<re_irc> <@a​damgreig:m​atrix.org> they do SOIC-8 stm32g0, that's pretty close to a dip!
<re_irc> <@t​herealprof:m​atrix.org> nfd: There're some chips in quite hand solderable packages like a STM32F042F6.
<cr1901> The amount of flux you need to put under the BGA pads needs to be carefully controlled. Certainly within the realm of human precision, but I manage to screw it up anyway
<re_irc> <@t​herealprof:m​atrix.org> But even soldering a QFP32 package to an DIP adapter board is easily doable for anyone with a simple solder iron.
<re_irc> <@a​damgreig:m​atrix.org> maybe they should do a DIP stm32g0 anyway :P
<re_irc> <@a​damgreig:m​atrix.org> once you have it ready for a soic-8 leadframe surely it's easy to DIP-8 package it
<cr1901> LPC810 was the last DIP ARM I'm aware of
<cr1901> discontinued in 2017 I think :/
<cr1901> Also, the SVDs NXP provided were shit
<re_irc> <@n​fd:c​ybre.space> therealprof: looks pretty nice...
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: It's still a lot of extra work for something which will not sell in millions.
<re_irc> <@t​herealprof:m​atrix.org> nfd: That was my goto chip for a long time, it's very feature packed and can even do USB without external crystal.
<re_irc> <@n​fd:c​ybre.space> doesn't look *super* available atm but
<re_irc> <@a​damgreig:m​atrix.org> +1, love the f042, at least when you can get it
<re_irc> <@t​herealprof:m​atrix.org> nfd: Yeah, that's a very real general problem at the moment.
<re_irc> <@a​damgreig:m​atrix.org> I think the new g0 chips are probably an exciting more modern option with generally the same or better features
<re_irc> <@n​fd:c​ybre.space> lol yup
<re_irc> <@n​fd:c​ybre.space> you'd think semiconductors were as valuable as toilet paper
<re_irc> <@n​fd:c​ybre.space> hmm
<re_irc> <@n​fd:c​ybre.space> dip-8 or no, are any of y'all aware of any chips nicely broken out to be solderless breadboard-friendly without extra miscellany?
<re_irc> <@n​fd:c​ybre.space> ideally pushing the unit price under around $2
<re_irc> <@n​fd:c​ybre.space> think classroom settings
<re_irc> <@t​herealprof:m​atrix.org> At the moment? No. 2 years ago I'd say it would have been possible to prepare something roughly at that pricepoint.
<re_irc> <@t​herealprof:m​atrix.org> At the moment your best shot in the <<$10 range would be a presoldered kit, like Rapberry Pi Pico, USB-C Pill, or a LPC845BRK.
<re_irc> <@n​fd:c​ybre.space> heh. even the 845 isn't in BYOMOSFET territory 😛
<re_irc> <@t​herealprof:m​atrix.org> Hm, I've misplaced 20 or so STM32F072... I need to better watch out for that silicon gold... 😅
<re_irc> <@n​fd:c​ybre.space> tru
<re_irc> <@n​fd:c​ybre.space> halfway tempted to grab some of those for funsies
tokomak has quit [Read error: Connection reset by peer]
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig: Their 255 bytes i2c is weird, can just fire the DMA and forget
<re_irc> <@t​halesfragoso:m​atrix.org> Although is the same in several other families :/
neceve has quit [Ping timeout: 252 seconds]
<re_irc> <@l​achlansneff:m​atrix.org> dirbaio: Should there be a trait for reading n bytes from SPI, but not writing it to a slice?
<re_irc> <@t​halesfragoso:m​atrix.org> Btw, I wanted to test my driver for using more than 255 bytes transfer, but I ssd1306 only does several 17 bytes transfers instead of everything at once
<re_irc> <@t​halesfragoso:m​atrix.org> Probably because of the lack of write_vectored or something
<re_irc> <@t​halesfragoso:m​atrix.org> Probably could do with WriteIter though, but not with DMA
<re_irc> <@t​herealprof:m​atrix.org> thalesfragoso: Yeah, legacy.
<re_irc> <@t​halesfragoso:m​atrix.org> Is it some hardware limitation of just because it needs the pre-pend the data byte ?
<re_irc> <@t​herealprof:m​atrix.org> It's just because of the extra buffering required for the prepended byte, yes.
<re_irc> <@t​herealprof:m​atrix.org> It's a compromise between overhead and efficiency.
<re_irc> <@t​halesfragoso:m​atrix.org> Maybe WriteIter would work ?
<re_irc> <@t​herealprof:m​atrix.org> Yes, but with DMA? 😉
<re_irc> <@t​halesfragoso:m​atrix.org> Yeah, no DMA, but most traits aren't implemented with DMA though
<re_irc> <@t​halesfragoso:m​atrix.org> But we might want a write_vectored in e-h
<re_irc> <@t​herealprof:m​atrix.org> I used the driver as a playground for `display-interface` so we could get rid of the built-in I2C/SPI abstractions but we never changed the way of operation.
<re_irc> <@l​achlansneff:m​atrix.org> Err, should most of these Read and Write traits be replaced with the canonical `Read`, `Write`, `AsyncRead`, and `AsyncWrite` traits?
<re_irc> <@l​achlansneff:m​atrix.org> Ignoring for the fact that those aren't available at the moment on no_std
<re_irc> <@t​herealprof:m​atrix.org> Lachlan Sneff: ?
<re_irc> <@l​achlansneff:m​atrix.org> I just thought of that. Most of the Read and Write traits in embedded-hal are almost, but not quite the same as Read and Write if the error were an associated type
<re_irc> <@t​herealprof:m​atrix.org> thalesfragoso: You can write your own `d-i` driver though which DMAs the data out.
<re_irc> <@l​achlansneff:m​atrix.org> Lachlan Sneff: Actually this is dumb, nvm
<re_irc> <@l​achlansneff:m​atrix.org> Ignore me
<re_irc> <@t​herealprof:m​atrix.org> Lachlan Sneff: It might be possible for some (and there's e.g. Write adapters for serial) but for others you need a different interface or a special adapter in order to do that. E.g. I2C requires an address to be supplied.
<re_irc> <@d​irbaio:m​atrix.org> Lachlan Sneff: what do you mean?
<re_irc> <@d​irbaio:m​atrix.org> Lachlan Sneff: I don't think this would really work, the protocols have quirks
<re_irc> <@d​irbaio:m​atrix.org> - as already stated, i2c requires an address
<re_irc> <@d​irbaio:m​atrix.org> - spi transfer is not the same as spi write, spi read (or any combination thereof)
<re_irc> <@d​irbaio:m​atrix.org> - i2c write_read is not the same as i2c write, then i2c read
<re_irc> <@d​irbaio:m​atrix.org> plus they can do short reads/writes which is annoying and doesn't make sense when taking directly to the hardware
<re_irc> <@l​achlansneff:m​atrix.org> dirbaio: For example, I know how many bytes are on the wire, but I want to ignore them because I only have so much space to store them.
<re_irc> <@l​achlansneff:m​atrix.org> But I still need some data at the end of the packet.
<re_irc> <@d​irbaio:m​atrix.org> oh.. dunno, seems very niche
<re_irc> <@l​achlansneff:m​atrix.org> Yeah, not very common probably
<re_irc> <@l​achlansneff:m​atrix.org> Implementation would just be a DMA transfer with both pointers set to null though
<re_irc> <@f​irefrommoonlight:m​atrix.org> cr1901: try QFN
<re_irc> <@f​irefrommoonlight:m​atrix.org> Its auto-centering is magic. If it doesn't work, apply flux to edges, and tap with iron
<re_irc> <@t​halesfragoso:m​atrix.org> Lachlan Sneff: That would cause an error, no ?
<re_irc> <@t​halesfragoso:m​atrix.org> Usually bus error on the DMA
<re_irc> <@f​irefrommoonlight:m​atrix.org> adamgreig: I'm probably going to use a G0 next time I need a super-cheap MCU
<re_irc> <@l​achlansneff:m​atrix.org> thalesfragoso: Certainly might, not sure
<re_irc> <@f​irefrommoonlight:m​atrix.org> dirbaio: What's the difference between SPI transfer, and write followed by read? (Assuming the write is a single word)
<re_irc> <@d​irbaio:m​atrix.org> transfer writes and reads at the same time
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ah gotcha! I've been doing mostly blocking
<re_irc> <@d​irbaio:m​atrix.org> yeah even blocking transfer reads and writes at the same time
<re_irc> <@f​irefrommoonlight:m​atrix.org> Now that you mention it, the DMA recipe is to kick off in a way where they run concurrently
<re_irc> <@f​irefrommoonlight:m​atrix.org> I2C has further subtleties
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think re autoending
<re_irc> <@d​irbaio:m​atrix.org> transfer of 1 byte does 8 clocks on the bus, shifting out a bit AND shifting in a bit at every clock cycle
<re_irc> <@f​irefrommoonlight:m​atrix.org> Sweet
<re_irc> <@d​irbaio:m​atrix.org> write 1 byte + read 1 byte will do 16 clocks, first shifting out the write, then shifting in the read
<re_irc> <@f​irefrommoonlight:m​atrix.org> Thank you for the expalanation!
<re_irc> <@f​irefrommoonlight:m​atrix.org> I may need to adjust some code...
<re_irc> <@d​irbaio:m​atrix.org> hahaha :)
<re_irc> <@f​irefrommoonlight:m​atrix.org> (FYI, doing the read after teh write works for SPI blocking, but it sounds like it's inefficient)
<re_irc> <@f​irefrommoonlight:m​atrix.org> And I2C will flat out not work if you try it that way
<re_irc> <@f​irefrommoonlight:m​atrix.org> due to the termination
<re_irc> <@d​irbaio:m​atrix.org> firefrommoonlight: implementing Transfer with Write and Read?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea
<re_irc> <@d​irbaio:m​atrix.org> it's not just slow, it won't work
<re_irc> <@d​irbaio:m​atrix.org> it does a different thing
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hmm....
<re_irc> <@f​irefrommoonlight:m​atrix.org> Seems to work for me, unless I'm missing something
<re_irc> <@f​irefrommoonlight:m​atrix.org> On several devices
<re_irc> <@d​irbaio:m​atrix.org> you don't choose when your slave chip sends you the data
<re_irc> <@f​irefrommoonlight:m​atrix.org> Might be working by coincidence.
<re_irc> <@f​irefrommoonlight:m​atrix.org> Is this approach from `embedded-hal`'s default transfer impl wrong? https://github.com/rust-embedded/embedded-hal/blob/master/src/blocking/spi.rs#L34
<re_irc> <@d​irbaio:m​atrix.org> nb::spi::FullDuplex is specified to write+read at the same time
<re_irc> <@d​irbaio:m​atrix.org> when you do `write`, it'll do 8 cycles writing the value, AND reading a value back
<re_irc> <@d​irbaio:m​atrix.org> it stores that value somewhere
<re_irc> <@d​irbaio:m​atrix.org> and with `read` you just get that value out, it doesn't do another 8 clock cycles
<re_irc> <@d​irbaio:m​atrix.org> so nb `write` then `read` really is writing+reading at the same time
<re_irc> <@f​irefrommoonlight:m​atrix.org> Doesn't this `nb::block!(self.write(word.clone()))?;` block during the write, and the read can't start until the write is complete?
<re_irc> <@d​irbaio:m​atrix.org> but blocking `write` then `read` is not
<re_irc> <@d​irbaio:m​atrix.org> nb::block!(self.write(word.clone()))?; blocks during the write AND does a read at the same time without you asking for it
<re_irc> <@f​irefrommoonlight:m​atrix.org> so it assumes `write` does a read too?
<re_irc> <@d​irbaio:m​atrix.org> `self.read()` pops that byte out
<re_irc> <@f​irefrommoonlight:m​atrix.org> Actually, now that I look at the code I'm using on stm32, the first step in the write is to read from SR register
<re_irc> <@f​irefrommoonlight:m​atrix.org> Thank you. I'm going to do some digging and try to learn more about this. I evidently have some gaps
<re_irc> <@d​irbaio:m​atrix.org> not your fault... I find that nb spi trait to be ultra confusing too
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think what happened is I blindly aped it without understanding, with the actual write and read code coming from a STM32 RM
<re_irc> <@d​irbaio:m​atrix.org> and it's very underspecified
<re_irc> <@d​irbaio:m​atrix.org> can you call write n a loop without ever reading? docs suggest you can, but impls explode if you try that
<re_irc> <@f​irefrommoonlight:m​atrix.org> This could be related to why I'm struggling wtih SPI DMA
<re_irc> <@f​irefrommoonlight:m​atrix.org> Haven't tried - the `write_one` method I've been using starts with a read
<re_irc> <@f​irefrommoonlight:m​atrix.org> Might give it a shot just to prove it to myself, but I'm confident you're right
<re_irc> <@d​irbaio:m​atrix.org> dma, fun
<re_irc> <@d​irbaio:m​atrix.org> what chips are you targeting for dma?
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm trying to get it to work with an SPI display
<re_irc> <@d​irbaio:m​atrix.org> what stm32 families I mean
<re_irc> <@f​irefrommoonlight:m​atrix.org> Any/all
<re_irc> <@f​irefrommoonlight:m​atrix.org> At least ones F3 and newer
<re_irc> <@f​irefrommoonlight:m​atrix.org> Testing on L4. (I say any/all since the SPI and DMA periphs are very similar across)
<re_irc> <@f​irefrommoonlight:m​atrix.org> With some quirks like L4 needing a special channel select that none of the others have, and the newer ones using DMAMUX
<re_irc> <@d​irbaio:m​atrix.org> lol, no they aren't :o
<re_irc> <@f​irefrommoonlight:m​atrix.org> H7 has some diff status codes. What significant differences have you found?
<re_irc> <@f​irefrommoonlight:m​atrix.org> (Obviously this could be related to why I can't get it working...)
<re_irc> <@f​irefrommoonlight:m​atrix.org> And G0's missing some DMA channels
<re_irc> <@d​irbaio:m​atrix.org> there's at least 5 variants 🤣
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ok, but what are the differences, and are you referring to SPI or DMa?
<re_irc> <@d​irbaio:m​atrix.org> thalesfragoso and Bob McWhirter are having lots of fun with it in embassy
<re_irc> <@d​irbaio:m​atrix.org> DMA
<re_irc> <@d​irbaio:m​atrix.org> BDMAv1: F0, F1, F3, L1
<re_irc> <@d​irbaio:m​atrix.org> hardcoded set of peripherals. Two peripherals that are associated
<re_irc> <@d​irbaio:m​atrix.org> to the same DMA channel can't be used with DMA at the same time, AT ALL.
<re_irc> <@d​irbaio:m​atrix.org> no request selection capabilities. Each DMA channel is the OR of a
<re_irc> <@f​irefrommoonlight:m​atrix.org> The L0, L4 caveat is the one I mentioned. I haven't implemented for F4, F7, F2
<re_irc> <@f​irefrommoonlight:m​atrix.org> So that's probably consistent with what I'm doing
<re_irc> <@d​irbaio:m​atrix.org> note that "BDMA" is called "DMA" by ST unless in the H7
<re_irc> <@d​irbaio:m​atrix.org> in embassy we decided to call it "BDMA" in all to prevent going crazy
<re_irc> <@f​irefrommoonlight:m​atrix.org> I just looked at my notes: I skipped H7 because I couldn't figure it out!
<re_irc> <@f​irefrommoonlight:m​atrix.org> The L4 thing is weird - why do you need to specify the channel when you have no choice?!?!
<re_irc> <@d​irbaio:m​atrix.org> you do have a choice, that's the point
<re_irc> <@f​irefrommoonlight:m​atrix.org> I have 2 broad categories: DMAMUX and non-DMAMUX, with L4 being an exception to the latter with an additional step
<re_irc> <@d​irbaio:m​atrix.org> there's these 5 categories :P
<re_irc> <@f​irefrommoonlight:m​atrix.org> What I'm tracking: There's a CxS field you set to pair a channnel to which peripheral is on it
<re_irc> <@f​irefrommoonlight:m​atrix.org> But each periph only has 1 option for channel
<re_irc> <@f​irefrommoonlight:m​atrix.org> RM0394, Table 41
<re_irc> <@f​irefrommoonlight:m​atrix.org> If I'm missing something, this could absolutely explain why my DMA isn't going well
<re_irc> <@f​irefrommoonlight:m​atrix.org> Other than the CxS (x being channel num), what other L4 steps are there?
<re_irc> <@d​irbaio:m​atrix.org> nope, there are some exceptions :D
<re_irc> <@d​irbaio:m​atrix.org> for example: i2c1_tx can go in DMA1_CH6 or DMA2_CH7
<re_irc> <@f​irefrommoonlight:m​atrix.org> Gotta run for 30 mins I'll take a look!
<re_irc> <@d​irbaio:m​atrix.org> if peripheral requests were ORed together like in BDMAv1 (f0, f1, f3, l1), if you're using I2C1_TX for DMA1_CH6, it would also spam DMA2_CH7 with requests so you wouldn't be able to use it for something else
<re_irc> <@d​irbaio:m​atrix.org> in BDMAv2 you can set DMA2_CH7's CSELR to something else so you can still use it
<re_irc> <@d​irbaio:m​atrix.org> and there's quite a few more of these
<re_irc> <@d​irbaio:m​atrix.org> for example
<re_irc> <@d​irbaio:m​atrix.org> (search for `dma_channels`)
<re_irc> <@b​obmcwhirter:m​atrix.org> At least flavors of bdma are 3 of the 5
<re_irc> <@d​irbaio:m​atrix.org> and of dma too 🤣
<re_irc> <@d​irbaio:m​atrix.org> intersecting in the H7 which has both
<re_irc> <@t​halesfragoso:m​atrix.org> And you still have chips in the same family that have chsl while others don't
<re_irc> <@f​irefrommoonlight:m​atrix.org> dirbaio: I'm only tracking CH6
<re_irc> <@f​irefrommoonlight:m​atrix.org> CH7 is for the Dma2 periph
<re_irc> <@f​irefrommoonlight:m​atrix.org> So there are still 0 degrees of freedome
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ah I see your explanation now. Makes sense. awkward. I think my code there is right though
<re_irc> <@f​irefrommoonlight:m​atrix.org> Mainly because I cheated and didnt' implement DMA2 for any MCU...
<re_irc> <@f​irefrommoonlight:m​atrix.org> Broken down, I've implemented on G0, G4, L4, L5, WB, WL, and F3. F3 doesn't use DMAMUX. L4 is like F3, but also has that CxS thing we just talked about. The rest use DMAMUX
<re_irc> <@d​irbaio:m​atrix.org> :)
crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #rust-embedded
<cr1901> f​irefrommoonlight: QFN is fine, I have an okay success rate w/ that
<re_irc> <@b​obmcwhirter:m​atrix.org> So much DMA
<re_irc> <@b​obmcwhirter:m​atrix.org> I think of DMAMUX as a bolt on to BDMA this evening.
<re_irc> <@b​obmcwhirter:m​atrix.org> Fancy chsel