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

"Paul Burke" <p...@scazon.com> wrote in message
news:btdqrc$61l2t$3...@ID-128611.news.uni-berlin.de...
> >
> >>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
>

.......... Paul, I didn't write that, you replied to the wrong post.......

Cheers

Klaus

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

Well, I use Cygnal - so I guess am just lucky then :-)

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

Ok, but do you really enjoy writing all that code? I can live with some
errors that are not my fault from time to time, but I am certainly not going
back to ASM because that would delay all my schedules.

I think the point is to weigh off the time used to debug compiler originated
C language errors versus the added time writing ASM code. I think I know the
answer, but you may well disagree...

I can say that I know no-one who writes in ASM anymore except for _very_
time critical routines such as interrupts. Moreover ASM is platform
dependant. What are you going to do if for example your manager decides to
switch from say 8051 to AVR? I'm just going to rewrite a couple of headers
and re-fit some details. You will have to start from scratch, wouldn't you?

Cheers

Klaus

Klaus Vestergaard Kragelund wrote:

> 
> I can say that I know no-one who writes in ASM anymore except for _very_
> time critical routines such as interrupts. 

Hi Klaus.  My name is Ian.  I still write complete applications in assembler
and not just ones with very time critical interrupt routines.

>Moreover ASM is platform
> dependant. What are you going to do if for example your manager decides to
> switch from say 8051 to AVR? I'm just going to rewrite a couple of headers
> and re-fit some details. You will have to start from scratch, wouldn't
> you?
> 

C is platform dependant too when it comes to samll 8 bit micros.

Ian

"Ian Bell" <i...@ruffrecordsDOTworldonline.co.uk> wrote in message
news:3...@mk-nntp-1.news.uk.worldonline.com...
> Klaus Vestergaard Kragelund wrote:
>
> >
> > I can say that I know no-one who writes in ASM anymore except for _very_
> > time critical routines such as interrupts.
>
> Hi Klaus.  My name is Ian.  I still write complete applications in
assembler
> and not just ones with very time critical interrupt routines.
>
> >Moreover ASM is platform
> > dependant. What are you going to do if for example your manager decides
to
> > switch from say 8051 to AVR? I'm just going to rewrite a couple of
headers
> > and re-fit some details. You will have to start from scratch, wouldn't
> > you?
> >
>
> C is platform dependant too when it comes to samll 8 bit micros.
>

Well, I use Keil and that one is ANSI C compliant. And if you need to switch
then choose a compiler that too is ANSI C compliant or close to that effect

Cheers

Klaus

"Klaus Vestergaard Kragelund" <k...@hotmail.com> wrote in
news:3ffaaf20$0$9719$e...@dread14.news.tele.dk: 

> 
> "Ian Bell" <i...@ruffrecordsDOTworldonline.co.uk> wrote in message
> news:3...@mk-nntp-1.news.uk.worldonline.com...
>> Klaus Vestergaard Kragelund wrote:
>>
>> >
>> > I can say that I know no-one who writes in ASM anymore except for
>> > _very_ time critical routines such as interrupts. 
>>
>> Hi Klaus.  My name is Ian.  I still write complete applications in
>> assembler and not just ones with very time critical interrupt
>> routines. 
>>
>> >Moreover ASM is platform
>> > dependant. What are you going to do if for example your manager
>> > decides to switch from say 8051 to AVR? I'm just going to rewrite a
>> > couple of headers and re-fit some details. You will have to start
>> > from scratch, wouldn't you? 
>> >
>>
>> C is platform dependant too when it comes to samll 8 bit micros.
>>
> 
> Well, I use Keil and that one is ANSI C compliant. And if you need to
> switch then choose a compiler that too is ANSI C compliant or close to
> that effect 
> 

Keil C51 has a number of 8051 specific extensions, which will require 
rework when migrating to a different processor.

-- 
On Erollisi Marr in <Sanctuary of Marr>
Elder Graeme Faelban, Barbarian Prophet of 65 seasons
Tainniel Fleabane, Halfling Warrior of 31 seasons
Giluven, Wood Elf Druid of 26 seasons
Graeniel, High Elf Enchanter of 25 seasons

Graeme Faelban <R...@netscape.net> wrote in 
news:Xns9468499754391richardrapiernetscap@130.133.1.4:

