Hacker News new | ask | show | jobs
by posborne 4042 days ago
That is the hope, since master is currently out of date.

I have been working with Matt Coffin some on getting this working. Feel free to increase its chances of merging by helping us test any of the supported boards (Freescale K20, NXP LPC17xx, SAM3x (on a branch), STM32F4, STM32l1, TI Tiva C).

I plan on putting together an RFC for how we can modify zinc (or provide documentation) to make it easier for individuals to create both libraries and projects that work well with zinc, but do not require modifying zinc itself.
1 comments
Animats 4042 days ago
Zinc looks very promising. Will it fit on the Arduino Due, which is an ARM system with limited memory?
link
posborne 4042 days ago
Yes, I believe so. The binaries I have built so far have been very small (<2KB for a blink example). mcoffin has a branch with SAM3x support, which appears to be the processor on the Due: https://github.com/mcoffin/zinc/tree/sam3x

The Due has 512KB of room for code which is quite a lot (for microcontrollers).

link
TickleSteve 4042 days ago
2KB to blink LEDS? seriously? this needs to be on the order of a few ten of bytes to be competitive...
link
posborne 4042 days ago
A few points:

* I don't think a few tens of bytes is realistic for a real application that needs to set up the stack, timers, and then blink some LEDs (https://github.com/mcoffin/zinc/blob/new-build/examples/app_... / https://github.com/mcoffin/zinc/blob/new-build/examples/app_...)

* Assuming the code size overhead does not continue to bloat after some initial overhead, I think rust can still be very competitive. Although modern embedded systems are still very constrained, the days of 8-bit micros are basically over. You can buy a 32-bit ARM micro for nearly the same cost with sufficient RAM/Flash to run rust well.

* Looking back, I think the size of blink should actually be closer to 600 bytes. Will need to investigate: http://zinc.rs/stats/

link
rkangel 4042 days ago
That depends on what's in there. My understanding is that that 2Kb is not so much overhead as required dependencies. Dependencies that most real applications would probably end up pulling in anyway, like a dynamic memory allocator.

The end of the market with tiny micros and extremely simple applications (like just blinking LEDs) is likely to never be well suited to Rust, but doesn't gain much from it anyway.

link
Ygg2 4042 days ago
It probably can be lowered by manually linking and similar stuff.

See: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-...

link