Replacing a few words in your statement, we have: "doing hi-level programming in a non-hi-level language demands ..." This applies to using assembly, and equally to using C.
The better programmers in both languages impose exactly that sort of discipline on themselves, and get very irritated at languages that do not allow them to ignore those disciplines when needed. Unfortunately many such programmers have a poor perception of 'when needed' and thus leave many incipient bugs and insecurities.
The C programmers attitude to Pascal, and the inverse, are examples. The languages are highly similar, with very similar end capabilities. Escape hatches in Pascal need to be carefully thought out to preserve reliability. External routines, file drivers, etc. come to mind. A system which allows controlled intermixing is Ada.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
Yes it is controversial. Whether you accept it or not, the OO approach is the current vogue. Graduating Software Engineers are conversant with OOA & OOD. A common language, UML, has been developed so that analysis & design can be better expressed. There are a plethora of OO tools available now.
Also why is software developed for embedded system any different in quality requirements from that of other fields? It isn't. The same process that is adopted in the OO methodology is applicable for embedded development. The name of the game is to produce "quality" software. OO in itself doesn't guarantee this, but it's the associated process & approach (in using modelling) that empowers the Software Engineer with the ability to achieve this goal.
Don't quite understand this comment.
I disagree. Sure for embedded systems there is an association between the hardware & software, but like any software system the hardware can be mapped to drivers. I can imagine that one can write software for an embedded system where hardware access is spaghetti-ed throughout the code. If you do, then one is not writing their software in a fashion that would make it easily testable. Sure one has In-Circuit Emulators & alike, but I regard them as belated options in testing.
Where I work, we write the software such that it can be readily ported to other platforms which may employ different micros and/or different hardware and/or different operating systems. To remotely achieve this, one has to delineate the hardware from the software application. Also I'm not talking about monster applications but embedded systems based on micros like Hitachi's SH-1, Tiny H8 & Motorola's 6805.
In a current project with the Tiny H8, we are achieving about 98% structural (branches & conditional) unit test coverage of the Software Application, with a test harness that runs in a console window on a PC and about 95% structural unit test coverage of drivers that run on the target system. That's the current status, but our goal is to achieve
100% coverage -- which we expect to do. The integrated system does fit & run on a Tiny H8, but unfortunately, there isn't enough ROM space to accomodate a full test harness on the target system & so it has to be broken up.
Ken.
+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com
I have been wrong before, but I believe that Ada modules (or am I thinking of Java, or both?) have to specify all exceptions that they may generate. Thus code linking to such modules knows what it must cater for.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
As a C++ developer for embedded systems with some twenty years of toil behind me, I have nothing but respect for Forth developers. I envy the fact that they can develop interactively and be running code on new hardware in minutes. We have many more obstilces in our way (compiler, linker, debug target, download agent, debug client; all of these have to work before anything works). We work far from the hardware; forth developers are in contact with it.
This is the crux of the matter and the key word is gainfully. My view is that the OO metaphor/paradigm (PYO buzzword) does not of itself provide any gains in the development of embedded systems. It is not proven that it is better in this context than other design methodology.
I agree with everything you say. However you appear to make the erroneous assumption that OO is the only and best methodology available. it is neither in my view.
I agree. But a hardware driver is not an OO concept.
I agree, but again OO is neither necessary nor desirable to achieve this.
Tee hee. But if it was true, I would have been out of business long ago. Modern Forth compilers produce good code, and where code density matters, Forth still produces applications that are often half the size of C applications. And yes, I do have numbers to back this up for a payment terminal (8051) and an embedded web server (68xxx, H8S and ARM).
Very true. I would also add that with the exception of web weenies, very few junior programmers have used any languages other than C/C++ and perhaps Java. This in distinct comparison from 15 years ago, when most programmers in any field had actually used a much wider range of languages and had the experience to be able to select an appropriate language for a job. If you have never used interactive languages, you will never be able to appreciate what they have to offer. Remember Smalltalk, Eiffel, BASIC ... Any community misses out if its focus is on a range of culturally similar languages, programming or spoken.
Apart from OO (the current silver bullet), there is little to separate any of the batch compiled languages such as C, C++, Pascal and so on. At least Modula 2 dealt with the dependency issues.
It is August and the silly season is upon us :-)
Stephen
-- Stephen Pelc, snipped-for-privacy@mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web:
Yes, it is correct. Unfortunately the entire CodeProject web-site seems to have gone breast-up. Do try later; it's an interesting article: "A Look At What's Wrong With Objects "
only c99, and since I haven't yet come across a c99 compiler (for embedded systems or otherwise) that generates native object code (comeau(sp?) generates c89 code which you must then compile with a c89 compiler), I tend to stick to using /* these comments */ just in case some c89 compiler out there cant be persuaded to accept // comments at the drop of a compiler switch.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.