Pavel Pisa

@raiden00pl, @michallenc I only confirm that design of universal API for all purposes is problematic. In this respect and respect of hardware defined grouping, I am OK with actual design...

@michallenc , as for the unification of the structure, I would suggest small swap ``` #ifdef CONFIG_PWM_MULTICHAN #define PWM_NCHANNELS CONFIG_PWM_NCHANNELS #else #define PWM_NCHANNELS 1 #endif struct pwm_info_s { FAR void...

The ifdefs are gone this way and peripheral drivers for the single channel can be left almost unchanged to actual state, only fields names change, would include one more dot.

I think that it would worth to discuss Rust on NuttX with @lupyuen https://lupyuen.github.io/ . I have seen lot of useful information on his site.

I understand and I think that ESP32 would take some time to resolve legacy and others. But as I have suggested, I would be happy with some option to map...

You are right that there is problem with `template.S` when xlen = 64. But problem is not in the instructions execution but in assembly phase. If you use external assembler...

The commit 09435a40a28789526137768d2742826a42a43b31 Machine: add peripherals high/top address aliases for XLEN=64 provides aliases for peripherals in 64-bit mode to allow template.S and other code to work properly in 64-bit mode...

Hello @KotorinMinami, thanks for contribution. But I see more drawbacks there. The first and most important principle for QtRvSim is to make it illustrative for students us much as possible...

There are some related articles and presentations (usually text in English, recording often in Czech) ### Conference papers - Lenc, M., Píša, P., and Bucher, R.: [pysimCoder – Open-Source Rapid...

> @ppisa Can we merge this? The implementation is clear, straightforward, fits and fills place for extension. It can be merged. I am not sure (doubt) how uses-full it is...