EmbeddedRelated.com
Forums

Using C to program the 8051 family

Started by Aliasger January 1, 2004
In article <3ff87e0b_2@mk-nntp-1.news.uk.worldonline.com>, Ian Bell wrote:

>> The H8 "value series" is a bit cheaper: $3.99 for a 25MHz part w/ 128K
[...]
> > Hitachi do sell some amazingly low cost processors. They are > lacking however in certain areas of peripheral integration > e.g. LCD drivers.
As always: the right mix of peripherals is the key. I've never needed an LCD driver.
> 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.
Dunno, the Gnu tools work great for me. The linker didn't have a feature I wanted -- so I added it. Try that with IAR or Keil or Hi-Tech or whoever. ;) -- Grant Edwards grante Yow! YOW!! Now I at understand advanced visi.com MICROBIOLOGY and th' new TAX REFORM laws!!
On Sat, 03 Jan 2004 22:38:01 +0000, Ian Bell wrote:

> Albert Lee Mitchell wrote: > > None of these comments is 8051 or 8bit micro specific.
Agreed, sorry if I implied otherwise. -- Regards, Albert ---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts http://www.amresearch.com 916.780.7623 ----------------------------------------------------------------------
On Sun, 04 Jan 2004 09:48:26 +0000, Chris Hills wrote:
> Surely interpreted languages can not be used for debugging real time > code. An ICE is the only option.
Nope, Forth executes in real time. Better yet is that it executes on the actual hardware, not in an ICE.
> > 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?
Perhaps you aren't familiar with Forth for all dialects that I'm currently aware of give great detail and debuggability. Certainly greater than a compile-only language such as either Assembler or C.
> Many novices like BASIC because it is in interpreted... but you don't > find professionals using it (in the interpreted form) for embedded work.
Agreed, to a great extent. There are a lot of 'professionals' using the Parallax Basic Stamp for instance, just look at their success. It's incredibly cheap and quite functional for simple applications. I'm not a language zealot however, I will use the best tool for the job. I don't use Forth in systems administration or on web pages although it is possible. Basic has it's place but I don't care for it either.
> 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.....
Or perhaps I've made a well-kept secret public? The number of users says absolutely nothing about tool. -- Regards, Albert ---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts http://www.amresearch.com 916.780.7623 ----------------------------------------------------------------------
On Sat, 03 Jan 2004 21:14:57 +0100, Klaus Vestergaard Kragelund wrote:

> While I am not a embedded guy by far, but I have done my share of 8051 > projects. > > Could you elaborate on why you don't think C is appropriate for this
family? Yes. Many of my complaints of the C language has to do with library functions written by others which are generic by nature. I see two faults with this which override the advantages in my opinion. First is that the library routines are rarely reviewed by the programmer, just plugged in and assumed to be correct. This is one of the major problems in Windows and even Linux/BSD too. Others have mentioned 'safety-critical' applications, do those same people review every line of code in their included libraries? Secondly, few people turn off the optimizer when using C. Earlier C compilers didn't even give you this option. When I laboriously hack a chunk of time-critical code I don't want the compiler messing with it later after testing. Third, C is essentially impossible to debug without a In Circuit Emulator. Even when using an ICE you cannot guarantee that your circuit will behave identically when the ICE is replaced with silicon. ICE's have different fan-outs, different rise times, different responses than a production 8051 from your favorite vendor. Yes, and ICE is _nearly_ the same but I've seen problems creep in shortly after production release or after a change in silicon or new vendor months down the road due to circuit performace affecting the microcontroller. Granted that is rare but I don't like being surprised this way. Having done a number of biomedical applications, including one which still scares the hell out of me by taking a blood or cerebral-spinal fluid sample from teh patient, I demand a high degree of accountability from my designs. So much so that I admit to being paranoid about the subject. Clients who know what they are doing appreciate this paranoia. Another arguement is personal preference which doesn't really speak to "Why not C?" but to what I believe is a better tool. I won't go into that here unless requested. -- Regards, Albert ---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts http://www.amresearch.com 916.780.7623 ----------------------------------------------------------------------
cbarn24050@aol.com (CBarn24050) wrote in
news:20040102222847.26263.00002250@mb-m06.aol.com: 

