[jan-xyz]

Make startup take a shared borrow so it can run while other stack futures hold the stack, e.g. other startup code on the board.

[ivmarkov]

Hmmm, strictly speaking, nothing in startup needs &mut, but I created it this way deliberately, because run should not be called before startup had done its job (and run can be called more than once, while startup is supposed to be called once only, during init).

In other words, while we do not have full protection (run can be called without startup called first and I need to close this gap) you currently can't do select(startup, run).await, which is a straight bug you are protected from.

Can you elaborate why you need startup to take &self? If you absolutely need that, we can still do it but it would need a small change in rs-matter as well - run failing at runtime if a new startup_called flag is not set yet).

[jan-xyz]

I am currently trying to speed up the awake intervals, one way I thought I could do that is by starting matter in parallel while I'm also evaluating button presses. It doesn't seem to be just solved by making this immutable, so it can run in parallel with the other code, so maybe I'm barking up the wrong tree and this isn't necessary.

[ivmarkov]

startup currently - although marked as async for future-proofing - does not have a single await point inside it.

What this means is that it is pure computation, and 0% IO-waiting (sure, it reads from flash, but that's a blocking IO task for reasons and I don't think the NOR flash impl in esp-hal* IO-waits inside it). So even if you try to schedule it "in parallel" with another - truly IO-bound task - you'll not see any shorter awake intervals because on a single CPU startup has to compute what it has to compute.

Shortening the awake intervals is better chased elsewhere - as in what rs-matter does after that - as in how much time it takes to re-connect to Thread, then send all those check-ins, report on subscriptions, etc. Perhaps you can do a simple timing how much time startup takes, vs. how much time until the active period is over. Also and if I remember correctly, there was a parameter for the device how much time to stay active which is configurable. You should not set it to 0 though or else the device might not have enough time to connect to the network, to send check-ins AND to wait a bit if the controller asks it to switch to SIT mode or if the controller heart-beats it so that it stays in Active mode until further notice. A lot of this might sound gibberish but I hope once you look at matter-peek you'll see what I mean, as the UI there allows you to see the "active interval timeout" - (I think by default it is 30s or so) - and why such an interval is necessary beyond activating the operational network, sending check-ins and so on.

[jan-xyz]

thanks! I will close this PR, and thanks again for the explanation!

[github-actions]

PR #53: Size comparison from d971742 to cab326d

Full report (2 builds for light, light_eth)

platform	target	config	section	d971742	cab326d	change	% change
light	x86_64-unknown-linux-gnu	infologs-optz-ltofat	FLASH	2687372	2689020	1648	0.1
			RAM	78080	78080	0	0.0
light_eth	x86_64-unknown-linux-gnu	infologs-optz-ltofat	FLASH	1972487	1972951	464	0.0
			RAM	73048	73048	0	0.0