Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25342 > unrolled thread

C# for Embedded ?...

Back to article view | Back to comp.arch.embedded

Contents

  C# for Embedded ?... Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-04 13:12 +0000
    Re: C# for Embedded ?... Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-11-04 15:16 +0200
      Re: C# for Embedded ?... Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-04 13:39 +0000
      Re: C# for Embedded ?... Jack <jack4747@gmail.com> - 2016-11-04 07:52 -0700
        Re: C# for Embedded ?... Luke A. Guest <laguest@archeia.com> - 2016-11-30 12:47 +0000
    Re: C# for Embedded ?... Dave Nadler <drn@nadler.com> - 2016-11-04 06:44 -0700
      Re: C# for Embedded ?... Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-04 14:30 +0000
        Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 11:54 -0700
          Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 12:10 -0700
            Re: C# for Embedded ?... Mike Perkins <spam@spam.com> - 2016-11-06 14:55 +0000
              Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-06 12:46 -0700
                Re: C# for Embedded ?... Mike Perkins <spam@spam.com> - 2016-11-06 20:48 +0000
                  Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-06 14:25 -0700
          Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-04 12:11 -0700
            Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 15:17 -0700
              Re: C# for Embedded ?... Clifford Heath <no.spam@please.net> - 2016-11-05 09:24 +1100
          Re: C# for Embedded ?... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-11-04 22:38 +0100
            Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 15:12 -0700
              Re: C# for Embedded ?... Clifford Heath <no.spam@please.net> - 2016-11-05 09:21 +1100
              Re: C# for Embedded ?... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-11-05 07:21 +0100
                Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 23:39 -0700
                Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-04 23:52 -0700
                  Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 00:44 -0700
                    Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-05 04:03 -0700
                      Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 04:41 -0700
                        Re: C# for Embedded ?... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-11-06 10:03 +0100
                          Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-06 14:32 -0800
                      Re: C# for Embedded ?... upsidedown@downunder.com - 2016-11-05 15:39 +0200
                        Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 11:12 -0700
                      Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-05 11:35 -0700
                        Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 11:46 -0700
      Re: C# for Embedded ?... Luke A. Guest <laguest@archeia.com> - 2016-11-30 12:47 +0000
    Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 15:37 +0000
      Re: C# for Embedded ?... Tim Wescott <tim@seemywebsite.really> - 2016-11-04 11:32 -0500
        Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 18:19 +0000
    Re: C# for Embedded ?... George Neuner <gneuner2@comcast.net> - 2016-11-04 12:07 -0400
      Re: C# for Embedded ?... David Brown <david.brown@hesbynett.no> - 2016-11-04 17:54 +0100
        Re: C# for Embedded ?... Tim Wescott <seemywebsite@myfooter.really> - 2016-11-04 12:54 -0500
      Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 18:36 +0000
        Re: C# for Embedded ?... George Neuner <gneuner2@comcast.net> - 2016-11-04 22:00 -0400
          Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-04 21:02 -0700
            Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 08:45 +0000
          Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 08:38 +0000
            Re: C# for Embedded ?... George Neuner <gneuner2@comcast.net> - 2016-11-06 04:50 -0500
              Re: C# for Embedded ?... Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-11-06 19:49 +0200
              Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-06 19:05 +0000
      Re: C# for Embedded ?... Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-11-06 19:52 +0100
        Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-06 11:10 -0800
          Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-06 22:44 +0000
        Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-06 19:12 +0000
          Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-06 11:33 -0800
            Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-06 22:59 +0000
              Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-06 15:48 -0800
                Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-07 07:45 +0000
                  Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-07 00:09 -0800
                    Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-07 09:56 +0000
                      Re: C# for Embedded ?... Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-11-07 18:38 +0100
                        Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-07 19:17 +0000
                          Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-07 21:29 -0800
                            Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-08 08:07 +0000
                              Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-08 01:00 -0800
                                Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-08 10:19 +0000
    Re: C# for Embedded ?... John Speth <johnspeth@yahoo.com> - 2016-11-04 10:03 -0700
      Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 12:04 -0700
      Re: C# for Embedded ?... Clifford Heath <no.spam@please.net> - 2016-11-05 09:13 +1100
        Re: C# for Embedded ?... Ed Prochak <edprochak@gmail.com> - 2016-11-07 11:16 -0800
          Re: C# for Embedded ?... Clifford Heath <no.spam@please.net> - 2016-11-08 21:39 +1100
            Re: C# for Embedded ?... Ed Prochak <edprochak@gmail.com> - 2016-11-11 15:25 -0800
    Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-04 11:22 -0700
      Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 18:50 +0000
        Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-04 11:58 -0700
          Re: C# for Embedded ?... kalvin.news@gmail.com - 2016-11-04 12:17 -0700
        Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-04 12:51 -0700
          Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-04 23:23 +0000
            Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-04 17:35 -0700
              Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 09:04 +0000
      Re: C# for Embedded ?... Wouter van Ooijen <wouter@voti.nl> - 2016-11-04 22:55 +0100
      Re: C# for Embedded ?... Luke A. Guest <laguest@archeia.com> - 2016-11-30 15:55 +0000
    Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-04 11:48 -0700
    Re: C# for Embedded ?... asdf <asdf@nospam.com> - 2016-11-05 12:40 +0000
      Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 15:48 +0000
        Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-05 11:41 -0700
          Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 20:20 +0000
            Re: C# for Embedded ?... Paul Rubin <no.email@nospam.invalid> - 2016-11-05 19:14 -0700
      Re: C# for Embedded ?... upsidedown@downunder.com - 2016-11-05 20:15 +0200
        Re: C# for Embedded ?... Tom Gardner <spamjunk@blueyonder.co.uk> - 2016-11-05 20:25 +0000
          Re: C# for Embedded ?... Don Y <blockedofcourse@foo.invalid> - 2016-11-05 17:15 -0700
    Re: C# for Embedded ?... Mike Perkins <spam@spam.com> - 2016-11-05 21:04 +0000
    Re: C# for Embedded ?... Chris <xxx.syseng.yyy@gfsys.co.uk> - 2016-11-06 00:31 +0000
      Re: C# for Embedded ?... Dave Nadler <drn@nadler.com> - 2016-11-05 18:11 -0700
    Re: C# for Embedded ?... Luke A. Guest <laguest@archeia.com> - 2016-11-30 12:43 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#25449

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> Please read what I wrote. I did not suggest writing the /application/
> in assembler.