> "Klaus Vestergaard Kragelund" <k...@hotmail.com> wrote in
> news:3ffaaf20$0$9719$e...@dread14.news.tele.dk: 
> 
>> 
>> "Ian Bell" <i...@ruffrecordsDOTworldonline.co.uk> wrote in message
>> news:3...@mk-nntp-1.news.uk.worldonline.com... 
>>> Klaus Vestergaard Kragelund wrote:
>>>
>>> >
>>> > I can say that I know no-one who writes in ASM anymore except for
>>> > _very_ time critical routines such as interrupts. 
>>>
>>> Hi Klaus.  My name is Ian.  I still write complete applications in
>>> assembler and not just ones with very time critical interrupt
>>> routines. 
>>>
>>> >Moreover ASM is platform
>>> > dependant. What are you going to do if for example your manager
>>> > decides to switch from say 8051 to AVR? I'm just going to rewrite a
>>> > couple of headers and re-fit some details. You will have to start
>>> > from scratch, wouldn't you? 
>>> >
>>>
>>> C is platform dependant too when it comes to samll 8 bit micros.
>>>
>> 
>> Well, I use Keil and that one is ANSI C compliant. And if you need to
>> switch then choose a compiler that too is ANSI C compliant or close to
>> that effect 
>> 
> 
> Keil C51 has a number of 8051 specific extensions, which will require 
> rework when migrating to a different processor.
> 

Bah, forgot to change that sig for my rare appearance here.

-- 
Richard

"Graeme Faelban" <R...@netscape.net> wrote in message
news:Xns9468499754391richardrapiernetscap@130.133.1.4...
> "Klaus Vestergaard Kragelund" <k...@hotmail.com> wrote in
> news:3ffaaf20$0$9719$e...@dread14.news.tele.dk:
>
> >
> > "Ian Bell" <i...@ruffrecordsDOTworldonline.co.uk> wrote in message
> > news:3...@mk-nntp-1.news.uk.worldonline.com...
> >> Klaus Vestergaard Kragelund wrote:
> >>
> >> >
> >> > I can say that I know no-one who writes in ASM anymore except for
> >> > _very_ time critical routines such as interrupts.
> >>
> >> Hi Klaus.  My name is Ian.  I still write complete applications in
> >> assembler and not just ones with very time critical interrupt
> >> routines.
> >>
> >> >Moreover ASM is platform
> >> > dependant. What are you going to do if for example your manager
> >> > decides to switch from say 8051 to AVR? I'm just going to rewrite a
> >> > couple of headers and re-fit some details. You will have to start
> >> > from scratch, wouldn't you?
> >> >
> >>
> >> C is platform dependant too when it comes to samll 8 bit micros.
> >>
> >
> > Well, I use Keil and that one is ANSI C compliant. And if you need to
> > switch then choose a compiler that too is ANSI C compliant or close to
> > that effect
> >
>
> Keil C51 has a number of 8051 specific extensions, which will require
> rework when migrating to a different processor.
>

I'm aware of that, but isn't it still better than rewriting all the ASM
code? If you write your C code in a strutual manor, you need to change very
little...

Cheers

Klaus

On 6 Jan 2004 14:14:03 GMT, Graeme Faelban wrote:

>> Well, I use Keil and that one is ANSI C compliant. And if you need to
>> switch then choose a compiler that too is ANSI C compliant or close to
>> that effect 
>> 
> 
> Keil C51 has a number of 8051 specific extensions, which will require 
> rework when migrating to a different processor.

Which would be what, about 0.1% of the code? As opposed to 100% of an
assembler program.

Bob

On Sat, 3 Jan 2004 21:14:57 +0100, "Klaus Vestergaard Kragelund"
<k...@hotmail.com> 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?

I'm not the one you asked, but I didn't see where anyone really
answered this question...

C is totally, completely, and utterly usuited for the 8051.  Or any
other 8-bit micro.  And vice-versa.  (Well, the AVR isn't too bad, but
that's a special case: it was developed with the help of a compiler
vendor specifically to work nicely with C.)

1) C assumes 16 (or more) bit calculations are efficient.  The "int"
type is supposed to have the width "natural" to the processor, but
must be at least 16 bits wide.  There is _no_ way in C to to write an
uncast expression containing at least one operator whose result is
either {[un]signed] short or [[un]signed] char.

2) C assumes minimum resources are available.  For example, there must
be a minimum of 511 identifiers allowed within a block scope.  And 127
parameters to a function.  And 4095 characters in a string literal.
and 1023 members in a structure.  Try that with 128 bytes of data RAM.

3) Functions must be able to be called recursively, including main.

4) C has no concept of separate memory spaces, let alone separate RAM
spaces (data, idata, xdata).  This is bad enough on a von Neumann
architecture, but on a Harvard micro (like the 8051) it's devastating.

This is off the top of my head.  I'm sure there are others.  

The 8051 seems to have been fiendishly designed to make programming in
C difficult, inefficient or just impossible.  Some of the worst
problems are the lack of stack space, access of xdata through dptr
only, and of course, the Harvard architecture.  The only chip that
seems to be worse (disregarding 4-bitters) is the 12- and 14-bit PIC
cores (I haven't looked closely at the 16-bit PIC core or the dsPIC
yet).

OTOH, Keil (and some of the other vendors and perhaps SDCC as well)
has generally done an excellent job with its NQC (Not Quite C)
development systems.  They're very effective and easy to use, and make
efficient use of the 8051 resources.

Just don't go confusing them with C.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.