Hacker News Reader

Comment by NickPollard | Hacker News Reader

This looks to me to be an important and very promising change. I don't know how much they've had to compromise, but making this easily callable in from C (and hence, easily callable from other languages with C interop) makes it simple to embed rust in other languages and applications.

For example, I'd been looking at doing Rust development for Android; currently native (i.e. C/C++ apps) on Android get run through a Java wrapper; starting a Rust process with the Rust runtime active is incredibly complex. With this change, it should be trivial to have a basic Android activity that just calls a Rust main() and have everything go from there.

View on HN

Does anyone know if this makes using Rust code on an Arduino easier? There's [https://github.com/jensnockert/dueboot] which only works on the Due, not the Uno.

I think the main blocking part there is getting LLVM working on AVR. I believe there is a fork of LLVM that does (https://github.com/sushihangover/llvm-avr), but you would have to merge that fork with the LLVM that Rust uses in order to run Rust on it, and it looks like the fork is a little out of date so it may take some work.

This particular likely doesn't affect running Rust on an Arduino at all, as what it is doing is removing the runtime for std, which contains many of the OS abstractions. You don't have an OS on an Arduino however, so std isn't particularly helpful there. Several months ago they already did what was necessary for that, factoring out much of the completely OS independent functionality into a "core" library (http://doc.rust-lang.org/core/), so you can opt out of using std and use "core" instead, plus add a little bit of platform specific glue, to run Rust on bare metal.

Too bad, I was hoping for easier embedded usage as well. I don't particularly like the Arduino abstractions, too much is hidden, and to get decent performance or ADC precision often requires dropping to low-level C or even assembler.

But the last commit to that fork was just 10 months ago though... might be tempted to have a look during the holidays.

Yeah, as said above, checkout zinc.rs. It runs on ARM MCUs though, but AVRs are becoming legacy anyway.

Aren't AVR and ARM different power envelopes, though? I thought ARM was for small computers and AVR is for things that want to be slightly more complicated than a gearbox.

Cortex-A series is for small computers (eg smartphones etc), Cortex-M is more of a contender for AVR, especially Cortex-M0 which are the smallest ARM cores. There is currently lot of activity around ARM and power-optimization in the industry, while AVRs are generally bit older design.

Just for fun, I picked a semi-random example of ARM mcu from digikey: EFM32ZG110F32[1]. Based on the datasheet it consumes about 8mW when running on full 24MHz speed. Meanwhile the AVR chip used in eg. Arduino Uno[2] consumes about 10mW when running at 8MHz. Of course at these ultra-low power levels there are quite a large amount of variability depending exactly what you are doing and how well your code is made.

[1] http://www.digikey.com/product-detail/en/EFM32ZG110F32-QFN24...

[2] Atmega 328p http://www.atmel.com/devices/atmega328p.aspx

There's a wide range of ARM processors, but you can maybe sort them into three tiers: small AVR-like scale (e.g. Cortex-M), the smartphone speed (e.g. Cortex-A8/9 what most people come into contact with), and edging it's way into the market - the server targeted ARMs.

The small, deeply embedded scale usually runs bare-metal or a small RTOS, while the next tier up often runs Linux. Now the small scale ARM is basically on the fast side (32bit proc) the very low end embedded cpus class. But it's often selected for everything but the most cost or power sensitive applications which tend to go for very small, power sipping 8bit cpus (e.g. MSP430s)

I love it. The day C and C++ die I'll be dancing on their grave and twerking on the tombstone.

Will be hard to find an ARM equivalent for the ultra low power MSPs though.

The new atmel D21 arm looks interesting - 40ua/mhz , and 0.9ua standbay with ram retention and rtc.

With rust-bindgen , you should be able to use vendor supplied HAL written in c quite easily.

Not what you want, but for Arduino safe systems programing one can in the mean time use

Ada, http://sourceforge.net/p/avr-ada/wiki/Home/

Pascal, http://www.mikroe.com/mikropascal/avr/

It's a less general language, but the Ivory language applies, as well. Ivory is a Haskell library that generates C code, so it can piggyback on Haskell's type checker to prove safety but still target a multitude of embedded systems by virtue of producing plain C.

http://ivorylang.org/ivory-introduction.html

Still limited by lack of an LLVM backend for AVR, doesn't make it any easier or harder.

Atmel really should sponsor AVR support for LLVM.

Totally unlikely. They are more likely to deprecate them in favour of Cortex-M's.

I see your point.

The cheapest "large memory" part on Mouser for the ARM arch with an A/D is a Freescale MKL02Z8VFG4 8K flash / 4k ram and a 12 bit A/D is 1.12 qty 1, just above 50 cents qty 500.

The chips Atmel is trying to move are not AVRs; it sounds like a money sink to push a harvard architecture in a von Neumann world.

ARM Cortex chips are better than Atmel in virtually every way. The only sometimes-disadvantage is that they are 3.3V rather than 5V (though that is often an advantage these days).

So I doubt many people will be motivated to work on this.

The dueboot project is rather dead, checkout zinc.rs :)

While it's true that this is a pretty big win, both were already supported. The second production deployment of Rust is a Ruby gem, written in Rust, and we test each commit against Android.

Reply on news.ycombinator.com