Embedded platforms for beginners?

David Brown <david.brown@hesbynett.no> writes:
>> http://www.memorymanagement.org/
> I had a little look at that site.  It had some useful explanations, but
> is /seriously/ biased.  ...

You might look at

  https://www.cs.kent.ac.uk/people/staff/rej/gc.html

I've seen the 2011 book and it is great.

Hans Boehm also has some good GC pages.

George Neuner <gneuner2@comcast.net> writes:
> In the broader programming world, the average skill level is just
> slightly above "script kiddy".  The headlong march to "managed"
> languages such as Java, C#, Python, etc. is industry acknowledging
> that the average programmer simply can't write a complex program
> without hand-holding.

I'm not ready to think of the Lisp pioneers who developed and used most
of today's GC techniques as "script kiddies".  Here's what
E. W. Dijkstra said about Lisp in his Turing award lecture, all the way
back in 1972:

    With a few very basic principles at its foundation, it [LISP] has
    shown a remarkable stability. Besides that, LISP has been the
    carrier for a considerable number of in a sense our most
    sophisticated computer applications. LISP has jokingly been
    described as &ldquo;the most intelligent way to misuse a computer&rdquo;. I
    think that description a great compliment because it transmits the
    full flavour of liberation: it has assisted a number of our most
    gifted fellow humans in thinking previously impossible thoughts.

There are certainly times when GC imposes unacceptable costs, and maybe
those times happen more in embedded programming than in other kinds of
programming.  But if the hardware can accomodate it and it helps do the
job faster, why would anyone not use it?  

I worked on a thing a few years ago that had around $50K of software NRE
(Python) and used $300 worth of hardware including two ARM processors.
By writing it in C maybe we could have spent $10 less per hardware unit,
but at least 3x more on programming, plus the time-to-market delay, loss
of feature flexibility, etc.  We'd have to ship quite a lot of units to
even think of switching to that approach.  And I think it would have
been silly to use C from the beginning, instead of using it for an
eventual cost reduction once we had gotten experience from multiple
generations of fielded units programmed in Python.

Obviously not all situations are like that.  But I think it is getting
more and more typical.

Paul Rubin wrote on 9/4/2017 1:20 AM:
> rickman <gnuarm@gmail.com> writes:
>> It's not like "GC'd" is a commonly used abbreviation.
>
> At least among language geeks, it's definitely commonly used.

Exactly, when you are talking to people who already know what you are 
talking about.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

On 06/09/17 12:06, rickman wrote:
> Paul Rubin wrote on 9/4/2017 1:20 AM:
>> rickman <gnuarm@gmail.com> writes:
>>> It's not like "GC'd" is a commonly used abbreviation.
>>
>> At least among language geeks, it's definitely commonly used.
> 
> Exactly, when you are talking to people who already know what you are 
> talking about.

Most people would just Google "memory gc" to educate themselves,
rather than bleating about how ignorant they are. "Garbage
Collection" is the very first hit on Google. But instead of
you spending 30 seconds learning something, a hundred or more
people have had to spend 30 seconds reading unnecessary posts.

Clifford Heath.

On 06/09/17 09:54, Paul Rubin wrote:
> Clifford Heath <no.spam@please.net> writes:
>> No, [GC is] *still* not the way to get the best from most embedded
>> hardware. It's an acceptable compromise, some of the time, is all that
>> can really be said.
> 
> Sure, that's absolutely true, for big hardware as well as embedded, but
> we live in an era where "getting the best from the hardware" isn't an
> issue for most projects these days.

This isn't a thread about "most projects" but about how a beginner
can learn to program embedded devices. It's pretty important to
learn *what memory is* before you learn to let the tools manage it
for you.

I've seen smart graduate software engineers who've only ever used
IDEs and GC languages who *don't really know* what memory is.
I find that absolutely alarming. A good feel for the underlying
hardware is essential to good results.

