Learning embedded coding, which uC? - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Learning embedded coding, which uC?

[%X]

Quoted text here. Click to load it

[%X]

Quoted text here. Click to load it

I am sure that Elizabeth Rather would be able to provide the most detailed
answer on that topic if you care to ask the question in comp.lang.forth. I
know that the Open Firmware standard (IEEE1275) was developed from the work
at Sun Microsystems and is included on each and every Sun workstation. The
Forth code in the ROM, I think, would be a byte-coded version of the source
code.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

It's my own consultancy, yes.
 
Quoted text here. Click to load it

While it may not be met very commonly in the majority of development
circles it does emerge in a wide range of systems. One should at least look
at Leo Brodies "Thinking Forth" to get a flavour for the philosophy behind
Forth. You never know, it may improve the way you think about your approach
to programming in other languages too.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?
Quoted text here. Click to load it

Thanks, I will have a look. I do have a forth for my PC but having the
time to play with it is another matter.

Forth is not something I would advocate for some one trying to get into
the embedded world as a career. The market is too small and specialised.
(besides you have most of it :-) After they have got started with C and
the main stream 8 bit MCU (where the work is) they could move to forth
later.



--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?
Quoted text here. Click to load it

FWIW, one example of Ada in medical stuff is Newport Instruments:

http://www.newportinstruments.com /


--
Niklas Holsti
Tidorum Ltd
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?
Hello Niklas,

Quoted text here. Click to load it

Well, maybe I should have said medical hardware and mostly midsize to
larger companies with >$50 million a year in sales.

Regards, Joerg

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

It is well known that C has many pitfalls and that creating safety
critical programs in that language involves a lot of work.

This is specially the case for multitasking where tasks share
resources. C has no built in mechanism for the safe execution
of concurrent programs. A RTOS provides mechanisms for this
but you can still bypass it and write an unsafe applications.


There are many other languages that make life simpler in theory.

High level concurrent languages:
- Ada
- Chill
- Modula-2
- Mesa
- Java - RTSJ
Message passing conccurency
- CSP
- Promela
- Handel-C
Synchronous languages
- Esterel
- Lustre
- Signal
- Statecharts
Hybrid languages
- Polis
- SDL
- System C
- CCSS

Why do developpers still use C and asm when other languages
would mean less risk and less effort ?

Are these languages only for academics, or do you use
some of them in industrial applications?


Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

I have heard of many of the languages on that list even if I haven't used
any of them in earnest. One thing that I think we should ask of those
posting such lists of languages is perhaps a short paragraph that indicates
the sort of target machine resources required in order to do anything very
useful with it. I know some embedded system developers still have to
produce systems that use resource limited hardware (mainly as a means to
keep the per unit cost down). I don't think the likes of Ada or Modula-2
would be the right choice for those (as an example).

In order to get some feel of proper system size you should perhaps quote
the resource requirements in terms of how much is required per Function
Point (or 100 function points if that is more sensible).

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Learning embedded coding, which uC?

Quoted text here. Click to load it


That explains it. I mistakenly assumed Mod51 was the name of the *language*.
A google search for modula-2 8051 turns up a lot more hits.

Thanks

Ian


Re: Learning embedded coding, which uC?
Hello Lanarcam,

Quoted text here. Click to load it

It's a matter of discipline and good documentation. Treat it like hardware.

Quoted text here. Click to load it

That requires even better docs and reviews. The most prevalent mistakes
I see in C and other programming around me is the fact that most SW
folks document after they are done. Or they do not document at all,
thinking that a few comment lines are good enough.

I always document while designing. So when I finish the design the
document explaining everything is completed at about the same time.

RTOS: We had good results with QNX. Seems to be pretty bullet-proof. But
I am not a SW guy by trade.

Quoted text here. Click to load it

In industry I have only seen C and assembler. Basic and Pascal are
pretty much gone and people go with where there is the largest talent
pool. That is C.

Regards, Joerg

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

Unfortunately that still does not guarantee error free concurrency. Do *you*
know if a given operation will be compiled into an atomic one at the
assembler level by your compiler?

Ian


Re: Learning embedded coding, which uC?
Hello Ian,

Quoted text here. Click to load it

No, it doesn't. That's not my point. My point is that it significantly
reduces the number of potential errors. There is no error free design by
man on earth. But there are differences in design quality and my
experience is that the level of documentation is quite proportional to
design quality.

