<GrantM11235[m]>
But you need to use a macro to impl it individually for each instance
<i509vcb[m]>
<GrantM11235[m]> "You can do something like this..." <- Huh I guess that's what I also forgot existed... Maybe thats how I do the micro-optimizztion for C110x because I have about 14 wakers which are forced to be in memory but are never used... And C110x has 1KB of ram...
<i509vcb[m]>
yeah the problem is I'd want to apply this to AnyPin
<i509vcb[m]>
And in order to get the waker I'd have to somehow construct an AnyPin out of effectively thin air (port and bit) and then somehow look up the waker
<i509vcb[m]>
Although that's 112 bytes of ram I could save for the pain...
<i509vcb[m]>
Which for C110X is literally 10% of RAM
<i509vcb[m]>
s/C110X/C110x/
<i509vcb[m]>
* the pain... (14 wakers are never used)
<i509vcb[m]>
* Which for C110x is literally 10% of RAM on just gpio wakers...
<i509vcb[m]>
The next up parts with 4K of ram still do suffer from this issue as well
Artea has joined #rust-embedded
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<JamesMunns[m]>
unused statics won't be included in the program image
<JamesMunns[m]>
ahh
<JamesMunns[m]>
nvm, now I get it with anypin
<JamesMunns[m]>
If you want a very silly idea (which might not be good, I still haven't finished my first coffee): you could use one `maitake-sync::WaitQueue` for ALL drivers
<JamesMunns[m]>
if any event goes off, it just wakes all tasks that are waiting on something, at the cost of wasted CPU for tasks that are not ready
<JamesMunns[m]>
costs 3 words for the WaitQueue, 2 words for each task waiting. It's intrusive, so there's no auto-sizing
<JamesMunns[m]>
Or you could step that one one level of silliness, and have a single WaitQueue per "group", e.g. one for GPIOs, one for UART, etc.
<JamesMunns[m]>
if you had 14 tasks waiting on GPIO interrupts at the same time it would be a little wasteful, but if you USUALLY are only waiting on one or two, it'd be fine
<JamesMunns[m]>
s/one/down/
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has joined #rust-embedded
mkj[m] has quit [Quit: Idle timeout reached: 172800s]
<correctalex[m]>
Hi folks - still new to rust - I'm trying my hand at making a smallish HAL for some Renesas RA chips (RA6M4, etc) - but I don't think the "problem" is unique to them. In essence, the SVD (and hence PAC) describe for example the various timers as derived from each other, so there's only one underlying struct for the type of timer. However, to e.g. get interrupt linking to work, I need some way of going from a particular instance
<correctalex[m]>
of the timer to its particular interrupt linking identifier. This is somewhat similar to the kind of event linking system some Microchip microcontrollers have as well (which this microcontroller _also_ has, in the form of ELC -- but one problem at a time).
<correctalex[m]>
I'd appreciate any advise on how to idiomatically express that in a HAL without just wrapping every instance of every peripheral in an extra struct (although maybe that is the way?).
<correctalex[m]>
* extra struct which then defines fields for the various events/interrupts that can be linked and their identifier (although maybe
<correctalex[m]>
A follow-on question is how to express the actual interrupt linking in a Embassy-style bind_interrupts in a way that handles that indirection (where each ISR can be linked to any peripheral via that kind of identifier).
<correctalex[m]>
* Embassy-style bind_interrupts // type traits in a
<correctalex[m]>
FWIW, I realize I've probably bitten off way more than I can chew - but thought I might as well learn by doing.
pcs38 has quit [Quit: leaving]
Maebli[m] has quit [Quit: Idle timeout reached: 172800s]
ello- has joined #rust-embedded
ello has quit [Read error: Connection reset by peer]
ello- has quit [Ping timeout: 276 seconds]
ello_ has quit [Ping timeout: 260 seconds]
ello has joined #rust-embedded
ello_ has joined #rust-embedded
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]>
question: is stm32h7xx-hal maintained
<GuineaWheek[m]>
or did everyone run off to embassy-stm32
rom4ik has quit [Quit: Ping timeout (120 seconds)]
<JamesMunns[m]>
<GuineaWheek[m]> "question: is stm32h7xx-hal..." <- I think it's still used by the people that develop(ed) it, I don't think it's as active as embassy-stm32. There's nothing wrong with it, but it does get updated far less often.
rom4ik has joined #rust-embedded
Socke has quit [Quit: WeeChat 4.5.1]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
Socke has joined #rust-embedded
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
danielb[m] has joined #rust-embedded
<danielb[m]>
<thejpster[m]> "Also https://crates.io/crates/..."; <- it depends on cortex-m but doesn't use it so I'm not sure whether it would work
<danielb[m]>
* would work. otherwise it would actually be an interesting tool for our HIL test setup, RTT is pretty intrusive in stop mode for some timing-sensitive tests
<danielb[m]>
* it depends on cortex-m but doesn't use it so I'm not sure whether it would work. otherwise it would actually be an interesting tool for our HIL test setup, RTT is pretty intrusive in stop mode for some timing-sensitive tests
<danielb[m]>
my slight complaint is that I don't think tools have a way to discover which channel uses defmt. For RTT, probe-rs infers this from the channel name most of the time, but for semihosting what can we do?
<danielb[m]>
* it depends on cortex-m but doesn't use it so I'm not sure whether it would work. otherwise it would actually be an interesting tool for our HIL test setup, RTT is pretty intrusive in stop mode for some timing-sensitive tests
<danielb[m]>
my slight complaint is that I don't think tools have a way to discover which channel uses defmt. For RTT, probe-rs infers this from the channel name most of the time, but for semihosting what can we do? perhaps "use rzcobs encoding and try to decode everything that comes out of the MCU" is a viable enough strategy for now 🤔
<danielb[m]>
* it depends on cortex-m but doesn't use it so I'm not sure whether it would work. otherwise it would actually be an interesting tool for our HIL test setup, RTT is pretty intrusive in stop mode for some timing-sensitive tests
<danielb[m]>
my slight complaint is that I don't think tools have a way to discover which channel uses defmt. For RTT, probe-rs infers this from the channel name most of the time, but for semihosting what can we do? perhaps "use rzcobs encoding and try to decode everything that comes out of the MCU" is a viable enough strategy for now 🤔 or `--semihosting-encoding defmt`
<rmsyn[m]>
<thejpster[m]> "got spec: https://rustfoundation..." <- thank you all for you work on the spec, and donating it to the Rust Foundation. this is another huge step for the language!