C# for Embedded ?...

On 11/4/2016 11:54 AM, Don Y wrote:
> Embedded systems come in all different sizes and varieties.
> Also the "depth" of the embedding varies tremendously
> (the code running on the Mars Rover is designed to operate
> in a very different environment than the code that runs
> the cash registers at your local supermarket!)
>
> As do the consequences of failures, etc.

Here's a great "safety critical" application that's essentially
trivial:  dispensing gasoline!  (a "process" controlled by unskilled
users:  DRIVERS!)

perjantai 4. marraskuuta 2016 20.55.05 UTC+2 Don Y kirjoitti:
> On 11/4/2016 7:30 AM, Chris wrote:
> > On 11/04/16 13:44, Dave Nadler wrote:
> >> On Friday, November 4, 2016 at 9:13:01 AM UTC-4, Chris wrote:
> >>> C# raises alarm bells here for all kinds of reasons, but what do you
> >>> think ?...
> >>
> >> Alarm bells are definitely in order.
> >>
> >> C# is MS's answer to Java, and highly Windows-centric.
> >> The Mono open-source port of the C# VM does have support for
> >> some embedded architectures, but this should have been verified
> >> for your target prior launching into development...
> >>
> >> See: http://www.mono-project.com/docs/about-mono/supported-platforms/
> >>
> >> While I've used C# for Windows applications I haven't tried it
> >> on an embedded platform. For embedded projects normally I use C++
> >>
> >> Hope that helps!
> >> Best Regards, Dave
> >
> > Thanks for the reply and link. Do homework before going in
> > etc :-).
> >
> > So from what I can see, it's a big systems language in memory
> > requirements for libraries and run time support. C# also uses
> > dynamic memory allocation and garbage collection, another red
> > line for the this type of application.
> 
> "Big system language" and "memory requirements" and "runtime"
> don't preclude a particular choice.  Consider Ada in your
> above assessment (hardly "small", economical, etc.).

Ada has a so called Ravenscar-profile (subset of the Ada language) which is targeted especially to the embedded systems, and has removed some of the language features that were considered unnecessary or unsuitable for the safety critical systems. Heck, the free AVR-Ada compiler can produce code even for the 8-bit Atmel atmega328 microcontroller.

Br,
Kalvin

perjantai 4. marraskuuta 2016 20.58.59 UTC+2 kalvi...@gmail.com kirjoitti:
> perjantai 4. marraskuuta 2016 20.51.03 UTC+2 Tom Gardner kirjoitti:
> > On 04/11/16 18:22, kalvinnospamherenews@gmail.com wrote:
> > 
> > > Some people might argue that C++ would be just fine,
> > 
> > Make sure such people can provide good answers to
> > the "Frequently Questioned Answers"
> > http://yosefk.com/c++fqa/
> > 
> > 
> > > but I would argue that it is very easy to create something that is doing something that you didn't intend to do. The C++ is such a clever language that I will do some things behind the scene (like allocate an object from the dynamic heap although you didn't do it explicitly) unless you are very careful and know what to do. So, I would rule out the C++ unless you are really competent with it.
> > 
> > It is worse than that: the /designers/ didn't
> > understand what they were creating, so what chance
> > do you think mere mortals have!
> > 
> > It was discovered the c++ template was Turing-complete,
> > but the design committee didn't believe it until someone
> > rubbed their noses in it by causing the compiler to emit
> > the sequence of prime numbers during (infinite) compilation!
> > That's from
> > <https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP>
> > The original is at <http://www.erwin-unruh.de/primorig.html>
> > 
> > Note: not designed, but discovered - and that's exactly
> > what happened.
> 
> I just wanted to bring that up as I do see C++ suitable for the safety-critical applications, although there may be some people suggesting that C++ is suitable for the safety-critical applications as there is also the MISRA C++ subset. But the C++ is really hard to master so that it behaves predictably.
> 
> Br,
> Kalvin

