first: i have to agree in C in team projects (teams whit 3 or more - in 2
eng team asm works perfect from my personal experience)
second: i noticed 2 kind of projects: hit and run (C is great, lot of PMs have
made careers, looks great on CV) and one life projects (projects at the edge of
known technical field, where every bit counts, where asm programmers sometimes
writes C but just for clearence)
3rd: in x86 word reuse is different from the uC`s word. writing common code for
more apps on the same core is done in both cases,  the difference is when the
code must run over several uCs. i think that such reuse is some kind of hunting
the wind. if porting from a 8051 from intel to a 8051 from philips yes it can be
done, but what about upgrating from a pic to an avr? (just my 2 eurocents ... 
on a 2 euro paper)
 
avram
ps: please do not mixt here on the msp430 soup the  x86, arm embeded experience,
this are from other recepies

Tim Wade <rtdb.wade@rtdb...> wrote:
I have to dispute that there is no real reuse in embedded stuff. I have
done a few items on the AVR that had a MIDI interface for talking to
keyboards. The actual things being built were quite different but a
large amount of the code was similar... Surely reuse? We had a software
manager here who had lots of interesting terms for the methodology of
writing code... One of my favourites was "scavenging". Which again is
reuse where you cut and paste useful sections of code out of previous
projects... Again reuse. If you structure your reuse properly,
regardless of assembler or C, then fixing up the serial port class, for
instance, only happens once, not five or six times.

On the subject of C vs ASM I would have to say that I am sure that I
would always of picked Z80 assembler over any 'high level' language
but
as I have had to work in teams I must admit that C is just a lot easier.
If a project is written in ASM then there do seem to be more
opportunities for writing cryptic code (especially on the PIC). I am not
saying that people don't do it in C it is just, in my experience, if you
are picking up a project that needs some work it is usually easier to
understand somebody's C over somebody else's ASM. This can be quite a
big consideration for companies which have long development cycles on a
project and an associated turn over of people working on that project.
As always, this is a generalisation....



-----Original Message-----
From: avram ionut [mailto:avramionut_m@avra...] 
Sent: Thursday, 3 March 2005 8:18 PM
To: msp430@msp4...
Subject: Re: [msp430] TimerA ISR




Patrick Huesmann <patrick.huesmann@patr...> wrote:
Hi,

On Thu, 03 Mar 2005 20:14:48 +1030, Onestone <onestone@ones...>
wrote:
>  I doubt you could implement any of my current designs in C on the 
> same  MSP430

This may be an issue in very high-volume applications.

But the company that I work for, only does low quantity, and there you
have it the other way around: cost of parts (MCUs etc.) is almost
irrelevant, whereas development cost is crucial.

And development cost would skyrocket if we had to learn new asm
languages for each new MCU we're using. Not to mention the impact on
code reuse and portability.

... let it down! there is no real code reuse in embedded ... what do you
reuse: a for cycle, a swich or a multiply ... each uC architecture must
fit the purpose, target, scope of the project and this is the direction
of the effort not to inherit code lines 

>  The major issue is that universities are 
churning out C and C++ 
> programmers by the bucketful, but very few leave  uni with good asm 
> skills, why?

Why should I learn asm at university? The professors would probably
teach assembly language based on some ancient, bizarre architecture that
is obsolete even before the students receive their diploma ;)

... the purpose is to give students abilities to solve problems not to
give them diplomas (my 2 eurocents ....)

>  Hell my sons been programming in C since he was
10, he  reckons it 
> was easier to learn than VB.

I'm glad that I never had to use VB yet ;-))

... regatds,
... avram 

regards,
Patrick


.








---------------------------------
. 



            
---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 





.


. 


__________________________________________________
 

On Fri, Mar 04, 2005 at 12:34:26PM +1030, Onestone wrote:

> To be able to upload a virus to a mobile phone
implies that there is 
> external access to control the telephones functions. ie the telephone 
> company has full control over your phone. The implications of this are 
> not good.

The viruses today are uploaded by bluetooth or special SMS messages,
not only the phone provider have access; the whole world has. Well
not much different to Windows hosts and the Internet Exploder ;-). 
The implications are bad, very bad; it's one hour after 12.

        Matthias

I have only had to work on teams a few times. For 5 years in a previous 
job 4 of them running the teams. All coding was in asm, and, once I'd 
gotten rid of the 20 man teams, and reduced them all to no more than 4 
people, and then stopped the interminable 'planning' meetings. where 
nothing got done, and no plans were laid, but instead listened to what 
each member had to say separately, then dictated policy things worked 
out fine. Both the other teams I've worked on were also small, one 
involved just two other juniors, and worked well, the other was a 
disaster because one team member refused to cooperate. Once he was fired 
things went well. ASm can work in suitably skilled teams, but they are 
hard to find, and, I admit, harder to manage. I once read an article in 
the C users journal which referred to (c) programmers as Gods and none 
programmers as ants, (I stopped my subscription). Unfortunately many asm 
programmers have a similar attitude to c programmers, and consider 
themselves a 'cut above'. This is just a job, it takes all sorts of 
skills to be successful, and, lets face it, salesmen earn more than most 
engineers.

Al

avram ionut wrote:

>first: i have to agree in C in team projects (teams
whit 3 or more - in 2 eng team asm works perfect from my personal experience)
>second: i noticed 2 kind of projects: hit and run (C is great, lot of PMs
have made careers, looks great on CV) and one life projects (projects at the
edge of known technical field, where every bit counts, where asm programmers
sometimes writes C but just for clearence)
>3rd: in x86 word reuse is different from the uC`s word. writing common code
for more apps on the same core is done in both cases,  the difference is when
the code must run over several uCs. i think that such reuse is some kind of
hunting the wind. if porting from a 8051 from intel to a 8051 from philips yes
it can be done, but what about upgrating from a pic to an avr? (just my 2
eurocents ...  on a 2 euro paper)
> 
>avram
>ps: please do not mixt here on the msp430 soup the  x86, arm embeded
experience, this are from other recepies
>
>Tim Wade <rtdb.wade@rtdb...> wrote:
>I have to dispute that there is no real reuse in embedded stuff. I have
>done a few items on the AVR that had a MIDI interface for talking to
>keyboards. The actual things being built were quite different but a
>large amount of the code was similar... Surely reuse? We had a software
>manager here who had lots of interesting terms for the methodology of
>writing code... One of my favourites was "scavenging". Which again
is
>reuse where you cut and paste useful sections of code out of previous
>projects... Again reuse. If you structure your reuse properly,
>regardless of assembler or C, then fixing up the serial port class, for
>instance, only happens once, not five or six times.
>
>On the subject of C vs ASM I would have to say that I am sure that I
>would always of picked Z80 assembler over any 'high level'
language but
>as I have had to work in teams I must admit that C is just a lot easier.
>If a project is written in ASM then there do seem to be more
>opportunities for writing cryptic code (especially on the PIC). I am not
>saying that people don't do it in C it is just, in my experience, if
you
>are picking up a project that needs some work it is usually easier to
>understand somebody's C over somebody else's ASM. This can be
quite a
>big consideration for companies which have long development cycles on a
>project and an associated turn over of people working on that project.
>As always, this is a generalisation....
>
>
>
>-----Original Message-----
>From: avram ionut [mailto:avramionut_m@avra...] 
>Sent: Thursday, 3 March 2005 8:18 PM
>To: msp430@msp4...
>Subject: Re: [msp430] TimerA ISR
>
>
>
>
>Patrick Huesmann <patrick.huesmann@patr...> wrote:
>Hi,
>
>On Thu, 03 Mar 2005 20:14:48 +1030, Onestone <onestone@ones...>
>wrote:
>  
>
>> I doubt you could implement any of my current designs in C on the 
>>same  MSP430
>>    
>>
>
>This may be an issue in very high-volume applications.
>
>But the company that I work for, only does low quantity, and there you
>have it the other way around: cost of parts (MCUs etc.) is almost
>irrelevant, whereas development cost is crucial.
>
>And development cost would skyrocket if we had to learn new asm
>languages for each new MCU we're using. Not to mention the impact on
>code reuse and portability.
>
>... let it down! there is no real code reuse in embedded ... what do you
>reuse: a for cycle, a swich or a multiply ... each uC architecture must
>fit the purpose, target, scope of the project and this is the direction
>of the effort not to inherit code lines 
>
>  
>
>> The major issue is that universities are  churning out C and C++ 
>>programmers by the bucketful, but very few leave  uni with good asm 
>>skills, why?
>>    
>>
>
>Why should I learn asm at university? The professors would probably
>teach assembly language based on some ancient, bizarre architecture that
>is obsolete even before the students receive their diploma ;)
>
>... the purpose is to give students abilities to solve problems not to
>give them diplomas (my 2 eurocents ....)
>
>  
>
>> Hell my sons been programming in C since he was 10, he  reckons it 
>>was easier to learn than VB.
>>    
>>
>
>I'm glad that I never had to use VB yet ;-))
>
>... regatds,
>... avram 
>
>regards,
>Patrick
>
>
>.
>
>
>
>
>
>
>
>
>---------------------------------
>. 
>
>
>
>            
>---------------------------------
>Celebrate Yahoo!'s 10th Birthday! 
>Yahoo! Netrospective: 100 Moments of the Web 
>
>
>
>
>
>.
>
>
>. 
>
>
>__________________________________________________
> 
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

