21–30 of 96 posts
let mut led = pins.d13.into_input();
let mut led = pins.d13.into_output();
Correct me if I'm wrong, but I see nothing in the Rust example that couldn't just as well be implemented in C++. A comparison to C would have made more sense.
See also https://docs.google.com/document/d/e/2PACX-1vSt2VB1zQAJ6JDMa... for the general case.
I think there's an error in the final block of Rust code. let mut led = pins.d13.into_input(); Should be let mut led = pins.d13.into_output(); I think.
Earlier quoted context omitted.
>"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 t…
Exactly, 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…
>"This looks fine, but what happens if you do not get the pin mode right, for any of many possible reasons?" This is such a contrived and pathetic example. None of it has anything to do with C++ or Rust. It was a decision of whomever wrote pin access libraries. In either of the languages mentioned there is absolutely no problem creating an interface that would return particular pin in "right" state ready to be operat…
Correct me if I'm wrong, but I see nothing in the Rust example that couldn't just as well be implemented in C++. A comparison to C would have made more sense.
It could, but the comparison to Arduino still makes more sense since that's very well known and is pretty much C. It makes very little use of C++ features. Especially advanced stuff like this - probably partly to avoid difficult error messages for beginners and partly because the Arduino developers (the original ones at least) were shit at API design.
import numpy as np
np.linspace(2.0, 3.0, num=5)
But if I do the same in Python, it works and works very well! Python > C++"
Sorry for the troll post, but this really is ridiculous.
Correct me if I'm wrong, but I see nothing in the Rust example that couldn't just as well be implemented in C++. A comparison to C would have made more sense.
>"This looks fine, but what happens if you do not get the pin mode right, for any of many possible reasons?" This is such a contrived and pathetic example. None of it has anything to do with C++ or Rust. It was a decision of whomever wrote pin access libraries. In either of the languages mentioned there is absolutely no problem creating an interface that would return particular pin in "right" state ready to be operat…
I think the author has left out a big piece why Rust enables better interface here: ownership. In C++ could the compile time checks prevent me from creating both an input and output type working on the same pin?
With template metaprogramming those invariants can be done at compile time.
It is a matter of type system design, the whole point of type-level programming.
Earlier quoted context omitted.
Exactly, 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…
Switching 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.
Rust can be made as unsafe as the C example, by calling digitalWrite() directly, instead of using the language type system.