Hi, I have yet to see a project written in C where the 8051 was the best choice
on either performance or price. C is to the 8051 what windows is to a pentium.
Of course is your poduct doesn't need much performance then allmost anything
would do.

c...@aol.com (CBarn24050) wrote in
news:2...@mb-m29.aol.com: 

> Hi, I have yet to see a project written in C where the 8051 was the best
> choice on either performance or price. C is to the 8051 what windows is
> to a pentium. Of course is your poduct doesn't need much performance
> then allmost anything would do.

I have yet to see one that wasn't. What kind of statement is that you are
making? The 8051 is dog-simple to program, supplied by an unbelievable
array of companies, has *excellent* C compilers available, wonderful
peripheral choices, the core can be placed into an FPGA for SoC designs,
Cygnal has JTAG debuggable version that run 12x the clock efficiency of
the original 8051, you can use off-chip CODE and XDATA space if needed,
fast interrupt context switching using register banks, etc. etc. 

-- 
- Mark ->
--

> on either performance or price. C is to the 8051 what windows is to a pentium.

I guess you belong to the "Real Programmers use COPY CON PROGRAM.EXE"
school of programming?

The choice between C and assembly isn't anything like as simple as you
make out, and "performance" is measured in different ways. For almost
any nontrivial piece of code where you're not actually down to the
cycle-counting level of time criticality, the [potential] portability
and [potential] productivity gains of using C are a strong argument
against assembler - even in 8-bit platforms.

Mark A. Odell wrote:

> c...@aol.com (CBarn24050) wrote in
> news:2...@mb-m29.aol.com:
> 
>> Hi, I have yet to see a project written in C where the 8051 was the best
>> choice on either performance or price. C is to the 8051 what windows is
>> to a pentium. Of course is your poduct doesn't need much performance
>> then allmost anything would do.
> 
> I have yet to see one that wasn't. What kind of statement is that you are
> making? The 8051 is dog-simple to program, supplied by an unbelievable
> array of companies, has *excellent* C compilers available, wonderful
> peripheral choices, the core can be placed into an FPGA for SoC designs,
> Cygnal has JTAG debuggable version that run 12x the clock efficiency of
> the original 8051, you can use off-chip CODE and XDATA space if needed,
> fast interrupt context switching using register banks, etc. etc.
> 

He is beginning to sound like a troll to me.

Ian

"CBarn24050" <c...@aol.com> pontificated in message
news:2...@mb-m29.aol.com...
> Hi, I have yet to see a project written in C where the 8051 was the best
choice
> on either performance or price. C is to the 8051 what windows is to a
pentium.
> Of course is your poduct doesn't need much performance then allmost
anything
> would do.

It seems to me you have never developed any projects using the 8051 and C
language, or just aren't very good at it.

On Fri, 02 Jan 2004 12:42:06 -0500, Mark wrote:

> 
> "CBarn24050" <c...@aol.com> pontificated in message
> news:2...@mb-m29.aol.com...
>> Hi, I have yet to see a project written in C where the 8051 was the best
> choice
>> on either performance or price. C is to the 8051 what windows is to a
> pentium.
>> Of course is your poduct doesn't need much performance then allmost
> anything
>> would do.
> 
> It seems to me you have never developed any projects using the 8051 and C
> language, or just aren't very good at it.

	Please don't turn this newsgroup into another flaming IRC session. 
Implying negative attributes to someone you disagree with is poor debating
practice and precludes a respectful response.

	While I think CBarn24050 may have been too terse I agree with his
fundamental position, C is inappropriate for 8-bit micros in general.  Be
aware that C and assembler are not the only two choices.  In some
applications Basic is even appropriate while we use Forth for it's
inherent debuggability.  If that's a word.
 
-- Regards, Albert
----------------------------------------------------------------------
AM Research, Inc.    			  The Embedded Systems Experts
http://www.amresearch.com          			  916.780.7623
----------------------------------------------------------------------

"Albert Lee Mitchell" <a...@albert.amresearch.com> wrote in message
news:p...@albert.amresearch.com...
> On Fri, 02 Jan 2004 12:42:06 -0500, Mark wrote:
>
> >
> > "CBarn24050" <c...@aol.com> pontificated in message
> > news:2...@mb-m29.aol.com...
> >> Hi, I have yet to see a project written in C where the 8051 was the
best
> > choice
> >> on either performance or price. C is to the 8051 what windows is to a
> > pentium.
> >> Of course is your poduct doesn't need much performance then allmost
> > anything
> >> would do.
> >
> > It seems to me you have never developed any projects using the 8051 and
C
> > language, or just aren't very good at it.
>
> Please don't turn this newsgroup into another flaming IRC session.
> Implying negative attributes to someone you disagree with is poor debating
> practice and precludes a respectful response.
>
> While I think CBarn24050 may have been too terse I agree with his
> fundamental position, C is inappropriate for 8-bit micros in general.  Be
> aware that C and assembler are not the only two choices.  In some
> applications Basic is even appropriate while we use Forth for it's
> inherent debuggability.  If that's a word.

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?

I have used Assembler, but that was happily only a short time before I came
to know the Keil compiler. I would anytime pay a price in a little faster
microcontroller with more memory in order to get the project done instead of
using my time on Assembler programming

Mind you my projects have predominately included control systems that needed
textoutput (nice and easy with sprintf) and floating point calculus...

Cheers

Klaus

Cheers

Klaus

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
----------------------------------------------------------------------

"Albert Lee Mitchell" <a...@albert.amresearch.com> wrote in message
news:p...@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
----------------------------------------------------------------------