www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - embedded ARM support

reply Andrey <avraliov gmail.com> writes:
Hi guys!!!

I'm very intrested to use D. Tryed to code some simple programs 
for Linux. But now I'm trying to make some ARM embedded solutions.

The main language for this point is C. All involved corporations, 
which research compilers for embedded ARM stuff support C.

How do you think, when we can expect D support for ARM MCU's like 
CMSIS 
(http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-int
rface-standard.php) for C compilers?

I understand, that this is a long way to progress for a new 
ambitious programming language, but perspective to write compile 
time depended code for embedded solutions in friendly environment 
is very attractive ))

Thanks!!!
Nov 09 2015
next sibling parent reply Kagamin <spam here.lot> writes:
https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study like this?
Nov 09 2015
parent reply Andrey <avraliov gmail.com> writes:
On Monday, 9 November 2015 at 08:35:01 UTC, Kagamin wrote:

 https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study like 
 this?


Yes. But I mean the real supported library, with header files, 
registers declarations and so on... That is realy low 
instructions. It is good for experiments and self-affirmation, 
but not usefull for daily work. It't not realy cool to declare 
manualy all needed registers adresses and manualy manage adresses 
for linker
Nov 09 2015
next sibling parent reply Timo Sintonen <t.sintonen luukku.com> writes:
On Monday, 9 November 2015 at 08:49:57 UTC, Andrey wrote:

 On Monday, 9 November 2015 at 08:35:01 UTC, Kagamin wrote:

 https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study like 
 this?


 Yes. But I mean the real supported library, with header files, 
 registers declarations and so on... That is realy low 
 instructions. It is good for experiments and self-affirmation, 
 but not usefull for daily work. It't not realy cool to declare 
 manualy all needed registers adresses and manualy manage 
 adresses for linker


https://bitbucket.org/timosi/minlibd
contains a modified runtime library and a toolset with a working 
example.
It supports many D language features like object creation.

There are some register definitions but it is far from complete.
Suggestions and contributions are welcome.

One thing why the project is going so slowly is the issue with 
accessing peripheral registers. The official D does not want to 
support register access directly, but only with library 
functions. In gdc it is possible with shared variables but this 
feature is unstable.

There are some Cortex-m users hanging here but so far any big 
project has not been made.
Nov 09 2015
next sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 9 November 2015 at 10:14:17 UTC, Timo Sintonen wrote:

 There are some register definitions but it is far from complete.
 Suggestions and contributions are welcome.


https://github.com/JinShil/stm32f42_discovery_demo/tree/master/source/stm32f42
like these ones? Not sure about usage of classes though.
Nov 09 2015
parent Timo Sintonen <t.sintonen luukku.com> writes:
On Monday, 9 November 2015 at 11:39:16 UTC, Kagamin wrote:

 On Monday, 9 November 2015 at 10:14:17 UTC, Timo Sintonen wrote:

 There are some register definitions but it is far from 
 complete.
 Suggestions and contributions are welcome.


 https://github.com/JinShil/stm32f42_discovery_demo/tree/master/source/stm32f42
like these ones? Not sure about usage of classes though.


A little overkill to me but may very well be what op wants.
But this is not the whole thing.

I think this is what op and many others are looking for:
- D compiler that is able to compile code for the target processor
- Build system that uses the compiler, linker etc
- Register and bit definitions
- Library code to do basic operations

It is too much work if everybody writes an own version. We should 
make one complete set and publish that as the official Cortex-m 
toolset. It could be possible to translate existing C headers and 
use the C library but it is also lots of work and the library is 
quite complex.

What made me to look at D in the first place was the ability to 
put register definitions in a struct and then make member or 
property functions to do the basic operations. At this level I 
think it is important to know the actual hex codes of bitfields 
anyway and the bit names are not so important. If this is well 
done, there is little need to use individual bits outside of the 
struct. For example, to use an uart, usually we need only select 
7 or 8 bits and with or without parity. The property functions 
can handle this.
If something else is needed, it is possible to access the 
registers directly. The bit names can be defined even in another 
file and imported when needed. I think enums are suitable for 
that.

