www.digitalmars.com         C & C++   DMDScript  

D.gnu - Embedded D, top down?

reply "Henri Sundelin" <henri.sundelin iki.fi> writes:
Hello folks,

I'm trying to evaluate a possibility to use D for an embedded 
case. We want to use the same application base from the high end 
to the low end. In this case high end means full Linux server, 
and low end must be a single chip solution, with no OS. Processor 
families may vary, only thing certain is GCC backend.

High end side is obviously a no brainer, but the low end stuff is 
a big question. We do have a requirement for OO programming and 
design by contract pre/postconditions etc. OO requirement is 
actually not too heavy, models are not dynamic or complicated, 
but are suitable for embedded in "object-based" sense what Ada83 
talked about in the olden days..

I've been trying to find what has been done in the D embedded 
area so far, and the issue turns always to the runtime itself. 
However I've not been able to find complete runtimes meant for 
embedded applications, just either full-blown or just bare-bones 
minimum stuff.

My big question is:
- is there any suitable runtime currently available for embedded?
- How much RAM would be needed for such runtime in real life?

So if anyone is working on these fronts, I'd appreciate any 
input..:)

//Henri
Feb 17 2015
parent reply "Timo Sintonen" <t.sintonen luukku.com> writes:
On Tuesday, 17 February 2015 at 22:07:38 UTC, Henri Sundelin 
wrote:

 Hello folks,

 I'm trying to evaluate a possibility to use D for an embedded 
 case. We want to use the same application base from the high 
 end to the low end. In this case high end means full Linux 
 server, and low end must be a single chip solution, with no OS. 
 Processor families may vary, only thing certain is GCC backend.

 High end side is obviously a no brainer, but the low end stuff 
 is a big question. We do have a requirement for OO programming 
 and design by contract pre/postconditions etc. OO requirement 
 is actually not too heavy, models are not dynamic or 
 complicated, but are suitable for embedded in "object-based" 
 sense what Ada83 talked about in the olden days..

 I've been trying to find what has been done in the D embedded 
 area so far, and the issue turns always to the runtime itself. 
 However I've not been able to find complete runtimes meant for 
 embedded applications, just either full-blown or just 
 bare-bones minimum stuff.

 My big question is:
 - is there any suitable runtime currently available for 
 embedded?
 - How much RAM would be needed for such runtime in real life?

 So if anyone is working on these fronts, I'd appreciate any 
 input..:)

 //Henri


please have a look at
https://bitbucket.org/timosi/minlibd
There are several readme files that explain various aspects of 
using D in small systems.
It has a working example for stm32f4 but should be easy to use 
with any suitable processor. I have recommended 64/64k rom and 
ram but it could work with 32/32. It might work with smaller 
memory but the prices of bigger processors are so low nowadays 
that I have not yet done any work in this area.

I just got the first prototypes of our stm32 usb stick boards. 
There will be at least stm32f0 and f4 boards available in 2 
months and at least the f4 board will have support for D. They 
are sold at reasonable price and we may provide free samples to 
the users of this forum.

Installing gdc for cross compiling may be a difficult task. We 
will provide a compiler server with some peripheral libraries. 
The service is free for evaluation use.

Check the documentation in the repo. Do not hesitate to ask if 
you still have something you want to know.
Feb 18 2015
parent reply "Henri Sundelin" <henri.sundelin iki.fi> writes:
Hi Timo,

Thanks for the info! I looked the minlibd, the biggest question 
for me is whether it targets too small devices, taking out the 
most of phobos functionality in the process? What are your 
ultimate goals?

My embedded target spec looks something like 256k RAM/256M flash, 
so I'd expect it to be possible to bring of plenty of phobos 
onboard? What I need is full OO, templates, string processing 
etc.. we want to (de)serialize JSON a lot. Malloc is provided. 
Threading, networking etc stuff is not required.
Feb 20 2015
parent "Timo Sintonen" <t.sintonen luukku.com> writes:
On Friday, 20 February 2015 at 19:51:16 UTC, Henri Sundelin wrote:

 Hi Timo,

 Thanks for the info! I looked the minlibd, the biggest question 
 for me is whether it targets too small devices, taking out the 
 most of phobos functionality in the process? What are your 
 ultimate goals?


While my personal interests are in stm32 processors, the goal of 
the library project is:
- to be able to run D programs in any platform without operating 
system support
- to change the standard library as little as possible
- to get the changes in the stardard library when possible


 My embedded target spec looks something like 256k RAM/256M 
 flash, so I'd expect it to be possible to bring of plenty of 
 phobos onboard? What I need is full OO, templates, string 
 processing etc.. we want to (de)serialize JSON a lot. Malloc is 
 provided. Threading, networking etc stuff is not required.


One big thing here is the lack of gc. All allocated objects must 
be freed manually. Many library functions use gc allocated data 
internally and they may not be freed. There is work going on to 
remove gc data in labrary functions.
Otherwise objects wotk fine. Templates are a compile time feature 
and not depending on target.

Many phobos features require support from operating system or on 
libc which in turn depends on the operating system. There are 
features like string functions that could be used. The issue is 
that phobos files usually import several files that in turn 
import other files. In the chain there may always be a file that 
can not be compiled. There is active work going on to reduce the 
amount of imports. This will make easier to port phobos and so I 
have not hurried with phobos yet.
Feb 20 2015