C# for Embedded ?...

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> 1) lack of GC leads many programmers to be more defensive than is
> necessary in a managed environment. Typically that manifests itself as
> "unnecessary copies", which is a real problem since memory is usually
> the bottleneck nowadays.

C++ avoids that pretty well these days, with move semantics and smart
pointers introduced in C++11.  If you haven't used it, give it a try.

> 2) C/C++ can only optimise what it /guesses/ will happen at runtime.

Serious compilers support profile-based optimization these days.

> If Java was slow, it would be out the door in an instant; instead it
> is becoming the normal platform.

It seems to be going out of style in the past few years, though maybe
mostly because of Oracle being annoying than technical issues.

On 11/5/2016 11:35 AM, Paul Rubin wrote:
> kalvin.news@gmail.com writes:
>>>      heating_element(ON)
>>>      while (temperature < setpoint) {...
>> Worst yet, the software engineer cannot specify the valid numeric
>> range of the variables that it is expected to hold....
>> Ada has a very strong type checking system.
>
> I have trouble believing that a sane toaster would have
> software-controlled at all.  Most toasters use an electromechanical
> thermostat, so when when it reaches the right temperature, the
> thermostat trips the spring that pops the toast up.

Ours has a darkness setting, LED indicators, and buttons that act
as presets for:
- frozen
- warm
- bagels
- pastry
- waffle
- cancel (eject)
We purchased it ~15 years ago -- primarily because it was dirt cheap!

<http://kitchen.manualsonline.com/manuals/mfg/sunbeam/6220.html>

> But, in the old days, that stuff was written in asm, which was even more
> typeless than something like BASIC.  These days even in cheap appliances
> I suspect C prevails.

On 05/11/16 18:41, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> 1) lack of GC leads many programmers to be more defensive than is
>> necessary in a managed environment. Typically that manifests itself as
>> "unnecessary copies", which is a real problem since memory is usually
>> the bottleneck nowadays.
>
> C++ avoids that pretty well these days, with move semantics and smart
> pointers introduced in C++11.  If you haven't used it, give it a try.

"Pretty well" is like "only a little bit pregnant".


>> 2) C/C++ can only optimise what it /guesses/ will happen at runtime.
>
> Serious compilers support profile-based optimization these days.

I'm out of touch w.r.t. that. I wonder how effective
is the support w.r.t Hotspot technology. For realtime
embedded work, neither is particularly attractive,
of course.

And for hard realtime work, even hardware caches
present significant problems!


>> If Java was slow, it would be out the door in an instant; instead it
>> is becoming the normal platform.
>
> It seems to be going out of style in the past few years, though maybe
> mostly because of Oracle being annoying than technical issues.

Hah! I'm not going to argue about Oracle; arguably they
have worse behaviour than Microsoft ;}

What appears to you to be "the new black"?

On 05/11/16 18:15, upsidedown@downunder.com wrote:
> On Sat, 5 Nov 2016 12:40:21 +0000 (UTC), asdf <asdf@nospam.com> wrote:
>
>> On Fri, 04 Nov 2016 13:12:57 +0000, Chris wrote:
>>
>>> Hi,
>>>
>>> I've been invited to a meeting to discuss am automotive like engineering
>>> project with a high level of safety critical requirements.
>>>
>>> They are using Simulink for some of the top level design work, but are
>>> programming the whole lot in C#, with some of the code already written.
>>> Not sure at this stage which rtos is being used, if at all.
>>
>>> ...
>>
>>
>> C# or Java (C# is essentially MS/Java) are not suitable for embedded
>> systems, and in a safety critical environment with very likely also
>> some realtime constraints, is the worst possible choice ever.
>> In those contexts even C++ (which runs circles around C#/Java
>> performance wise) would be a suboptimal choice.
>
> With truly safety critical systems (such as nuclear reactors), you
> throw in as much hardware as required, cost is absolutely not an
> issue.
>
> In this thread, there has been an attitude of claiming that a specific
> programming language would "solve" any programming safety issues.  In
> practice, the worst errors are made in the design phase, typically
> written in plain (English) text.
>
> Noting that for safety critical projects, there is a _huge_ amount of
> paperwork done before any single line of a computer programming
> language line is actually written,
>
> For truly safety critical systems, the programming language used, is
> not really an issue. Even assembly language is quite acceptable due to
> the huge paper work.

