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