A bluetooth or SMS message is simply an incoming data block, and should 
not be able to alter, or affect program memory. This is a serious bit of 
stupidity if it can.

Al

Matthias Weingart wrote:

>On Fri, Mar 04, 2005 at 12:34:26PM +1030,
Onestone wrote:
>
>  
>
>>To be able to upload a virus to a mobile phone implies that there is 
>>external access to control the telephones functions. ie the telephone 
>>company has full control over your phone. The implications of this are 
>>not good.
>>    
>>
>
>The viruses today are uploaded by bluetooth or special SMS messages,
>not only the phone provider have access; the whole world has. Well
>not much different to Windows hosts and the Internet Exploder ;-). 
>The implications are bad, very bad; it's one hour after 12.
>
>        Matthias
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

HERE IS AN ASM FUNC POINTER. I don't know how you would force c to do 
this, function pointers in C tend to be cumbersome.

TA12_ISR:

    PUSH   R5
    MOV   &TAIV,R5
    CALL   FUNCTABLE(R5)
    POP   R5

NOFUNC:

    RETI

FUNCTABLE:
          DW         NOFUNC, TA1ISR,TA2ISR,NOFUNC,NOFUNC,TAOVF_ISR    

In fact the most economical way to use TAIv is in a simple jump table, 
as illustrated in the Ti user guide. The following is a shell to 
illustrate this. After I posted I realised that even function pointers 
aren't very efficient in C.

