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

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.

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.

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.