<AlexandrosLiarok>
basically prevents multiple function calls from being inline and putting all local variables to the top level frame which results in accumulated stack usage
<AlexandrosLiarok>
note that in the lost_stack_forever function, we get a 128kb penalty forever
<AlexandrosLiarok>
* note that in the lost_stack_forever function, we get a 128kb stack penalty forever
<AlexandrosLiarok>
* note that in the lost_stack_forever function, we get a 128kb stack penalty forever because the called_once local variable has been inlined in the diverging function's frame
<AlexandrosLiarok>
worst part of it is it adds up
<AlexandrosLiarok>
so if you call called_once twice it will eat twice the memory for the remainder of the program
<AlexandrosLiarok>
this affects basically any init code that can possibly be inlined the main, eating stack for the remainder of your program execution
<AlexandrosLiarok>
* be inlined in the main, * the main function, eating
<AlexandrosLiarok>
this happens even for implicit initialization copies
<AlexandrosLiarok>
* this happens even for implicit stack usage used for initialization.
<AlexandrosLiarok>
is also an issue for diverging futures
<AlexandrosLiarok>
* is possibly also an, * diverging futures,, * I /think/ these frames are embedded in the structure even if they are only temporarily used
<AlexandrosLiarok>
* is possibly also an, * diverging futures,, * I /think/ these frames are embedded in the structure even if they are only temporarily used, but I am not sure about that.
<AlexandrosLiarok>
* is possibly also an, * diverging futures,, * I /think/ these frames are embedded in the structure even if they are only temporarily used, but I am not sure about that, I could be wrong.
<AlexandrosLiarok>
in any case this is actually a huge footgun
<AlexandrosLiarok>
what I do is sprinkle some print_stack calls immediately at main start and before the main loop call.
<AlexandrosLiarok>
* what I do is sprinkle some print_stack calls immediately at main start and before the main loop call and then use localize_stack_usage to reduce both.
<AlexandrosLiarok>
pcs38: Ah sorry I was not aware of that. Note taken.
<pcs38>
(not a serious issue, was just meant as a friendly suggestion, I understand that the community is mostly matrix)
inara has joined #rust-embedded
kevinmehall[m] has joined #rust-embedded
<kevinmehall[m]>
With all the talk of embedded-hal I2C / GPIO over USB, I wanted to share my work-in-progress project for commanding common microcontroller peripherals over USB:
<kevinmehall[m]>
I have the SPI and I2C embedded-hal-async impls working (and GPIO that now has an async trait I should implement🎉). Firmware side (RP2040 / SAMD21 / SAMD11) needs some cleanup before release because it's closely coupled to a half-finished async executor and USB device stack that does some unique things that Embassy can't but I'm not sure if I actually want to re-invent that wheel.
<dirbaio[m]>
> USB device stack that does some unique things that Embassy can't
<dirbaio[m]>
just curious, what is that embassy is missing?
<kevinmehall[m]>
This started off because I wanted async on SAMD11, which Embassy doesn't support, and embassy-usb wouldn't fit in flash on. My async executor + async USB stack on SAMD11 fits in about 6KB of flash, Viking with SPI, I2C, and a few GPIOs totals 12KB.
<kevinmehall[m]>
It runs entirely in handler mode, effectively turning the Cortex-M NVIC into an async executor, where awaiting an interrupt means your task continues execution from that interrupt handler. Just bouncing between ISRs, with sleep-on-exit to go to sleep on idle instead of ever returning to thread mode.
<kevinmehall[m]>
Because ISRs at the same priority level run to completion without preemption, this means there is no need for any synchronization anywhere, which plays very nicely with Cortex-M0's lack of atomics.
<kevinmehall[m]>
But: No scheduling fairness, ISR execution order pre-determined in silicon.
<kevinmehall[m]>
Because it's hyper-optimized for Cortex-M0, it also seemed like a great fit for RP2040, but that suddenly got a lot less interesting when RP2350 came out with Cortex-M33.
<dirbaio[m]>
<kevinmehall[m]> "It runs entirely in handler mode..." <- iiiiinteresting
<dirbaio[m]>
so if your task e.g. awaits something from uart, the isr itself will poll the task, not just wake it?
<kevinmehall[m]>
exactly, and then it will run in that ISR to the next .await, and configure itself to be woken up by the next UART byte or whatever else it awaits next.
<dirbaio[m]>
and you store some isr -> task mapping somewhere?
<kevinmehall[m]>
Yeah, each task compiles to a function that polls that task, and it just stores that function pointer and calls it.
<dirbaio[m]>
for example if you share an i2c bus between tasks (like, a task locks the mutex, does some i2c transaction, unlocks) the i2c isr know which task(s) to poll with that
<dirbaio[m]>
fun
<dirbaio[m]>
and if you join/select two periphs (e.g. uart + i2c) you have to manually ensure the two isrs are at the same prio or you get unsoundness, right?
<kevinmehall[m]>
Yeah, it doesn't support changing IRQ priority (at least for things that touch any state of the executor). It would support sub-priority though on parts that have it.
<dirbaio[m]>
how do you do task-task wakes? like, task A unlocks a mutex which needs to wake task B that was waiting?
<kevinmehall[m]>
There's a linked list of tasks and normal waker.wake() appends to it and sets PendSV pending. The PendSV handler walks the list and polls each task.
<dirbaio[m]>
hm so if any task can potentially be polled from pendsv then all irqs must have the same priority?
<dirbaio[m]>
so it can't do multiprio at all (?)
<kevinmehall[m]>
Yes, that's the big drawback.
<dirbaio[m]>
got it
<dirbaio[m]>
sorry for so many questions, it's that I tried exploring these ideas a while back for Embassy
<dirbaio[m]>
and couldn't figure it out a way to make it work soundly and for enough use cases
<dirbaio[m]>
fitting async executor+usb in 6k is quite impressive
<dirbaio[m]>
I wonder how much is the executor design vs coding things for minimum code size from day zero
<TomB[m]>
<kevinmehall[m]> "It runs entirely in handler mode..." <- isn't this basically what rtic does?
<TomB[m]>
I guess there's the macro though...
<dirbaio[m]>
no, it doesn't do that for async
<kevinmehall[m]>
dirbaio[m]: I think it's a combination of both -- the critical sections are quite a bit of bloat, especially on parts without atomics.
<dirbaio[m]>
rtic's executor design is the same as embassy's InterruptExecutor. One task is always polled from the same interrupt
<kevinmehall[m]>
Yeah, RTIC hardware tasks are just run-to-completion handlers, and the async executor is all in thread mode.
pcs38 has quit [Quit: leaving]
<dirbaio[m]>
> the async executor is all in thread mode
<dirbaio[m]>
not really, if you set tasks at higher prios it'll poll them from the "dispatchers" software interrupts.
<dirbaio[m]>
* you set async tasks at
<kevinmehall[m]>
ah
<dirbaio[m]>
each priority has one dispatcher irq, and one queue of tasks that need to be polled
<dirbaio[m]>
thread mode is treated as a "irq with lowest priority" kinda
<dirbaio[m]>
* and thread mode
<dirbaio[m]>
* and thread mode, * priority" kinda, also with its own queue
<dirbaio[m]>
so you can have an async task preempting another async task
<dirbaio[m]>
it's the same as if you create multiple InterruptExecutors in Embassy
<kevinmehall[m]>
In terms of features, one thing that I don't think Embassy has but I don't see why it couldn't add is the ability for one task to synchronously cancel another. E.g. a USB device's handler for SET_CONFIGURATION / SET_INTERFACE configures all the bulk endpoints and spawns tasks to service them, but it will first kill existing instances of those tasks to re-start them or switch to a different set of tasks for a different mode.
<kevinmehall[m]>
(this just drops the task state and sets a bit that makes polling the task a no-op until it's spawned again)
<dirbaio[m]>
it's been proposed before
<dirbaio[m]>
there's no reason it can't be done, i'd accept a PR
<dirbaio[m]>
as long as it's optional, because it brings in the "full" drop codepath for all task futures
<dirbaio[m]>
which adds quite a bit of bloat
<dygear[m]>
I managed to get SD Cards working on the Adafruit Metro. I think Rust / Embassy is the first ecosystem that is able to do that on this board. They had put in their product page that the SD Card reading and writing was forthcoming in CircuitPython (their preferred programming language for these devices.)
<AlexandrosLiarok>
just realized serde has a deserialize_in_place method for the Deserialize trait.