Dirk O. Kaar

@d-a-v > There are #6048+#6055 and this one #6047. > Does OP states #6047 replace both ? Yes, it should work this way (in git). > Also I understand #5922...

@d-a-v @hreintke To keep you informed, with this std::function based ISR attach code, I see sporadic crashes after reset. So yes, there is still something not in order with the...

@hreintke I almost can't resist giving an answer that's just as cryptic :-) No, don't worry, I am glad you care! I am putting a lot of work into keeping...

@d-a-v It seems you've some time at your hands today to talk - I've a question: What is the state of the IRAM linker segment manipulations w.r.t. std::function now? I...

@d-a-v I believe, with the information you provided me, that this PR now contains a safe refactoring of the IRQ code that has the relevant code paths in IRAM. It...

@d-a-v No, I don't think so, that's an oversimplification. https://en.cppreference.com/w/cpp/utility/move explains this better. What I am trying to express/achieve is that the move constructors/assignments are selected if available.

@d-a-v it's certainly desirable avoiding copying objects all the time for no good reason - but yes, that's a lot of extra work doing it just for consistency. Are you...

@d-a-v I was asked by @devyte to test and improve the performance of this patch, such that it is no worse for void(*)(void) ISRs over before. I am now seing...

Some test results. But first, I noticed that in master, `set_interrupt_handlers()` is missing the `ICACHE_RAM_ATTR` attribution - which when done right adds a few bytes to IRAM use. Master including...

Latest master compared to rebased PR branch. Master: ``` Executable segment sizes IROM *: 234064 - code in flash (default or ICACHE_FLASH_ATTR) IRAM *: 27580 \ 32768 - code in...