In article , Dan writes
You are for 8 bit processors
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
In article , Dan writes
The vast majority of embedded systems are 8 bit. There are no C++ compilers for 8 bit systems (not commercial quality anyway)
It is VERY useful to know assembly for any embedded target you work on.
The last stats I saw said C, ASM and C++ in that order for embedded systems. Of course it gets hazy when you look at PC104 and PDA's etc
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
So what about the IAR EC++ for the AVR?
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
It's pretty good. I've been writing my own Forth cross compiler for it. While pbForth is a good way to learn Forth, it won't necessarily teach much about embedded systems on its own.
There's also legOS lets you program directly with a GCC cross compiler, has multiple tasks, semaphores, lets you add your own interrupt handlers, and so forth. So it gives more direct exposure to embedded systems concepts.
--
Darin Johnson
Gravity is a harsh mistress -- The Tick
OK, so I think I want to build my own mp3 player. Is this too big of a task for entering into embedded systems? Which processors/development systems mentioned here would fit my low budget, ease of use criteria?
I'm thinking PIC since I recently came across this:
processors vendors are : PIC Hitachi Freescale Olimex
If I am wrong about these, let me know.
No an MP3 Player is an embedded project. I do not know if it is good for a beginner.
for low end CPUs PIC Atmel AVR Hitachi Freescale
8052 (many companies) Olimex ?? not a chip maker, protoboards TI MPS430 (16bits ) Cypress PSoC Zilog
CodeWarrior for the Freescale HC(S)08 has this claim:
Gary Schnabl
Depends on your 8-bit processor. GCC supports C++ for AVR. I don't use it myself, but others do, and it is supported and available.
Ciebo used to have a C++ for 8051. Never heard anything good about it.
Leaving C++, there is a Modula-2 for 8051.
Hmmm. Is PLM still around?
Regards,
-=Dave
-- Change is inevitable, progress is not.
In article , Dave Hansen writes
Which I think proves my point. GCC for one processor and Ceibo for another. The code density of the GCC makes it not very useful compared to the commercial C compilers for the AVR.
!!!!!! ?Where did this come from? Mod2 is a procedural language like C but a lot less well supported. It is effectively as dead as Pascal. There is more Forth about than Mod2 and Pascal.
Yes but not supported at all AFAIK. Though I do have one of the last versions of the Intel PLM compiler for 51 and x86. It is used for maintenance of some VERY old MoD projects.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
And one of the more popular AVR compilers is the IAR, which has C++ support...
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This message is intended to be my own personal view and it may or may not be shared by my employer Atmel Nordic AB
FWIW, avr-gcc code generation compares favorably with the commercial compiler I have for that platform (avr-gcc code varies between slightly larger to much smaller). IAR probably beats it, but the version of IAR I have is old enough that it doesn't support the processors I'm using.
New Zealand. ;-)
It was generating much better code (at least for a pathological checksum I posted a few years back) than Keil C51 v5.5.
A few years back, GM required the use of Modula-GM for safety-critical software, such as that in antilock braking systems. They may still, I'm not sure. Modula's advantages over C are widely (if not universally) recognized.
Which means "no." I last used PLM-80 on an avionics project back in
1983/84. I recently read that Boeing built the last of that aircraft the end of last year.Regards,
-=Dave
-- Change is inevitable, progress is not.
Hmmmm!, I could certainly get by without an assembler product when I find it necessary to include some machine code in an embedded application. My first project was 4k of hand compiled machine code (look up op-codes and structure of instruction in the databook and enter the code on switches - but that was a long time ago). So, the essential ingredient is, in my view, a knowledge and appreciation of the processor hardware to the extend that you can get intimate with it at the machine code level from the databooks/instruction reference card. I have often included little snippets of machine code into my Forth based firmware (often need something like 30 to 40 instructions doing this way to speed things up a bit).
I wouldn't be so sure on that score.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/********************************************************************
Also, the Ada gcc front end has been ported to the AVR. (However, since I don't use AVRs, I don't know how good the port is.)
Simon.
-- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: The Standard Oil Company of the 21st century
In article , Dave Hansen writes
I think most automotive things have moved to C now.
Actually "yes." Boeing is not the only user. There are several aerospace systems in service that still use it. There was recently some modifications done to one of the systems. Also some security systems in current use. The last Intel PLM compiler I have is dated 1986.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
Not really. Someone has to write all the code that appears between a system reset and the call to main(). Someone has to write all the stuff that inside the system libraries (and the C library).
--
Darin Johnson
Gravity is a harsh mistress -- The Tick
I certainly hope not. That in itself would show gross disregard for safety, and could be the grounds for all sorts of lawsuits and punitive awards. Ada would be more reasonable.
-- "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
Considering that there are quite well known projects, that used Ada, that still failed (some in quite spectacular fashion) I would have thought would have constituted sufficient evidence that the proogramming language used has little to do with the final system safety.
There are constructs in every language that, if used, are probably potentially lethal in a system. What seems to be evident, though, is that using an inadequately rigourously applied development process leads to important facets of the system being missed. Such development processes should include plenty of reviews, unit, integration and system level testing and reviews of the results obtained.
I am not sure of the current distribution of languages in automotive projects at present but I am sure that you will find quite a wide range, including assemblers are still in there.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 Tel: +44 (0)1235-811095 Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/********************************************************************
C or assembly coding with a good coding standard and thorough code reviews will catch much more problems than an Ada compiler alone.
This can be quite critical especially if the Ada users are overconfident due to "it compiles, it is ready for shipping" attitude.
Paul
Just put the address of the init routine (written in some high level language) into the reset vector of the processor. The requirement is only that the high level language can access the processor registers e.g. as pseudo variables, as many compiler extensions have done for decades. On critical requirement is that the compiler only use internal processor registers before the stack pointer and other critical globally used registers have been set up.
After the stack pointer(s) have been set up in the high level code, other registers as well as hardware registers can been set and interrupt vectors can be written all in the high level language.
Many high level compilers already have various "interrupt" keywords to generate a register save/restore preamble, before an interrupt service routine is started.
For the startup code, it would be quite trivial to add some kind of "init" keyword to force the compiler to generate code, which uses only the internal register and not referencing any external memory, except through the program counter. In this way, the initialisation code for any environment (e.g. location of RAM and ROM) could be written in a high level language for each system separately.
On minicomputers, run time libraries were written in assembler for a quarter of a century ago. But with 32 bit super minis the situation changed. For instance, much of the VAX run time library was written in BLISS, which, IMHO did not generate a very effective code, not at least compared to current compilers. Assembler was used mostly in kernel mode code, especially accessing hardware registers, some of which were processor type specific.
For current small and medium sized embedded systems with a more or less sensible processor architectures, there are only a few cases, in which larger routines really needs to be coded in assembly for acceptable performance. Such routines are typically any extended precision arithmetics, involving frequent use of the Carry bit, which is typically not supported in any high level language. Access to machine specific instructions can be handled with in-line assembly (which can be disguised as functions) etc.
Thus, these days there is not much need to be able to write large assembly programs (except for 4 bitters and processors with awkward architecture), however, assembly reading skill is still very important, e.g. in the "init" example in the beginning of this message.
Paul
Yes, these include the assignment statement in most high level languages, various "move", store" and "out" in various assembly languages. With a detonator connected to a PC port can be quite lethal, if an out instruction is executed on that port address. Thus, all such instructions and constructs should be banned from all environments :-) :-).
Paul
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.