This looks nice!

Rust is starting to join Ada, Oberon, Pascal dialects compilers in bare metal support.

Good way to dispel the belief only C compilers can do it.

Specially if like Zinc, there is zero C code there.

I'm very exciting to see Rust move into embedded!

Some minor comments: The page includes example code. I worry that it might be abstracting TOO much away, while at the same time hiding details.

For example, in the main oscillator example, you still would have to consult deep in the manual to understand what m, n and divisor do if you wanted to change the frequency. I think if you're going to use a library, it would be cool to operate at a higher level than this.

Also notice in the timer example, you still have no idea what frequency the timer will run at! Maybe I just want something higher-level built on top of this? Maybe I should implement libopencm3 on top of this?

p.s. Crazed fans of the greatest microcontroller of all time, the stm32f4, check out http://reddit.com/r/stm32f4 and http://diydsp.com/livesite/pages/stm32f4

>http://diydsp.com/livesite/pages/stm32f4

Very cool page! Great links to some amazing projects on the stm32f4.

I see you mention Lua and JavaScript on the stm32f4, have you seen micropython running on it?

https://github.com/micropython/micropython/wiki/Board-STM32F...

Wow. I didn't know that was possible! Ima haveta try it. You can easily see I'm obsessed. I'll add it now.

Seriously, a chip like this hasn't been out in a long time. Sure there are more powerful ones like the BeagleBoards and RPis, but they require more support hardware, space, components and power. Hell, the stm32f4 can run with just a few capacitors and no external crystal, and still have 24 analog inputs, two analog outputs and floating point. Plus it has internal cache so it can run at 168+ MHz and DMA, etc.

I read that they will be release a new $1 stm32f4 mcu using a new process soon.

http://www.st.com/web/en/news/n3547

BTW , my mistake , it's stm32f3 , altough it's cortex-m4. a bit weird naming.

At some point I realised that abstracting to the level of "source_frequency" and "out_frequency" is too fragile, That will be going away in some places, will be added in another, where applicable. You are going to specify the exact PLL configuration, but zinc will compute the clocks for e.g. timer or UART based on frequency or baud rate.

> p.s. Crazed fans of the greatest microcontroller of all time, the stm32f4

The greatest until you need to do something complex with both DMA peripherals. Yay for silicon bugs and using tons of third party IP cores without proper testing.

A came upon this the other day, and was so impressed that I'm about to drop $60 on an lpc1768, which is the primary MCU they are using at the beta stage (they plan to expand to others once the API is solidified).

They also have used an stm32f4, which I do have at the moment, but support for it seems to have dwindled over the past few months.

But I really like the safe way they are developing the API. Even the hardware configuration is done as a safe DSL. Very impressive.

This project looks like a great foundation for a realtime OS in Rust I've been itching to try my hand at.

> I'm about to drop $60 on an lpc1768

I usually buy them at ~$3 a piece...

Yeah, I should have specified the eval board, which includes peripherals. This Zinc project already has support for several of the peripherals, including a few TFT drivers, which I want to be able to try out.

I don't always buy eval boards -- if a chip comes in a DIP package, I've just breadboarded it in the past. As a hobbyist, I haven't yet tried to build a breakout board for any SMT-mounted chips, but it's on my todo list.

The one I'm looking at (by RioRand) is not a bad deal, since it actually includes a 2.8 inch TFT on the board as well as Ethernet interface. But I did consider just buying the chip and breadboarding it. I may still do that and buy the LCD separately.

$60 would indeed be expensive for the chip alone.

BTW, you cand find cheaper boards or with more peripherals from China, just check out eBay or aliexpress

Yeah, I know I can probably get the eval board a bit cheaper -- I've bought chips from China on ebay and frequently look at TFT LCD displays on aliexpress while dreaming of a commercial product I'd love to do some day.

But in this case, I don't want to wait 2-4 weeks for delivery. The RioRand will be here in 2 days since it's on Amazon Prime.

He means the demo board: http://www.nxp.com/demoboard/OM11043.html

Can someone clarify two things please?

Firstly, bare metal here means this stack can create an img with an executable that will be run with nothing more the uboot? I.e. No OS, no kernel, not even a Rust runtime (hence, presumably, no std in the example)?

Secondly, can anyone recommend a good reference to get a handle on platform trees? I first came across them on my beagle bone. My understanding it was mostly because Linus got fed up of hundreds of patches for each and every ARM board.

