jackneillll has quit [Remote host closed the connection]
jackneillll has joined #rust-embedded
jackneilll has joined #rust-embedded
jackneillll has quit [Ping timeout: 240 seconds]
<re_irc>
<@nihal.pasham:matrix.org> quick question - is there a standard way to do stack allocations that are (say 2MB) aligned?
<re_irc>
<@henrik_alser:matrix.org> nihal.pasham:matrix.org: What do you mean 2MB aligned? You can mark a wrapper struct with something like `#[repr(align(4))]` to make sure it’s word aligned
<re_irc>
<@nihal.pasham:matrix.org> the way I figured - I have 2 options. Use a static but that's brings up problems like where in memory do I put my static
<re_irc>
<@nihal.pasham:matrix.org> and the other is simple stack allocation that satisfies the alignment requirement
<re_irc>
<@nihal.pasham:matrix.org> worse case - I'll have to resort to some `unsafe hackery` but before I do, just thought I'd ask around first.
<re_irc>
<@gdamjan:spodeli.org> nihal.pasham:matrix.org: perhaps define a custom section in memory.x
<re_irc>
<@nihal.pasham:matrix.org> thanks, that may just work. let me try editing the linker script.
<re_irc>
<@nihal.pasham:matrix.org> So, it worked finally and yep, Linux has a 2MB base-address alignment requirement. So, instead of relying on the stack for allocation, I edited the linker-script to add custom sections, one for each the dtb and kernel and it worked.
<re_irc>
<@nihal.pasham:matrix.org> Ps: the one thing I'll take away from this - rust's documentation is a godsend relative to pretty much everything out there (including Linux)
<re_irc>
<@gdamjan:spodeli.org> are you writing a bootloader? and what is it
<re_irc>
<@9names:matrix.org> > cant find a root fs. (there isn't one for now)
<re_irc>
<@9names:matrix.org> I usually cheat and build an initramfs into the kernel binary for bootstrapping
<re_irc>
<@9names:matrix.org> I guess it's not relevant since you're using a distro kernel, it should have all the drivers you need
<re_irc>
<@nihal.pasham:matrix.org> gdamjan:spodeli.org: Yes, it's called [rustBoot] (https://github.com/nihalpasham/rustBoot) . Still early days but the plan is to build plug and play support for a variety of architectures and boards
<re_irc>
<@nihal.pasham:matrix.org> 9names: Yeah, the first step was to get the kernel to boot and subsequently add an initrd fs
tokomak has joined #rust-embedded
<re_irc>
<@ubik:matrix.org> I got my hands on a CMSIS-DAP presumably from Keil (at least that's what the USB vendor id says)
<re_irc>
<@ubik:matrix.org> Is this supposed to work with probe-run?
<re_irc>
<@ubik:matrix.org> It doesn't seem like it detects it.
<re_irc>
<@adamgreig:matrix.org> Yea, it should work with all cmsis-dap devices. What OS? If you enable trace logging you should see output from probe-rs checking for probes
<re_irc>
<@adamgreig:matrix.org> Might be simpler with the probe-rs tools like cargo-flash or probe-rs-cli if you have those installed
<re_irc>
<@adamgreig:matrix.org> nihal.pasham: maybe you can use a static for both without a custom linker section but with the #[align(2097152)]
<re_irc>
<@adamgreig:matrix.org> (so they end up in BSS)
<re_irc>
<@ubik:matrix.org> adamgreig: Linux
<re_irc>
<@ubik:matrix.org> I added a udev rule, but that doesn't seem to help
<re_irc>
<@adamgreig:matrix.org> What's the rule, and did you restart udev and replug device after adding it?
<re_irc>
<@ubik:matrix.org> I did
<re_irc>
<@adamgreig:matrix.org> The verbose log output will show it considering each device and saying what it found so that's probably the best clue
<re_irc>
<@ubik:matrix.org> just `RUST_LOG=trace probe-run --list-probes` ?
<re_irc>
<@ubik:matrix.org> that doesn't seem to print anything else
<re_irc>
<@ubik:matrix.org> OK, `probe-rs-cli` does print something
<re_irc>
<@ubik:matrix.org> ` DEBUG probe_rs::probe::cmsisdap::tools > Found 0 CMSIS-DAP probes using libusb, searching HID`
<re_irc>
<@yatekii:matrix.org> did you restart/reload udev after adding the rule?
<re_irc>
<@yatekii:matrix.org> ah that was asked already lol sorry
<re_irc>
<@adamgreig:matrix.org> there should be a line in the log where it considers the VID/PID of your probe and rejects it
<re_irc>
<@adamgreig:matrix.org> so long as it's not a libusb problem
<re_irc>
<@nihal.pasham:matrix.org> adamgreig: Hmm, that would be ideal. I'll try it
<re_irc>
<@adamgreig:matrix.org> btw for udev I like this: `ATTRS{product}=="*CMSIS-DAP*", MODE="660", GROUP="plugdev", TAG+="uaccess"`
<re_irc>
<@adamgreig:matrix.org> it will allow users access to anything with CMSIS-DAP in the product ID
<re_irc>
<@ubik:matrix.org> `[ 8178.351718] hid-generic 0003:C251:F001.000D: hiddev96,hidraw1: USB HID v1.00 Device [CMSIS-DAP by ARM CMSIS_DAP] on usb-0000:00:14.0-1/input2`
<re_irc>
<@ubik:matrix.org> but probe-rs-cli doesn't mention it
<re_irc>
<@adamgreig:matrix.org> could you pastebin the full trace log?
tokomak has quit [Read error: Connection reset by peer]
<re_irc>
<@adamgreig:matrix.org> unusual for it to not find it via libusb or hidapi
<re_irc>
<@adamgreig:matrix.org> what if you try with `sudo`?
<re_irc>
<@adamgreig:matrix.org> though it seems like it should have succeeded with hidapi later anyway, which shouldn't generally have permissions problems
<re_irc>
<@adamgreig:matrix.org> might suggest probe-rs is deciding it's not a valid probe for some reason but i'd usually expect more helpful log messages in that case
<re_irc>
<@adamgreig:matrix.org> your device says "CMSIS_DAP" in the product string
<re_irc>
<@adamgreig:matrix.org> but the cmsis-dap specification says: "Note that "CMSIS-DAP" must be part of that string to allow identification by debuggers (or part of interface string for USB composite device)."
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@ubik:matrix.org> oh... I see, must have gotten a really crappy one
<re_irc>
<@adamgreig:matrix.org> but it's ARM's own probe??? the madness never ends lol
<re_irc>
<@adamgreig:matrix.org> but I wonder if this is arm being incredibly annoying
<re_irc>
<@ubik:matrix.org> I bought it off AliExpress
<re_irc>
<@adamgreig:matrix.org> technically this is a composite device with three interfaces and the final interface says "CMSIS-DAP-QYF"
<re_irc>
<@adamgreig:matrix.org> maybe that makes it compliant :/
<re_irc>
<@ubik:matrix.org> it's probably some chinese clone
<re_irc>
<@adamgreig:matrix.org> hmm maybe it's not really made by keil then lol
<re_irc>
<@ubik:matrix.org> i doubt it
<re_irc>
<@adamgreig:matrix.org> but I wonder if a clearer (and much more annoying) reading of the spec implies you don't need to say CMSIS-DAP in the product string if you say it in the interface string
<re_irc>
<@adamgreig:matrix.org> aw the muselab stuff is usually reasonable
<re_irc>
<@adamgreig:matrix.org> I guess it's a custom compile of the ARM DAPLINK firmware
<re_irc>
<@adamgreig:matrix.org> and their own hardware design
<re_irc>
<@ubik:matrix.org> maybe I should try flashing it with something else?
<re_irc>
<@adamgreig:matrix.org> I think these days you can build daplink with gcc (rather than needing keil) in which case I guess you could compile that but it seems a lot of bother
<re_irc>
<@adamgreig:matrix.org> ugh, how annoying!!
<re_irc>
<@adamgreig:matrix.org> I wonder......
<re_irc>
<@adamgreig:matrix.org> any idea what "version" you have?
<re_irc>
<@adamgreig:matrix.org> they seem to have firmwares 1.0, 2.0, 2.1, 2.3
<re_irc>
<@ubik:matrix.org> how do i get to know that?
<re_irc>
<@adamgreig:matrix.org> maybe it's written on the pcb
<re_irc>
<@adamgreig:matrix.org> I'm wondering if you could do something a bit gross and just take their .bin firmware file, patch the underscore to a hyphen, and reflash it
<re_irc>
<@ubik:matrix.org> nothing on the board
<re_irc>
<@adamgreig:matrix.org> alas
<re_irc>
<@ubik:matrix.org> (good practices)
<re_irc>
<@ubik:matrix.org> maybe I'll try that
<re_irc>
<@adamgreig:matrix.org> before you do
<re_irc>
<@adamgreig:matrix.org> maybe just clone probe-rs and tell it to also look for CMSIS_DAP
<re_irc>
<@ubik:matrix.org> ah, good point
<re_irc>
<@adamgreig:matrix.org> in probe-rs/probe-rs/src/probe/cmsisdap/tools.rs L65 and L127
<re_irc>
<@adamgreig:matrix.org> and L169 and L366
<re_irc>
<@ubik:matrix.org> yep
<re_irc>
<@adamgreig:matrix.org> does your PCB have an stm32f103c8t6 or stm32f103cbt6 ?
<re_irc>
<@adamgreig:matrix.org> (c8t6 / cbt6 at the end)
<re_irc>
<@ubik:matrix.org> cbt6
<re_irc>
<@ubik:matrix.org> seems like some clone of an STM
<re_irc>
<@ubik:matrix.org> CH32?
<re_irc>
<@ubik:matrix.org> wth
<re_irc>
<@adamgreig:matrix.org> probably the only thing left in stock
<re_irc>
<@adamgreig:matrix.org> all the firmware images available from that github repo have CMSIS-DAP instead of CMSIS_DAP as far as I can tell, and they all say "MuseLab" in their vendor strings instead of Keil/ARM
<re_irc>
<@adamgreig:matrix.org> so it seems like you're not running a firmware from that github, heh
<re_irc>
<@adamgreig:matrix.org> a few do say CMSIS-DAP by ARM, but seemingly none with an underscore...
<re_irc>
<@adamgreig:matrix.org> some say CMSIS-DAP-JYD but none say CMSIS-DAP-QYF either
<re_irc>
<@ubik:matrix.org> OK, same error as with the dash
<re_irc>
<@adamgreig:matrix.org> hmm, that's disappointing, even when you probe-rs-cli info --probe bla bla?
<re_irc>
<@ubik:matrix.org> yep
<re_irc>
<@ubik:matrix.org> anyway, maybe I should try flashing the official firmware then
<re_irc>
<@adamgreig:matrix.org> if the product string contains the matched thing it should at least spit out some more debug lines, so it might be your change hasn't taken effect somehow
<re_irc>
<@adamgreig:matrix.org> but yea, maybe it's easy to try one of their firmware images which seem to have the right product ID strings
<re_irc>
<@ubik:matrix.org> > plug the DAPLink into PC USB, a USB DISK named MAINTAINENCE will appear.
<re_irc>
<@ubik:matrix.org> NO IT WON'T 😭
<re_irc>
<@ubik:matrix.org> i guess that's what the unsolderer 4-pin header is for
tokomak has quit [Read error: Connection reset by peer]
<re_irc>
<@barafael:matrix.org> I've written a few simple embedded-hal drivers. I kept asking myself - what will happen if/when embedded hal will add non-blocking traits? Will all drivers need to be rewritten/adapted?
<re_irc>
<@barafael:matrix.org> is that rolling eyes, as the question has come up? Sorry :D
<re_irc>
<@ubik:matrix.org> no, it's "i'm interested" eyes
<re_irc>
<@ubik:matrix.org> (at least in my case)
<re_irc>
<@dngrs:matrix.org> Same
<re_irc>
<@mathias_koch:matrix.org> Quick question around HAL design.
<re_irc>
<@mathias_koch:matrix.org> For lots of reconfig stuff after initial setup, the issue always seems to resolve around getting access to clock configs.
<re_irc>
<@mathias_koch:matrix.org> But why would it not be an option to have static read only functions to obtain the currently configured sysclk, hclk, ahbX clk etc?
<re_irc>
<@dngrs:matrix.org> mathias_koch:matrix.org: I would love that
<re_irc>
<@dngrs:matrix.org> but also I'm a dummy with very little embedded background, so don't take my opinion as anything close to *informed*
<re_irc>
<@disasm-ewg:matrix.org> This idea sounds good to me as clock is kind of a global property of the system, and if we have access to separate peripherals from everywhere, why not to have access to clocks.
<re_irc>
<@dirbaio:matrix.org> embassy-stm32 stores all clock config in a global, so anything that needs it (like setting UART baudrate) can do it without the user having to pass a `Clocks` struct around
<re_irc>
<@disasm-ewg:matrix.org> This would also open possibilities for clock reconfiguration, this way user will only have to notify peripherals about clock update, without passing new clock values everywhere
<re_irc>
<@mathias_koch:matrix.org> disasm-ewg:matrix.org: This part sounds a bit more elaborate, but the first step of just reading the current clock configs would probably solve reconfiguring most other peripherals on that front
<re_irc>
<@dirbaio:matrix.org> you can't calc absolute clock freqs from just the RCC registers
<re_irc>
<@dirbaio:matrix.org> for example, if RCC is configured so "sysclk = HSE * whatever"
<re_irc>
<@disasm-ewg:matrix.org> Yes, but you can store all the required clocks in global static variables
<re_irc>
<@dirbaio:matrix.org> you can know what "whatever" multiplier you have, but the HSE depends on what actual crystal is mounted on the board, which is up to the board designer
<re_irc>
<@dirbaio:matrix.org> so at the very least you have to ask the user "what HSE do we have?"
<re_irc>
<@mathias_koch:matrix.org> Sure thing.. But just storing the HSE value in global static should be enough, right?
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> but if you gotta store that, you might as well store all the already-calculated freqs to avoid doing register reads and maths every time
<re_irc>
<@firefrommoonlight:matrix.org> See `hclk_prescaler()`, `apb2prescaler()` etc
<re_irc>
<@firefrommoonlight:matrix.org> mathias_koch:matrix.org: Agree. Freeze is based on the assumption that config doesn't change after initial setup, which may not be true
<re_irc>
<@firefrommoonlight:matrix.org> Btw, if anyone has ideas on hosting docs pages for multiple features flags, I'm all ears. That page I linked is for L4x3. Eg someone trying to see the docs for H7 clocks is out of luck unless they build locally
<re_irc>
<@firefrommoonlight:matrix.org> Maybe get a web server and self-host? Would need a script etc that auto builds, or new releases would be too cumbersome
<re_irc>
<@dirbaio:matrix.org> firefrommoonlight:matrix.org: i'm trying to build that for embassy as we speak lol 🤣
<re_irc>
<@firefrommoonlight:matrix.org> May I steal?!!
<re_irc>
<@dirbaio:matrix.org> I'm doing it the ugly bruteforce way though... basically `foreach feature: cargo doc --features $feature` and stick that in a webserver
<re_irc>
<@firefrommoonlight:matrix.org> Related: For situations like this, does it matter what feature flags you pass when running`cargo package`, `cargo publish` etc?
<re_irc>
<@dirbaio:matrix.org> no, package/publish don't use features
<re_irc>
<@firefrommoonlight:matrix.org> dirbaio:matrix.org: Well... It shouldn't be too hard to make a BASH script, python script etc
<re_irc>
<@firefrommoonlight:matrix.org> Or a Rust binary if you want!
xnor has quit [Ping timeout: 256 seconds]
<re_irc>
<@dirbaio:matrix.org> but doing that for every single one of the 1200 stm32 chips generates like 100gb of output
<re_irc>
<@firefrommoonlight:matrix.org> So, pick one or 2 from each family
<re_irc>
<@firefrommoonlight:matrix.org> Automate whatever it is that's taking up time with your manual approach
<re_irc>
<@firefrommoonlight:matrix.org> 1 per family would be way better than 1 for teh whole thing
<re_irc>
<@dirbaio:matrix.org> yeah... but the thing is stm32-metapac is way more granular than stm32-rs pacs
<re_irc>
<@dirbaio:matrix.org> for example, stm32-rs has a single `stm32f103` feature
<re_irc>
<@dirbaio:matrix.org> stm32-metapac has one for each chip
<re_irc>
<@firefrommoonlight:matrix.org> I don't understand the details of this situation, but surely you can find a way to pick an arbitrary chip per family right?
<re_irc>
<@dirbaio:matrix.org> and it does matter, for example STM32F103C8 doesn't have UART5, STM32F103VG does have it
<re_irc>
<@firefrommoonlight:matrix.org> You don't need perfect. Just better
<re_irc>
<@dirbaio:matrix.org> in stm32f1 if you use the `stm32f103` feature you do get the `UART5` singleton, but if you try to use it in `STM32F103C8` it compiles, but fails to work
<re_irc>
<@firefrommoonlight:matrix.org> Eg, the clock doc I posted is mostly relevant for anything in the L or G, or W series', but totally off for H7 or F3/4
<re_irc>
<@firefrommoonlight:matrix.org> So, having just 3 variants alone would IMO be a big improvement
<re_irc>
<@dirbaio:matrix.org> and I want people to be able to see that in the docs...
<re_irc>
<@firefrommoonlight:matrix.org> You don't need perfect. Just better
<re_irc>
<@firefrommoonlight:matrix.org> (I'm saying this as someone who's too lazy to do this lol)
<re_irc>
<@dirbaio:matrix.org> I'm too perfectionist 🙈
<re_irc>
<@firefrommoonlight:matrix.org> Nah. You wouldn't have gotten embassy off the ground near-solo if that was true
<re_irc>
<@dirbaio:matrix.org> so I'm currently fighting the thing, to deduplicate identical html files and compress the whole thing 🤣
<re_irc>
<@dirbaio:matrix.org> I got it from 100gb to 7mb lol
<re_irc>
<@firefrommoonlight:matrix.org> I should just try this. What are you using to host?
<re_irc>
<@firefrommoonlight:matrix.org> Why are the docs so big; just a handfull of HTML pages right?
<re_irc>
<@adamgreig:matrix.org> "just"
<re_irc>
<@firefrommoonlight:matrix.org> I've never messed with docs outside of `cargo publish`
<cr1901>
>in stm32f1 if you use the `stm32f103` feature you do get the `UART5` singleton
<re_irc>
<@adamgreig:matrix.org> the stm32ral doc build is 1.2 million html files for example
<cr1901>
What is "stm32f1" referring to?
<re_irc>
<@adamgreig:matrix.org> and that's not even close to the number in all combinations of stm32-metapac
<re_irc>
<@david:lenfesty.ca> I've heard from the docs folks that the stm-rs docs are some of the most comprehensive stress-testers they have
<re_irc>
<@adamgreig:matrix.org> i feel so bad every time i publish 😬
<re_irc>
<@adamgreig:matrix.org> it has gotten better over time, but all the crates had to ask for special increased limits, and even then I only have docs.rs build 3-4 chips per crate instead of all of them
<re_irc>
<@adamgreig:matrix.org> stm32ral found out that their new compressed file format couldn't handle >64k files per archive... by having 1.2M files, lol
<re_irc>
<@adamgreig:matrix.org> dread to think what the distribution of number of files looks like... "almost the entire rust ecosystem" in the 1-10000 bin, and stm32ral allllll the way to the right with 1.2M
<re_irc>
<@firefrommoonlight:matrix.org> I went from "I'm going to do it!" to *slowly backing away* over this convo
<re_irc>
<@firefrommoonlight:matrix.org> "Just go skim the source code or something if you're using a different variant"
<cr1901>
Do STM32 PACs still have horrific compile times?
<re_irc>
<@adamgreig:matrix.org> i don't think so?
<re_irc>
<@adamgreig:matrix.org> it's been getting better and better and better
<re_irc>
<@sajattack:matrix.org> is there anything available in the ecosystem for usb host yet? specifically on a STM32F401
<re_irc>
<@dngrs:matrix.org> no - some discussions recently in #usb-rs:matrix.org
<re_irc>
<@dngrs:matrix.org> I am interested in support on the same platform, I think I might try to take tinyusb as a first approach - written in C though and its host support is also kinda rudimentary. No idea how viable
<re_irc>
<@sajattack:matrix.org> K, I have a friend struggling with stm32cube ide and was wondering if we even had an option to save him :P
<re_irc>
<@dngrs:matrix.org> oh, does Cube HAL have USB host support?
<re_irc>
<@sajattack:matrix.org> It looks like it
<re_irc>
<@dngrs:matrix.org> nice! But I suppose it requires FreeRTOS or something?
<re_irc>
<@sajattack:matrix.org> would you know anything about hid host in stm32duino? He's a beginner and would be happier in that environment if there's anything available
<re_irc>
<@dngrs:matrix.org> nope, never really worked with anything arduino - closest I got was platformio, but that was exclusively FastLED stuff
<re_irc>
<@sajattack:matrix.org> ok thanks anyway
<re_irc>
<@dkhayes117:matrix.org> adamgreig: I've added `asm::nop`, `asm::delay`,`delay::McycleDelay` to the `riscv` crate. They aren't released yet, but usable as a toml patch. 🙂
<re_irc>
<@adamgreig:matrix.org> yay, thank you!
<re_irc>
<@dkhayes117:matrix.org> Sure, no problem. I like helping however I can.
<re_irc>
<@adamgreig:matrix.org> for delay_ms, a good trick is to call delay_us in a loop 1000 times, instead of calling it once with ms*1000
<re_irc>
<@adamgreig:matrix.org> then you can keep it a u32
<re_irc>
<@adamgreig:matrix.org> though I guess if delay_us already works for a u64 it doesn't make much difference
<re_irc>
<@adamgreig:matrix.org> also, I wonder if `delay` might be safe? and `nop` I guess but dunno if you have a way to make those instructions safe
<re_irc>
<@dkhayes117:matrix.org> Not sure. It would be nice if they were though.
<re_irc>
<@adamgreig:matrix.org> anyway the new `delay()` method works on my soft-core :D
<re_irc>
<@adamgreig:matrix.org> i don't think this implementation has an mcycle register though...
<re_irc>
<@adamgreig:matrix.org> trying to use McycleDelay brings my firmware from 924 bytes to 3132 bytes 😅
<re_irc>
<@adamgreig:matrix.org> but, it does run! so I guess it must have such a register
<re_irc>
<@dkhayes117:matrix.org> Wow, quite a bit of fluff added.
<re_irc>
<@adamgreig:matrix.org> looks like it's all software divide and multiply routines
<re_irc>
<@adamgreig:matrix.org> probably the delay_us 64-bit div and mul
<re_irc>
<@adamgreig:matrix.org> luckily I have 4kB of program memory so it still fits :P
<re_irc>
<@dngrs:matrix.org> adamgreig: you nailed it, flipping (ha) these two lines fixed it!
<re_irc>
<@dngrs:matrix.org> will raise this with knurling
<re_irc>
<@adamgreig:matrix.org> nice, makes sense