The Java applets on the card are what I mean by the application.  It
does things like manage PKI credentials, etc.  I don't know if phone
contacts on sim cards are usually implemented with applets.

Yes, crypto primitives are done with assembly code and/or hardware
accelerators on the card.  Your Java applet can them through appropriate
interfaces.

> Having said that, my suspicion is that the /applications/ on JavaCards
> are so simple that they /could/ be coded in assembler

I think you have a picture of these applets being coded by the card
manufacturer.  But it's usually the client application developer who
codes them.  Who expects to expect them to progam the cards in
assembler?  Java makes life a lot easier even if assembler were
feasible.

> but I wouldn't push that point. It could be easily countered by
> outlining an application that was /necessarily/ too complex for that
> to be reasonable.

PKCS11 token, one of the driving applications for javacard.  Spec is
linked from here:

  https://www.cryptsoft.com/pkcs11doc/

The "base" spec is a 150 page pdf and then there's some extensions in
separate documents.  There's a ton of code involved.  But, I don't know
how much of it has to be on the card itself.

G10 also offers PGP/GPG key management smart cards.

These cards run complex protocols--they're not just running some number
through AES and sending back the answer.

> Sigh. Please use some common sense about what "sufficiently complex to
> warrant" might mean.  Hint: a googling leads to the first definition
> of warrant as a verb: "justify or necessitate (a course of action)."

I certainly think using Javacard is justified when faced with the much
larger hassle and vulnerability surface of using assembler.  That is
true even of very small applications.  The payment card and mobile phone
industries use billions of javacards for a reason, not because they were
hoodwinked by marketing crap.

> I would be interested in whether there are any real-world cases of
> multiple applications for different corporations on the same JavaCard.

Payment credentials for more than one bank account or credit card.

>> You mean like Java?  ;-)
> Yes, as one of several.