> Well Mark when I got it it was supposed to be state of the art I imagine > in another 5 years you'll be saying the same thing about the current > Kiel package. For the sort of things I do I can't see me going back to > the 8051.
No, I wouldn't be saying that about the current Keil package because like modern PCs it's gotten good enough that further improvementts don't really matter much to me. The 2500 never had a good rep. as I seem to recall. -- - Mark -> --
<snip>. 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.
I agree, Hitachi is a very nice processor family and not comparable with 8051's. I have a scheduler which is not suitable for 8051 projects because it won't compile (only when I simplify some structures). If you use 'complex' structures or function pointers then the 8051 is not the best choice. But, for smaller projects it can be very nice programming (even in 'C') . regards gerard zagema www.stacktools.com
"Albert Lee Mitchell" <albmit@albert.amresearch.com> wrote in message
news:pan.2004.01.05.07.40.22.335398@albert.amresearch.com...
> On Sat, 03 Jan 2004 21:14:57 +0100, Klaus Vestergaard Kragelund wrote: > > > While I am not a embedded guy by far, but I have done my share of 8051 > > projects. > > > > Could you elaborate on why you don't think C is appropriate for this > family? > > Yes. Many of my complaints of the C language has to do with library > functions written by others which are generic by nature. I see two faults > with this which override the advantages in my opinion. First is that the > library routines are rarely reviewed by the programmer, just plugged in > and assumed to be correct. This is one of the major problems in Windows > and even Linux/BSD too. Others have mentioned 'safety-critical' > applications, do those same people review every line of code in their > included libraries? > > Secondly, few people turn off the optimizer when using C. Earlier C > compilers didn't even give you this option. When I laboriously hack a > chunk of time-critical code I don't want the compiler messing with it > later after testing. > > Third, C is essentially impossible to debug without a In Circuit > Emulator. Even when using an ICE you cannot guarantee that your circuit > will behave identically when the ICE is replaced with silicon. ICE's have > different fan-outs, different rise times, different responses than a > production 8051 from your favorite vendor. Yes, and ICE is _nearly_ the > same but I've seen problems creep in shortly after production release or > after a change in silicon or new vendor months down the road due to > circuit performace affecting the microcontroller. Granted that is rare > but I don't like being surprised this way. >
Hmm, I just using the JTAG runtime debugger, that IS the actual application and there is no difference in the fan-out etc As for the library functions, I have seldomly found errors in these. Somehow error all often "Error 40" (40cm from the keyboard) :-) Cheers Klaus
On Mon, 05 Jan 2004 22:24:38 +0100, Klaus Vestergaard Kragelund wrote:

> ---------snip----------- > Hmm, I just using the JTAG runtime debugger, that IS the actual application > and there is no difference in the fan-out etc
If a JTAG interface exists that's a valid alternative but how many 8051's have one other than Cygnal? Even if you have a JTAG interface though you can't easily put a subroutine or function into a loop for scoping.
> As for the library functions, I have seldomly found errors in these. Somehow > error all often "Error 40" (40cm from the keyboard) :-)
I think I clearly stated that library errors are rare but when they occur diagnosis is quite difficult. In glibc there have been exploits in the tree on occasion which were later used to cause havok. Another issue with library functions is that they are generic and sometimes wasteful in execution speed and/or memory useage where routines specifically written for the application will be more optimal. -- Regards, Albert ---------------------------------------------------------------------- AM Research, Inc. The Embedded Systems Experts http://www.amresearch.com 916.780.7623 ----------------------------------------------------------------------
> >>On Sat, 03 Jan 2004 21:14:57 +0100, Klaus Vestergaard Kragelund wrote: >> > >> >>Third, C is essentially impossible to debug without a In Circuit >>Emulator.
I wonder what I've been doing all these years. Not debugging, clearly, so the programs I write must be self- correcting. Paul Burke
"Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message
news:3ff80f38$0$9773$edfadb0f@dread14.news.tele.dk...
> "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? >
Cbarn24050 - where's your part numbers, spec and price? \..Klaus