Nice typo above. Of course I meant to say "I just wanted to bring that up as I do *not* see C++ suitable for the safety-critical applications ..."

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> On 04/11/16 18:22, kalvin.news@gmail.com wrote:
>> Some people might argue that C++ would be just fine,
> Make sure such people can provide good answers ... http://yosefk.com/c++fqa/

That's an entertaining document but it mostly describes:

1) Hazards in C++ that are also present in C, so you don't escape from
them by choosing C over C++.

2) Hazards of complicated C++ features that aren't used that frequently
and that programmers can decide not to use in a given project

3) Deficiencies in "old" (C++98) C++ that have been fixed in "modern"
(C++11 and later) C++.  C++11 was really a big improvement over earlier
versions and I didn't get much interested in C++ til it came out.

I've written tons of C and a (so far) smallish amount of "modern" C++
and would consider both of them to be scary, but overall my current
impression is that C++ is safer if you know take #2 above into account.

For example, in C++ it's, idiomatic to say array.at(i) instead of
array[i], and the .at() method on STL arrays checks that the subscript
is in range (measurements I've done in my own programs have so far
encountered almost no performance loss from this).  In C, most people
end up using unchecked subscripts.  C++ RAII avoids a lot of dangling-
resource bugs, etc.  None of this has anything to do with C# though.

I've fooled with Ada a little bit and would consider it to be much safer
than either C or C++ while being somewhere between the two of them in
expressiveness, though much worse in terms of tooling.  I can't possibly
be saying "my language is better" in naming Ada, since my languages are
C and C++, and I've only looked into Ada as a possible alternative to
them.

That C# allows escaping to unsafe operations doesn't seem worse to me
than Java having a JNI.  Even Haskell supports unsafe operations.
Of course C# has other issues that make it not sound good for real time.

Here are Bjarne Stroustrup's currently recommended C++ core guidelines
which spell out a much safer set of practices than I usually see in C
programs:

https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

On 16-11-04 19:54 , Don Y wrote:
> "Big system language" and "memory requirements" and "runtime"
> don't preclude a particular choice.  Consider Ada in your
> above assessment (hardly "small", economical, etc.).

I challenge you to prove that facile slander of Ada. Ada-the-language is 
certainly "larger" than C, but not larger than C++. Ada applications are 
comparable in performance and memory needs to C applications. You can 
prefer C if you like, but not for such reasons.

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

Op 04-Nov-16 om 7:22 PM schreef kalvin.news@gmail.com:
> As the others has already stated the C# is not suitable for the real-time and safety-critical systems.
>
> Typically there are two options:
>
> 1. Use Ada language.
> 2. Use MISRA subset of C language.
>
> Some people might argue that C++ would be just fine, but I would argue that it is very easy to create something that is doing something that you didn't intend to do. The C++ is such a clever language that I will do some things behind the scene (like allocate an object from the dynamic heap although you didn't do it explicitly)

That's easily solved by linking without heap support (so using the heap 
will cause a linker error.

Wouter "Objects? No Thanks!" van Ooijen

On 11/4/2016 2:38 PM, Niklas Holsti wrote:
> On 16-11-04 19:54 , Don Y wrote:
>> "Big system language" and "memory requirements" and "runtime"
>> don't preclude a particular choice.  Consider Ada in your
>> above assessment (hardly "small", economical, etc.).
>
> I challenge you to prove that facile slander of Ada. Ada-the-language is
> certainly "larger" than C, but not larger than C++. Ada applications are
> comparable in performance and memory needs to C applications. You can prefer C
> if you like, but not for such reasons.

Do you consider Ada a "SMALL system language"?  I'm not talking about
the number of words/constructs in the language -- do you think it is
designed with "small systems" in mind?  Would you choose it to
implement a microwave oven controller (a half page of "BASIC")?

Ada is inherently targeted towards "bigger systems" (bigger
meaning more complex).  Why employ all those capabilities when
your overall objective is a "small project"?

