Reduce responder tasks size; fix transport scheduling

[ivmarkov]

This PR is fixing the following TBD left unsolved in #332
"
Fix the large "responder" future by splitting it into multiple tasks in an embassy-executor task pool. This should reduce these 20KB down to ~ 10KB on x64 and even less for the other targets
"

Additionally, it fixes a bug in the scheduling of the transport tasks, because matter.run_transport needs to be called only once, and if there are multiple transports (as in UDP and BTP in our case) they need to be chained together.

[github-actions]

PR #333: Size comparison from d8463db to 255121a

Full report (8 builds for dimmable-light, onoff-light, onoff-light-bt, rs-matter-core, speaker)

platform	target	config	section	d8463db	255121a	change	% change
dimmable-light	infologs-optz-ltofat	x86_64-unknown-linux-gnu	FLASH	1942176	1941968	-208	-0.0
			RAM	42720	42720	0	0.0
onoff-light	infologs-optz-ltofat	x86_64-unknown-linux-gnu	FLASH	1852688	1852496	-192	-0.0
			RAM	42704	42704	0	0.0
onoff-light-bt	infologs-optz-ltofat	x86_64-unknown-linux-gnu	FLASH	3207768	3207616	-152	-0.0
			RAM	9308	9308	0	0.0
rs-matter-core	infodefmt-optz-ltofat	riscv32imac-unknown-none-elf	FLASH	390438	382768	-7670	-2.0
			RAM	68952	60752	-8200	-11.9
		thumbv6m-none-eabi	FLASH	325992	319192	-6800	-2.1
			RAM	65348	57180	-8168	-12.5
		thumbv7em-none-eabi	FLASH	301396	294624	-6772	-2.2
			RAM	64836	56668	-8168	-12.6
	infologs-optz-ltofat	x86_64-unknown-linux-gnu	FLASH	840647	826383	-14264	-1.7
			RAM	73634	60066	-13568	-18.4
speaker	infologs-optz-ltofat	x86_64-unknown-linux-gnu	FLASH	1912880	1912688	-192	-0.0
			RAM	5480	5480	0	0.0

[ivmarkov]

Update:

• Turns out, the content of "target" and "config" was swapped so I fixed that
• Renamed "rs-matter-core" to just "(core)" to shorten it and to make sure (given the alphanum sorting) that is always shows on top, as this is the key metric, not the linux examples.

[ivmarkov]

Hmmmm, cargo size shows ~ 770KB for FLASH for the Riscv32 target (which is way above what I've expected). bloaty shows ~ 390KB.

ivan@m800:~/dev/rs-matter/bloat-check$ cargo size --release --target riscv32imac-unknown-none-elf
    Finished `release` profile [optimized] target(s) in 0.14s
   text    data     bss     dec     hex filename
 773412    3512   57240  834164   cba74 bloat-check

Wondering which tool to trust? :)

(The other targets show no significant differences.)

[gmarcosb]

Hmmmm, cargo size shows ~ 770KB for FLASH for the Riscv32 target (which is way above what I've expected). bloaty shows ~ 390KB.

ivan@m800:~/dev/rs-matter/bloat-check$ cargo size --release --target riscv32imac-unknown-none-elf
    Finished `release` profile [optimized] target(s) in 0.14s
   text    data     bss     dec     hex filename
 773412    3512   57240  834164   cba74 bloat-check

Wondering which tool to trust? :)

(The other targets show no significant differences.)

Interesting... do you know if cargo size is actually looking at the file output? i.e. why does it need a --release arg?

[ivmarkov]

Interesting... do you know if cargo size is actually looking at the file output? i.e. why does it need a --release arg?

Like many other cargo plug-ins, cargo size first does a cargo build (hence the --release flag) and then - to my knowledge - inspects the resulting ELF using the elf crate

In any case, what I just found out (stupid me!) is that:

• The embedded targets cargo size uses hard-coded targets (?!) because the plug-in does not do any command-line parsing or anything so that it can figure out the actual --target arg.
• The project seems dead (last commit 7 years old)

I need to move off from this one, perhaps by just using the native LLVM tooling.

[ivmarkov]

Or maybe I just fork cargo-size and make it work. Not a rocket science.