Trust about D programming.

[Paulo Pinto]

Am 22.01.2013 17:19, schrieb Freddie Chopin:
> On Tuesday, 22 January 2013 at 15:42:04 UTC, Paulo Pinto wrote:
>> It is possible to do C free development in embedded systems, using
>> system programming languages with GC.
>
> Instead of just ditching C or C++ for something related to Delphi, it
> would be nicer to use D, as it's multithreading options look quite nice (;

Sure, I was actually trying to point out the existence of strong type 
languages for (some type) of embedded development.

It would be surely nice to use something like D.

>
>> There are of course embedded systems, where the only way to program is
>> either Assembly or a crippled down version of C due to hardware
>> constraints.
>
> Well, a typical ARM Cortex-M3 is not THAT crippled, it just does not
> have that much RAM to waste - rarely there's more than 64kB, usually
> less than 32kB...
>
>> However, if the hardware is able to execute full ANSI C code, then
>> there are other options becoming available.
>
> Well, it's not about "full ANSI C", because you could do that on 8051 30
> years ago... it just the matter of:
> a. RAM usage
> b. heap usage
> c. real-time constraints

I had PIC micro-controlers with memory in the order of bytes, when I 
wrote that.

If I am not mistaken, many of the C compilers for such environments are 
limited on what is actually possible to use from ANSI C.

There was an assembler from TI which looked like C control flow with 
intrinsics, but I am no longer able to find the information.


>
> For a typical ARM bare-metal microcontroller C++ exceptions are
> a-bit-too-much (taking ~60kB of flash code when almost not used, and
> 60kB quite often would be 95% of available code memory, but in more
> common cases 25-50%), in D these are probably inevitable and I could
> live with that (; But I just cannot imagine a GC on a microcontroller
> that has so little RAM and which has to do something in real-time - you
> probably will just get annoyed if an app on PC freezes for a second, but
> if a 100-tonne crane controller freezes for that time it can end really
> bad (;

Agreed.

>
> Yes, GC and dynamic memory is really cool, but it costs just a lot of
> RAM... You can sometimes live with mallocs() (but modestly used), yet I
> cannot imaging GC in so small memory. It can be easily assumed that such
> applications don't do a lot of memory allocation at run-time (usually
> none), so the GC would just waste time and memory...

True, although in my naïve opinion, I would expect such systems to still 
be developed in Assembly.

>
>> It is just a matter to get a more widespread acceptance.
>
> I think it's just a matter of realistic expectations (; A LOT (and I
> really mean that) people think that ARM based microcontrollers are an
> overkill for most of the tasks, so you'll just not convince them to use
> an even more expensive chip, which has 4x the amount of RAM just to use
> "a fancy language".

Yes, I know the issues of a few cents per unit might imply.

>
> And do remember we're not talking about routers and smartphones that
> have 128MB of RAM, but rather about home automation systems, some
> industrial controllers (but not HMI with a fancy GUI, but the devices
> that really do the monitoring and control), maybe some electronics
> embedded in toys (RC models etc.).
>
> 4\/3!!

Faire enough, I guess even C has issues on those systems right?

Thanks for the comprehensive post,
Paulo