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