00:02 <re_irc> <@adamgreig:matrix.org> Huh. What's in memory.x and are you using flip-link?

00:03 <re_irc> <@adamgreig:matrix.org> Can you check the first word of the vector table? If you use objdump to binary it'll be the first four bytes

09:58 <re_irc> <@ubik:matrix.org> Default memory.x from rp-hal and using flip-link. But not using it results also in a mess.

11:06 <re_irc> <@monacoprinsen:matrix.org> Hey guys,

11:06 <re_irc> <@monacoprinsen:matrix.org> What gives a faster output to console:

11:06 <re_irc> <@monacoprinsen:matrix.org> Used Hprintln before but I feel it updates slow

11:06 <re_irc> <@monacoprinsen:matrix.org> Hprintln from semihosting or Iprintline from ITM dump?

11:18 <re_irc> <@9names:matrix.org> ITM should be way faster

11:37 <re_irc> <@ubik:matrix.org> adamgreig: first word of `.vector_table` is `0xc8f60320`

11:37 <Lumpio-> Semihosting is pretty much the slowest option out of the commonly used ones.

11:38 <re_irc> <@adamgreig:matrix.org> monacoprinsen:matrix.org: I'd try rprintln from rtt-target, it goes over the debugger like semihosting so is convenient (while iprintln requires swo), but is almost as fast and low-overhead as iprintln

11:38 <re_irc> <@adamgreig:matrix.org> ubik:matrix.org: Is that little endian or just the first four bytes in order? Perhaps it's 2003f6c8 which sounds like quite a reasonable initial stack pointer

11:39 <re_irc> <@ubik:matrix.org> that's the way object-dump outputs it

11:40 <re_irc> <@ubik:matrix.org> but yeah, probably that

11:41 <Lumpio-> Which chip is it?

11:41 <Lumpio-> Oh, RP3040 huh

11:41 <re_irc> <@ubik:matrix.org> RP2040

11:41 <Lumpio-> RP2040 even

11:42 <Lumpio-> Alright

11:43 <re_irc> <@monacoprinsen:matrix.org> adamgreig: Tnx!

11:43 <Lumpio-> I forgot how the boot process even works on that heh, it has like a built-in bootloader of sorts doesn't it

11:49 <re_irc> <@9names:matrix.org> yeah, there's a bootloader in ROM

11:52 <re_irc> <@9names:matrix.org> plus there's a 2nd stage bootloader that configures the flash controller to work with the particular spi flash that is connected

14:19 <re_irc> <@yruama_lairba:matrix.org> hello, i'd like to know how to profile code when using rust embed ?

14:19 <re_irc> <@k900:0upti.me> That's a tricky one

14:21 <re_irc> <@k900:0upti.me> The real answer is "use your chip's sampling feature if it has one, log timings if it doesnt'"

14:23 <re_irc> <@yruama_lairba:matrix.org> K900: it's seems your talking about benchmarking

14:23 <re_irc> <@k900:0upti.me> No, I'm not

14:26 <re_irc> <@yruama_lairba:matrix.org> ok, while i never did profiling before, i understand profiling is a way to know on wich part of the code most of the time is spend

14:26 <re_irc> <@k900:0upti.me> Yes, that's what it is

14:28 <re_irc> <@yruama_lairba:matrix.org> maybe there is a tutorial about how to do it ?

14:29 <re_irc> <@k900:0upti.me> There is no universal way to do it

14:30 <re_irc> <@k900:0upti.me> Most higher end ARM based SoCs have a built-in sampling feature that you can use with something like OpenOCD

14:30 <re_irc> <@k900:0upti.me> For other things it's probably easiest to just manually time the slow bits

14:31 <re_irc> <@adamgreig:matrix.org> many cortex-m will have the ITM that can emit timing information, profile the PC, etc

14:31 <re_irc> <@adamgreig:matrix.org> but it's a bit fiddly to set up and use, and I don't think there's very much open source tooling for it atm

14:32 <re_irc> <@k900:0upti.me> https://github.com/japaric/itm-tools

14:33 <re_irc> <@k900:0upti.me> Old-ish but should still be usable

14:35 <re_irc> <@yruama_lairba:matrix.org> ok, looks complicated,

14:40 <re_irc> <@yruama_lairba:matrix.org> and profiling functions seems to not worth the effort, benchmarking should be enought

16:32 <re_irc> <@monacoprinsen:matrix.org> Does itm-decode work the same way as itm?

16:32 <re_irc> <@monacoprinsen:matrix.org> Since itm is deprecated

16:32 <re_irc> <@k900:0upti.me> I'm not sure what you mean by "itm" here

16:35 <re_irc> <@adamgreig:matrix.org> yea, it's basically the same

16:43 <Lumpio-> Benchmarking = running different versions of the same thing, or the same thing on multiple platforms, or both, and seeing how long it takes

16:43 <Lumpio-> Profiling = running one version of your thing, and seeing how much time the different parts of it take

16:43 <Lumpio-> essentially

16:44 <Lumpio-> (Replace time with memory or power or whatever other thing you're interested in)

16:44 <Lumpio-> Both can be done with logging, doing profiling with just logging can take more work, but sometimes it also gives you more easily interpretable resluts.

20:28 <re_irc> <@lkostka:matrix.org> Hi. I've been wondering is there any more elegant way then hardcoding / macro programming way of getting individual GPIO pins ?

20:28 <re_irc> <@lkostka:matrix.org> https://users.rust-lang.org/t/how-to-declare-constant-pins-across-different-boards-stm32/58685/2

20:38 <re_irc> <@newam:matrix.org> For that you can the traits from embedded-hal. Those GPIO structures implement the embedded-hal traits to make it generic. For example

20:38 <re_irc> <@newam:matrix.org> pub fn example<P, E>(pin: &mut P) -> Result<(), E>

20:38 <re_irc> <@newam:matrix.org> where

20:38 <re_irc> <@newam:matrix.org> ```rs

20:38 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/2c523c510db4526868bb02b6ae74c87a235851aef38aa2990bb59fc6c981fb32 (9 lines)

20:38 <re_irc> <@newam:matrix.org> Whoops wrong chat