Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-27 Thread Andrea Fontana via Digitalmars-d-announce

On Saturday, 22 July 2017 at 18:51:34 UTC, Sönke Ludwig wrote:

Am 21.07.2017 um 09:40 schrieb Andrea Fontana:
It has a lot of potential. I always hope that someone will 
start a 3d

Printer firmware written in D for a 32bit microcontroller.


I've actually started to implement a GCode processor in D a 
while ago, because I was unsatisfied with the open source 
firmwares that exist. It's more tailored towards CNC routers, 
but since those are pretty similar that shouldn't be a big 
problem. The bad news is that I don't have time to work on it 
anymore and it was still at a relatively early stage.


D for programming + Vibe for web/mobile interface + Mir for math 
would be a win for a 3d printer firmware. Using templates and 
component programming should fit perfectly a generic-composable 
firmware for printers. (check delta vs cartesian vs corexy + 
different stepper drivers + different motors + different boards + 
...)






Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-26 Thread Laeeth Isharc via Digitalmars-d-announce

On Thursday, 20 July 2017 at 12:23:31 UTC, Mike wrote:
A few years ago I created a bare metal demo on an ARM Cortex-M4 
microcontroller entirely in D.  It was just a demonstration 
that one could do bare metal programming for microcontrollers 
in D without any dependencies on C or assembly.  It was also a 
proof of some ideas I had about leveraging compile-time 
features of D to generate highly-optimized code (both small and 
fast) for these resource constrained systems.  I hit a wall, 
however, with Issue 14758[0], and ultimately abandoned D for 
other alternatives.


Well, that issue was recently fixed in GDC [1].  In addition, 
he GDC developers did some work to reduce the number of phony 
stubs one had to add to the runtime to get a build [2], removed 
the "shared is volatile" hack, and implemented the 
`volatileLoad/Store` intrinsics so I no longer need to do 
volatile access in assembly.  So, I decided to give it another 
try, and updated that demo. You can see the results at 
https://github.com/JinShil/stm32f42_discovery_demo


Congratulations, Mike.

https://www.reddit.com/r/programming/comments/6pn31c/d_on_bare_metal_stm32f4_redux/

Could someone post to Hacker News?  I don't have enough rep for 
it to propagate.


Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-22 Thread Sönke Ludwig via Digitalmars-d-announce

Am 21.07.2017 um 09:40 schrieb Andrea Fontana:

It has a lot of potential. I always hope that someone will start a 3d
Printer firmware written in D for a 32bit microcontroller.


I've actually started to implement a GCode processor in D a while ago, 
because I was unsatisfied with the open source firmwares that exist. 
It's more tailored towards CNC routers, but since those are pretty 
similar that shouldn't be a big problem. The bad news is that I don't 
have time to work on it anymore and it was still at a relatively early 
stage.


Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-21 Thread aberba via Digitalmars-d-announce

On Friday, 21 July 2017 at 07:40:20 UTC, Andrea Fontana wrote:

On Thursday, 20 July 2017 at 12:23:31 UTC, Mike wrote:
A few years ago I created a bare metal demo on an ARM 
Cortex-M4 microcontroller entirely in D.  It was just a 
demonstration that one could do bare metal programming for 
microcontrollers in D without any dependencies on C or 
assembly.  It was also a proof of some ideas I had about 
leveraging compile-time features of D to generate 
highly-optimized code (both small and fast) for these resource 
constrained systems.  I hit a wall, however, with Issue 
14758[0], and ultimately abandoned D for other alternatives.


It has a lot of potential. I always hope that someone will 
start a 3d Printer firmware written in D for a 32bit 
microcontroller.


Can't wait to see that day


Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-21 Thread Mr.D via Digitalmars-d-announce

On Friday, 21 July 2017 at 00:27:09 UTC, Mike wrote:

On Thursday, 20 July 2017 at 17:09:40 UTC, Mr.D wrote:
Thanks for your work with bare metal MCUs! I am dreaming that 
someday I can program smart house IoT automation on D.


You already can; it just may not be the most professional 
experience.  If you have the hardware and the time, do it!


Mike


I am stopped by the lack of a system library for work with GPIO, 
PWM etc specific MCU things.




Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-21 Thread Andrea Fontana via Digitalmars-d-announce

