8 bit microcontroller market
in [Embedded]
|
Prev: Tiny Bootloader
Next: Link&Locate 86?
From: David Brown on 8 Sep 2006 03:12 David Ashley wrote: > Dave wrote: >> The C code is a recent addition and is used only for CAN communications. >> Of the C compilers I have looked at for 68K use (Diab, Metrowerks), none >> could generate 68K code to compete with the M-GM compiler. > > Are you saying the Motorola 68000 is still being used in stuff these > days? I wrote tons of 68000 code for the Amiga. Are there surface > mount 68000's? Can you embed the core in with useful peripherals? > The 68000 itself, and the other processors in the original 68k family, are not much used now. However, there are plenty of microcontrollers based directly on the 68020 core which are still very popular - the 68332 has been a common choice in the automotive industry for the last 15 years or so. A number of years ago, Motorola (as it was then) took the m68k ISA, simplified it a little, and did a completely new implementation of the ISA using more modern techniques. The result is a core that is as easy to program and as powerful as the 68k (being nearly identical from the programmers viewpoint), yet as compact, low-power and high speed as a good RISC core like the ARM. These ColdFire cores come in a wide range from smaller and cheaper devices to large and fast devices, with all sorts of different peripherals (actually, the majority of ColdFire cores are apparently built into ASICs - presumably the automotive industry). Have a look at http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=0162468rH3YTLC > gcc supports 68000. > The 68000 was the original target for the first version of gcc, and it is still a major target. Codesourcery are actively improving the ColdFire backend, and provide ready-to-use packages: http://www.codesourcery.com/gnu_toolchains/coldfire/ > -Dave >
From: Tom Lucas on 8 Sep 2006 04:22 "Didi" <dp(a)tgi-sci.com> wrote in message news:1157661225.971419.260410(a)d34g2000cwd.googlegroups.com... > Tom, > >> I presume this monitors the exhaust emissions? > > no-no, this is not automotive. It is a full-blown analytical gamma > spectrometry > system, using mostly HPGe (that is high-purity_Germanium) detectors > etc. > Feel free to contact me directly if you need some related info, > I'll be glad to help - right now I don't even know what you want > to be measuring :-). E-mail on its way.
From: Didi on 8 Sep 2006 05:29 > Due to the lack of quotes and top-posting it is impossible to tell > what your problem is. Due to partial quoting and bottom posting it may not be clear which issue in my message you refer to :-) :-) . > I might be able to help; I spent something > like 30 years in and around the nucleonics industry. I did not ask for help, I just offered some :-). I have been doing much of what has been happening in nuclear spectrometry innovation over the last 15 years and may keep on doing it for another while. However, everyone can use some help at some stage, thanks for offering yours. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ CBFalconer wrote: > Didi wrote: > > > ... snip ... > > > > no-no, this is not automotive. It is a full-blown analytical > > gamma spectrometry system, using mostly HPGe (that is > > high-purity_Germanium) detectors etc. > > Feel free to contact me directly if you need some related info, > > I'll be glad to help - right now I don't even know what you want > > to be measuring :-). > > Due to the lack of quotes and top-posting it is impossible to tell > what your problem is. I might be able to help; I spent something > like 30 years in and around the nucleonics industry. > > -- > Chuck F (cbfalconer at maineline dot net) > Available for consulting/temporary embedded and systems. > <http://cbfalconer.home.att.net>
From: Walter Banks on 8 Sep 2006 09:24 We wrote the C compiler for thread based engine controller that was used to program most of the current automotive engines (eTPU). Most of the engine controller implementations that I have seen do not have a single line of asm. The compiler can however generate every individual machine code from C if desired. (It is one of our tests) I agree with the basic point about the time critical nature of engine control software. w.. Joerg wrote: > Yep. He who thinks assembler is all stone age has probably never > programmed an engine control or something like that. There might only be > milliseconds between loss of loop lock and a destructive detonation, > pieces raining out of the sky and all that.
From: Walter Banks on 8 Sep 2006 09:45
The TPU's were essentially all programmed in a assembler. The eTPU's have essentially all been programmed in C. The eTPU has 29 instructions some with as many as 14 fields is well suited for machine generated code and difficult to effectively hand optimize. The hand optimizing issue is multiple simultaneous control and data sequences with selection from many alternatives combined with a very large number of illegal instruction combinations. The instruction selection in the compiler uses a nasty bit constraint code to organize and schedule execution. (Called Tetris for those who are familiar with TPU and eTPU architectures) This was a fun project w.. Jim Granville wrote: > Do you use the TPUs, and if so, how are they coded ? |