If you prefer BASIC, try basiccard.com.  I have some of these.  The
cards aren't as flexible but the dev kit is cheaper.

[toc] | [prev] | [next] | [standalone]

#25452

On 08/11/16 09:00, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> Please read what I wrote. I did not suggest writing the /application/
>> in assembler.
>
> The Java applets on the card are what I mean by the application.  It
> does things like manage PKI credentials, etc.  I don't know if phone
> contacts on sim cards are usually implemented with applets.
>
> Yes, crypto primitives are done with assembly code and/or hardware
> accelerators on the card.  Your Java applet can them through appropriate
> interfaces.
>
>> Having said that, my suspicion is that the /applications/ on JavaCards
>> are so simple that they /could/ be coded in assembler
>
> I think you have a picture of these applets being coded by the card
> manufacturer.  But it's usually the client application developer who
> codes them.  Who expects to expect them to progam the cards in
> assembler?  Java makes life a lot easier even if assembler were
> feasible.

Oh yes indeed; I use assembler as an extreme - which I
suspect would be practical (even if not desirable!) for
the simple apps I /imagine/ being on a JavaCard.

I'd welcome use cases of apps with complex logic, where the
same end result couldn't reasonably be achieved by simply
passing a magic number to a server.


>> but I wouldn't push that point. It could be easily countered by
>> outlining an application that was /necessarily/ too complex for that
>> to be reasonable.
>
> PKCS11 token, one of the driving applications for javacard.  Spec is
> linked from here:
>
>    https://www.cryptsoft.com/pkcs11doc/
>
> The "base" spec is a 150 page pdf and then there's some extensions in
> separate documents.  There's a ton of code involved.  But, I don't know
> how much of it has to be on the card itself.
>
> G10 also offers PGP/GPG key management smart cards.
>
> These cards run complex protocols--they're not just running some number
> through AES and sending back the answer.

I certainly haven't got time or inclination to read that!

A /quick/ skim didn't indicate compelling use cases, let
alone for complex logic in the JavaCard.

As I said, examples would be welcome.


>> Sigh. Please use some common sense about what "sufficiently complex to
>> warrant" might mean.  Hint: a googling leads to the first definition
>> of warrant as a verb: "justify or necessitate (a course of action)."
>
> I certainly think using Javacard is justified when faced with the much
> larger hassle and vulnerability surface of using assembler.  That is
> true even of very small applications.  The payment card and mobile phone
> industries use billions of javacards for a reason, not because they were
> hoodwinked by marketing crap.

Oh yes indeed. But convenience is one thing, necessity another.


>> I would be interested in whether there are any real-world cases of
>> multiple applications for different corporations on the same JavaCard.
>
> Payment credentials for more than one bank account or credit card.

Only if from different companies (e.g. banks). Multiple
accounts with the same institution can be dealt with by
a single magic number.

After all, when Javacards aren't involved, I simply
login to a bank once, and then fettle with all my
accounts in that bank simultaneously.


>>> You mean like Java?  ;-)
>> Yes, as one of several.
>
> If you prefer BASIC, try basiccard.com.  I have some of these.  The
> cards aren't as flexible but the dev kit is cheaper.

OK, if I argue from one extreme, I can't complain if
you use others :)

[toc] | [prev] | [next] | [standalone]

#25352

> 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.  I would hope there are 
well defined SW QA requirements.  Using C# just opens up a lot of 
possible quality holes that might be avoided with some other programming 
language.  Every hole needs to be tested.  Every test costs money and 
time.  It sounds like your customer is wearing blinders and only looking 
at how easy it would be for the programmer to code it.  I think if 
you're opposed to C#, present a case in terms of dollars that will 
convince them the choice is ill considered.  It's always all about money 
after all.

JJS

[toc] | [prev] | [next] | [standalone]

#25361

On 11/4/2016 10:03 AM, 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.

The problem is that many languages/implementations are buggy or
temperamental or contain nondeterministic characteristics that
can hinder testing.

I use Limbo as a scripting language yet it has many areas where
the implementation isn't quite as predictable as I'd like
OTOH, it is a much "safer" environment for casual developers;
many of the things that "seasoned professionals" often get caught
making errors (buffer overruns, dereferencing pointers, etc.)
are simply not possible.

