Very interesting -- I hadn't seen that before. I haven't worked with an 8051 for 15+ years, and I don't think I'll be getting a chance to try it out in the immediate future.
Ah. I've wondered in the past how hard it would be to get gcc's Ada support working on an embedded target.
I don't really see anything that looks suitable for civilian embedded systems work. No listed targets for anything I'm using (ARM, MSP430, H8/300).
--
Grant Edwards grante Yow! This PORCUPINE knows
at his ZIPCODE... And he has
visi.com "VISA"!!
I think this is more an argument for using gcc instead of commercial tools!"
But different versions of gcc do not work the same as other versions, and for example inserting inline assembly might not produce exactly what you want in gcc 3.x in contrast to gcc 2.x. I am not sure about the status of inline assembly code in gcc 4.x.
I found it a rather disappointing web site. No downloads - not even of documentation - and no idea of costs.
Mod51 seems to be the perfect high level language for the 8051. I have googled extensively but I cannot find ant other information on it.
Ian
If they vary, then they are not really rules are they! :)
This is true to some extent - but it will likely be the case for any language (that does not run on a virtual machine). In C there *are* rules you can follow to minimise this.
If your solution is assembler, then I think you will have more problems running AVR assembler on an ARM, then running correctly written C on either.
-- John Devereux
(fixed attributions, hopefully)
If you are doing maintenance on an old project, it is essential
*anyway* to use the original version of the tools. And you can do this very easily with gcc. It is *commercial* tools that force you to upgrade because the old dongle no longer works with any of your machines!-- John Devereux
Which brings us right back on-point! Nice.
Jon
Oh, yes they are. US law and UK law are not the same but they are both a set of rules for the same thing.
On small 8 bit projects my solution is, as you suggest, assembler.
The real problem is for bigger projects (presumably on bigger processors). The trouble is that C is such a poor language that errors are inevitable. C is the standard language I know and it has tremendous inertia but it is most certainly not the right language for embedded systems.
Which of course begs the question what is the best language. That's a tough one. Pascal is better (less error prone) than C but beyond that I don't know. Modula-2 might be a good candidate.
Ian
>
There are a set of "rules" which, if followed, will let your programs work consistently in different environments, independent of compiler and CPU. A few months lurking in comp.lang.c will clarify this. It is true that these are not always obvious. And for an embedded system there will always be parts of the system where the "rules" must be broken. The trick is to minimise and isolate these so that you can move to a new system, or reuse code libraries, with the minimum effort and maximum safety.
I would never claim that C is perfect, but like you it is the standard language, that I now know reasonably well.
Well, there's always C++!
-- John Devereux
Not for real-time, embedded systems, there aren't.
The "rules" of which you speak place no limits on the time or memory resources required to execute the program. In embedded systems, there are time and resource requirements that are just as important as any other. A program that is "correct" according to the rules of C but won't fit in ROM or RAM is just about as useful as a bucket of random bits.
No it won't.
More often, there are ways where the rules must be followed differently on different targets. There are often cases where either of two datatypes or code-fragments will produce "correct" results according the standards. Depending on the compiler and CPU, one might be unusable in one instance, and the other choice might be unusable in another instance because of time/resource limitations.
But, merely writing code that's "correct and portable" according to the C standards isn't sufficient.
--
Grant Edwards grante Yow! I'm having fun
at HITCHHIKING to CINCINNATI
visi.com or FAR ROCKAWAY!!
True, there are additional considerations.
Well, of course the execution speed and code size will be different for different machines. It is true that this is another "dimension" to the problem. And if your application is critical in these areas, then some of your code may have to change. But this is true for any language, surely.
Agreed, but I have found it to be a helpful starting point, for major parts of the systems I have written.
-- John Devereux
It is, and for PLC programming, under the IEC(6)1131 standard, you will find their Structured Text langauge is close to Modula-2, with some Ada extentions. Mod51 adds some of the IEC1131 extensions, where they are 'safe supersets'. ie = 2#11_11_0101; is valid for binary, the underscores are allowed for clarity. 6#5432 is also legal, and yes, we have actually used base 6 numbers in a product: it was a security add on, that borrowed 6 keys from the front panel.
Seems I should give an update on Mod51 status : It is now a maintenance product, but still in quite widespread use, and is still used for new product design. It is supported in Debuggers, like the SiLabs IDE.
We have looked at a Win32 port, of the Borland Pascal sources, but could not get the compiler to what I considered releasable stabilty, in Win32. Tried Delphi, FreePascal, TMT Pascal and the most reliable was TMT Pascal. [ Strange that what was rock-solid as 16 bit code, becomes fragile as Win32... ]. The realities of time pressures, meant this was shelved. There are Win32 editors [CRedit, Context] that have Mod51 highlighters.
There are also other Pascal/Modula-2 style langauges for the C51, because the Wirth languages are such a good fit on the C51. Years ago, we seriously looked at an AVR version, but the compromises made in the AVR core meant the code was less efficent, and all the libraries and linker, would also have needed rewriting.
-jg
CS courses tend to include 'writing a compiler' for several reasons:
(1) Back when most older lecturers were studying, you could get a PhD for writing a compiler back end. Or doing a front-end in a quicker way. (2) there exist lots of cheap textbooks that mean the lecturers don't need to drum up any good teaching material ("it's in the Dragon Book") (3) You can very easily make an artificial "team project" out of a compiler - split up lexer, parser, symbol table, codegen, peephole optimiser etc. into small enough chunks... (4) Sheer bloody inertia. It takes more effort to change a syllabus than to keep going with a useless course, and there's a whole pile of past-papers and old questions that can be regurtigated every few years, mutatis mutandis. (5) (and perhaps more positively) you can use a compiler construction course as a moderately-sized exercise pulling together various topics from algorithms, data structures, program design etc. without making the poor little dears deal with "reality" - you know, they can still debug by printf and declare arrays of size 100000.
I took my first compiler course nearly 20 years ago. I think it's fair to say that I've never actually used anything taught on it, given that it spent a whole term telling you how to do less than I'd already figured out how to do with lex and yacc. (Some small bits of it were useful in a Formal Language Theory option I took later, but I've never used *that* explicitly). It was a soft course - the exam was virtually the same every year, learn how to parrot the implementation of a recursive-descent parser, a symbol table with nested scopes, and the differences between LALR and LL(1) and you were sorted. The "advanced" course was an option which got as far as (gasp!) code-generation for CISCs.
Even in the late 80s I could see that in future all but the highest-performance compilers were going to be lashed together from lex and yacc at the front end and some form of RTL at the back (gcc, essentially ;)) -- no point taking a course that was going to be of such minimal utility.
I would argue that these days, there is some scope for teaching either "generating efficient code for pipelined or VLIW processors" as an advanced option for students focussing on high-performance computer architecture, or "generating space-efficient code for tiny micros" as part of an advanced embedded-systems course, but I agree that "compiler construction" for procedural languages on most CISC architectures is grave-robbing.
I'd be more impressed by a course that taught virtual machines, interpreters (inc. FORTH), data-driven programming, on-the-fly code generation, and other *useful* things. I still maintain that the most useful programming book I ever encountered - even though it's got very little to do with embedded - is Abelson, Sussmann and Sussmann's "Structure and Interpretation Of Computer Programs", because it makes you *think* about what you're trying to build and represent.
pete
-- pete@fenelon.com [Support no2id.net: working to destroy Blair's ID card fraud]
... snip ...
I hope you aren't trying to even approach seriousness with that. I agree on the Modula, largely because it allows you to isolate the system dependant stuff quite easily. At the same time I have had good experience with Pascal in the past, sticking closely to ISO standards with a very few carefully selected extensions, all lumped under "standard procedures". The PascalP manual details these extensions.
-- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: Also see
I'm afraid you missed the point. The beauty of a toolchain like GCC is that you have sourcecode of the tools themselves, so the tools will run literally *anywhere*. Which means you don't have to conserve the environment the tools ran on, i.e. no more ancient PCs kept working at all costs, just because tool XYZ simply won't run on anything else.
If you get a new desktop machine, which you can make look sufficiently like Unix (and even plain MS-DOS eventually managed that trick!), you just build all your old cross-GCCs from sources and that's that. If the new box can't be Unix-ified, you'll find out why GCC and binutils have *three* platform names controlling the build process. ;->
-- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
I'm from 1972. The Pet was my Dad's, on loan from his office (university maths department).
"On 2006-02-13, Colin Paul Gloster wrote: [..]
I don't really see anything that looks suitable for civilian embedded systems work. No listed targets for anything I'm using (ARM, MSP430, H8/300)."
Well maybe not for your civilian targets, but MIPS and Motorola/Freescale
68000 processors are predominantly used by civilians.Though military versions of various Texas Instruments DSPs may be referred to in
Is the source available?
What about a Linux port?
I have done lots of googling but not come across any C51 specific ones. Can you give some pointers?
Ian
Not presently; there are still commercial derivatives.
No
Some of these are not specifically C51, but ones I know of are ( in order of decreasing C51 focus )
-jg
My "advanced" writing training/education was from another engineer after graduation. The primary technique was "keep doing it until you get it right". Amazingly, at the time, we were doing numerous reports regarding an AA missile system and it was quite some time before someone bothered to tell me that it's "ordnance" and "missile", not "ordinance" and "missle"!
At one point in history, I worked for FMC Northern Ordnance Division (on AAW and ASW missile launchers even).
You only misspelled "ordnance" in an official document once.
--
Grant Edwards grante Yow! Isn't this my STOP?!
at
visi.com
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.