Also worth noting that the Pico SDK is a lot "barer-metal" than it looks.
Lots of things that are presented as function calls and might cause you to think "I could save space/performance by going bare metal and hitting the registers directly" - but if you look at how the SDK actually implements them, they are inline functions in .h files, so by the time the compiler has been allowed to optimise it, you end up generating exactly the same code as you might have written by hand.
Therefore, IMO, there's only two reasons to want to bypass the SDK and go bare-metal: for educational reasons, to learn the basic principles (ie. how the SDK does it); and to achieve functionality not provided by the SDK (the SDK doesn't provide interrupt-driven drivers for many of the peripherals, for example).
"I don't like CMake" is quite often posted here as a reason, but it doesn't really make sense. If you simply don't like CMake, is it really going to take you less effort to re-implement the whole SDK than to gain the little bit of CMake proficiency needed to use the SDK as intended? Or if you have a legitimate reason why you can't use CMake (as I do in one of my projects), you can still build the SDK files from a conventional Makefile instead - it's not easy, but again better than re-implementing everything bare metal.
Lots of things that are presented as function calls and might cause you to think "I could save space/performance by going bare metal and hitting the registers directly" - but if you look at how the SDK actually implements them, they are inline functions in .h files, so by the time the compiler has been allowed to optimise it, you end up generating exactly the same code as you might have written by hand.
Therefore, IMO, there's only two reasons to want to bypass the SDK and go bare-metal: for educational reasons, to learn the basic principles (ie. how the SDK does it); and to achieve functionality not provided by the SDK (the SDK doesn't provide interrupt-driven drivers for many of the peripherals, for example).
"I don't like CMake" is quite often posted here as a reason, but it doesn't really make sense. If you simply don't like CMake, is it really going to take you less effort to re-implement the whole SDK than to gain the little bit of CMake proficiency needed to use the SDK as intended? Or if you have a legitimate reason why you can't use CMake (as I do in one of my projects), you can still build the SDK files from a conventional Makefile instead - it's not easy, but again better than re-implementing everything bare metal.
Statistics: Posted by arg001 — Thu Jul 11, 2024 4:43 pm