But, it's much harder for me (or said users) to look at a
limbo code fragment and predict how well it will behave in any
given set of circumstances (e.g., how long will it take to
execute?  when will the GC kick in?  what will happen when
there is insufficient memory to satisfy the next dynamic memory
request?  what happens if the target of a remote communication
channel goes down?)

> I would hope there are well defined SW QA
> requirements.  Using C# just opens up a lot of possible quality holes that
> might be avoided with some other programming language.  Every hole needs to be
> tested.  Every test costs money and time.

And every language moves those holes to different places in the
development process and runtime!

> It sounds like your customer is
> wearing blinders and only looking at how easy it would be for the programmer to

It sounds like the programmers have picked a tool/environment with
which they are comfortable/familiar -- instead of considering its
applicability!  Note that if the developers are held constant,
ALL OTHER CHOICES may, in fact, be *worse*!  :>

> code it.  I think if you're opposed to C#, present a case in terms of dollars
> that will convince them the choice is ill considered.  It's always all about
> money after all.

[toc] | [prev] | [next] | [standalone]

#25370

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.

[toc] | [prev] | [next] | [standalone]

#25437

On Friday, November 4, 2016 at 6:13:38 PM UTC-4, Clifford Heath wrote:
> 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.

Sorry for joining late in the conversation.

Actually I would say it depends on the systems architecture.
C# is a decent GUI language. If you then assign the hard real
time features to low level controllers (device drivers &/or
micro controllers like Arduino), you can build a decently
robust system.

So I guess my opinion is "it depends".

Ed

[toc] | [prev] | [next] | [standalone]

#25453

On 08/11/16 06:16, Ed Prochak wrote:
> On Friday, November 4, 2016 at 6:13:38 PM UTC-4, Clifford Heath wrote:
>> 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.
>
> Sorry for joining late in the conversation.
>
> Actually I would say it depends on the systems architecture.
> C# is a decent GUI language. If you then assign the hard real
> time features to low level controllers (device drivers &/or
> micro controllers like Arduino), you can build a decently
> robust system.
>
> So I guess my opinion is "it depends".

Ed,

You responded to my message, but not to anything I actually said.

Why?

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

#25478

On Tuesday, November 8, 2016 at 5:39:35 AM UTC-5, Clifford Heath wrote:
> On 08/11/16 06:16, Ed Prochak wrote:
[]
> >
> > So I guess my opinion is "it depends".
> 
> Ed,
> 
> You responded to my message, but not to anything I actually said.
> 
> Why?
> 
> Clifford Heath.

Sorry I should have snipped.

And I've stayed out since because I think some of this is overthinking
the problem without knowing details. (not saying you specifically).

[toc] | [prev] | [next] | [standalone]

#25355

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) unless you are very careful and know what to do. So, I would rule out the C++ unless you are really competent with it.

In addition to the suitable programming language you will need an operating system. Typically in a real-time systems you would need an operating system that has real-time features. However, in a safety critical systems you will need an OS that is simple enough to be safely used in a safety critical systems.

I am not an expert of the safety critical systems, so I will not be able to point you to any direction on selecting the operating system.

However, what I have read and learnt, the operating systems of highly reliable systems (like early satellites at least) had very simple "operating systems" that didn't have any fancy features like pre-emptive multitasking or even interrupts. The "operating system" was just a simple control loop running fast enough using polling to get the data from the sensors. What, no interrupts or multitasking? Why? Because the simple system was predictable. Something that a real-time and safety-critical system needs to be.

Want tasks anyway? No problemo, just implement the tasks as state machines, and use a simple yet effective timer-triggered, co-operative, run to completion tasker.

Br,
Kalvin

[toc] | [prev] | [next] | [standalone]

#25358

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 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.

[toc] | [prev] | [next] | [standalone]

#25360

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

[toc] | [prev] | [next] | [standalone]

#25364

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 ..."

[toc] | [prev] | [next] | [standalone]

#25365

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

[toc] | [prev] | [next] | [standalone]

#25374

