<Ralph[m]>
<TomB[m]> "its not like there's a simple..." <- 🤫 don't mention the rust-for-linux DMA topic 😅
<TomB[m]>
That whole thing was bound to happen seemingly and it’s I think clear now where Linus and Greg stand after the kerfuffle, unfortunate but par for the course seemingly in Linux history…
sroemer__ has quit [Quit: WeeChat 4.4.3]
<TomB[m]>
Btw redox Just Worked on my thinkpad the other day, kind of promising and cool to see
<TomB[m]>
So maybe one day…
<whitequark[cis]>
didn't linus eventually force the dma subsystem maintainer to accept some form of rust api for it?
Arty is now known as Artea
kaoD has joined #rust-embedded
<thejpster[m]>
I think he said "maintain it, or don't block it. You can't block anything you don't maintain".
<thejpster[m]>
I don't know if it got merged
SEGFAULT[m] has joined #rust-embedded
<SEGFAULT[m]>
Some annoying embassy Questions:
<SEGFAULT[m]>
Would it be posssible to use this crate https://crates.io/crates/cap with embassy's allocator to monitor heap usage and prevent stack smashing?
<SEGFAULT[m]>
Is there a fixed size for embassy's CPU0 stack?
<JamesMunns[m]>
in general in embedded, stacks are "whatever RAM you don't use for statics"
<JamesMunns[m]>
there's no fixed size
<JamesMunns[m]>
preventing stack smashing requires creative linking, like with flip-link, or using an MPU to create a guard page, or using newer thumbv8 features like stack limits
<JamesMunns[m]>
and most applications don't use a heap at all, you might be able to use `cap` if it doesn't require `std`, and only `alloc`.
<SEGFAULT[m]>
<JamesMunns[m]> "and most applications don't..." <- I got curious so I just wrote a global allocator that on all call to alloc will print the request then panic! It is currently running without panicking, so unless I missed something it seems that everything I have embassy doing rn (USB, logging, PIO, various bus transfers, nothing as every attempted to may a dynamic memory request
<JamesMunns[m]>
correct
<JamesMunns[m]>
unless they say otherwise, nearly no embedded crates use alloc out of the box
<SEGFAULT[m]>
I am impressed I was sure the log crate at the very least would need alloc
<JamesMunns[m]>
(not universally true, but it's fairly unusual in "built for embedded" crates, vs "happens to work on embedded" crates)
<SEGFAULT[m]>
well "log" isn't a dedicated embedded crate
<SEGFAULT[m]>
that said I don't know where the fmt machinery is being implemented
<JamesMunns[m]>
it's in core itself
<diondokter[m]>
log is just a facade. The implementation you're using to make log actually do things is purposely built for embedded
<JamesMunns[m]>
basically, if you have a no-std app, and you DON'T define a global allocator, you KNOW none of your deps ever allocate
<JamesMunns[m]>
(there's no automatic/built-in malloc)
<SEGFAULT[m]>
on the topic of log, I would like to try out defmt at some point but I couldn't figure out how to set it up on the RP2040 last time I tried
<SEGFAULT[m]>
I did all that but I think thats assuming you're debugging over SWD. I only have USB rn
<JamesMunns[m]>
ah, there are other crates, defmt-rtt is indeed the SWD transport, maybe someone else knows a USB one.
<SEGFAULT[m]>
I need to get one of those adapters for SWD programming that support the RP20 series, but it hasn't been high priority
<JamesMunns[m]>
SEGFAULT[m]: if you have a second rp2040, you can turn it into an SWD adapter 😛
<danielb[m]>
JamesMunns[m]: technically it's any debug interface, and technically JTAG can go through some ESP USB magic, so technically defmt-rtt can be usb ;)
<SEGFAULT[m]>
that was a tad jank for me, I travel with this stuff a lot,
<JamesMunns[m]>
I should make a defmt-prpc crate for shoveling defmt data over a postcard-rpc link for USB folks :p
<korbin[m]>
SEGFAULT[m]: rust-dap is so much better than my segger
<korbin[m]>
i almost never use it
<korbin[m]>
the pico CMSIS DAP probe is the way to go, make a case for it
<ckrenslehner[m]>
this should log to a serial, maybe this helps
<MartinSivk[m]>
korbin: My experience with cheap DAP probes is not great, the speed is bad (the hsprobe is not really available anywhere). STLink was better and my blackmagic probe is working much better than any probe-rs tool I have tried.
<korbin[m]>
MartinSivk[m]: what kind of speed is it you are looking for exactly? the PIO-based rust pico DAP will max out any MCU i've ever used it on
<korbin[m]>
my expensive segger is not as fast
<korbin[m]>
(the non-PIO pico probe is not fast)
<MartinSivk[m]>
Hmm, I have no rp2040 at home, maybe I could try. Generally I want at least USB high speed (2.0) for the transfers.
<MartinSivk[m]>
The cheap DAP stuff I have was definitely slow
<korbin[m]>
are you clocking SWD at >10MHz?
<korbin[m]>
what chip is that possible on?
<MartinSivk[m]>
(and cheap)
<korbin[m]>
the blackmagic probe has a gigadevice STM F103 clone on it - it has USB FS
<MartinSivk[m]>
USB 1 has a theoretical limit of 12 MHz right? But that is the bus itself with all the devices on it. The upload was not the issue as I recall, but the RTT interaction was.
<MartinSivk[m]>
korbin: It is not blazing fast, but it is not killing my software timing like the DAP was. Not sure why that was the case, but it was.
<korbin[m]>
MartinSivk[m]: USB FS clocks at 12MHz, i forget what the actual practical max with protocol is specifically but it's like 8mbit
<korbin[m]>
USB HS is 480MHz
<MartinSivk[m]>
SWD on STLink V3 can do up to 24 MHz, my cpus are not that fast though
<korbin[m]>
MartinSivk[m]: can it *actually* do this on the target, though?
<korbin[m]>
i've just never found a target that can be this fast for SWD specifically
<korbin[m]>
JTAG FPGA targets can absolutely be 50mbit+, but SWD is a slower beast in my experience
<korbin[m]>
(i spent a year doing USB->JTAG stuff, this is kind of my thing)
<MartinSivk[m]>
According to the docs it can (STM32F7?), but on my L031 definitely not
<korbin[m]>
there's no way that the gigadevice STM clone (or even a real STM clone) can compete with the RP2040 PIO for SWD in terms of speed from USB because of the DIR turnarounds
<korbin[m]>
s/clone/F-series chip/
<korbin[m]>
even on an STM HS USB chip, honestly, the turnarounds will absolutely smoke your max speed because you are effectively bitbanging it
<MartinSivk[m]>
Yeah PIO looks nice, I haven't had the pleasure using it yet though
<korbin[m]>
with JTAG you can do clever things like use an SPI peripheral for long sequences
<korbin[m]>
(and then bitbang the TMS interactions)
<MartinSivk[m]>
I think the bit banging is the reason why the cheap probes are so solow
<korbin[m]>
how would an STLink do it without bitbanging?
<korbin[m]>
i used FlexIO in the NXP IMXRT10xx for 60mbit JTAG w/ USB HS
<korbin[m]>
(in the ST, there might be a suitable GPIO DMA mode but i am not aware of one that can handle the DIR turnaround logic)
<MartinSivk[m]>
STLink probably uses bit banging, but at least reasonably written. The cheap (like really cheap) DAP probes I have here are nowhere that fast. So probably bit banging and badly written?
<korbin[m]>
(i've done 50MHz+ SPI on the PIO and SPI peripherals in the RP2040 - you are limited by USB FS for this application actually)
<MartinSivk[m]>
Yeah, I am probably just comparing bad with worse, because I never had such high speed devices
<korbin[m]>
(but yeah, have faith that the $2 pico dap is really, really good, beyond my commercial tools including STLinks onboard NUCLEO EVKs - no idea about standalone)
<korbin[m]>
i could make a DAP probe for the USB HS NXP IMXRT via FlexIO (like i did with JTAG), but i've just never felt like it was necessary
<JamesMunns[m]>
<MartinSivk[m]> "USB 1 has a theoretical limit of..." <- (this is slightly less true, modern USB hubs will typically have MTTs on each port, meaning that each FS device on a HS/SS hub will be able to use the full 12mbps, it does still depend on your actual hub tho)
<JamesMunns[m]>
yeah, sorry, still minus protocol overhead
<JamesMunns[m]>
but not like /4 if there are four devices connected to the hub
<korbin[m]>
yeah, most of the nice new hubs have MTTs, older cheap chinese off-brand hubs don't
<korbin[m]>
the USB2514/USB2534 and all of the WCH ones are MTT afaik
<JamesMunns[m]>
heh, I was pleasantly surprised the CH334F had MTTs on each port, and it's a jellybean at this point
<JamesMunns[m]>
there's probably a lot of existing designs that don't have it tho
<korbin[m]>
yeah the FE1.1s is STT and common
<korbin[m]>
FE2.1 is MTT
ello has quit [Ping timeout: 248 seconds]
ello_ has quit [Ping timeout: 248 seconds]
<i509vcb[m]>
<korbin[m]> "i could make a DAP probe for the..." <- This happens to be part of the thing I am working on
<korbin[m]>
i509vcb[m]: i implemented the FTDI MPSSE protocol technically, but not CMSIS-DAP - CMSIS-DAP will be much faster and easier to do
<korbin[m]>
CDC-ACM is much nicer
<korbin[m]>
the one thing that is shitty is that the EHCI controller is not DMA-capable (it does its own "DMA" to your memory slab because EHCI, but it doesn't have peripheral trigger capability)
<korbin[m]>
* trigger capability for the full DMA core)
<i509vcb[m]>
From what I can tell, I can use the flexio for multiple separate things assuming I sub-allocate the resources there
<korbin[m]>
i509vcb[m]: just be aware of how the parallel bus shit works if you need it
<i509vcb[m]>
The only bidirectional bit is JTAG/swd
<korbin[m]>
there are restrictions on specific pins and shifter orders if you want to DMA a bunch of data out onto several pins in parallel
<i509vcb[m]>
Everything else is pure input
<korbin[m]>
and so you don't have to try it - the datasheet is not lying with regards to VDDIO on the IMXRT1011 not supporting 1v8 - i tried
<korbin[m]>
the more expensive chips do support 1v8 IO, this one most definitely does not
<korbin[m]>
i spun a board specifically powering USB etc at 3v3, IO at 1v8 - no dice
<korbin[m]>
the IMXRT1011s are $1.30, the IMXRT1064s are $6 if you are really lucky
<i509vcb[m]>
Yeah I'm not going to try to work around voltage ranges
<i509vcb[m]>
Going to involve level shifting anyways
<i509vcb[m]>
Also since you are around, is the datasheet lying about VBUS being required for the PHY to work?
<i509vcb[m]>
I really don't like that I've needed to throw a 5V LDO on solely for that (power delivery so I cannot hardwire vbus to it)
<korbin[m]>
i509vcb[m]: that i am not sure about, but it is used for HW VBUS detection in my driver impl
<JamesMunns[m]>
@i509vcb btw definitely interested in what you are doing, and if I can support it better in postcard-rpc/poststation :D
<JamesMunns[m]>
lemme know if you ever want to chat about it!
<JamesMunns[m]>
I do also sort of wonder if it would be possible to make some kind of "super probe", that could speak postcard-rpc to probe-rs, to do certain things like faster rtt streaming without requiring round trips over USB, sort of like black magic I guess
<JamesMunns[m]>
but that might be a yak for another day
<korbin[m]>
JamesMunns[m]: this is a job for the $2 zynq 7000 - in linux
<JamesMunns[m]>
(probe-rs now uses postcard-rpc for remote debugger functionality, so there's even maybe some room to re-use things like that so it's the same interface for remote pcs and "super" probes)
<i509vcb[m]>
<korbin[m]> "that i am not sure about, but it..." <- Hmm, although detection is possible without VBUS I assume (the usb connection goes over other side of a USB isolator)
<JamesMunns[m]>
JamesMunns[m]: just being loud that it's a problem I want solved, I'll help support whoever tries to solve it however they want :D
<korbin[m]>
i509vcb[m]: probably - many of the embassy chips dont use it but iirc this has suspend mode implications that i am unaware of
<korbin[m]>
the USB PHY is powered via a specific 3v3 line though
<korbin[m]>
named
<JamesMunns[m]>
JamesMunns[m]: (also for potentially doing things like raw tracing, for chips that have more than just the standard 2 SWD lines exposed)
<korbin[m]>
VDD_USB_CAP
<korbin[m]>
btw i509vcb -
<i509vcb[m]>
korbin[m]: Yes I did notice that, but is it legal to power it from 3.3V (I think it's 3.3V)
<M9names[m]>
<korbin[m]> "how would an STLink do it..." <- Abusing the spi peripheral, probably. That's what hs-probe does.
<M9names[m]>
I did some benchmarking with probe-rs a few years ago, st-link v3 did pretty well.
<M9names[m]>
The mcu-link firmware got a lot faster since then, I assume they wrote better custom logic for handling it using the SCT peripheral on LPC55.
<korbin[m]>
This regulator has a built in power-mux that allows
<korbin[m]>
of the USB VBUS voltages is present, then, the regulator automatically selects this supply.
<korbin[m]>
the user to select to run the regulator from either USB VBUS supply, when both are present. If only one
<korbin[m]>
M9names[m]: for JTAG this makes sense, how does this practically work for SWD
<i509vcb[m]>
korbin[m]: Yes I have already used that one before
<korbin[m]>
it's brand new?
<korbin[m]>
nice
<korbin[m]>
they had an older one iirc sans EPR
<i509vcb[m]>
The one thing I dislike is the interrupt pin is 5V drive
<i509vcb[m]>
But that's an easy divider to fix
<korbin[m]>
wow, interesting choice of not using open drain
<i509vcb[m]>
The best part about that part is their eval board has 5V pull ups
<i509vcb[m]>
And they have an example app note using it from a Raspberry Pi which is 3.3V max
<i509vcb[m]>
* 3.3V max for gpii
<korbin[m]>
does look like the VIH/VIL for the i2c OD pins is 1.4V/0.4V
<i509vcb[m]>
* 3.3V max for gpio
<korbin[m]>
so that's nice
<i509vcb[m]>
korbin[m]: Yes I did see that, so 3.3V pullups will work
<korbin[m]>
this is the only sink chip with the ideal behavior
<korbin[m]>
sink-only (non-phy) chip
<korbin[m]>
the hynetek epr capable one has dangerous startup behavior you can't opt out of
<korbin[m]>
(you get resistor strapping OR 28Vin minimum profile if you want I2C capabilities - the diodes correctly negotiates 5V SPR and lets you change later)
<thejpster[m]>
having a bad time with GHA today. Trying to make QEMU run in GHA on Windows (because Ubuntu 24.04's qemu is too old)
<thejpster[m]>
I had it working, then squashed some stuff and managed to break it
<thejpster[m]>
Which adds SMP support. There's a CAS based multi-core spin lock which someone needs to look at *very carefully* because I don't entirely know what I'm doing. Also getting the second core out of EL2 without running the .data and .bss init was ... interesting. I don't like all the copy-pasta assembly.
<thejpster[m]>
OK, so I just looked at that for a solid minute, and I still have no idea what version of QEMU it is installing, or whether it installs qemu-system emulators or only does qemu-user user-mode emulation.
<thejpster[m]>
you're very welcome to open a PR and try it
cbjamo[m] has joined #rust-embedded
<cbjamo[m]>
Has anyone started the legwork for defmt 1.0 in embedded-hal crates? If not I'll do it. The only question I have is should we chop out defmt 0.3 entirely, or should fundamental crates like this keep them both around?
ello has joined #rust-embedded
ello_ has joined #rust-embedded
<diondokter[m]>
cbjamo[m]: 0.3 can only be rid of if it doesn't break anyone
<cbjamo[m]>
Yeah, that's what I figured.
<thejpster[m]>
your 0.3 will probably update to 0.3.100, which is 1.0 in a trenchcoat. I believe that the only people you'll break by saying defmt = "1" instead of defmt = "0.3" are people who pin the crate to lower than 0.3.100.
<thejpster[m]>
I bumped derive-mmio to defmt = "1", but it has very few users.
<thejpster[m]>
in fact, bumping to defmt = "1" gets you basically nothing except locking out people pinned to older versions.
<thejpster[m]>
it is, by the way, impossible to import two versions of defmt in build, because they use no_mangle symbols. That's why we had to do the semver trick.
<thejpster[m]>
* it is, by the way, impossible to import two versions of defmt in one build, because they use no_mangle symbols. That's why we had to do the semver trick.
<cbjamo[m]>
Hmm, I must have something accidentally pinned somewhere. Then I assumed it would have to update everywhere.
<cbjamo[m]>
Yup, fixed that and everything worked. Thanks JP.
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
<MartinSivk[m]>
Folks, I think I have seen a trick that used associated types in a trait to define types in a struct that then somehow inferred the types from the compile time instantiation. I have a board support structure with nice names for gpios, serials etc and the need to maintain types like Switch<PA3<stm32l0xx_hal::gpio::Output<stm32l0xx_hal::gpio::PushPull>>, ActiveHigh> manually is driving me nuts. If the trick exists I can't find it
<MartinSivk[m]>
anymore.. so if you good folks have any idea about how to make this ledd tedious I would love to hear about it.
<MartinSivk[m]>
* Folks, I think I have seen a trick that used associated types in a trait to define types in a struct that then somehow inferred the types from the compile time instantiation. I have a board support structure with nice names for gpios, serials etc and the need to maintain types like Switch\<PA3\<stm32l0xx\_hal::gpio::Output\<stm32l0xx\_hal::gpio::PushPull>>, ActiveHigh> manually is driving me nuts. If the trick exists I can't
<MartinSivk[m]>
find it anymore.. so if you good folks have any idea about how to make this less tedious I would love to hear about it.
<i509vcb[m]>
Something like embassy-stm32 gets around this with AnyPin and erasing the pin type on Output
<i509vcb[m]>
But does the stm32-hal crates allow type erasing the specific pin?
<MartinSivk[m]>
Well, it is not just gpios, I preconfigure the Spi bus and Uarts too for example. I guess I could allocate it statically somehow and use dyn pointers with traits, but that has runtime impact.
<MartinSivk[m]>
Right now I am crying every time I change something, because I need to change all the types too..
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
is there any interest in HALs which provide little if any type-level safety, at the cost of code size, or simply catching fewer semantic errors?
<whitequark[cis]>
not wanting to deal with the rather extra types HALs seem to have is why i normally just use PACs directly, but a much simpler HAL has some appeal to me still
<whitequark[cis]>
(actually, i feel like PACs could perhaps be slightly simpler too, and one day i might tilt at the windmill that is svd2rust again, but that's by no means urgent)
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
I feel like we're slowly trying to figure what exactly should be type vs runtime state. At the moment we probably have too much type state in hals and drivers.
<whitequark[cis]>
the approach i've taken in smoltcp and elsewhere is to not add a type parameter unless it would provide an overwhelming benefit in efficiency, safety, etc that cannot be achieved by other means
<RobinMueller[m]>
I still like using type state for the GPIO pins which also need to be configured to be usable for some peripherals, but I started to always provide a completely type erased API in addition to type state API. I actually only used type-state API for the GPIO pins in my most recent HAL components I have written, and got rid of all other type state for peripherals like UART/SPI/I2C etc. . I do all the type state checks inside the
<whitequark[cis]>
(i actually feel like smoltcp still tries to do too much with regions, but i couldn't see a way around that and i still don't)
<whitequark[cis]>
i'm wondering whether the pin configuration would not be better expressed with something like a macro
<whitequark[cis]>
you could have much better error reporting that way
<whitequark[cis]>
and while it is more limited in flexibility, as Robin says, if you use all the typestate APIs once at the initialization anyway, there's no real difference in practice
<whitequark[cis]>
* in flexibility, if, as Robin
<whitequark[cis]>
* and while it is more limited in flexibility, if, as Robin says, you use all the typestate APIs once at the initialization anyway, there's no real difference in practice
<whitequark[cis]>
alternatively, i wonder if the constraints involved could not be checked using const fn sequences that evaluate them imperatively, instead of turning your problem into type-encoded-prolog more or less
<whitequark[cis]>
i'm not sure if const fn is powerful enough for that; i know it's much more advanced now than five years ago but i don't know exactly how so
<RobinMueller[m]>
I think it would be nice if https://docs.rust-embedded.org/book/design-patterns/hal/index.html is extended. HAL programming is a specialized topic but I still think it was kind of hard getting into it when I started doing it, because the various HALs out there tend to solve problems differently. The GPIO docs really helped me, but maybe this could be extended by adding patterns like completely type erased pins, or
<RobinMueller[m]>
suggestions for UART/SPI/I2C implementations (maybe also with trade-offs of type-state API vs. type-erased APIS) ? I think the Rust HALs are still a blessing compared to the chaos that are vendor provided C APIs.
<RobinMueller[m]>
* I think it would be nice if https://docs.rust-embedded.org/book/design-patterns/hal/index.html is extended. HAL programming is a specialized topic but I still think it was kind of hard getting into it when I started doing it, because the various HALs out there tend to solve problems differently. The GPIO docs really helped me, but maybe this could be extended by adding patterns like completely type erased pins, or
<RobinMueller[m]>
suggestions for UART/SPI/I2C implementations (maybe also with trade-offs of type-state API vs. type-erased APIS) ? Rust HALs are definitely a blessing compared to the chaos of vendor provided C HALs though. I really like working with them
<dngrs[m]>
<MartinSivk[m]> "Right now I am crying every time..." <- I like to write type aliases when stuff like `AnyPin` is not possible. That way code is flexible/portable (e.g. I can switch between SPI1 and SPI2 using a `feature` and only change the alias instead of all usage sites)