What I currently want to add to my library is register 
definitions and basic use of the most common peripherals of the 
most common processor types. A newcomer would then just select 
the processor and build the example and send it to the board.
Nov 09 2015
prev sibling parent reply Taylor Hillegeist <taylorh140 gmail.com> writes:
On Monday, 9 November 2015 at 10:14:17 UTC, Timo Sintonen wrote:

 On Monday, 9 November 2015 at 08:49:57 UTC, Andrey wrote:

 On Monday, 9 November 2015 at 08:35:01 UTC, Kagamin wrote:

 https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study like 
 this?


 Yes. But I mean the real supported library, with header files, 
 registers declarations and so on... That is realy low 
 instructions. It is good for experiments and self-affirmation, 
 but not usefull for daily work. It't not realy cool to declare 
 manualy all needed registers adresses and manualy manage 
 adresses for linker


 https://bitbucket.org/timosi/minlibd
 contains a modified runtime library and a toolset with a 
 working example.
 It supports many D language features like object creation.

 There are some register definitions but it is far from complete.
 Suggestions and contributions are welcome.

 One thing why the project is going so slowly is the issue with 
 accessing peripheral registers. The official D does not want to 
 support register access directly, but only with library 
 functions. In gdc it is possible with shared variables but this 
 feature is unstable.

 There are some Cortex-m users hanging here but so far any big 
 project has not been made.


Maybe I am wrong, But I believe that the low level community is 
awaiting the release of GDC/LDC compatible with 2.067 DMD front 
end. This will allow for volatile store/load. and hopefully begin 
a new era of D micro programming. I'm sure this isn't the whole 
story. but i get the feeling it is a major part of the minimal 
micro-controller involvement.
Nov 09 2015
next sibling parent reply Timo Sintonen <t.sintonen luukku.com> writes:
On Monday, 9 November 2015 at 19:00:32 UTC, Taylor Hillegeist 
wrote:

 Maybe I am wrong, But I believe that the low level community is 
 awaiting the release of GDC/LDC compatible with 2.067 DMD front 
 end. This will allow for volatile store/load. and hopefully 
 begin a new era of D micro programming. I'm sure this isn't the 
 whole story. but i get the feeling it is a major part of the 
 minimal micro-controller involvement.


Yes, that is the problem but the solution is not acceptable. We 
discussed about alternative solutions in gdc forum last year. 
Possibilities are to make something gdc specific or to use a 
custom data type. It was seen good to build this feature somehow 
into gdc but on the other hand there is a need to keep gdc as 
close to dmd as possible.
Nov 09 2015
parent reply Taylor Hillegeist <taylorh140 gmail.com> writes:
On Monday, 9 November 2015 at 20:09:05 UTC, Timo Sintonen wrote:

 On Monday, 9 November 2015 at 19:00:32 UTC, Taylor Hillegeist 
 wrote:

 Maybe I am wrong, But I believe that the low level community 
 is awaiting the release of GDC/LDC compatible with 2.067 DMD 
 front end. This will allow for volatile store/load. and 
 hopefully begin a new era of D micro programming. I'm sure 
 this isn't the whole story. but i get the feeling it is a 
 major part of the minimal micro-controller involvement.


 Yes, that is the problem but the solution is not acceptable. We 
 discussed about alternative solutions in gdc forum last year. 
 Possibilities are to make something gdc specific or to use a 
 custom data type. It was seen good to build this feature 
 somehow into gdc but on the other hand there is a need to keep 
 gdc as close to dmd as possible.


In what way is the solution unacceptable?

Solution is not easy to use.
Solution is does not solve problem.
Solution is not easy/possible to implement.
Can not be implemented in a uniform way.

Just curious? perhaps a link to the discussion would be good 
enough. thanks.
Nov 09 2015
parent Timo Sintonen <t.sintonen luukku.com> writes:
On Monday, 9 November 2015 at 20:24:05 UTC, Taylor Hillegeist 
wrote:

 On Monday, 9 November 2015 at 20:09:05 UTC, Timo Sintonen wrote:

 On Monday, 9 November 2015 at 19:00:32 UTC, Taylor Hillegeist 
 wrote:

 Maybe I am wrong, But I believe that the low level community 
 is awaiting the release of GDC/LDC compatible with 2.067 DMD 
 front end. This will allow for volatile store/load. and 
 hopefully begin a new era of D micro programming. I'm sure 
 this isn't the whole story. but i get the feeling it is a 
 major part of the minimal micro-controller involvement.


 Yes, that is the problem but the solution is not acceptable. 
 We discussed about alternative solutions in gdc forum last 
 year. Possibilities are to make something gdc specific or to 
 use a custom data type. It was seen good to build this feature 
 somehow into gdc but on the other hand there is a need to keep 
 gdc as close to dmd as possible.


 In what way is the solution unacceptable?

 Solution is not easy to use.
 Solution is does not solve problem.
 Solution is not easy/possible to implement.
 Can not be implemented in a uniform way.

 Just curious? perhaps a link to the discussion would be good 
 enough. thanks.