[Seriously, look at what it takes to implement YOUR microwave
oven's controller]

On 05/11/16 04:03, John Speth wrote:
>> 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 ?...
>
> I agree with your negative concerns about the choice.  But from a
> testing point of view, any language is just as good as any other *IF* it
> can be proved as such through thorough testing.
> Every hole needs to be tested.

Not every hole *can* be tested. You run into the halting problem,
first and mainly with the garbage collector. There is no way to
prove it will always complete "in time" for any definition of
"in time". The same is likely true of many of the application's
own algorithms; but at least you're in control of those.

Clifford Heath.

On 11/4/2016 12:11 PM, kalvin.news@gmail.com wrote:
> perjantai 4. marraskuuta 2016 20.55.05 UTC+2 Don Y kirjoitti:
>> On 11/4/2016 7:30 AM, Chris wrote:
>>> On 11/04/16 13:44, Dave Nadler wrote:
>>>> On Friday, November 4, 2016 at 9:13:01 AM UTC-4, Chris wrote:
>>>>> C# raises alarm bells here for all kinds of reasons, but what do
>>>>> you think ?...
>>>>
>>>> Alarm bells are definitely in order.
>>>>
>>>> C# is MS's answer to Java, and highly Windows-centric. The Mono
>>>> open-source port of the C# VM does have support for some embedded
>>>> architectures, but this should have been verified for your target
>>>> prior launching into development...
>>>>
>>>> See: http://www.mono-project.com/docs/about-mono/supported-platforms/
>>>>
>>>> While I've used C# for Windows applications I haven't tried it on an
>>>> embedded platform. For embedded projects normally I use C++
>>>>
>>>> Hope that helps! Best Regards, Dave
>>>
>>> Thanks for the reply and link. Do homework before going in etc :-).
>>>
>>> So from what I can see, it's a big systems language in memory
>>> requirements for libraries and run time support. C# also uses dynamic
>>> memory allocation and garbage collection, another red line for the this
>>> type of application.
>>
>> "Big system language" and "memory requirements" and "runtime" don't
>> preclude a particular choice.  Consider Ada in your above assessment
>> (hardly "small", economical, etc.).
>
> Ada has a so called Ravenscar-profile (subset of the Ada language) which is
> targeted especially to the embedded systems, and has removed some of the
> language features that were considered unnecessary or unsuitable for the
> safety critical systems. Heck, the free AVR-Ada compiler can produce code
> even for the 8-bit Atmel atmega328 microcontroller.

You can write "tight LISP", too!

But Ada is intended to help manage system complexity.  A "small"
system is typically not very complex.  You wouldn't go hunting rabbit
with a Thompson submachine gun.

What Ada brings to the table is specifically for the "big systems"
that are too complex for "single brains" to accurately contain

[I am particularly fond of defining "complex" as "too big for a
single braincase"; it is a very effective way of differentiating
among "simple" and "complex" projects/problems.  If you have
to take notes or call on colleagues for assistance, it's "complex".
If, like pumping gasoline, you can "see" the entire application
in your mind, it's "simple"]

On 05/11/16 09:12, Don Y wrote:
> [Seriously, look at what it takes to implement YOUR microwave
> oven's controller]

I'm not sure that's a good example. I don't think I've
ever seen a microwave oven controller that did not suffer
from some firmware defect. The same goes for many other
domestic embedded appliances - the more trivial they seem,
the more likely the assembly-language programmer has made
an off-by-one error, or failed to handle easily seen human
factors issues.

Sony, Panasonic, Canon, seem to do a good job of this. At
least I've not seen one of their products with the gross
errors that affect Samsung, Xerox, and most other brands.
And we all know about Toyota!

Of course it's possible to write code in any language which
"respects the user"... but the differences between companies
in this regard are almost certainly reflected in their
choice of tools.

Clifford Heath.

P.S. On ADA; it's a big language, but it can target small
devices. The size of a language, compiler and toolchain
does not necessarily follow the size of its targets.