Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #25342 > unrolled thread
| Started by | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| First post | 2016-11-04 13:12 +0000 |
| Last post | 2016-11-30 12:43 +0000 |
| Articles | 20 on this page of 91 — 22 participants |
Back to article view | Back to comp.arch.embedded
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 1 of 5 [1] 2 3 4 5 Next page →
| From | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| Date | 2016-11-04 13:12 +0000 |
| Subject | C# for Embedded ?... |
| Message-ID | <nvi1go$n89$1@gioia.aioe.org> |
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 ?... Regards, Chris
[toc] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2016-11-04 15:16 +0200 |
| Message-ID | <nvi1m8$kr$1@dont-email.me> |
| In reply to | #25342 |
On 4.11.16 15: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 ?... > > Regards, > > Chris IMHO, plain C, and maybe MISRA is the way to go. -- -TV
[toc] | [prev] | [next] | [standalone]
| From | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| Date | 2016-11-04 13:39 +0000 |
| Message-ID | <nvi33a$q50$1@gioia.aioe.org> |
| In reply to | #25343 |
On 11/04/16 13:16, Tauno Voipio wrote: > On 4.11.16 15: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 ?... >> >> Regards, >> >> Chris > > IMHO, plain C, and maybe MISRA is the way to go. > Thanks. My feelings exactly and if a rtos is needed, something qualified for avionics work. The project is very mech eng centric and i'm not convinced that they really understand how critical the control software is to the success and safety of the system. As for Misra, not sure they have ever heard of it... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | Jack <jack4747@gmail.com> |
|---|---|
| Date | 2016-11-04 07:52 -0700 |
| Message-ID | <0062a0e3-ff97-4ad6-abab-23c6b536999f@googlegroups.com> |
| In reply to | #25343 |
Il giorno venerdì 4 novembre 2016 14:16:23 UTC+1, Tauno Voipio ha scritto: > On 4.11.16 15: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 ?... > > > > Regards, > > > > Chris > > IMHO, plain C, and maybe MISRA is the way to go. or ADA. But it depends on the platform and the compilers. Bye Jack
[toc] | [prev] | [next] | [standalone]
| From | Luke A. Guest <laguest@archeia.com> |
|---|---|
| Date | 2016-11-30 12:47 +0000 |
| Message-ID | <1546067893.502202764.040422.laguest-archeia.com@nntp.aioe.org> |
| In reply to | #25347 |
Jack <jack4747@gmail.com> wrote: >> IMHO, plain C, and maybe MISRA is the way to go. > > or ADA. > But it depends on the platform and the compilers. Australian/American Dentists/Disabilities Acts? Or do you mean, Ada? Why do people think a name is an acronym?
[toc] | [prev] | [next] | [standalone]
| From | Dave Nadler <drn@nadler.com> |
|---|---|
| Date | 2016-11-04 06:44 -0700 |
| Message-ID | <88363acc-623b-4001-aee7-2af89a02becd@googlegroups.com> |
| In reply to | #25342 |
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
[toc] | [prev] | [next] | [standalone]
| From | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| Date | 2016-11-04 14:30 +0000 |
| Message-ID | <nvi61j$vj5$1@gioia.aioe.org> |
| In reply to | #25345 |
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. Wouldn't surprise me to find out they are using Embedded Linux, but hope not... Regards, Chris
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-11-04 11:54 -0700 |
| Message-ID | <nvilhb$c5s$1@dont-email.me> |
| In reply to | #25346 |
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.). 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. > Wouldn't surprise me to find out they are using Embedded Linux, > but hope not... Why? It might be *perfectly* suited to the application -- that you've not disclosed. What you want to see is that "they" understand the issues that are important to THEIR application -- along with the capabilities, characteristics and limitations of the tools and implementation they are choosing -- and in sufficient detail that they can anticipate the sorts of problems they WILL encounter in reifying the design... so they can AVOID them in their implementation.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-11-04 12:10 -0700 |
| Message-ID | <nvimeh$ebg$2@dont-email.me> |
| In reply to | #25359 |
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!)
[toc] | [prev] | [next] | [standalone]
| From | Mike Perkins <spam@spam.com> |
|---|---|
| Date | 2016-11-06 14:55 +0000 |
| Message-ID | <nvng86$q34$1@news2.open-news-network.org> |
| In reply to | #25362 |
On 04/11/2016 19:10, Don Y wrote: > 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!) It may appear that way, but in reality I think you'll find some hardware interlock so when the user releases the nozzle trigger, one or more valves will close, independent of any software. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-11-06 12:46 -0700 |
| Message-ID | <nvo1al$ojs$1@dont-email.me> |
| In reply to | #25407 |
On 11/6/2016 7:55 AM, Mike Perkins wrote: > On 04/11/2016 19:10, Don Y wrote: >> 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!) > > It may appear that way, but in reality I think you'll find some hardware > interlock so when the user releases the nozzle trigger, one or more valves will > close, independent of any software. You do realize that you can latch the nozzle "on"? And, that there is no guarantee that the user will have it positioned *in* the filler neck of a vehicle (so the "full" backpressure sensor will disengage that latch)? I.e., a malevolent user at an unattended gas station could latch the nozzle on and walk away, flooding the area with fuel. Or, the backpressure sensor could fail. (when addressing safety critical/mission critical/etc. applications, you have to PLAN on failures and decide how you will address their inevitability) [This was one of the issues we had to address when accommodating unattended operation of the pumps. You'll note that most service stations either operate in prepay or semiattended mode -- though we have electric and LNG/propane dispensaries, here, that are completely unattended]
[toc] | [prev] | [next] | [standalone]
| From | Mike Perkins <spam@spam.com> |
|---|---|
| Date | 2016-11-06 20:48 +0000 |
| Message-ID | <nvo4v6$55f$1@news2.open-news-network.org> |
| In reply to | #25415 |
On 06/11/2016 19:46, Don Y wrote: > On 11/6/2016 7:55 AM, Mike Perkins wrote: >> On 04/11/2016 19:10, Don Y wrote: >>> 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!) >> >> It may appear that way, but in reality I think you'll find some hardware >> interlock so when the user releases the nozzle trigger, one or more >> valves will >> close, independent of any software. > > You do realize that you can latch the nozzle "on"? > And, that there is no guarantee that the user will have > it positioned *in* the filler neck of a vehicle (so the > "full" backpressure sensor will disengage that latch)? > > I.e., a malevolent user at an unattended gas station > could latch the nozzle on and walk away, flooding the > area with fuel. Or, the backpressure sensor could fail. > (when addressing safety critical/mission critical/etc. > applications, you have to PLAN on failures and decide > how you will address their inevitability) > > [This was one of the issues we had to address when accommodating > unattended operation of the pumps. You'll note that most service > stations either operate in prepay or semiattended mode -- though > we have electric and LNG/propane dispensaries, here, that are > completely unattended] Most pumps limit how much fuel can be dispensed. I doubt you would use software alone to limit the fuel and you would have a mechanical device to measure flow and cut off accordingly. I agree with you entirely on the planning of various risk control measures for a variety of scenarios. We're probably singing from the same hymn sheet though approaching from different directions. -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-11-06 14:25 -0700 |
| Message-ID | <nvo73n$epk$1@dont-email.me> |
| In reply to | #25416 |
On 11/6/2016 1:48 PM, Mike Perkins wrote:
> On 06/11/2016 19:46, Don Y wrote:
>> On 11/6/2016 7:55 AM, Mike Perkins wrote:
>>> On 04/11/2016 19:10, Don Y wrote:
>>>> 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!)
>>>
>>> It may appear that way, but in reality I think you'll find some hardware
>>> interlock so when the user releases the nozzle trigger, one or more
>>> valves will
>>> close, independent of any software.
>>
>> You do realize that you can latch the nozzle "on"?
>> And, that there is no guarantee that the user will have
>> it positioned *in* the filler neck of a vehicle (so the
>> "full" backpressure sensor will disengage that latch)?
>>
>> I.e., a malevolent user at an unattended gas station
>> could latch the nozzle on and walk away, flooding the
>> area with fuel. Or, the backpressure sensor could fail.
>> (when addressing safety critical/mission critical/etc.
>> applications, you have to PLAN on failures and decide
>> how you will address their inevitability)
>>
>> [This was one of the issues we had to address when accommodating
>> unattended operation of the pumps. You'll note that most service
>> stations either operate in prepay or semiattended mode -- though
>> we have electric and LNG/propane dispensaries, here, that are
>> completely unattended]
>
> Most pumps limit how much fuel can be dispensed.
And, you have to ensure that limit is on VOLUME and not "dollar amount"!
I.e., a station operator is likely to think in terms of limiting the
size of the largest SALE ("$100 ought to cover it!"). But, that doesn't
directly translate to fuel volume in a way that is easily (or even
reliably!) predictable: how many gallons would that be at $0.00/gal?)
> I doubt you would use software
> alone to limit the fuel and you would have a mechanical device to measure flow
> and cut off accordingly.
Dunno -- I haven't been inside a fuel dispenser for 30+ years.
At the time, the only "mechanical" valve was the "trigger" that
your hand engages on the pump nozzle. returning the nozzle to its
storage slot only trips a switch that signals the software
that the transaction is complete (pump SHOULD be turned off,
regardless).
You can verify this by pumping gas, holding the nozzle "on"
and reaching your hand up inside the storage slot -- push the
"flap" upwards as if you'd just returned the nozzle to that
position and you'll note that the pump stops... despite the
fact that your OTHER hand is still commanding the nozzle to
dispense.
[Note, also, that the hose will remain under pressure if you
release the "dispense" trigger (allowing pressure to build
in the hose) and then return the nozzle to its storage slot.
I.e., the pump is off but the stored pressure has no outlet as
the mechanical valve at the nozzle is closed -- and the pump won't
"bleed backwards"]
> I agree with you entirely on the planning of various risk control measures for
> a variety of scenarios. We're probably singing from the same hymn sheet though
> approaching from different directions.
My original point was that it is essentially a trivial problem.
Even allowing for "software safeguards", it hardly merits a
large design team (at least, not for the pump controller itself)
or sophisticated implementation language.
Rather, you want something that LOTS OF DEVELOPERS could maintain
instead of looking for someone with a deep history of designing
such systems. "Common sense" with advice from someone who already
has would be more than sufficient.
[toc] | [prev] | [next] | [standalone]
| From | kalvin.news@gmail.com |
|---|---|
| Date | 2016-11-04 12:11 -0700 |
| Message-ID | <e794552f-c2cb-4330-b280-2982e86c75d5@googlegroups.com> |
| In reply to | #25359 |
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
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-11-04 15:17 -0700 |
| Message-ID | <nvj1cp$n48$1@dont-email.me> |
| In reply to | #25363 |
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"]
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2016-11-05 09:24 +1100 |
| Message-ID | <581d0a99$0$34726$b1db1813$79461190@news.astraweb.com> |
| In reply to | #25371 |
On 05/11/16 09:17, Don Y wrote: > What Ada brings to the table is specifically for the "big systems" > that are too complex for "single brains" to accurately contain Most brains involved in embedded programming cannot accurately contain many small problems, as I just pointed out elsewhere. Of course, having a better language guarantees nothing, but the choice of a better language is a good indication of awareness of the difficulty of even "small problems".
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-11-04 22:38 +0100 |
| Message-ID | <e84de0FaoglU1@mid.individual.net> |
| In reply to | #25359 |
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
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Don Y <blockedofcourse@foo.invalid> |
|---|---|
| Date | 2016-11-04 15:12 -0700 |
| Message-ID | <nvj149$m8i$1@dont-email.me> |
| In reply to | #25367 |
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]
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2016-11-05 09:21 +1100 |
| Message-ID | <581d09f7$0$34726$b1db1813$79461190@news.astraweb.com> |
| In reply to | #25369 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2016-11-05 07:21 +0100 |
| Message-ID | <e85c3tFh7cdU1@mid.individual.net> |
| In reply to | #25369 |
On 16-11-04 23:12 , Don Y wrote:
> 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"?
Certainly it it suitable for small systems. Remember, Ada was originally
designed in the early 1980s, for applications including embedded
systems, many of which were then quite small by current standards.
The emphasis on embedded systems was so strong that some people believed
that Ada wasn't good for anything else (IMO a false belief, of course).
> 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")?
If an Ada compiler were available, certainly. And a half page of BASIC
would be a very simple microwave oven indeed (depending of course on how
much of the functions, safety interlocks etc. are implemented in HW).
> Ada is inherently targeted towards "bigger systems" (bigger
> meaning more complex).
It was designed to *support* such systems -- that was often called
"programming in the large". But those features of Ada -- in particular
the strong modularity (packages) and the encapsulation and information
hiding features -- are entirely source-level, compile-time features and
imply no overhead at run time.
One of the goals in the design of Ada was to avoid "distributed
overhead" from language features that are not used in an application. If
your application does not need multi-threading, fine, use a run-time
system without tasking support. If you need only simple multi-threading,
use a Ravenscar RTS, and so on.
> Why employ all those capabilities when
> your overall objective is a "small project"?
Small projects tend to grow, and to need maintenance, sometimes over a
long time. Readability and maintainability are important and were also
explicit design goals of the Ada language.
> Seriously, look at what it takes to implement YOUR microwave
> oven's controller
I've not seen the code in there, but I suspect that it is rather more
than a half page of BASIC.
Still, this thread is (or was) not about micowave ovens, but about a
safety-critical automotive application, which I suspect is larger than a
microwave-oven controller.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web