Clifford Heath.

Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes:
> I've never felt the need for GC in an embedded system myself....
> There are probably situations where it's helpful, but I'm an
> instruments builder, and the MCU and memory are very rarely the cost
> driver.

I suspect that type of application uses mostly static memory, so GC
wouldn't help that much even if it's available and you trust it.
It's invaluable when you have lots of dynamically allocated objects
moving around through the system.  And yes, programs like that
can have very high reliability, such as with phone switches programmed
in Erlang with 40 year uptimes.

On 06/09/17 12:35, Paul Rubin wrote:
> Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes:
>> I've never felt the need for GC in an embedded system myself....
>> There are probably situations where it's helpful, but I'm an
>> instruments builder, and the MCU and memory are very rarely the cost
>> driver.
> 
> I suspect that type of application uses mostly static memory, so GC
> wouldn't help that much even if it's available and you trust it.
> It's invaluable when you have lots of dynamically allocated objects
> moving around through the system.  And yes, programs like that
> can have very high reliability, such as with phone switches programmed
> in Erlang with 40 year uptimes.

Erlang is designed to fault without failing, with
close to zero overhead. It's an entire world apart
from most other kinds of programming. If it works
for you, great!

<http://erlang.org/doc/reference_manual/errors.html>

Clifford Heath wrote on 9/5/2017 10:21 PM:
> On 06/09/17 12:06, rickman wrote:
>> Paul Rubin wrote on 9/4/2017 1:20 AM:
>>> rickman <gnuarm@gmail.com> writes:
>>>> It's not like "GC'd" is a commonly used abbreviation.
>>>
>>> At least among language geeks, it's definitely commonly used.
>>
>> Exactly, when you are talking to people who already know what you are
>> talking about.
>
> Most people would just Google "memory gc" to educate themselves,
> rather than bleating about how ignorant they are. "Garbage
> Collection" is the very first hit on Google. But instead of
> you spending 30 seconds learning something, a hundred or more
> people have had to spend 30 seconds reading unnecessary posts.

Exactly.  I see dozens of un-useful abbreviations in newsgroups every day. 
They waste people's time.  In this case it wasn't just mine.  The rule for 
use of abbreviations in documents is to explain the abbreviation the first 
time it is used in a doc.  It would be a good rule for usage in a thread.

-- 

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

Clifford Heath <no.spam@please.net> writes:
> This isn't a thread about "most projects" but about how a beginner
> can learn to program embedded devices. It's pretty important to
> learn *what memory is* before you learn to let the tools manage it
> for you.

I'm just a dabbler in embedded devices, but on bigger computers it
stopped being that way years ago.  I work with smart productive
programmers every day who do all their stuff in Python and Ruby and have
never seen C code.  Do I find it alarming?  Well, it took me a little
while to get used to.  But they deliver working products that do what
the customer wanted, and what else in engineering is supposed to matter?

What I'm coming to believe (your judgment may well be better than mine,
at least if you've done it both ways) is that it's gotten the same way
with embedded devices.  A coin-size MCU board that appears as a USB
flash drive where you drag and drop a Python program sounds about as
beginner-friendly as it gets.  Another approach (recommended by Rickman)
is Forth, which in some ways is similar in spirit.  But the value of a
self-contained system needing no extra boards and stuff is very high.

On 09/05/2017 10:35 PM, Paul Rubin wrote:
> Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> writes:
>> I've never felt the need for GC in an embedded system myself....
>> There are probably situations where it's helpful, but I'm an
>> instruments builder, and the MCU and memory are very rarely the cost
>> driver.
> 
> I suspect that type of application uses mostly static memory, so GC
> wouldn't help that much even if it's available and you trust it.
> It's invaluable when you have lots of dynamically allocated objects
> moving around through the system.  And yes, programs like that
> can have very high reliability, such as with phone switches programmed
> in Erlang with 40 year uptimes.
> 
A big-ass phone switch is _not_ my idea of an embedded system.

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net