digitalmars.D - D in MPLAB FOR PIC32
- Igor Myronov (6/6) Jan 06 2017 Hi there comunity !!!
- Ignacious (10/16) Jan 06 2017 It would be nice, but I seriously doubt it. There used to be a
- Mike (86/88) Jan 06 2017 D has 3 compilers DMD, LDC, and GCC,
- Iain Buclaw via Digitalmars-d (8/56) Jan 08 2017 No, -betterC is not a dialect, it just tells the compiler not to
- tomsmith (3/78) Jun 23 2019 You can find the controller here
Hi there comunity !!! Im an beginner in programming MCU ,but i'm already programming in D and also here im an absolute beginner. So ,my question is : Is possible to program in D micro*-controllers like the PIC32 ? Thanks to all.
Jan 06 2017
Ignacious <I.D.T ProjectMaya.com> On Friday, 6 January 2017 at 15:47:21 UTC, Igor Myronov wrote:Hi there comunity !!! Im an beginner in programming MCU ,but i'm already programming in D and also here im an absolute beginner. So ,my question is : Is possible to program in D micro*-controllers like the PIC32 ? Thanks to all.It would be nice, but I seriously doubt it. There used to be a c++ compiler for the PIC16/24 that worked well but was discontinued. There are, of course, C compilers so maybe there is a way to hijack the toolset to do it(IIRC they convert the c (to obj) to assembly then run the assembler on that to create the binary http://www.microchip.com/forums/m793665.aspx) If that is the case, then maybe D could used somehow. I doubt it though, probably require adding the pic instruction set to the D compiler.
Jan 06 2017
On Friday, 6 January 2017 at 15:47:21 UTC, Igor Myronov wrote:Is possible to program in D micro*-controllers like the PIC32 ? Thanks to all.D has 3 compilers DMD, LDC, and GCC, DMD only has a backend for Intel CPUs. LDC uses the LLVM backend, but I don't see an LLVM backend for PIC. GDC uses GCC's backends, but again, I don't see a backend there for PIC either. LLVM and GDC both, however, have backends for other microcontrollers, specifically ARM Cortex-M (search for ST Discovery[1], Teensy, Adafruit Feather, Arduino Zero). There was even some success a few years back testing D on an Atmel AVR [2]. The Arduino 101 [3] uses an Intel Quark MCU, so it may be possible to program that using DMD, but to my knowledge, noone has tried. [1] - D on ST Discovery - https://github.com/JinShil/stm32f42_discovery_demo [2] - D on Atmel AVR - https://github.com/D-Programming-microD/avr-playground [3] - Arduino 101 - Intel Quark MCU - https://www.arduino.cc/en/Main/ArduinoBoard101 That all being said, as being one spent some time exploring D on microcontrollers, I can't recommend it. The problem is that the D compiler is tightly coupled to the D runtime, and expects a full-featured runtime in order to get build [4] [5] (even if your code doesn't make use of the features). I'm the one who wrote the previously mentioned ST Discovery proof of concept [1], and in order to reduce code bloat from the D runtime, I had to compile to assembly, use a sed script [6] to modify the assembly, and then recompile the assembly to the binary. Sometimes it didn't even work. The binary was 600K without the sed script, and 6K after the sed script. There is no way such huge binary sizes can be used for microcontrollers, and the hacks to get around it are just too ridiculous for me recommend D for this kind of work. An issue [7] for this problem was created, but the solution wasn't implemented properly to allow the LDC and GDC backends to benefit. And since DMD doesn't support ARM Cortex-M, it was essentially useless. [4] - Demonstration of D compiler-runtime coupling - http://forum.dlang.org/post/kfspvnrbykweyowjtkkl forum.dlang.org [5] - D compiler-typeInfo coupling - http://forum.dlang.org/post/nevipjrkdqxivoerftlw forum.dlang.org [6] - Sed command to reduce code bloat - https://github.com/JinShil/stm32f42_discovery_demo/blob/master/build.d#L69 [7] - TypeInfo code-bloat issue - https://issues.dlang.org/show_bug.cgi?id=14758 DMD has a switch called -betterC [8] which was intended to use a C-like dialect of D, but it was never fully implemented. One problem with the whole idea of the -betterC switch is it's not granular enough to disable only some features, but not others, so its not a good solution anyway. I believe there are better solutions [9]. [8] - An interesting read on the -betterC switch - http://arsdnet.net/this-week-in-d/2016-oct-09.html [9] - Proposal to decouple D compiler from D runtime - http://forum.dlang.org/post/psssnzurlzeqeneagora forum.dlang.org The 2017H1 vision document [10] mentions two items ('Templatize dmd <-> druntime API' & 'Better support for C-style libraries with light or no runtime') that will help this situation, but they are not high priority. The latter is not well-defined enough for anyone to do any real work without facing an uphill battle justifying their changes to others. D places a disproportionate high priority on stabilization, so any changes that may improve matters, but will cause too much disruption, will likely not be accepted. [10] - 2017H1 D Vision - https://wiki.dlang.org/Vision/2017H1 Due to D's shortcomings in this domain, so I have been exploring Rust. Rust has placed a high priority on ensuring it has a minimal runtime [11], so microcontroller programming in Rust is really taking off [12] [13] [14]. [11] - Rust "minimal runtime" as a priority feature - https://www.rust-lang.org/ [12] - Rust Embedded Community on Github - https://github.com/rust-embedded [13] - Discover - Tutorial for Programming Microcontrollers in Rust - https://japaric.github.io/discovery/ [14] - Tock - OS for Microcontrollers in Rust - http://www.tockos.org/ I greatly miss many of the nice features of D (modeling power, metaprogramming, etc...), but Rust is gaining ground [16] [17], and, IMO, has a bright future in the micocontroller world. [16] - Efficient Code Reuse in Rust - https://github.com/rust-lang/rfcs/issues/349 [17] - Procedural Macros in Rust - https://github.com/rust-lang/rfcs/blob/master/text/1566-proc-macros.md Nim [18] may also be a good language for programming microcontrollers, but I haven't spend much time on it. [18] - Nim programming language - http://nim-lang.org/
Jan 06 2017
On 7 January 2017 at 01:39, Mike via Digitalmars-d <digitalmars-d puremagic.com> wrote:On Friday, 6 January 2017 at 15:47:21 UTC, Igor Myronov wrote:No, -betterC is not a dialect, it just tells the compiler not to generate module info. Making it also mean to tell the compiler not to generate any RTTI would be an improvement, but then you have every runtime function depending on RTTI. :-) IainIs possible to program in D micro*-controllers like the PIC32 ? Thanks to all.D has 3 compilers DMD, LDC, and GCC, DMD only has a backend for Intel CPUs. LDC uses the LLVM backend, but I don't see an LLVM backend for PIC. GDC uses GCC's backends, but again, I don't see a backend there for PIC either. LLVM and GDC both, however, have backends for other microcontrollers, specifically ARM Cortex-M (search for ST Discovery[1], Teensy, Adafruit Feather, Arduino Zero). There was even some success a few years back testing D on an Atmel AVR [2]. The Arduino 101 [3] uses an Intel Quark MCU, so it may be possible to program that using DMD, but to my knowledge, noone has tried. [1] - D on ST Discovery - https://github.com/JinShil/stm32f42_discovery_demo [2] - D on Atmel AVR - https://github.com/D-Programming-microD/avr-playground [3] - Arduino 101 - Intel Quark MCU - https://www.arduino.cc/en/Main/ArduinoBoard101 That all being said, as being one spent some time exploring D on microcontrollers, I can't recommend it. The problem is that the D compiler is tightly coupled to the D runtime, and expects a full-featured runtime in order to get build [4] [5] (even if your code doesn't make use of the features). I'm the one who wrote the previously mentioned ST Discovery proof of concept [1], and in order to reduce code bloat from the D runtime, I had to compile to assembly, use a sed script [6] to modify the assembly, and then recompile the assembly to the binary. Sometimes it didn't even work. The binary was 600K without the sed script, and 6K after the sed script. There is no way such huge binary sizes can be used for microcontrollers, and the hacks to get around it are just too ridiculous for me recommend D for this kind of work. An issue [7] for this problem was created, but the solution wasn't implemented properly to allow the LDC and GDC backends to benefit. And since DMD doesn't support ARM Cortex-M, it was essentially useless. [4] - Demonstration of D compiler-runtime coupling - http://forum.dlang.org/post/kfspvnrbykweyowjtkkl forum.dlang.org [5] - D compiler-typeInfo coupling - http://forum.dlang.org/post/nevipjrkdqxivoerftlw forum.dlang.org [6] - Sed command to reduce code bloat - https://github.com/JinShil/stm32f42_discovery_demo/blob/master/build.d#L69 [7] - TypeInfo code-bloat issue - https://issues.dlang.org/show_bug.cgi?id=14758 DMD has a switch called -betterC [8] which was intended to use a C-like dialect of D, but it was never fully implemented. One problem with the whole idea of the -betterC switch is it's not granular enough to disable only some features, but not others, so its not a good solution anyway. I believe there are better solutions [9].
Jan 08 2017
On Sunday, 8 January 2017 at 21:37:41 UTC, Iain Buclaw wrote:On 7 January 2017 at 01:39, Mike via Digitalmars-d <digitalmars-d puremagic.com> wrote:On Friday, 6 January 2017 at 15:47:21 UTC, Igor Myronov wrote:Is possible to program in D micro*-controllers like the PIC32 ? Thanks to all.D has 3 compilers DMD, LDC, and GCC, DMD only has a backend for Intel CPUs. LDC uses the LLVM backend, but I don't see an LLVM backend for PIC. GDC uses GCC's backends, but again, I don't see a backend there for PIC either. LLVM and GDC both, however, have backends for other microcontrollers, specifically ARM Cortex-M (search for ST Discovery[1], Teensy, Adafruit Feather, Arduino Zero). There was even some success a few years back testing D on an Atmel AVR [2]. The Arduino 101 [3] uses an Intel Quark MCU, so it may be possible to program that using DMD, but to my knowledge, nooneYou can find the controller here https://www.allicdata.com/list.html?category_id=1900has tried. [1] - D on ST Discovery - https://github.com/JinShil/stm32f42_discovery_demo [2] - D on Atmel AVR - https://github.com/D-Programming-microD/avr-playground [3] - Arduino 101 - Intel Quark MCU - https://www.arduino.cc/en/Main/ArduinoBoard101 That all being said, as being one spent some time exploring D on microcontrollers, I can't recommend it. The problem is that the D compiler is tightly coupled to the D runtime, and expects a full-featured runtime in order to get build [4] [5] (even if your code doesn't make use of the features). I'm the one who wrote the previously mentioned ST Discovery proof of concept [1], and in order to reduce code bloat from the D runtime, I had to compile to assembly, use a sed script [6] to modify the assembly, and then recompile the assembly to the binary. Sometimes it didn't even work. The binary was 600K without the sed script, and 6K after the sed script. There is no way such huge binary sizes can be used for microcontrollers, and the hacks to get around it are just too ridiculous for me recommend D for this kind of work. An issue [7] for this problem was created, but the solution wasn't implemented properly to allow the LDC and GDC backends to benefit. And since DMD doesn't support ARM Cortex-M, it was essentially useless. [4] - Demonstration of D compiler-runtime coupling - http://forum.dlang.org/post/kfspvnrbykweyowjtkkl forum.dlang.org [5] - D compiler-typeInfo coupling - http://forum.dlang.org/post/nevipjrkdqxivoerftlw forum.dlang.org [6] - Sed command to reduce code bloat - https://github.com/JinShil/stm32f42_discovery_demo/blob/master/build.d#L69 [7] - TypeInfo code-bloat issue - https://issues.dlang.org/show_bug.cgi?id=14758 DMD has a switch called -betterC [8] which was intended to use a C-like dialect of D, but it was never fully implemented. One problem with the whole idea of the -betterC switch is it's not granular enough to disable only some features, but not others, so its not a good solution anyway. I believe there are better solutions [9].No, -betterC is not a dialect, it just tells the compiler not to generate module info. Making it also mean to tell the compiler not to generate any RTTI would be an improvement, but then you have every runtime function depending on RTTI. :-) Iain
Jun 23 2019