4 ms·

I would love to see into the future and know if Rust adoption will meet or exceed C adoption in the microcontroller space. Right now, it seems like the trend se

by uticus 3y ago

I would love to see into the future and know if Rust adoption will meet or exceed C adoption in the microcontroller space. Right now, it seems like the trend seems to be going more towards greater adoption of high-level/scripting languages (MicroPython especially), instead of replacing C with another "low level"* language. Now, replacing a MicroPython written in C, with a MicroPython written in Rust? I can easily see that. * I know some consider C high level, especially if you are writing Assembly.

jemynine 3y ago
Really high level (as in visual programming) is actually the most optimal way to do some of the embedded programming - in particular when it comes to the setup/configuring part. Setting up the clock tree, configuring pins/port functions, enabling peripheral clocks, interrupts (which ones and their priority levels), fixing erratas, etc. All of that should at the end of the day come down to a couple loads/stores to some memory mapped registers, and these registers are usually "wide" where they contain N bits to set N things - so if you design a C (or rust) api something like this: enable_clock(int clock_id); You wont get optimal code for: enable_clock(FOO); enable_clock(BAR); Because if FOO and BAR are both enabled by setting bit 3 and 7 in register X you get two loads, two bitwise or's and two stores when a single store with a single constant would have sufficed. So fire up a GUI program that lets you click on "enable FOO, enable BAR", "set main clock to crystal oscillator at N MHz, enable PLL x4, etc", have that generate optimal code and go from there.
- uticus 3y ago
  makes sense. did you have in mind something like makecode[0], something else, or wishing for something that hadn't been invented yet? [0] https://makecode.adafruit.com/ https://makecode.adafruit.com/
- yakubin 3y ago
  Or you could write an API like set(FOO | BAR) and get the same benefit for comparably basically no cost (+ now you get nice diffs in git).
  - uticus 3y ago
    good point on nice diffs. collaborative work (using git or other source control) is really why text is king. there's no good way to collaborate, compare, etc with a low-code format.
  - jackieooh 3y ago
    Problem is that some registers have non-zero default values (swd debug pin functions for example) so the set() function would still need to do a read modify write operation which isn't the theoretically optimal code gen.
    - yakubin 3y ago
      Then it’s a question of annotating this function with ALWAYS_INLINE and letting the compiler optimise it.
pjmlp 3y ago
A reason being that many of those microcontrollers happen to be more powerfull than the 8 and 16 bit home computers that we were coding in BASIC, AMOS, Modula-2, Pascal, C, C++, Clipper, Lisp, Forth,.... While Python has taken over BASIC's role from those days.

by uticus 3y ago

jemynine 3y ago

Really high level (as in visual programming) is actually the most optimal way to do some of the embedded programming - in particular when it comes to the setup/configuring part. Setting up the clock tree, configuring pins/port functions, enabling peripheral clocks, interrupts (which ones and their priority levels), fixing erratas, etc. All of that should at the end of the day come down to a couple loads/stores to some memory mapped registers, and these registers are usually "wide" where they contain N bits to set N things - so if you design a C (or rust) api something like this: enable_clock(int clock_id); You wont get optimal code for: enable_clock(FOO); enable_clock(BAR); Because if FOO and BAR are both enabled by setting bit 3 and 7 in register X you get two loads, two bitwise or's and two stores when a single store with a single constant would have sufficed. So fire up a GUI program that lets you click on "enable FOO, enable BAR", "set main clock to crystal oscillator at N MHz, enable PLL x4, etc", have that generate optimal code and go from there.

uticus 3y ago
makes sense. did you have in mind something like makecode[0], something else, or wishing for something that hadn't been invented yet? [0] https://makecode.adafruit.com/ https://makecode.adafruit.com/
yakubin 3y ago
Or you could write an API like set(FOO | BAR) and get the same benefit for comparably basically no cost (+ now you get nice diffs in git).
- uticus 3y ago
  good point on nice diffs. collaborative work (using git or other source control) is really why text is king. there's no good way to collaborate, compare, etc with a low-code format.
- jackieooh 3y ago
  Problem is that some registers have non-zero default values (swd debug pin functions for example) so the set() function would still need to do a read modify write operation which isn't the theoretically optimal code gen.
  - yakubin 3y ago
    Then it’s a question of annotating this function with ALWAYS_INLINE and letting the compiler optimise it.

pjmlp 3y ago

A reason being that many of those microcontrollers happen to be more powerfull than the 8 and 16 bit home computers that we were coding in BASIC, AMOS, Modula-2, Pascal, C, C++, Clipper, Lisp, Forth,.... While Python has taken over BASIC's role from those days.