4 ms·
>"So if people could also do that in C/C++ they are apparently not doing it." Maybe because they do not feel that it is worth doing. It maybe poor decision on
by FpUser 4y ago
>"So if people could also do that in C/C++ they are apparently not doing it."
Maybe because they do not feel that it is worth doing. It maybe poor decision on their side but it has nothing to do with the implementation language. From a practical standpoint - I programmed enough microcontrollers and frankly initializing pin for particular mode before using it is hardwired into my brain. I do not remember ever having this type of error in my code. In the end if you do not like it you can always roll out your very own "safe" version. Just make sure your "safe" version does not have bugs either.
- throwbadubadu 4y agoExactly, this is a lot for something rarely going wrong,.and if going wrong pretty apparent what's wrong.. Also, that approach would need quite some extension for modern capabilities of pins and conflicting options across multiple registers (pin dir, pin mux and what else driver options).. Also what about those pins you really need to be use in both directions (e.g. one wire protocol, or pins where you have your own mux behind), how to do that? The current approach does not look like supporting switching at runtime.. another complexity level added..
- morelisp 4y agoSwitching the pin mode should be exactly what Rust is offering over potentially more advanced C++ solutions, because you can take a "raw" pin as an input pin and ensure you don't use it as an output pin for exactly the duration you have it as an input pin.
- pjmlp 4y agoSame thing in C++, when one actually uses the C++ type system. Rust can be made as unsafe as the C example, by calling digitalWrite() directly, instead of using the language type system.