4 ms·

> There's no idea which peripheral is being manipulated. The Arduino-y function usually maps internal pin mappings (and to the pin numbers on the given PCB. I

> There's no idea which peripheral is being manipulated. The Arduino-y function usually maps internal pin mappings (and to the pin numbers on the given PCB. It's quite clear if you know what you're compiling the code for. Not to mention that how a pin-remapping function works usually doesn't matter, the resulting abstraction is very nice to use. > pioc.oer tells you that you're using the PIOC peripheral, oer tells you're your manipulating the oer register specifically And why should I care about that information when I already have the abstraction written before? The Rust code is much much worse in terms of ease-of-use in this case - manually having to look up how pins on the board map to internal registers is cumbersome. Some of the confusion about the names might also stem from that I expect consistent capitalization when dealing with registers, why would `pioc` be lowercase if it's in reality a register being modified? It's actually weird. I won't even begin how horrible-looking the "expanded" form is, compared to the 2-line C equivalent. One more thing I just now realized, the Rust team made an incredibly bad decision picking the symbols, for example for mutable references. I don't see anyone with any good amount of C experience ever wanting to use Rust if they have to re-learn what `&` really means - useless waste of time for most. It's akin to designing a new safer bike but switching the handlebar direction. And in the end, the amount of symbols in Rust, combined with how annoying they're to type on non-US layouts, combined with the (wrongly) carried over connotations from other languages makes it a terrible replacement for what it's advertised for. > So, for instance, trying to configure the watchdog timer twice on the MCU I'm using will not compile because you don't even have that original object around anymore. That is very cumbersome and illogical. Reconfiguration is quite common. > There's no idea which peripheral is being manipulated. I think that's just your unfamiliarity with the platform and the example you chose. If you'd write the exact same code you brought as an example in C it'd be much clearer than the Rust code and just two lines. I'd love to see the asm of the Rust code.

inferiorhuman 7y ago
Your criticism (e.g. OMG wrong case, OMG C uses & to mean something else) seems mostly centered around the fact that rust isn't C and less around the merits of rust itself. But I'll bite... Some of the confusion about the names might also stem from that I expect consistent capitalization when dealing with registers, why would `pioc` be lowercase if it's in reality a register being modified? Typically in rust screaming snake case is reserved for constants. In this case, pioc is not a register (so there you go). In the context of the embedded stuff the peripherals typically get screaming snake case names at the top level struct. In this example I've configured it and assigned it to a local variable named pioc. That is very cumbersome and illogical. Reconfiguration is quite common. In the example I gave it's not possible. After an initial write to the watchdog's configuration register all subsequent writes are ignored by the MCU. That's the whole point of having compile time checks. If it compiles, it's probably OK. If it doesn't compile you're probably doing something that won't work or won't do what you expect. If you were to take the example something that can be modified you'd still have the functions laying around to modify the register. I think that's just your unfamiliarity with the platform and the example you chose. I think you'd probably want to guess again. Which peripheral is being manipulated? What happens if I get a magic number wrong and that function operates on the wrong peripheral?
- Avamander 7y ago
  > seems mostly centered around the fact that rust isn't C and less around the merits of rust itself. If a language is advertised as a replacement for C/C++ then one can reasonably expect there to be little that works counter-intuitively coming from the to-be-replaced language. > In this case, pioc is not a register (so there you go). "It's in reality a register being modified" is not the same as "it's a register". > After an initial write to the watchdog's configuration register all subsequent writes are ignored by the MCU. If it compiles, it's probably OK. Hardware isn't perfect. You brought up the immutability of the watchdog timer as a benefit, it really isn't, that's all I wanted to say. I also doubt that just a compiling piece of Rust can usually handle a hardware failure or an error. > Which peripheral is being manipulated? What happens if I get a magic number wrong and that function operates on the wrong peripheral? If you already have an Arduino-y abstraction then it doesn't matter in which language it's written, the same opaqueness would happen if you can't look up the pin mapping from documentation. If you really need to see which peripheral is being manipulated then it's not difficult to write two very simple lines of C to do the same thing just as clearly. You're comparing two very different things, it's just not a very good comparison.

inferiorhuman 7y ago

Your criticism (e.g. OMG wrong case, OMG C uses & to mean something else) seems mostly centered around the fact that rust isn't C and less around the merits of rust itself. But I'll bite... Some of the confusion about the names might also stem from that I expect consistent capitalization when dealing with registers, why would `pioc` be lowercase if it's in reality a register being modified? Typically in rust screaming snake case is reserved for constants. In this case, pioc is not a register (so there you go). In the context of the embedded stuff the peripherals typically get screaming snake case names at the top level struct. In this example I've configured it and assigned it to a local variable named pioc. That is very cumbersome and illogical. Reconfiguration is quite common. In the example I gave it's not possible. After an initial write to the watchdog's configuration register all subsequent writes are ignored by the MCU. That's the whole point of having compile time checks. If it compiles, it's probably OK. If it doesn't compile you're probably doing something that won't work or won't do what you expect. If you were to take the example something that can be modified you'd still have the functions laying around to modify the register. I think that's just your unfamiliarity with the platform and the example you chose. I think you'd probably want to guess again. Which peripheral is being manipulated? What happens if I get a magic number wrong and that function operates on the wrong peripheral?

Avamander 7y ago
> seems mostly centered around the fact that rust isn't C and less around the merits of rust itself. If a language is advertised as a replacement for C/C++ then one can reasonably expect there to be little that works counter-intuitively coming from the to-be-replaced language. > In this case, pioc is not a register (so there you go). "It's in reality a register being modified" is not the same as "it's a register". > After an initial write to the watchdog's configuration register all subsequent writes are ignored by the MCU. If it compiles, it's probably OK. Hardware isn't perfect. You brought up the immutability of the watchdog timer as a benefit, it really isn't, that's all I wanted to say. I also doubt that just a compiling piece of Rust can usually handle a hardware failure or an error. > Which peripheral is being manipulated? What happens if I get a magic number wrong and that function operates on the wrong peripheral? If you already have an Arduino-y abstraction then it doesn't matter in which language it's written, the same opaqueness would happen if you can't look up the pin mapping from documentation. If you really need to see which peripheral is being manipulated then it's not difficult to write two very simple lines of C to do the same thing just as clearly. You're comparing two very different things, it's just not a very good comparison.