On 04/11/16 19:51, Paul Rubin wrote:
> 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

Your suggested actions w.r.t. C/C++ are ameliorations,
not cures. But you know that.

Even if (and it is a big if) they were a cure,
how could you guarantee that /everybody/ (in
whatever company) that produced any code that
ends up in your product has fully followed the
recommended practices.

Using C/C++ for safety critical system is "building
a castle on sand".

If you look back (to say 1993) in the archives you will
find cases where competent compiler writers have asked
expert users with a record of knowing where skeletons
are likely to be buried, "what does the standard mean
by X?" and "how do we simultaneously resolve the standard
saying X and Y?". That doesn't warm the cockles of
my heart.

[toc] | [prev] | [next] | [standalone]

#25375

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> C++ core guidelines
> Your suggested actions w.r.t. C/C++ are ameliorations, not cures. 

The guidelines basically say to use the current reasonably safe subset
of C++ rather than the leftover legacy stuff.  C++ itself can't get rid
of the old stuff because old programs would break, but new code can
avoid it straightforwardly.

> Even if (and it is a big if) they were a cure, how could you guarantee
> that /everybody/ (in whatever company) that produced any code that
> ends up in your product has fully followed the recommended practices.

1) Most (not all) of the guideline recommendations are statically
machine checkable and the guideline discusses that for each item.

2) Critical code even in Ada usually has multi-person code reviews that
should be able to spot departures from coding rules.

3) Stuff like excluding the use of certain runtime libraries can be
enforced by replacing those libraries with versions that signal errors.

4) The same "amelioration" issues apply to C (MISRA guidelines for
acceptable practices), Ada (Spark subset and profile), etc.

> Using C/C++ for safety critical system is "building a castle on sand".

C and C++ these days are completely different languages and Stroustrup
likes to say "I take most uses of the compound C/C++ as an indication of
ignorance." (http://www.stroustrup.com/bs_faq.html#C-slash)

The C++ FQA sometimes is used to support the view that C++ is more
dangerous than C.  Having used C++ for a while now, my current
subjective impression is that if you follow the core guidelines and use
traditional coding/debugging processes, C++ is safer than C, especially
with modern (C++11 and later) dialects.  Ada is probably safer than
either.  I definitely choked a little when I heard that the Tesla car
and SpaceX rocket are both programmed in C++.

C has better static analysis tools like Frama-C that I'd like to try
using, which could be considered an advantage of C over C++.  I
currently haven't used them though.

> "what does the standard mean by X?" and "how do we simultaneously
> resolve the standard saying X and Y?". That doesn't warm the cockles
> of my heart.

Yep.  It's still like that.  You also can see that type of thing in
comp.lang.ada, so it's not C specific.

[toc] | [prev] | [next] | [standalone]

#25384

On 05/11/16 00:35, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>> C++ core guidelines
>> Your suggested actions w.r.t. C/C++ are ameliorations, not cures.
>
> The guidelines basically say to use the current reasonably safe subset
> of C++ rather than the leftover legacy stuff.  C++ itself can't get rid
> of the old stuff because old programs would break, but new code can
> avoid it straightforwardly.

Yes, but "legacy" => "sand", and very few programs are completely
new code.

>
>> Even if (and it is a big if) they were a cure, how could you guarantee
>> that /everybody/ (in whatever company) that produced any code that
>> ends up in your product has fully followed the recommended practices.
>
> 1) Most (not all) of the guideline recommendations are statically
> machine checkable and the guideline discusses that for each item.

Such guidelines are certainly a significant help, but for
safety critical work /guarantees/ are valuable. Other
languages are a better starting point where guarantees
are required.


> 2) Critical code even in Ada usually has multi-person code reviews that
> should be able to spot departures from coding rules.

Of course. You can create a bad/dangerous/stupid system
in any language.


> 3) Stuff like excluding the use of certain runtime libraries can be
> enforced by replacing those libraries with versions that signal errors.

Dangerous in an embedded safety-critical application.
Avoidance by design and construction is highly preferable.
While not completely achievable, other languages get you
considerably closer to nirvana.


