Basic questions about Dartuino

[Ravi Teja Gudapati]

Hi,

Recently I saw this blog post: http://embeddeddart.blogspot.se/2016/06/dartino-getting-started.html

It totally blew my mind. I have some very basic questions about Dartuino that most embedded developers would have.

1. How large is the final stripped binary compared to baremetal C?

2. Does it extensively use heap? Or does it use mostly Data and BSS sections. There is a notion in embedded industry (atleast in safety related applications) to stay away from using heap (malloc, free, etc). Since most requirements are already known at compile time and to avoid failures due to memory fragmentation (which are very hard to reproduce during tests) or lack of memory.

3. how is GC taken care of?

A not very important but a curiosity question

4. What needs to be done to port it to other architectures? Like maybe PIC32, AVR atmega (can it even run on 8 bit processors?), etc.

Thanks and regards,

Ravi Teja Gudapati.

[Erik Corry]

Hi,

These are all good questions, but we don't have an answer to them all yet.

On 16 June 2016 at 19:46, Ravi Teja Gudapati <teja...@gmail.com> wrote:

Hi,

Recently I saw this blog post: http://embeddeddart.blogspot.se/2016/06/dartino-getting-started.html

It totally blew my mind. I have some very basic questions about Dartuino that most embedded developers would have.

1. How large is the final stripped binary compared to baremetal C?

We'll try to get back with a good number here.  There are a lot of more-or-less optional parts, like the source level debugger, the USB support, the drawing library for the screen of the STM modules etc. and we don't have a number right now for the absolute minimum size.  We have paired it with FreeRTOS and LittleKernel (the LK embedded kernel). As a data point, we do have it running on an STM32F4 board with 256k flash and 128k RAM.

2. Does it extensively use heap? Or does it use mostly Data and BSS sections. There is a notion in embedded industry (atleast in safety related applications) to stay away from using heap (malloc, free, etc). Since most requirements are already known at compile time and to avoid failures due to memory fragmentation (which are very hard to reproduce during tests) or lack of memory.

We try to avoid allocating on the malloc heap, but we haven't been through the system with a fine-toothed comb and there may still be silly places where we use it.  Again, the debugger "doesn' count" since it won't be active on a production system. There's a malloc implementation that we normally use, cmpctmalloc, which is very eager to coalesce adjacent free areas, but of course you can still get fragmentation.

We provide full access to allocation on the C-heap from Dart code running in the VM through our FFI (foreign function interface) API, in order to integrate well with existing C libraries.  However, that part is something that the programmer is in full control of.  An alternative pattern to using BSS could be to allocate what is needed outside Dartino's own heap through malloc during startup.

3. how is GC taken care of?

Dartino has its own heap with its own GC. This is a compacting GC so it is immune to fragmentation.  It is not pauseless.  There are small collections of 1-2 milliseconds and rare large collections at a speed of 10-20k per millisecond (eg 6ms for a 100k heap).  So clearly there are some parts of a system that will be too time-critical to drive directly from Dart code.  The plan is to use threads and FFI calls to write the time-critical parts in C or C++.  FFI support is very rudimentary at the moment, but this is an area that we will continue to improve as interfacing to existing C/C++ code is important to us.

 

A not very important but a curiosity question

4. What needs to be done to port it to other architectures? Like maybe PIC32, AVR atmega (can it even run on 8 bit processors?), etc.

It is 64-bit or 32-bit only at the moment.  16-bit is thinkable, but not planned. 8-bit is impossible.

The only part that needs to be ported is the interpreter, which is not very big.  We have had some contributions to a MIPS interpreter, which is not complete yet.

--

Erik Corry

Google Denmark ApS

Frederiksborggade 20B, 1 sal

1360 København K

Denmark

CVR nr. 28 86 69 84