Compilers carry risks. You have to put trust into a product designed by
someone else. That's a normal risk and you can't avoid it, short of
writing your own compiler. It's the same when you step on an aircraft.
While lots of meticulously documented procedures for pilots and others
involved are meant to make that flight as safe as possible you still
trust Boeing or Airbus that they did their stuff right. Believe me,
their doc system is pretty much water tight. You can't even puncture a
conformal coating with your scope probe without documenting that fact.

Regards, Joerg

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

I agree documentation can reduce errors, but you made the point in reply to
a point about C and concurrency.

Quoted text here. Click to load it

Absolutely, and you can be certain their software is *not* written in C
which was the OPs point.

Ian

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

What a load of rubbish. Good documentation only ensures the design is
documented - it does not ensure the design is good. Code reviews only
ensure the code works - not that it is a good design.

Ian

Re: Learning embedded coding, which uC?

[...]
Quoted text here. Click to load it

Agreed, but IME, lack of documentation is an excellent indicator of a
poor design.

Quoted text here. Click to load it

But that alone makes it worth the price, neh?

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

Agreed, but the converse is *not* true.
Quoted text here. Click to load it

Definitely no. I don't want to know it works, I want to know it works the
way it is supposed to.

Ian


Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

Not necessarily. Many very subtle bugs are hidden this way. Code reviews in
my experience rarely find them.

Quoted text here. Click to load it

Er?? Let's be clear. I expect there to exist a document that describes how
it is supposed to work *before* software design commences. I also expect
the software design to document *how* it achieves this. Again, code reviews
alone cannot adequately verify this. If they could then presumably testing
would be unnecessary.

Ian

Quoted text here. Click to load it


Re: Learning embedded coding, which uC?

Quoted text here. Click to load it
[...]
Quoted text here. Click to load it

I don't think anyone was arguing that code reviews were sufficient.

Only necessary.

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

Re: Learning embedded coding, which uC?
Hello Ian,

Quoted text here. Click to load it

Simple code reviews may not but design reviews can. One example: I asked
  a group of SW engineers what would happen if the image rotation data
written to disk were corrupt because someone shut down the unit while it
was being written. "Well, they are supposed to do an orderly shut-down
first"... "What if the power went and they couldn't?".... "Er, ahem,
well, ahm.........".

We ended up doing what aircraft guys do, three consecutive writes and a
majority decision. Without a design review this would have gone
unnoticed and because the FRS just isn't that detailed.

Regards, Joerg

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?
Hello Ian,

Quoted text here. Click to load it

I disagree. Without a good documentation process it is almost guaranteed
that there will be misunderstandings between team members. Some of these
can cause real havoc.

Reviews do increase the quality of a design, HW as well as SW. The
reason is simple: The whole review team has a chance to understand
what's going on and to ask tough questions. With docs there will be no
tough questions and hence a potentially bad product can result.

Sad example: Recently a helicopter crashed about 10 miles from here, the
most likely cause was engine failure because of a diaphragm installed in
the wrong direction. Had there been a thorough enough design review I
suppose someone would have asked the obvious: Why wasn't it designed
"keyed" so that it simply will not go in when reversed? I have always
asked this question when someone had a non-keyed connector in the
drawings, prompting a correction. This would have saved two lives and
maybe a third one. He is clinging on by a thread now and might not make
it or be severely disabled later.

Regards, Joerg

http://www.analogconsultants.com

Re: Learning embedded coding, which uC?

Quoted text here. Click to load it

There are engineering practices that help to make sure
errors will be caught early, and that applies to all
engineering fields.

With software you must distinguish between design documents made
before you start coding and documentation you make afterward
to *explain*.

But there are also tools that help prove that your specification
or your design is correct. You have to write them formally
and the tool checks for consistency and safety. This is used in
safety critical designs. Of course the device can be perfectly
safe but not doing what was required, that's another subject.

There is an analogy with the coding phase. If the language
has features that prevent bugs your code won't make harm
but this does not ensure it will be consistent with the
design.

Unless you have a CASE tools that checks the correctness of
the specification and writes the code automaticaly you have
to use *good engineering practices* to avoid mistakes as far
as possible. Such tools exist but they are limited to
specific applications such as control. AFAIK, there is
no universal tool for all kinds of software.


Site Timeline