On Fri, 19 Aug 2005 08:10:09 +0200, Matthias wrote:

>I think the people here that vote for ASM have
never used C extensively on a
>micro to see the advantages.

Not so.  I've been using C since 1978, when I was using it in Unix
operating system work under version 6.  I've completed perhaps a dozen
projects in it in the last 6 years alone, on exclusively embedded
systems.  If I added PC applications, it would be many more than that.

Jon

Al,
You R right that the libraries are important. But more important is to
develop them. My personal libraries count at
this time 14740 functions all written in ANSI C. This means portability. One
great asset of an ANSI HLL is the portability :) But if you're stuck on the
430 this might not be important to you :)

Alex


----- Original Message ----- 
From: "Onestone" <onestone@ones...>
To: <msp430@msp4...>
Sent: Friday, August 19, 2005 3:03 AM
Subject: Re: [msp430] Re: Interrupt occurs in ISR A


I've used both too, though I admit I haven't recently used C on a
micro
'in anger' because i simply haven't seen any personal advantage
in doing
so. To me the advantage of any HLL is the laibraries. Without them why
bother? Simply redefining putchar() won't go far when you're doing
graphics.

Al

Matthias Weingart wrote:

>On Fri, Aug 19, 2005 at 03:20:07PM +0930,
Onestone wrote:
>
>
>
>>>I hope "embedded C" (that is using more CPU-features in C)
will become a
>>>standard very fast.
>>>
>>>
>>>
>>Now this might sound really strange but I would LOVE to see a EC that
>>was stripped right down to the functions that mean anything to a micro,
>>that handled bits cleanly, that allowed flag access, especially with
>>shifts,
>>
>>
>
>
>
>>and that included things like a cprintf that allowed you to
>>write data to one of the 4 most popular character LCD panels (in 4 or 8
>>bit mode), after first setting their I/O allocation. Or a gprintf that
>>did the same for graphics panels, again after initialisation, and which
>>covered perhaps the 4 most popular controller families. Or a kscanf,
>>that implemented a keyboard string interface, and a kgets that
>>implements a single keyboard get function, perhaps similar routines for
>>IIC, SPI, UART, CAN and USB, then why not A/D, D/A and finally some
>>timer functions like tpulse, tperiod, spwm, tduty, gpulse, gperiod etc
>>where t = time, and g = generate.
>>
>>
>
>You mix basic features and libraries here. I think a eC standard should
only
>handle simple things (cpu related, like shifts, bit
access ...)
>- not libraries. And well with each good c-compiler you can of course use
>the printf with any of your output devices. You just need to redefine the
>putchar().
>
>I think the people here that vote for ASM have never used C extensively on
a
>micro to see the advantages. (Of course there is a
hurdle - some simple
>things look more complicated in C than in ASM.) I have used both (and still
>use both) and from my experiences C makes sense - absolutely.
>
>        Matthias
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>




.


Yahoo! Groups Links









---
avast! Antivirus: Inbound message clean.
Virus Database (VPS): 0533-3, 08/17/2005
Tested on: 8/19/2005 8:24:29 AM
avast! - copyright (c) 1988-2005 ALWIL Software.
http://www.avast.com

But that doesn't affect portability. I couldn't imagine what
14740 
functions you couold possibly have, mine number less than 1000, but for 
most jobs they cover at least 80% of the necessary code. There are too 
many things that ANSI C standard leaves to the implementer, especially 
with embedded systems, to make C 100% portable. this is a myth.

Lets see, so far this year I've worked on LPC2138, LPC2106, ADuC7024, 
MSP430, MAXQ2000, PIC10F, dsPIC and Z8F04, so I guess I'm not stuck on 
anything.

Al

alex@alex... wrote:

>Al,
>You R right that the libraries are important. But more important is to
>develop them. My personal libraries count at
>this time 14740 functions all written in ANSI C. This means portability. One
>great asset of an ANSI HLL is the portability :) But if you're stuck on
the
>430 this might not be important to you :)
>
>Alex
>
>
>----- Original Message ----- 
>From: "Onestone" <onestone@ones...>
>To: <msp430@msp4...>
>Sent: Friday, August 19, 2005 3:03 AM
>Subject: Re: [msp430] Re: Interrupt occurs in ISR A
>
>
>I've used both too, though I admit I haven't recently used C on a
micro
>'in anger' because i simply haven't seen any personal
advantage in doing
>so. To me the advantage of any HLL is the laibraries. Without them why
>bother? Simply redefining putchar() won't go far when you're doing
graphics.
>
>Al
>
>Matthias Weingart wrote:
>
>  
>
>>On Fri, Aug 19, 2005 at 03:20:07PM +0930, Onestone wrote:
>>
>>
>>
>>    
>>
>>>>I hope "embedded C" (that is using more CPU-features
in C) will become a
>>>>standard very fast.
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>Now this might sound really strange but I would LOVE to see a EC
that
>>>was stripped right down to the functions that mean anything to a
micro,
>>>that handled bits cleanly, that allowed flag access, especially with
>>>shifts,
>>>
>>>
>>>      
>>>
>>
>>    
>>
>>>and that included things like a cprintf that allowed you to
>>>write data to one of the 4 most popular character LCD panels (in 4
or 8
>>>bit mode), after first setting their I/O allocation. Or a gprintf
that
>>>did the same for graphics panels, again after initialisation, and
which
>>>covered perhaps the 4 most popular controller families. Or a kscanf,
>>>that implemented a keyboard string interface, and a kgets that
>>>implements a single keyboard get function, perhaps similar routines
for
>>>IIC, SPI, UART, CAN and USB, then why not A/D, D/A and finally some
>>>timer functions like tpulse, tperiod, spwm, tduty, gpulse, gperiod
etc
>>>where t = time, and g = generate.
>>>
>>>
>>>      
>>>
>>You mix basic features and libraries here. I think a eC standard should
>>    
>>
>only
>  
>
>>handle simple things (cpu related, like shifts, bit access ...)
>>- not libraries. And well with each good c-compiler you can of course
use
>>the printf with any of your output devices. You just need to redefine
the
>>putchar().
>>
>>I think the people here that vote for ASM have never used C extensively
on
>>    
>>
>a
>  
>
>>micro to see the advantages. (Of course there is a hurdle - some simple
>>things look more complicated in C than in ASM.) I have used both (and
still
>>use both) and from my experiences C makes sense - absolutely.
>>
>>       Matthias
>>
>>
>>
>>.
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>---
>avast! Antivirus: Inbound message clean.
>Virus Database (VPS): 0533-3, 08/17/2005
>Tested on: 8/19/2005 8:24:29 AM
>avast! - copyright (c) 1988-2005 ALWIL Software.
>http://www.avast.com
>
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>