>Firstly, bare metal here means this stack can create an img with an executable that will be run with nothing more the uboot? I.e. No OS, no kernel, not even a Rust runtime (hence, presumably, no std in the example)?

Yes, that is correct. No OS, no kernel, no runtime. Now, Rust is isolating a core library (called libcore) that can be used without runtime support (and hence in projects like this one).

To be pedantic, from compiler design point of view, that is also a runtime.

Well, it uses the libc runtime [This is actually mostly incorrect, see comment below by dbaupp], which obliges me to invoke the old quote, "the greatest trick C ever played was to convince the world it has no runtime".

I wish I could track down the originator of that quote, but I have no idea. I'm sure someone here will know.

Libcore doesn't use the (entire) libc runtime; IIRC, it essentially just needs the memcpy and memset symbols to be defined.

Why not just implement those in Rust too? It seems like you could break the dependency entirely.

Yes, you can, and they are even provided in pure Rust for exactly that reason: http://doc.rust-lang.org/master/rlibc/

(Seems there were 2 more mem* symbols required than I remembered.)

You can implement those in Rust if you want.

Couldn't it use librlibc then?

Yes, that's exactly what librlibc is for and what is used.

The runtime really isn't mandatory, though. It's entirely feasible to have an embedded system where the only code that runs is your own.

I'll agree that glibc is a much larger iceberg than people think, though.

Yes, now we have to make the world understand what a lie it was.

Zinc doesn't really need u-boot too. So far we're targeting smaller MCUs that don't even run "big" OSes like Linux, but there's absolutely no problem in running zinc on e.g. RPi.

Zinc includes it's own preemptive scheduler, so, effectively it's an OS for user-defined tasks, as it does manage the hardware resources.

Platform trees in zinc are not really the same as devices tress in linux. Initially I tried to use linux device tree specification but in progress I realised, that zinc doesn't need some things and needs others. And with all the changes there's no reason to keep similar syntax.

First question: I don't know but I interpreted it the same as you.

Second question: The "platform trees" described in this post are not exactly the same as the "device trees" used by Linux on ARM (and also MIPS I think?). They are essentially the same concept, but device trees have their own DSL amd binary format. They are basically descriptions of the hardware om a system: the CPUs, the RAM, the peripherals. It allows the same kernel image to boot on multiple systems by intwrpreting the devicetree at boot time, rather than having to embed info about the system at compile time. You can get more info about device trees (a.k.a FDTs where F stands for "flattened") on devicetree.org and elinux.org.

Yes, that is usually what bare metal means.

Zinc doesn't rust though.

ED: Read the correction below.

That is almost incorrect. Zinc is used as a plating because it corrodes preferentially to steel, and in doing so it removes electrons needed for oxidation and thus prevents the steel from rusting. This is why you can stop a ship hull rusting by simply bolting a block of zinc to it.

I read ages ago that the Sydney Opera House uses sea water for air conditioning, and has a sacrificial zinc anode.

I think it's unfortunate that LLVM has no first-class public targets smaller than ARM to help guard against ‘all the world's a VAX’ pitfalls. There are/were projects for MSP430 and AVR but it's not practical to keep up with LLVM without full-time developers.

As I understand, MSP430 is such first-class target. MSP430 is in-tree and maintained.

Great domain name for a project.

Is anyone here actually using Rust in a "real-world" situation? My impression is that is gaining traction, yet is not yet stable enough for production use. Anyone have experience to say otherwise?

There are three production deployments of Rust: OpenDNS, something I always forget, and Tilde, for Skylight.io.

(I'm starting to think it's only two and my brain made up the mysterious second one)

That said, you have to be a certain kind of person to use a pre-release programming language in production.

The best kind of person. :)

((Members of) Tilde are writing Rust's awesome new package manager, Cargo: http://crates.io/ )

Right, which was great, as "We already use Rust in production" combined with "we built Bundler" is a pretty decent pitch.

Sweet, thanks for the reply!

You say pre-release, is there a set release schedule for Rust?

The aim for 1.0 is for the end of this year; it will offer backwards compatibility at the language level (syntax and semantics of language constructs), and a subset of the standard library. The rest of the library will stabilised progressively.

(The compiler warns/errors when using a nonstable language or library feature, so it will be easy to stick to the stable parts, or at least know what may need to be adjusted when updating. The goal is to a strict semantic versioning plan too.)