Rust support AVR friendly now

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks @dylanmckay contribution.

I track for a long time and now it can work friendly now.

I just search and only four topic discuss about Rust, so I post here.

 

 

Here is the beginning:

 

# The avr-rust Project Homepage

An open source project adding AVR microcontroller support to Rust.
![](https://www.avr-rust.com/res/ima...)

The avr-rust compiler, once existing as a [fork](https://github.com/avr-rust/rust), has since been merged into upstream Rust as of July 2020.   
The standard Rust nightly compiler can be used to compile crates for AVR - no compiling from source required.

The recommended way to use avr-rust is via [rustup](https://www.avr-rust.com/#instal...) using the official nightly version of the Rust compiler.

Last Edited: Fri. Aug 7, 2020 - 03:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rust is something that it is usually bad, why is it good for AVRs?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's quite a 'fashionable' language but it does has some interesting capabilities compared to other languages. It's a 'curly bracket' language and should be pretty familiar to many programmers.

 

https://en.wikipedia.org/wiki/Rust_(programming_language)

Rust is a multi-paradigm programming language focused on performance and safety, especially safe concurrency. Rust is syntactically similar to C++, and provides memory safety without using garbage collection.

Rust is designed to be memory safe, and thus it does not permit null pointers, dangling pointers, or data races in safe code. Data values can only be initialized through a fixed set of forms, all of which require their inputs to be already initialized.

Of course, having used C, and later C++, for 30 years, I never have null pointer errors ;)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm comfortable with ASM with AVR, anything else is an overkill wink

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I looked at Rust, but it does nothing for me. I will keep using C,  Python, and a tiny itty bitty smattering of javascript.

 

Perhaps I will look more favorably after it is renamed stainless.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My sense is that it tries to address the deficiencies of C++, Java, C# and Python, all of which have been around for a while (20+ years) without much competition.

 

 - C/C++, high performance, concurrent, but not safe mainly due to pointers

 - Java and C#, safe but use managed memory and garbage collection, so unpredictable performance in real-time scenarios

 - Python, safe but it's interpreted (hence 10x slower and memory hungry) and rubbish at concurrency (due to the global interpreter lock)

 

Embedded has arguably stuck with C/C++ (and its risks/deficiencies) because nothing 'better' came along.

 

Clearly, Rust won't replace C++ overnight, but that's it's target, with an emphasis on memory safety, concurrency and performance.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
 - C/C++, high performance, concurrent, but not safe mainly due to pointers

 

Mainly due to improper use of pointers, and careless use of another hundred or so programming or style idioms (see MISRA).

 

C is not an unsafe language, any more or any less than using machine code direct on the part, or interpreting basic or python or compiling rust or whatever... the issue I have with any of the higher level abstractions is that there are way too many layers between the metal and the designer; there are too many libraries you have to trust have been correctly and completely tested, and too many levels of things calling things calling things. With C you have a well-defined API with well-known issues and with the aid of static testing and compliance with e.g. MISRA style rules it is easy to obtain a compliant and safe program (though if your program logic is wrong, that is, as always, your issue), particularly for embedded work.

 

Also, modern C compilers work well at catching many of the existing issues (I don't include MS's _CRT_SECURE_NO_DEPRECATE nonsense - many of the things it would rather you did are equally dangerous as those it would have you replace, and make the code non-portable) particularly if you set warnings as errors. In the case of embedded software, (which I generally take to mean code that doesn't run under a higher level operating system) then you would not use many of the more dangerous constructs (memory allocation being a big one in this respect) but use C as it was intended - a high level portable assembler. Use if for the program flow control and the arithmetic...

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wasn't justifying it, merely reporting my sense of its objectives :) It seems reasonable to imagine a 'better' C/C++ that avoids some of the pitfalls, whilst retaining the efficiency.

 

The thrust of Java and C# have always been about making programmers cheaper and more productive. Why wait for 20 years for someone to become an expert and then pay them a fortune ? Most commercial development is about getting functional product out the door as quickly as possible and at the lowest cost. </cynic>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When an "inherently safe" programming language is a requirement wasn't the default choice always ADA ? Despite it's vintage it's still not particularly accessible.

 

https://hackaday.com/2019/09/10/why-ada-is-the-language-you-want-to-be-programming-your-systems-with/

 

Is RUST just a "flavour-of-the-month" or a serious contender.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

https://en.wikipedia.org/wiki/Rust_(programming_language)

Rust has been the "most loved programming language" in the Stack Overflow Developer Survey every year since 2016.

It makes sense to take advantage of what academic research and experience have produced in the decades since C++, Java, C#, etc appeared.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
C is not an unsafe language, ...
C can be safe by applied formal methods.

barnacle wrote:
Also, modern C compilers work well at catching many of the existing issues ...
and are improving

 


Frama-C | Features

https://www.avrfreaks.net/forum/what-static-code-analysis?page=1#comment-2970796

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
It seems reasonable to imagine a 'better' C/C++ that avoids some of the pitfalls, whilst retaining the efficiency.
Checked C

https://www.avrfreaks.net/forum/jack-ganssles-reason-4-why-embedded-software-projects-run-trouble#comment-2555411

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does Rust depends on dynamic memory allocation to generate space for objects (like Python, etc.)?   If so, then life in the embedded world may be tough.

The problem is not just having enough memory, it's the risk of fragmenting the heap the point where large object's can't be allocated anymore.

Last Edited: Sun. Aug 9, 2020 - 01:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:
When an "inherently safe" programming language is a requirement wasn't the default choice always ADA ?
No as Ada is conditionally safe, more safe by restricting the run-time (profiles), and safe by applied formal methods (SPARK)

N.Winterbottom wrote:
Despite it's vintage it's still not particularly accessible.
Ada has some traction (finally)

N.Winterbottom wrote:
Is RUST just a "flavour-of-the-month" or a serious contender.
riser

 


4. The Predefined Profiles — GNAT User's Guide Supplement for Cross Platforms 21.0w documentation via GNAT | Documentation - AdaCore

The Programming Language | SPARK Overview — learn.adacore.com

Witnessing the Emergence of a New Ada Era - The AdaCore Blog

Rust | TIOBE - The Software Quality Company

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Box, stack and heap - Rust By Example

All values in Rust are stack allocated by default. Values can be boxed (allocated on the heap) by creating a Box<T>.

...

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But Rust is 'multi-paradigm' so it must be the best.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If rust puts vars on the stack, then that sucks for RISC processors. You want your vars in registers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Rust Programming Language | The Embedded Muse 405

by James Munns [Ferrous Systems GmbH (Berlin, Germany), Managing Director]

[end of fourth paragraph]

Rust has built-in support for FFI interoperability with other languages, making it straightforward to combine languages like Rust and C within a single project.

 

[in sixth paragraph]

Currently, Rust supports bare-metal [multiple CPU] and more recently, Atmel's AVR architecture.

 

Ferrous Systems GmbH is the largest software consultancy worldwide focused on the Rust Programming Language. Ferrous Systems provides services in advising, development, and training, and has experience developing embedded systems and systems level software in Rust.

 


Ferrous Systems

 

FFI - Foreign Function Interface

FFI - The Rustonomicon

 

Platform Support - The rustc book

MIPS is present so a port to PIC32 is doable.

PIC24/dsPIC would be an effort.

 

"Dare to be naïve." - Buckminster Fuller