starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
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> <> quick question - is there a standard way to do stack allocations that are (say 2MB) aligned?
<re_irc> <> 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> <> I'm trying to load the linux kernel into memory. physical placement of arm64 kernels must be 2MB aligned (I believe that's a hard requirement)
<re_irc> <> 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> <> and the other is simple stack allocation that satisfies the alignment requirement
<re_irc> <> worse case - I'll have to resort to some `unsafe hackery` but before I do, just thought I'd ask around first.
<re_irc> <> perhaps define a custom section in memory.x
<re_irc> <> thanks, that may just work. let me try editing the linker script.
<re_irc> <> 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> <> [The kernel takes control]( and panics as it cant find a root fs. (there isn't one for now). gdamjan thanks for the tip πŸ™‚
<re_irc> <> 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> <> are you writing a bootloader? and what is it
<re_irc> <> > cant find a root fs. (there isn't one for now)
<re_irc> <> I usually cheat and build an initramfs into the kernel binary for bootstrapping
<re_irc> <> I guess it's not relevant since you're using a distro kernel, it should have all the drivers you need
<re_irc> <> Yes, it's called [rustBoot] ( . Still early days but the plan is to build plug and play support for a variety of architectures and boards
<re_irc> <> 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> <> I got my hands on a CMSIS-DAP presumably from Keil (at least that's what the USB vendor id says)
<re_irc> <> Is this supposed to work with probe-run?
<re_irc> <> It doesn't seem like it detects it.
<re_irc> <> 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> <> Might be simpler with the probe-rs tools like cargo-flash or probe-rs-cli if you have those installed
<re_irc> <> nihal.pasham: maybe you can use a static for both without a custom linker section but with the #[align(2097152)]
<re_irc> <> (so they end up in BSS)
<re_irc> <> adamgreig: Linux
<re_irc> <> I added a udev rule, but that doesn't seem to help
<re_irc> <> What's the rule, and did you restart udev and replug device after adding it?
<re_irc> <> I did
<re_irc> <> The verbose log output will show it considering each device and saying what it found so that's probably the best clue
<re_irc> <> `SUBSYSTEM=="usb", ATTR{idVendor}=="c251", ATTR{idProduct}=="f001", MODE:="0666"`
<re_irc> <> just `RUST_LOG=trace probe-run --list-probes` ?
<re_irc> <> that doesn't seem to print anything else
<re_irc> <> OK, `probe-rs-cli` does print something
<re_irc> <> ` DEBUG probe_rs::probe::cmsisdap::tools > Found 0 CMSIS-DAP probes using libusb, searching HID`
<re_irc> <> did you restart/reload udev after adding the rule?
<re_irc> <> ah that was asked already lol sorry
<re_irc> <> there should be a line in the log where it considers the VID/PID of your probe and rejects it
<re_irc> <> so long as it's not a libusb problem
<re_irc> <> adamgreig: Hmm, that would be ideal. I'll try it
<re_irc> <> btw for udev I like this: `ATTRS{product}=="*CMSIS-DAP*", MODE="660", GROUP="plugdev", TAG+="uaccess"`
<re_irc> <> it will allow users access to anything with CMSIS-DAP in the product ID
<re_irc> <> `[ 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> <> but probe-rs-cli doesn't mention it
<re_irc> <> could you pastebin the full trace log?
tokomak has quit [Read error: Connection reset by peer]
<re_irc> <> unusual for it to not find it via libusb or hidapi
<re_irc> <> not very useful output
<re_irc> <> lemme try on the mac
<re_irc> <> hm... doesn't worj
<re_irc> <> you could try with `RUST_LOG=trace probe-rs-cli info --probe c251:f001` maybe
<re_irc> <> that's more informative:
tokomak has joined #rust-embedded
<re_irc> <> ` TRACE probe_rs::probe::cmsisdap::tools > Trying device Bus 001 Device 007: ID c251:f001
<re_irc> <> TRACE probe_rs::probe::cmsisdap::tools > Error opening: Access` hmmm
<re_irc> <> what if you try with `sudo`?
<re_irc> <> though it seems like it should have succeeded with hidapi later anyway, which shouldn't generally have permissions problems
<re_irc> <> 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> <> in any event the access error when trying with libusb suggests some kind of permissions problem
<re_irc> <> hm, no access error, but no further information
<re_irc> <> not very helpful of it lol
<re_irc> <> could you try `lsusb -vv -d c251:f001` ?
<re_irc> <> urghhhhh
<re_irc> <> your device says "CMSIS_DAP" in the product string
<re_irc> <> 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> <> hmm
<re_irc> <> oh... I see, must have gotten a really crappy one
<re_irc> <> but it's ARM's own probe??? the madness never ends lol
<re_irc> <> but I wonder if this is arm being incredibly annoying
<re_irc> <> I bought it off AliExpress
<re_irc> <> technically this is a composite device with three interfaces and the final interface says "CMSIS-DAP-QYF"
<re_irc> <> maybe that makes it compliant :/
<re_irc> <> it's probably some chinese clone
<re_irc> <> hmm maybe it's not really made by keil then lol
<re_irc> <> i doubt it
<re_irc> <> 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> <> they link to this on the seller's page:
<re_irc> <> that's super annoying though, you can't read the interface strings via hidapi
<re_irc> <> ah, in english:
<re_irc> <> aw the muselab stuff is usually reasonable
<re_irc> <> I guess it's a custom compile of the ARM DAPLINK firmware
<re_irc> <> and their own hardware design
<re_irc> <> maybe I should try flashing it with something else?
<re_irc> <> 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> <> ugh, how annoying!!
<re_irc> <> I wonder......
<re_irc> <> any idea what "version" you have?
<re_irc> <> they seem to have firmwares 1.0, 2.0, 2.1, 2.3
<re_irc> <> (hardware version)
<re_irc> <> how do i get to know that?
<re_irc> <> maybe it's written on the pcb
<re_irc> <> 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> <> nothing on the board
<re_irc> <> alas
<re_irc> <> (good practices)
<re_irc> <> maybe I'll try that
<re_irc> <> before you do
<re_irc> <> maybe just clone probe-rs and tell it to also look for CMSIS_DAP
<re_irc> <> ah, good point
<re_irc> <> in probe-rs/probe-rs/src/probe/cmsisdap/ L65 and L127
<re_irc> <> and L169 and L366
<re_irc> <> yep
<re_irc> <> does your PCB have an stm32f103c8t6 or stm32f103cbt6 ?
<re_irc> <> (c8t6 / cbt6 at the end)
<re_irc> <> cbt6
<re_irc> <> seems like some clone of an STM
<re_irc> <> CH32?
<re_irc> <> wth
<re_irc> <> probably the only thing left in stock
<re_irc> <> 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> <> so it seems like you're not running a firmware from that github, heh
<re_irc> <> a few do say CMSIS-DAP by ARM, but seemingly none with an underscore...
<re_irc> <> some say CMSIS-DAP-JYD but none say CMSIS-DAP-QYF either
<re_irc> <> OK, same error as with the dash
<re_irc> <> hmm, that's disappointing, even when you probe-rs-cli info --probe bla bla?
<re_irc> <> yep
<re_irc> <> anyway, maybe I should try flashing the official firmware then
<re_irc> <> 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> <> but yea, maybe it's easy to try one of their firmware images which seem to have the right product ID strings
<re_irc> <> > plug the DAPLink into PC USB, a USB DISK named MAINTAINENCE will appear.
<re_irc> <> NO IT WON'T 😭
<re_irc> <> i guess that's what the unsolderer 4-pin header is for
tokomak has quit [Read error: Connection reset by peer]
<re_irc> <> πŸ₯³
<re_irc> <> hurray!
<re_irc> <> does it work?
<re_irc> <> at least it's detected
<re_irc> <> hm... `Probe(ArchitectureSpecific(DebugProbe(ArchitectureSpecific(NoAcknowledge))))`
<re_irc> <> maybe I'm connecting something wrong
<re_irc> <> it's an rpi pico, so i'm doing SWCLK <-> TCK/CK, SWDIO <-> TMS/IO, GND <-> GND
<re_irc> <> ah, but probe-run works
<re_irc> <> funny
<re_irc> <> uhm... OpenOCD is still broken
<re_irc> <> `Warn : could not claim interface: Resource busy`
<re_irc> <> `Error: error reading data: Input/Output Error` (like, many times)
<re_irc> <> 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> <> is that rolling eyes, as the question has come up? Sorry :D
<re_irc> <> no, it's "i'm interested" eyes
<re_irc> <> (at least in my case)
<re_irc> <> Same
<re_irc> <> Quick question around HAL design.
<re_irc> <> For lots of reconfig stuff after initial setup, the issue always seems to resolve around getting access to clock configs.
<re_irc> <> 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> <> ```rust
<re_irc> <> I would love that
<re_irc> <> but also I'm a dummy with very little embedded background, so don't take my opinion as anything close to *informed*
<re_irc> <> 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> <> 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> <> 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> <> 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> <> you can't calc absolute clock freqs from just the RCC registers
<re_irc> <> for example, if RCC is configured so "sysclk = HSE * whatever"
<re_irc> <> Yes, but you can store all the required clocks in global static variables
<re_irc> <> 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> <> so at the very least you have to ask the user "what HSE do we have?"
<re_irc> <> Sure thing.. But just storing the HSE value in global static should be enough, right?
<re_irc> <> yeah
<re_irc> <> 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> <> macro? build script?
<re_irc> <> huh?
<re_irc> <> [features]
<re_irc> <> hse_is_8mhz = []
<re_irc> <> hse_is_25mhz = []
<re_irc> <> I believe some people have tried "fully const RCC" before
<re_irc> <> could there be some pre-processing step which sets all those values based on input provided through e.g. a macro?
<re_irc> <> I don't think a fully const RCC makes sense, but RCC with a generic const HSE would probably make great sense
<re_irc> <> using features like that could be limiting if you want to calculate that at runtime
<re_irc> <> (or const generics / macros / buildscripts)
<re_irc> <> like, read some GPIO to know which board revision you have, becuase some ahve 8mhz HSE and others have 16mhz HSE
<re_irc> <> I already dont like the `freeze` pattern, as it limits setup to init time
<re_irc> <> exactly
<re_irc> <> I think const RCC is an orthogonal topic
<re_irc> <> true
<re_irc> <> There are at least two hals that implement const RCC, both return traditional `Clocks` in the end.
<re_irc> <> Anyone doing GDB debugging with a CMSIS-DAP probe? What are you using? OpenOCD? PyOCD?
<re_irc> <> probe-rs also supports gdb debugging, so I usually use that or pyocd
<re_irc> <> (use cargo-embed and enable gdb in Embed.toml)
<re_irc> <>
<re_irc> <> See `hclk_prescaler()`, `apb2prescaler()` etc
<re_irc> <> Agree. Freeze is based on the assumption that config doesn't change after initial setup, which may not be true
<re_irc> <> 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> <> 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> <> i'm trying to build that for embassy as we speak lol 🀣
<re_irc> <> May I steal?!!
<re_irc> <> I'm doing it the ugly bruteforce way though... basically `foreach feature: cargo doc --features $feature` and stick that in a webserver
<re_irc> <> Related: For situations like this, does it matter what feature flags you pass when running`cargo package`, `cargo publish` etc?
<re_irc> <> no, package/publish don't use features
<re_irc> <> Well... It shouldn't be too hard to make a BASH script, python script etc
<re_irc> <> Or a Rust binary if you want!
xnor has quit [Ping timeout: 256 seconds]
<re_irc> <> but doing that for every single one of the 1200 stm32 chips generates like 100gb of output
<re_irc> <> So, pick one or 2 from each family
<re_irc> <> Automate whatever it is that's taking up time with your manual approach
<re_irc> <> 1 per family would be way better than 1 for teh whole thing
<re_irc> <> yeah... but the thing is stm32-metapac is way more granular than stm32-rs pacs
<re_irc> <> for example, stm32-rs has a single `stm32f103` feature
<re_irc> <> stm32-metapac has one for each chip
<re_irc> <> 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> <> and it does matter, for example STM32F103C8 doesn't have UART5, STM32F103VG does have it
<re_irc> <> You don't need perfect. Just better
<re_irc> <> 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> <> 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> <> So, having just 3 variants alone would IMO be a big improvement
<re_irc> <> and I want people to be able to see that in the docs...
<re_irc> <> You don't need perfect. Just better
<re_irc> <> (I'm saying this as someone who's too lazy to do this lol)
<re_irc> <> I'm too perfectionist πŸ™ˆ
<re_irc> <> Nah. You wouldn't have gotten embassy off the ground near-solo if that was true
<re_irc> <> so I'm currently fighting the thing, to deduplicate identical html files and compress the whole thing 🀣
<re_irc> <> I got it from 100gb to 7mb lol
<re_irc> <> I should just try this. What are you using to host?
<re_irc> <> Why are the docs so big; just a handfull of HTML pages right?
<re_irc> <> "just"
<re_irc> <> 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> <> the stm32ral doc build is 1.2 million html files for example
<cr1901> What is "stm32f1" referring to?
<re_irc> <> and that's not even close to the number in all combinations of stm32-metapac
<re_irc> <> holy fuck
<re_irc> <> the htmls are super verbose, and if you multiply that by 1200 chips, well...
<re_irc> <> the cargo doc output from an svd2rust crate is sooo big
<re_irc> <> the metapac at least generates much smaller output right
<re_irc> <> smaller, but still too big
<re_irc> <> cr1901:
<re_irc> <> πŸ”₯
<cr1901> ahhh
<re_irc> <> I've heard from the docs folks that the stm-rs docs are some of the most comprehensive stress-testers they have
<re_irc> <> i feel so bad every time i publish 😬
<re_irc> <> it has gotten better over time, but all the crates had to ask for special increased limits, and even then I only have build 3-4 chips per crate instead of all of them
<re_irc> <> stm32ral found out that their new compressed file format couldn't handle >64k files per archive... by having 1.2M files, lol
<re_irc> <> 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> <> I went from "I'm going to do it!" to *slowly backing away* over this convo
<re_irc> <> "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> <> i don't think so?
<re_irc> <> it's been getting better and better and better
<cr1901> Last I checked was late 2019
<re_irc> <> I should update this chart but
<re_irc> <> firefrommoonlight: don't let me put you off! for the hal it should be way better than the PACs too
<re_irc> <> just give it a go locally to generate html, once you have the html hosting it's not too bad i think
<re_irc> <> Good call. Break it down into small steps
<re_irc> <> > for the hal it should be way better than the PACs too
<re_irc> <> embassy-stm32 generates impls for pins/peripherals from the PAC data so it also has 1200 chip features 🀣 😭
rardiol has joined #rust-embedded
Foxyloxy_ has quit [Quit: Textual IRC Client:]
<re_irc> <> is there anything available in the ecosystem for usb host yet? specifically on a STM32F401
<re_irc> <> no - some discussions recently in
<re_irc> <> 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> <> K, I have a friend struggling with stm32cube ide and was wondering if we even had an option to save him :P
<re_irc> <> oh, does Cube HAL have USB host support?
<re_irc> <> It looks like it
<re_irc> <> nice! But I suppose it requires FreeRTOS or something?
<re_irc> <> no idea
<re_irc> <> maybe not… but had a brief look at the source and ugh, I just can't with Cube HAL
<re_irc> <> haha
<re_irc> <> he sent me this screenshot of the cube configurator
Foxyloxy has joined #rust-embedded
<re_irc> <> 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> <> nope, never really worked with anything arduino - closest I got was platformio, but that was exclusively FastLED stuff
<re_irc> <> ok thanks anyway
<re_irc> <> 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> <> yay, thank you!
<re_irc> <> Sure, no problem. I like helping however I can.
<re_irc> <> 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> <> then you can keep it a u32
<re_irc> <> though I guess if delay_us already works for a u64 it doesn't make much difference
<re_irc> <> 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> <> Not sure. It would be nice if they were though.
<re_irc> <> anyway the new `delay()` method works on my soft-core :D
<re_irc> <> i don't think this implementation has an mcycle register though...
<re_irc> <> trying to use McycleDelay brings my firmware from 924 bytes to 3132 bytes πŸ˜…
<re_irc> <> but, it does run! so I guess it must have such a register
<re_irc> <> Wow, quite a bit of fluff added.
<re_irc> <> looks like it's all software divide and multiply routines
<re_irc> <> probably the delay_us 64-bit div and mul
<re_irc> <> luckily I have 4kB of program memory so it still fits :P
<re_irc> <> adamgreig: you nailed it, flipping (ha) these two lines fixed it!
<re_irc> <> will raise this with knurling
<re_irc> <> nice, makes sense