While it is /necessary/ to choose the "right" language,
it is not /sufficient/ to choose the right language.
Anyone that thinks otherwise hasn't thought about the
topic!

On 04/11/2016 13:12, Chris wrote:
> Hi,
>
> I've been invited to a meeting to discuss am automotive like engineering
> project with a high level of safety critical requirements.
>
> They are using Simulink for some of the top level design work, but are
> programming the whole lot in C#, with some of the code already written.
> Not sure at this stage which rtos is being used, if at all.
>
> From what I've read, C# is a web / application / database programming
> language and a quick look at the Wiki page suggests that the two
> most recent versions are not approved by any international standards
> organisation.
>
> C# raises alarm bells here for all kinds of reasons, but what do you
> think ?...

Without knowing more of the architecture, it is not uncommon to have a 
mix of emmbedded MISRA C on one processor and a higher language for use 
as a GUI or other network processes on another.

The key is to make sure the safety critical component is compact and 
well tested and can determine and react correctly to any fault, and 
possibly even restart the second CPU if it behaves incorrectly.

In short I would like to know more about the system before passing 
judgement. If as you say the whole system, including any safety critical 
component, is written in C# then alarm bells would indeed be ringing.

-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

On 11/5/2016 1:25 PM, Tom Gardner wrote:
> On 05/11/16 18:15, upsidedown@downunder.com wrote:

>> For truly safety critical systems, the programming language used, is
>> not really an issue. Even assembly language is quite acceptable due to
>> the huge paper work.
>
> While it is /necessary/ to choose the "right" language,
> it is not /sufficient/ to choose the right language.
> Anyone that thinks otherwise hasn't thought about the
> topic!

I'd temper that further:
     The right language *features* go a VERY long way towards
     the success of meeting a particular requirement set.
     (languages just represent particular feature *bindings*
     with variations in syntactic sugar)
I.e., even the wrong set of language features doesn't *preclude*
success; it just makes it considerably more of an effort to
attain!

On 11/04/16 13:12, Chris wrote:
> Hi,
>
> I've been invited to a meeting to discuss am automotive like engineering
> project with a high level of safety critical requirements.
>

I just wanted to thank you all for the replies on this. Tt
just confirms the view here and should provide additional
evidence for the meeting. Can't say more now, but will try
to report back to group later next week...

Regards,

Chris

On Saturday, November 5, 2016 at 8:31:59 PM UTC-4, Chris wrote:
> Can't say more now, but will try to report back to group later next week...

Thanks Chris, Looking forward to hear how this went...
Best Regards, Dave

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> C++ avoids that pretty well these days, with move semantics and smart
>> pointers introduced in C++11.  If you haven't used it, give it a try.
> "Pretty well" is like "only a little bit pregnant".

Well, it works pretty well in the sense that it gets rid of a lot of
cases where you'd have to do it manually.  You can of course always
still do it manually like before, or you can use shared_ptr which is
sort of a poor man's GC.  There's also an idea in development for gc'd
regions:

  https://github.com/hsutter/gcpp

C++ itself has gc hooks in the language and (independently) the
Boehm-Demers gc has been successful in various C and C++ applications.
The idea of these systems languages though (C++, Rust, Ada) is to
control resources precisely, which is in tension with the concept of gc.

> What appears to you to be "the new black"?

PenguinOfDoom (from irc #haskell) once said something like "being
sophisticated gents, we classify programming languages into sucks and
doesn't-suck, and put all of them in the first category".

I've never been involved with realtime critical systems (only
vicariously interested) but given enough budget I'd consider the
commercial Adacore Spark/Ada stuff.  I've fooled around a little with
the free stuff but for a genuine critical system I'd want their support
package.

I don't currently understand where complex HRT software is actually
needed.  E.g. I don't know squat about the subject, but I imagine
something like a flight control system being a fast PID jiggling some
actuators towards a desired flight vector (this is critical HRT but
fairly simple), wrapped in a slower control loop that adjusts the
desired vector at maybe a few Hz, i.e. critical and complex, but non-HRT
since it's ok if an update is late by some milliseconds now and then.
Or the whole airplane would contain a monstrous amount of code (complex)
but a lot of it would be stuff like in-flight entertainment
(non-critical).

