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
>
>
>
>
>
>
>
>
>
>
>
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
>
>
>
>
>
>
>
>
>
>
>
Reply by Onestone●March 4, 20052005-03-04
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
>
>
>
>
>
>
>
>
>
>
>
Reply by Matthias Weingart●March 4, 20052005-03-04
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
Reply by avram ionut●March 4, 20052005-03-04
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
.
.
__________________________________________________
Reply by Onestone●March 3, 20052005-03-03
I agree entirely I have huge libraries in asm that I plug into new
designs. The code is tested and proven, and typically more adaptable
than c style libraries. Ie I have code for PWM on a single timer, code
for PWM on dual timers, with or without hardware linked I/O pins. i have
graphics routines for character displays etc etc. translation is simple.
When I start a new project I have 4 files that start every project.
STD_DEFxxx, IO.asm, HDR.asm and MAIN.asm. In fact you could probably
include INIT.asm in that as well. the def file holds all the definitions
for just one micro. IO gives my IO allocation map, HDR holds constants,
RAM allocation etc, INITxxx has clock stabilisation routines and shell
initialisations for a specific micro MAIN holds the glue stuff, oh ISR
holds an ISR template, and ADC12x holds the ISRs and setup for the
analog sub-system. I have variants of this depending on which mode I am
using the A/D in.I then have things like KBD, LCDC, LCDG, LCDCG,
FLASHLIB, ADXL, ADXRS, SPI, COMMx, where there are different types for
different protocols. Most of these require just afew constants at the
start of the file to be configured. So re-use lives at a modular level.
I suspect Augusto was implying the wholesale re-use of programs doesn't
really happen in embedded. This I find especially true when it comes to
updating an old system written by someone else. I've mentioned the
litany of disastrous code I've seen before, but it sure aint re-uable.
Al
Tim Wade 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
>
>
>
>
>
>
>
>--
>This email is confidential and intended solely for the use of the individual
to whom it is addressed.
>Any views or opinions presented are solely those of the author and do not
necessarily represent those of NAUTRONIX LTD.
>
>If you are not the intended recipient, you have received this email in error
and use, dissemination, forwarding, printing, or copying of this email is
strictly prohibited. If you have received this email in error please contact
the sender.
>
>Although our computer systems use active virus protection software, and we
take various measures to reduce the risk of viruses being transmitted in e-mail
messages and attachments sent from this company, we cannot guarantee that such
e-mail messages and attachments are free from viruses on receipt. It is a
condition of our using e-mail to correspond with you, that any and all liability
on our part arising directly or indirectly out of any virus is excluded. Please
ensure that you run virus checking software on all e-mail messages and
attachments before reading them.
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
>
Reply by Onestone●March 3, 20052005-03-03
patrick_huesmann wrote:
>
>Last time I checked, there was only a low-level MAC really part of the
>zigbee standard (no real network layer or even application layer).
>
>OK, I'm also surprised that cellphone worms are around now. I think
>it's because the phones standardize on Symbian OS etc.
>But then, this allows you to write custom s/w apps for the phone
>(http://bemused.sf.net/ for example) so is it a good or a bad thing?
>
>
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.
Al
Reply by augusto einsfeldt●March 3, 20052005-03-03
You have a point.
Although I am ASM defender when you have team design C code is much easier
to handle.
Also, ASM software in bigger CPUs is just nonsense. This C vs ASM talk is,
of course, restricted to microcontrollers, CPUs with small amount of memory
or when one needs the ultimate performance of limited system.
My biggest ASM code needs near 46KB and it is amazing how often I find
someone doing even faster and smaller solutions for a piece of code already
well dry.
-----Original Message-----
From: Tim Wade [mailto:rtdb.wade@rtdb...]
Sent: Thursday, March 03, 2005 10:06 PM
To: msp430@msp4...
Subject: RE: [msp430] TimerA ISR
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
--
This email is confidential and intended solely for the use of the individual
to whom it is addressed.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of NAUTRONIX LTD.
If you are not the intended recipient, you have received this email in error
and use, dissemination, forwarding, printing, or copying of this email is
strictly prohibited. If you have received this email in error please
contact the sender.
Although our computer systems use active virus protection software, and we
take various measures to reduce the risk of viruses being transmitted in
e-mail messages and attachments sent from this company, we cannot guarantee
that such e-mail messages and attachments are free from viruses on receipt.
It is a condition of our using e-mail to correspond with you, that any and
all liability on our part arising directly or indirectly out of any virus is
excluded. Please ensure that you run virus checking software on all e-mail
messages and attachments before reading them.
.
Yahoo! Groups Links
--
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/2/2005
Reply by Tim Wade●March 3, 20052005-03-03
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
--
This email is confidential and intended solely for the use of the individual to
whom it is addressed.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of NAUTRONIX LTD.
If you are not the intended recipient, you have received this email in error and
use, dissemination, forwarding, printing, or copying of this email is strictly
prohibited. If you have received this email in error please contact the sender.
Although our computer systems use active virus protection software, and we take
various measures to reduce the risk of viruses being transmitted in e-mail
messages and attachments sent from this company, we cannot guarantee that such
e-mail messages and attachments are free from viruses on receipt. It is a
condition of our using e-mail to correspond with you, that any and all liability
on our part arising directly or indirectly out of any virus is excluded. Please
ensure that you run virus checking software on all e-mail messages and
attachments before reading them.
Reply by patrick_huesmann●March 3, 20052005-03-03
Hi,
--- In msp430@msp4..., "augusto einsfeldt" <aee@t...> wrote:
> My "first of all" complain against C is
the amount of trust you have
to give
> to few people (maybe just one) who wrote the
compiler, drivers or APIs.
Yes, that's true, you must trust s.o. else's code, even if you
don't
use standard library functions, you have to trust the compiler. And
compilers are not always perfect, they do have bugs at times.
> It is why there are so many backdoors, glitches,
"blue screens",
virus and
> worms: everyone is aceppting C tools like they are
perfect (or, at
least,
> like Microsoft, why to botter if a software hangs
only less than 10%
of the
> times?).
Perhaps, but then we'd be talking about C/C++ vs. Java, C# etc.
> If your C program works fine in the PC you cannot
trust it will remain
> working the same way when porting to a microcontroler.
If both compilers are standards-compliant and your code doesn't depend
on platform-specific features (API's, data type size/endian etc.),
then it should do the same. Of course, it needs to be tested again,
nevertheless.
> Let's see what will happen when Zigbee
becomes a must: several IC
vendors
> will offer a "free design references"
that will be used for everyone "to
> save design time" and few years(months) later: bang! A Zigbee virus
will be
> there... or worst: imagine if you have, say, 129
devices in the
network all
> of CPUs will call a non existent routine and WDT
will pop everywhere...
Last time I checked, there was only a low-level MAC really part of the
zigbee standard (no real network layer or even application layer).
OK, I'm also surprised that cellphone worms are around now. I think
it's because the phones standardize on Symbian OS etc.
But then, this allows you to write custom s/w apps for the phone
(http://bemused.sf.net/ for example) so is it a good or a bad thing?
Regards,
Patrick
