Re: What is the meaning of @future ?
On Friday, 17 September 2021 at 14:37:29 UTC, Meta wrote: On Friday, 17 September 2021 at 10:31:34 UTC, bauss wrote: On Thursday, 16 September 2021 at 20:53:34 UTC, Elmar wrote: [...] It's just another "useless" attribute that the language has added before fixing any of the real problems :) Basically it reserves a symbol for the future. It's similar to creating ex. an empty function that throws an error or something like "Not implemented" While I understand why it was added and what purpose it serves then I fail to see why that was prioritized over actual issues. It's solving an almost non-existing issue. I think the main reason it was added is because Sociomantic asked for it, but they are of course not around anymore. Off topic: what happened to them, out of curiosity?
Re: Building LDC runtime for a microcontroller
On Wednesday, 23 September 2020 at 10:02:58 UTC, Dylan Graham wrote: On Friday, 18 September 2020 at 07:44:50 UTC, Dylan Graham wrote: On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote: On Monday, 7 September 2020 at 16:18:00 UTC, IGotD- wrote: On Monday, 7 September 2020 at 15:23:28 UTC, Severin Teona wrote: [...] Use betterC, which is much better suited for microcontrollers than the full D. The disadvantage is that many great features are disabled in betterC. [...] How about an alternative runtime + standard library for embedded systems...with a least bare minimum. I've seen a number of efforts to get D to run in those environments but almost none of them is packaged for others to consume. [...] A lot of embedded stuff is done with RTOSs now that provide memory management and threading support, so having a flexible lightweight runtime with a generic backend (mem allocation, threads) that I can hook to the RTOS' libraries would be great. I'm starting work on a small runtime according to this specification. I can't promise a whole lot; it will be barebones. I'm targeting the STM32 series (ARM Cortex M0-4). So far I have been able to get a class and heap allocated struct to allocate and deallocate manually on an STM32F407 MCU. Array bounds checking works but so far just logs the error in my IDE and hangs. Abstract classes work too. Interfaces are giving me trouble for some reason - they crash LDC2 1.23.0. Going to add some proper support for D's assert(...) and array bounds checking to make things a little easier.
Re: Building LDC runtime for a microcontroller
On Friday, 18 September 2020 at 07:44:50 UTC, Dylan Graham wrote: On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote: On Monday, 7 September 2020 at 16:18:00 UTC, IGotD- wrote: On Monday, 7 September 2020 at 15:23:28 UTC, Severin Teona wrote: [...] Use betterC, which is much better suited for microcontrollers than the full D. The disadvantage is that many great features are disabled in betterC. [...] How about an alternative runtime + standard library for embedded systems...with a least bare minimum. I've seen a number of efforts to get D to run in those environments but almost none of them is packaged for others to consume. [...] A lot of embedded stuff is done with RTOSs now that provide memory management and threading support, so having a flexible lightweight runtime with a generic backend (mem allocation, threads) that I can hook to the RTOS' libraries would be great. I'm starting work on a small runtime according to this specification. I can't promise a whole lot; it will be barebones. I'm targeting the STM32 series (ARM Cortex M0-4).
Re: Building LDC runtime for a microcontroller
On Sunday, 20 September 2020 at 15:13:25 UTC, Steven Schveighoffer wrote: On 9/20/20 10:51 AM, Dylan Graham wrote: On Saturday, 19 September 2020 at 20:39:38 UTC, aberba wrote: Do you attend our monthly D online meetups? We have monthly online meetups? I would love to join of course! Happening next weekend! 🍻 https://forum.dlang.org/post/rjjcl4$30sm$1...@digitalmars.com Would love to hear about your work! -Steve Thank you so much!
Re: Building LDC runtime for a microcontroller
On Saturday, 19 September 2020 at 23:22:50 UTC, IGotD- wrote: On Friday, 18 September 2020 at 07:44:50 UTC, Dylan Graham wrote: I use D in an automotive environment (it controls parts of the powertrain, so yeah there are cars running around on D) on various types of ARM Cortex M CPUs, I think this will be the best way to extend D to those platforms. Do I dare to ask what brand of cars that are running D code. Maybe you're supplier that sells products to several car brands. Nah, I'm an aftermarket upgrades designer and manufacturer. My products only target Holden Commodores since I'm still quite small.
Re: Building LDC runtime for a microcontroller
On Saturday, 19 September 2020 at 20:39:38 UTC, aberba wrote: On Friday, 18 September 2020 at 07:44:50 UTC, Dylan Graham wrote: On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote: [...] [...] Wow. Happy to hear this. Do you attend our monthly D online meetups? We have monthly online meetups? I would love to join of course! [...] +1 [...] I think Ali was also working on or at least talked about that OS (if I remember correctly) at Dconf, right? RTOS is a type of minimalist operating system. Was he working on something like that? I have no clue. If there is some development I'd be happy to contribute.
Re: Building LDC runtime for a microcontroller
On Monday, 7 September 2020 at 19:12:59 UTC, aberba wrote: On Monday, 7 September 2020 at 16:18:00 UTC, IGotD- wrote: On Monday, 7 September 2020 at 15:23:28 UTC, Severin Teona wrote: [...] Use betterC, which is much better suited for microcontrollers than the full D. The disadvantage is that many great features are disabled in betterC. [...] How about an alternative runtime + standard library for embedded systems...with a least bare minimum. I've seen a number of efforts to get D to run in those environments but almost none of them is packaged for others to consume. I use D in an automotive environment (it controls parts of the powertrain, so yeah there are cars running around on D) on various types of ARM Cortex M CPUs, I think this will be the best way to extend D to those platforms. The existing runtime is PC-oriented. Embedded stuff doesn't need a GC or some of the more advanced features, but having things like classes, interfaces, dynamic arrays would make the development workload a lot easier. A lot of embedded stuff is done with RTOSs now that provide memory management and threading support, so having a flexible lightweight runtime with a generic backend (mem allocation, threads) that I can hook to the RTOS' libraries would be great.
Re: Arduino and MCU Support
On Friday, 26 June 2020 at 09:30:15 UTC, Dukc wrote: On Thursday, 25 June 2020 at 03:00:04 UTC, Dylan Graham wrote: I'm currently making an automatic transmission controller with Arduino. C++ just has too many traps that I keep falling into. Since stability is critical (if the code screws up at 100km/h I'm dead), I'd rather use a sane language like D. No, don't! Regardless of the language, you should never trust your safety on one single program. See https://www.digitalmars.com/articles/b39.html Realistically, doing such a controller cannot be one man/woman endeavour. Thank you for the article. It was an intriguing read. I don't really have any capacity to implement multiple concurrent programs given how limited the hardware is. What I do have is a "pipeline" of modules that have their own checks to mitigate logical errors. The transmission also has a mechanical backup should the electronics fail. What I meant more so was creature comforts D provides that you begin missing when you revert to C++ -- something that can assist me in avoiding certain classes of bugs, which is what was referring to in my original message and I fear the most. I have a running controller that even interacts with car's stock computers and is passing real world tests at current. Automotive engineering is more approachable than it first appears.
Re: Arduino and MCU Support
On Friday, 19 June 2020 at 11:57:01 UTC, frasdoge wrote: I am looking to use D for microcontroller programming due to its benefits over C in workflow and general language features. I was wondering what the current state of this is, especially with regards to AVR. An example of the MCUs I would like to develop with include anything from 8 bit ATmega328p to 32 bit ESP32. The ESP32 can be programmed in C, C++, micropython and Lua, so I'm hoping there's at least some compatibility there. I'd be pretty interested in this too. I'm currently making an automatic transmission controller with Arduino. C++ just has too many traps that I keep falling into. Since stability is critical (if the code screws up at 100km/h I'm dead), I'd rather use a sane language like D. I'm going to look into getting it to run, but I can't promise much and I'm busy atm.