There's a youtube video of Adacore founder Bob Dewar talking about the
F-22 fighter software (written in Ada).  He asked whether fighter plane
software was safety-critical and the audience laughed.  But then he
explained that a passenger airliner is obviously safety-critical and so
you have to run everything in a very conservative regime.  But the
purpose of a fighter is to go out and get shot at (unsafe by
definition), and they emphasize performance over safety in other parts
of the plane (unstable aerodynamics, driving engines to their limits,
etc.) so maybe they should think of the software that way too.  However,
he says, they don't.

On 16-11-05 12:41 , Don Y wrote:

[concerning the suitability of some "large" languages for "small" 
applications]

> The example offered has nothing to do with "tight code" -- a microwave
> oven isn't particularly challenging even with the slowest processor
> using an interpreted language!  Rather, it's just matching the
> complexity of the problem to the complexity of the solution.  Likewise
> wrt costs.
>
> You wouldn't bring a backhoe onto your property to plant daisies.
>
> Nor use a spade to excavate for a swimming pool!
>
> Using a backhoe to plant daisies requires you to hire someone capable of
> operating a backhoe.
>
> Using a spade to excavate a swimming pool requires you hire someone
> who has a strong back.
>
> You wouldn't use a Cray to control a microwave oven nor an 8b MCU
> to process airline reservations -- though BOTH could be done (poorly!)

Those are all false analogies, or at least misleading analogies. There 
are just two questions:

1) can the tool do the required job?

2) are there some draw-backs (e.g. cost, delay) associated with the tool?

A backhoe can be used to plant daisies (well, at least to dig the holes, 
if you don't mind the holes being too large), so perhaps (1) is ok. But 
clearly a backhoe costs more than a shovel, probably will take longer 
(including the time taken to bring the backhoe to the site, and remove 
it afterwards), and will mess up your lawn, so point (2) would argue 
against using a backhoe for this job.

Switching from the analogy to the real subject -- programming an 
embedded system -- it is clear that a "large" language can do "small" 
jobs, and can do them as well (from the functional point of view) as a 
"small" language, even for real-time aspects. So question (1) needs no 
discussion.

Question (2) is more interesting. What are the costs, or other 
draw-backs, of using a "large" language (e.g. Ada or C++)? These costs 
and other issues can apply to the development tools and process 
(non-recurring costs) or to the recurring production costs, in 
particular through the required computing resources in the embedded system.

The cost of development tools varies a lot. There are some no-cost tools 
as well for "large" languages as for "small" languages, and there are 
some expensive tools as well for "large" languages as for "small" 
languages. Of course I grant that there are more no-cost or cheap 
assemblers and C compilers for more targets than there are such Ada 
compilers -- unfortunately. And indeed there is probably a correlation 
here: creating a compiler for a large language is more work than for a 
small language, so one can expect a higher compiler price. However, for 
professional work that cost would be spread over several projects.

The nature and cost of the development process does not depend on the 
"size" of the language, but on the criticality of the application. So 
this point has no bearing.

There remains the question of the required embedded computing resources. 
Don's comment on the suitability of Ada for small applications was 
specifically on the "efficiency" of the language, and I understood him 
to mean efficiency in terms of the generated code size and execution 
speed compared, for example, to C or assembly language. As Ada is a 
traditional imperative, procedural language, usually compiled to native 
machine code, with no implicit need for dynamic memory allocation or 
garbage collection, I continue to object to Don's claim that it is 
inefficient for systems such as the one that started this thread.

For controlling a toaster, if one uses assembly language it is probably 
possible to use an MCU with no RAM, such as a tiny AVR. There is no 
fundamental technical reason why a "large"-language compiler could not 
generate code that runs without RAM, for a very small application, but 
one will probably not find such a compiler. However, once the 
application is large enough to require some RAM, the necessary RAM size 
become more a matter of application requirements and coding style than 
of the coding language -- assuming that the programming system links in 
only the required parts of the language-defined libraries.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .