EmbeddedRelated.com
Forums

Using C to program the 8051 family

Started by Aliasger January 1, 2004
"CBarn24050" <cbarn24050@aol.com> wrote in message
news:20040103182145.19924.00001557@mb-m01.aol.com...
> Hi Klaus, you could pay less money on say Hitachi H8 or Fujutsu 16lx > processors, still write in C and have your program run an order of
magnitude
> quicker, maybe several orders quicker if you want to do fp calculus.
Ok - just did a search on the H8. Seems like prices in order of 6-7 $ for a 5MIPS one (sloooooooooooooooooooow) I using Cygnal (www.cygnal.com) these days: 25MIPS 80C51Fxx with onchip mixed signal design, ADCs, comparators and so on. Cost about from 1$ up ;-) 100MIPS types are there too - but haven't had the need yet.... Cheers Klaus
Come Klaus, part numbers please.
"CBarn24050" <cbarn24050@aol.com> wrote in message
news:20040103185549.19854.00001557@mb-m01.aol.com...
> Come Klaus, part numbers please.
80C51F304, 25MIPS, 11pin MLP package (about the outline of a SOT-23 BJT), 3$/100pcs at digikey (expensive retailer) Barn - partnumbers, prices, specs? Cheers Klaus
In article <pan.2004.01.03.19.56.02.831606@albert.amresearch.com>,
Albert Lee Mitchell <albmit@albert.amresearch.com> writes
>On Fri, 02 Jan 2004 02:19:03 +0000, Steve at fivetrees wrote: > >> "CBarn24050" <cbarn24050@aol.com> wrote in message >> news:20040101200157.15398.00002261@mb-m04.aol.com... >>> Hi, I would think again, switching to another language won't make your >> problems >>> dissapear you just get some new ones. If C is the right chioce for your >> project >>> then the 8051 is allmost certainly not the right processor. >> >> I disagree. >> >> Taking the second point first: C is absolutely fine for an 8051. Ideal, >> even. > > I couldn't disagree more. C may be fine for larger platforms but it's >not just a pain in the Bush for an 8051 but can actually be dangerous if >you forget to turn the optimizer off.
This is incorrect... well it is according to the people I work with who do safety critical work with 8051's and C.
> Additionally C is a compiled language which leaves the programmer open >to >a number of dangers. You must either trust the compiler or learn to use a >disassembler, have the deductive powers of Mycroft Holms or use an ICE, >and beat yourself with a rubber hose instead of using an interpreted >language to debug by.
Surely interpreted languages can not be used for debugging real time code. An ICE is the only option. In fact I note that in 61508 forth is not even mentioned. ALL the languages suggested are complied languages. With an interpreted language like Forth you have no hope of debugging and testing to most high-integrity standards because you can't see what the interpreter is doing. You don't get the source. Also it is impossible to debug in hard real time. Can you ICE an interpreted language? Many novices like BASIC because it is in interpreted... but you don't find professionals using it (in the interpreted form) for embedded work. I note that many experienced embedded engineers have questioned your points no one has agreed with you. So either you are the only professional on this NG or..... /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Hi Klaus, are you telling me that you use this part to do your fp calculus?
"CBarn24050" <cbarn24050@aol.com> wrote in message
news:20040104050527.01665.00002233@mb-m18.aol.com...
> Hi Klaus, are you telling me that you use this part to do your fp
calculus? No, but this is the one I'm using on my current project Fp calculus, in the old days I used the 80C535 from Siemens and now I use Cygnal 80C51F023, 13$/100pcs: 25MIPS, 64kFlash, 4.3kRAM, 10bit 100kSa ADC, 12bit 1MSa DAC, 32 IO, 5x 16bit timers....... So, _your_ numbers? Cheers Klaus
In article <3ff754fa$0$9801$edfadb0f@dread14.news.tele.dk>, Klaus Vestergaard Kragelund wrote:
> > Ok - just did a search on the H8. Seems like prices in order of 6-7 $ for a > 5MIPS one (sloooooooooooooooooooow)
The H8 "value series" is a bit cheaper: $3.99 for a 25MHz part w/ 128K flash and 4K RAM (8 32-bit registers that can be used as 16 8 or 16 16-bit register, 32-bit ALU, 8 adn 16-bit addressing modes, A/D, D/A, 2xUARTs, 16MB address space, etc. Free toolchain (Gnu) free OSes (eCos, uCLinux, etc.), nice regular instruction set, free IDE framework from Hitache that uses Gnu, IAR or other toolchain. Very nice part to work with. -- Grant Edwards grante Yow! WHOA!! I'm having at a RELIGIOUS EXPERIENCE visi.com right NOW!!
On Sun, 4 Jan 2004 09:48:26 +0000, Chris Hills <chris@phaedsys.org>
wrote:

>Surely interpreted languages can not be used for debugging real time >code. An ICE is the only option.
I'm gobsmacked! I've been writing code in many languages for 30+ years in several domains including deep embedded. I have learned over time that debugging methodology is far more important than anything else. Debugging is a simple application of scientific method. begin begin Observation Hypothesis Experiment with yes/no answer until (this bug is fixed) until (number of bugs=0) Of course, I admit to the failure case when there are no observed bugs to begin with. The point is that your debugging tools are only an aid. The basis of testing for reliability is bottom-up testing. There's no point in testing higher level functions until the lower levels are themselves tested. It is vastly easier and very much faster to perform bottom-up testing using an interactive language than with a C debugger and an ICE.
>With an interpreted language like Forth you have no hope of debugging >and testing to most high-integrity standards because you can't see what >the interpreter is doing. You don't get the source. Also it is >impossible to debug in hard real time. Can you ICE an interpreted >language?
When you say interpreted, what do you mean? Forth is always interactive (you can talk to the hardware through a text interpreter). Some Forths are implemented as Threaded Interpretive Languages (TILs) and some generative optimised native code as good as that produced by any C compiler. Nearly all Forths provide all the target source code. Most of the jobs I do in Forth are hard real time. Bomb disposal and anaesthetic ventilators are also safety critical. An ICE is a wonderful tool every so often, but it's just one of the tools available. Of course you can ICE an interactive language. Of course you can ICE a TIL. Whether an ICE is an appropriate tool for either is another matter.
>I note that many experienced embedded engineers have questioned your >points no one has agreed with you. So either you are the only >professional on this NG or.....
Apart from myself, Paul Bennett and Elizabeth Rather are regular Forth users and posters to this newsgroup. I've met Albert and the others face to face. I regard them all as professionals. Stephen -- Stephen Pelc, stephenXXX@INVALID.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: http://www.mpeltd.demon.co.uk - free VFX Forth downloads
Chris Hills wrote:

> Surely interpreted languages can not be used for debugging real time > code. An ICE is the only option.
That depends on the timing requirements of the application. I have, on occasion, written realtime applications in interpreted Basic where speed was not an issue.
> With an interpreted language like Forth you have no hope of debugging > and testing to most high-integrity standards because you can't see what > the interpreter is doing. You don't get the source. Also it is > impossible to debug in hard real time.
I haven't used Forth, but my recollection is that Paul Bennett, the hard-core Forth programmer in this group, uses Forth for critical applications BECAUSE the whole system can be verified. My understanding (IANAFP) is that you normally work with source of the entire system. In C, many implementations do not distribute the source for the entire library, let alone the compiler and linker, which are all critical components. As far as debugging in hard realtime, I end up doing a lot of it with a scope/logic analyzer. I do agree that C is a good language for critical realtime applications, assuming you are careful and know the implementation well. Thad
Grant Edwards wrote:

> In article <3ff754fa$0$9801$edfadb0f@dread14.news.tele.dk>, Klaus > Vestergaard Kragelund wrote: >> >> Ok - just did a search on the H8. Seems like prices in order of 6-7 $ for >> a 5MIPS one (sloooooooooooooooooooow) > > The H8 "value series" is a bit cheaper: $3.99 for a 25MHz part w/ 128K > flash and 4K RAM (8 32-bit registers that can be used as 16 8 or 16 16-bit > register, 32-bit ALU, 8 adn 16-bit addressing modes, A/D, D/A, 2xUARTs, > 16MB address space, etc. Free toolchain (Gnu) free OSes (eCos, uCLinux, > etc.), nice regular instruction set, free IDE framework from Hitache that > uses Gnu, > IAR or other toolchain. Very nice part to work with. >
Hitachi do sell some amazingly low cost processors. They are lacking however in certain areas of peripheral integration e.g. LCD drivers. Also, I hope IAR have cleaned up their act a lot because last time I used their C compiler on an H8 it was riddled with bugs and inefficiencies. Ian