Al


TA12_ISR:                ;Timer A3 CC Block 1&2
    ADD    &TAIV,PC
    RETI
    JMP    TA_1INT            ;HANDLE TA-1 INTERRUPT
    JMP    TA_2INT
    RETI                                ;3 & 4 CAN'T OCCUR FOR A
'149
    RETI
   
/* Timer_A-0 is a 1 SEC timebase, used by the RTC only */
   
TA_OVF:                    ;DROPS HERE ON TAIV = 10
    BIS    #SECOND,&SYSTEM_FLAGS
    RETI
   
TA_1INT:   
    RETI   
TA_2INT:   
    RETI   
   
;****** Timer_A 0
   
TA0_ISR:                 ;Timer A3 CC Block 0
    RETI


Wagner R. Teixeira wrote:

>
>Hi everyone ;) This is my first post here. I'm beginning with MSP430s.
(and
>like them very much)
>
>Al, sorry, but I could not figure out what you mean. Could you please make
>an example of a "use TAIV in a function pointer"?
>
>Cheers.
>Wagner
>
>  
>
>>Why not just use TAIV in a function pointer? It will surely produce more
>>effciient code.
>>
>>Al
>>
>>Patrick Huesmann wrote:
>>
>>    
>>
>>>chetan loke wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>interrupt (TIMERA0_VECTOR) Timer_A (void)
>>>>{
>>>>switch( TAIV )
>>>>{
>>>>  case  2: break;                // CCR1 not used
>>>>  case  4: break;                // CCR2 not used
>>>>  case 10: *_p5out = 0x40;
>>>>           //CCR1 = 32;// 1ms duty cycle
>>>>           break;
>>>>}
>>>>}
>>>>
>>>>        
>>>>
>
>--
>
>
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>