Zinc – Rust’s safety features applied to embedded development

http://zinc.rs/

by sanxiyn • 12 years ago

147 40 12 years ago

zinc.rs

pjmlp4• 12 years ago

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.

nwh• 12 years ago

Zinc doesn't rust though.

ED: Read the correction below.

unfamiliar• 12 years ago

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.

marcosscriven2• 12 years ago

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

marcosscriven2• 12 years ago

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.

bjackman• 12 years ago

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.

eric_bullington6• 12 years ago

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).

pjmlp4• 12 years ago

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

pjmlp4• 12 years ago

Yes, that is usually what bare metal means.

farcaller2• 12 years ago

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.

gchp2• 12 years ago

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?

steveklabnik2• 12 years ago

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.

dbaupp5• 12 years ago

The best kind of person. :)

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

gchp2• 12 years ago

Sweet, thanks for the reply!

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

pestaa• 12 years ago

Great domain name for a project.

eric_bullington6• 12 years ago

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.

omgtehlion2• 12 years ago

I'm about to drop $60 on an lpc1768

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

bluefinity• 12 years ago

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

eric_bullington6• 12 years ago

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.

diydsp2• 12 years ago

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

eric_bullington6• 12 years ago

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...

diydsp2• 12 years ago

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.

akiselev• 12 years ago

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.

farcaller2• 12 years ago

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.

kps• 12 years ago

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.

sanxiyn• 12 years ago

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

Zinc – Rust’s safety features applied to embedded development

Related Stories