It is not easy to use.
This is just my personal opinion.

There were 3 debates in general forum and some discussions in gdc 
forum. (this is mostly gdc specific anyway) I have no interest to 
start a new debate or dig the archive for old things. If you want 
to search, I think something may be found around september last 
year.
Nov 09 2015
prev sibling next sibling parent David Nadlinger <code klickverbot.at> writes:
On Monday, 9 November 2015 at 19:00:32 UTC, Taylor Hillegeist 
wrote:

 Maybe I am wrong, But I believe that the low level community is 
 awaiting the release of GDC/LDC compatible with 2.067 DMD front 
 end.


LDC 0.16.0 (based on 2.067.1) has been out for two weeks at this 
point, and a testing version has been available for quite a bit 
longer.

  — David
Nov 09 2015
prev sibling parent Mike <none none.com> writes:
On Monday, 9 November 2015 at 19:00:32 UTC, Taylor Hillegeist 
wrote:


 Maybe I am wrong, But I believe that the low level community is 
 awaiting the release of GDC/LDC compatible with 2.067 DMD front 
 end. This will allow for volatile store/load. and hopefully 
 begin a new era of D micro programming. I'm sure this isn't the 
 whole story. but i get the feeling it is a major part of the 
 minimal micro-controller involvement.


Yes, there is much more to the story, but that was indeed a small 
part of it.  The nail in the coffin for me was 
https://issues.dlang.org/show_bug.cgi?id=14758, but even if that 
were to be addressed, there are other things that would keep me 
from further pursuing this.

As I explored using D for this kind of development, it became 
apparent to me that D was not designed from the start with 
minimalism in mind, so trying to use D for this kind of 
development, while possible, is like trying to put a square peg 
into a round hole (as they say).

If D is to attract the microcontroller community, it will need to 
find a way to modularize and reduce coupling between the compiler 
and the runtime.  Proposals to aid with this have, thus far, 
failed to gain support, or come with too many compromises.

I think D can be better applied to microPCs like the Raspberry 
Pi, BeagleBone Black, etc... where there are plenty of hardware 
resources, and all the features of the language may have utility.

Mike
Nov 09 2015
prev sibling parent Mike <none none.com> writes:
On Monday, 9 November 2015 at 08:49:57 UTC, Andrey wrote:

 On Monday, 9 November 2015 at 08:35:01 UTC, Kagamin wrote:

 https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study like 
 this?


 Yes. But I mean the real supported library, with header files, 
 registers declarations and so on... That is realy low 
 instructions. It is good for experiments and self-affirmation, 
 but not usefull for daily work. It't not realy cool to declare 
 manualy all needed registers adresses and manualy manage 
 adresses for linker


If I understand what you are after, I think the best way to use D 
in the way you describe is to compile your board's BSP code in C 
and then link to it from D (http://dlang.org/interfaceToC.html)

You'll still need to implement your own minimal D runtime to get 
things to compile, though, and many of the D language features 
will give you linker errors or runtime errors if used and not 
implemented in your runtime. The links others have already 
provided in this thread should give you what you need to get 
started, if you haven't already lost interest.

Bottom line:  it's possible, but not pretty.

Mike
Nov 09 2015
prev sibling parent ZombineDev <valid_email he.re> writes:
On Monday, 9 November 2015 at 08:20:28 UTC, Andrey wrote:

 Hi guys!!!

 I'm very intrested to use D. Tryed to code some simple programs 
 for Linux. But now I'm trying to make some ARM embedded 
 solutions.

 The main language for this point is C. All involved 
 corporations, which research compilers for embedded ARM stuff 
 support C.

 How do you think, when we can expect D support for ARM MCU's 
 like CMSIS 
 (http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-int
rface-standard.php) for C compilers?

 I understand, that this is a long way to progress for a new 
 ambitious programming language, but perspective to write 
 compile time depended code for embedded solutions in friendly 
 environment is very attractive ))

 Thanks!!!


I think you'll find this talk quite interesting: 
http://dconf.org/2014/talks/franklin.html
Nov 09 2015