> 4) The same "amelioration" issues apply to C (MISRA guidelines for
> acceptable practices), Ada (Spark subset and profile), etc.
>
>> Using C/C++ for safety critical system is "building a castle on sand".
>
> C and C++ these days are completely different languages and Stroustrup
> likes to say "I take most uses of the compound C/C++ as an indication of
> ignorance." (http://www.stroustrup.com/bs_faq.html#C-slash)

He's said many things over the decades, of course :)

To me what's important is what the average programmer
*doesn't* have to know/worry about. Most want to (and
are paid to) drain a swamp, not fend off alligators.


> The C++ FQA sometimes is used to support the view that C++ is more
> dangerous than C.

C++ /is/ more dangerous in that it is more poorly specified
and more misunderstood by typical programmers (and
language implementers, if anecdotes from those involved
in such things are to be believed).

In other respects they are equally safe/dangerous. The
question then becomes how much damage a typical programmer
could inflict knowingly or inadvertently.


> Having used C++ for a while now, my current
> subjective impression is that if you follow the core guidelines and use
> traditional coding/debugging processes, C++ is safer than C, especially
> with modern (C++11 and later) dialects.  Ada is probably safer than
> either.  I definitely choked a little when I heard that the Tesla car
> and SpaceX rocket are both programmed in C++.

Gag :(


> C has better static analysis tools like Frama-C that I'd like to try
> using, which could be considered an advantage of C over C++.  I
> currently haven't used them though.

And that's a problem: not many people do use them.

Tools like valgrind are used because they uncover
very common classes of problem that are completely
avoided by using "more advanced" languages and
managed environments that give you extra guarantees.


>> "what does the standard mean by X?" and "how do we simultaneously
>> resolve the standard saying X and Y?". That doesn't warm the cockles
>> of my heart.
>
> Yep.  It's still like that.  You also can see that type of thing in
> comp.lang.ada, so it's not C specific.

Agreed, but the issue is more widespread and significant
in C++ and (to a slightly lesser extent) in C.

[toc] | [prev] | [next] | [standalone]

#25368

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

[toc] | [prev] | [next] | [standalone]

#25527

<kalvin.news@gmail.com> wrote:

> 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) unless you are very careful
> and know what to do. So, I would rule out the C++ unless you are really competent with it.
> 

Any language that allows you to do stupid shit isn't clever at all.


> In addition to the suitable programming language you will need an
> operating system. Typically in a real-time systems you would need an
> operating system that has real-time features. However, in a safety
> critical systems you will need an OS that is simple enough to be safely
> used in a safety critical systems.
> 

Actually in Ada, if you implement enough low level stuff you could have the
runtime be your minimal OS.

Luke

[toc] | [prev] | [next] | [standalone]

#25357

On 11/4/2016 6:12 AM, 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 ?...

Flip your question around:
- why has C# been chosen (could it be that the developers chose it due to their
   familiarity with it and belief that one size fits all?)
- what does C# bring to the table (in their minds) that other languages don't
   (or, don't do as well)

These are THEIR questions to answer, not yours.

Virtually any language can be made safe -- if the particular implementation
is "well documented" and "predictable".  But, typically requires a higher
level of expertise of the developers.  This, in turn, tends to limit the pool
of individuals who can be called on to develop and maintain the product.

Also, "safety critical" can mean a variety of different things.  And, can
be addressed in a variety of different ways.  E.g., a system can be
designed to shutdown if it starts to "misbehave" or fails to behave
predictably.  OTOH, if that drives your availability to zero, the
system may be considered effectively useless.

The concern *I* would have is that C# is a MS product and they haven't
been known to stress stability, accuracy or reliability in ANY of
their products.  Is it hosted on anything OTHER than Windows?  Do
you really think Windows itself has been "qualified" to the level
of safety criticality/availability that the application requires?

<https://gcn.com/Articles/1998/07/13/Software-glitches-leave-Navy-Smart-Ship-dead-in-the-water.aspx>

If I was in your shoes, I'd be asking those advocating for C#/Windows
to defend their choice -- under an aggressive set of applicable criteria.

[toc] | [prev] | [next] | [standalone]

#25387

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.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web