On Thursday, 20 July 2017 at 12:23:31 UTC, Mike wrote:
A few years ago I created a bare metal demo on an ARM Cortex-M4 
microcontroller entirely in D.  It was just a demonstration 
that one could do bare metal programming for microcontrollers 
in D without any dependencies on C or assembly.  It was also a 
proof of some ideas I had about leveraging compile-time 
features of D to generate highly-optimized code (both small and 
fast) for these resource constrained systems.  I hit a wall, 
however, with Issue 14758[0], and ultimately abandoned D for 
other alternatives.


It has a lot of potential. I always hope that someone will start 
a 3d Printer firmware written in D for a 32bit microcontroller.


Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-20 Thread Andrey via Digitalmars-d-announce

On Friday, 21 July 2017 at 00:27:09 UTC, Mike wrote:

On Thursday, 20 July 2017 at 17:09:40 UTC, Mr.D wrote:
Thanks for your work with bare metal MCUs! I am dreaming that 
someday I can program smart house IoT automation on D.


You already can; it just may not be the most professional 
experience.  If you have the hardware and the time, do it!


Mike


Thanks for your work


Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-20 Thread Mike via Digitalmars-d-announce

On Thursday, 20 July 2017 at 17:09:40 UTC, Mr.D wrote:
Thanks for your work with bare metal MCUs! I am dreaming that 
someday I can program smart house IoT automation on D.


You already can; it just may not be the most professional 
experience.  If you have the hardware and the time, do it!


Mike


Re: Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-20 Thread Mr.D via Digitalmars-d-announce
Thanks for your work with bare metal MCUs! I am dreaming that 
someday I can program smart house IoT automation on D.


Update to Bare Metal STM32F4 (ARM Cortex-M4) LCD Demo Proof of Concept

2017-07-20 Thread Mike via Digitalmars-d-announce
A few years ago I created a bare metal demo on an ARM Cortex-M4 
microcontroller entirely in D.  It was just a demonstration that 
one could do bare metal programming for microcontrollers in D 
without any dependencies on C or assembly.  It was also a proof 
of some ideas I had about leveraging compile-time features of D 
to generate highly-optimized code (both small and fast) for these 
resource constrained systems.  I hit a wall, however, with Issue 
14758[0], and ultimately abandoned D for other alternatives.


Well, that issue was recently fixed in GDC [1].  In addition, he 
GDC developers did some work to reduce the number of phony stubs 
one had to add to the runtime to get a build [2], removed the 
"shared is volatile" hack, and implemented the 
`volatileLoad/Store` intrinsics so I no longer need to do 
volatile access in assembly.  So, I decided to give it another 
try, and updated that demo. You can see the results at 
https://github.com/JinShil/stm32f42_discovery_demo


A few observations:
* It is a better experience than it was a few years ago.  Fewer 
dirty hacks are required, and the resulting binary is small and 
fast.
* Everything is in D (inline assembly is D).  There's no need for 
any C or assembly startup code, and no need for silly things like 
-betterC (i.e. -worseD).  If you don't want the overhead from a 
feature of D, don't use it.
* Compile times are quite slow (about 1 minute to get a 3kB 
binary).  Some discussion about that is taking place on the GDC 
forum [4].
* -O2 and -O3 give me a broken binary, but -O0, -O1, and -Os work 
well.


I'm not sure where I'll go from here.  I'm interested in helping 
an amputee play the drums again, and building my own mechanical 
keyboard, so I probably won't be spending much more time on this 
LCD demo, except maybe to help compiler devs debug some issues.  
However, I might spend some more time with D in the near future, 
and see how far I can take this.  I'm still not as excited as I 
once was, but it's nice to see these improvements.


Anyway, Well done, GDC!

Mike

[0] - TypeInfo causes excessive binary bloat - 
https://issues.dlang.org/show_bug.cgi?id=14758
[1] - Put the TypeInfo name field into a static var - 
https://github.com/D-Programming-GDC/GDC/pull/505
[2] - Refactor and reformat typeinfo.cc - 
https://github.com/D-Programming-GDC/GDC/pull/456
[3] - Slow compile-time discussion at GDC forum - 
http://forum.dlang.org/post/iqryqssxooypdnszm...@forum.dlang.org