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
