On 08/08/2012 13:09, Jon Kirwan wrote:
> On Wed, 08 Aug 2012 10:39:10 +0200, you wrote:
>
> >On 08/08/2012 09:33, Jon Kirwan wrote:
> >> On Wed, 08 Aug 2012 00:30:20 -0700, I wrote:
> >>
> >> >
> >>
> >> >He would see that it possesses the CPU4 bug. (TI NEVER FIXES
> >> >AN ERRATA and won't fix them on newer processor designs,
> >> >either, it seems.) The CPU4 bug means that the constants +4
> >> >and +8 DON'T WORK!!! So the assembler nicely, and without any
> >> >warning, stuffs the constant inline.
> >> >
> >> >So. Your point is even BETTER than you may have imagined,
> >> >David. Dave Feldman might actually be able to improve the
> >> >response by using that register you just mentioned.
> >>
> >> >
> >>
> >> Shucks. It is definitely too late at night for me! This
> >> affects the PUSH (which I ran into some time back.) But not
> >> the BIS or BIC, so far as I'm aware. My mistake!! So there is
> >> nothing to be done about cycles in this case. Oh, well.
> >>
> >
> >That's what I thought (and your web page confirms it - that's a
nice
> >feature summary for the msp430).
>
> Thanks. I wrote it within a few months of first seeing the
> MSP430, I think. Quite a long time ago, now. First
> impressions and all that.
>
> >As for the CPU4 bug, I can imagine that if TI /did/ fix it, it could
> >cause plenty of confusion as to which chips can use the constant
> >generator for push #4 and push #8, and which can't.
> > Every other company DOES fix them. Mostly. Intel -- yes.
> Microchip -- yes. Energy Micro -- yes. And so on.
>
> It's not as though the idea is novel with me, David. People
> do fix things. And other people get used to that, too, and
> know where to look (the errata.) In fact, that is why you go
> to the errata. To see if your stepping has certain bugs. If
> it is NEVER fixed, then it is a feature and it should be
> documented in the Family Manual, permanently and forever. But
> TI chooses not to fix things, but to keep them in the errata
> anyway. Weird. Actually, I don't know of another company that
> doesn't ever fix this kind of errata (that TI doesn't own in
> some way.)
>
> TI does fix errata that would mean they couldn't sell chips
> at all. But then, who wouldn't?
>
> I see TI as standing unique, here. My other experience with
> other companies has consistently been otherwise.
>
> Anyway, per your point -- IT IS HANDLED IN THE DARNED
> ASSEMBLER for gosh sake. Since it knows what chip you are
> working on... guess what? It can pick and choose and generate
> appropriately. It's doing that kind of thing now.
>
It could have been fixed for the newer (20-bit) cores that have more
changes - but there would be no point in fixing it for existing chips,
precisely because it is handled in the assembler. The assembler knows
which chip family you are using, but it certainly doesn't know which die
revision you have. So you could never take advantage of a fix in
existing series.
Also remember that in this case, the impact of the bug is totally
negligible - out of the tiny proportion of cases where "push #4" or
"push #8" might be used, only in a tiny proportion will the extra two
cycles and extra code word be measurable. That's why I think TI should
document it as part of the msp430 specifications, and leave it there.
(Of course, the bug /was/ a big deal when it was newly discovered and
toolchain vendors hadn't implemented a workaround.)
> I really don't think there is any justifiable
barrier here.
>
It's not a justification - just an alternative way of handling it.
In general, of course, you are right - errata should be fixed where
possible, and TI are not always good at doing that. There are a lot of
other errata in the link you sent that have existed for just as long,
and can have more of an impact on users. After all, the CPU4 issue is
almost completely transparent to users, while the others can affect
users who just read the datasheets and not the errata (i.e., most users).
Assembler BIS instruction and register indirect as destination - can't assemble this line of code
Started by ●August 7, 2012
Reply by ●August 8, 20122012-08-08
Reply by ●August 8, 20122012-08-08
Thanks to everyone for the very helpful advice and commentary.
After (many years ago) much assembly language programming on PDP-11 and MOS
Technology 6501/6502 series, I clearly expected too much in terms of the
claims of nicely-orthogonal instruction set for the MSP430 (in my
opinion, rich addressing modes are more valuable than numerous registers...)
(also, the constant register issue discussion is interesting, but wasn't my
intended topic as I just cited "#4" in my example at random...)
Thanks again, everyone.
Dave
>The MSP430, terribly sadly to my mind, sacrified addressing
>modes in order to get 16 registers. In the case of two
>operand instructions, they have 2 bits for source operand and
>1 bit for destination. Your source value is #4. Which is
>fine. This gets coded as mode 2, register R2. But your
>destination mode doesn't exist (it does, in source mode.) You
>only have two destination modes -- register direct and
>register offset indirect (and two special cases, only one of
>which you should ever use -- absolute indirect. the other is
>the constant 1 -- which you shouldn't ever use.)
>
>You are hosed.
>
>Jon
After (many years ago) much assembly language programming on PDP-11 and MOS
Technology 6501/6502 series, I clearly expected too much in terms of the
claims of nicely-orthogonal instruction set for the MSP430 (in my
opinion, rich addressing modes are more valuable than numerous registers...)
(also, the constant register issue discussion is interesting, but wasn't my
intended topic as I just cited "#4" in my example at random...)
Thanks again, everyone.
Dave
>The MSP430, terribly sadly to my mind, sacrified addressing
>modes in order to get 16 registers. In the case of two
>operand instructions, they have 2 bits for source operand and
>1 bit for destination. Your source value is #4. Which is
>fine. This gets coded as mode 2, register R2. But your
>destination mode doesn't exist (it does, in source mode.) You
>only have two destination modes -- register direct and
>register offset indirect (and two special cases, only one of
>which you should ever use -- absolute indirect. the other is
>the constant 1 -- which you shouldn't ever use.)
>
>You are hosed.
>
>Jon
Reply by ●August 8, 20122012-08-08
> Thanks to everyone for the very helpful advice and
commentary.
>
> After (many years ago) much assembly language programming on PDP-11 and
> MOS Technology 6501/6502 series, I clearly expected too much in terms of
> the claims of nicely-orthogonal instruction set for the MSP430 (in my
> opinion, rich addressing modes are more valuable than numerous
> registers...)
I think you're wrong: registers are much more precious than addressing
modes.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
>
> After (many years ago) much assembly language programming on PDP-11 and
> MOS Technology 6501/6502 series, I clearly expected too much in terms of
> the claims of nicely-orthogonal instruction set for the MSP430 (in my
> opinion, rich addressing modes are more valuable than numerous
> registers...)
I think you're wrong: registers are much more precious than addressing
modes.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●August 8, 20122012-08-08
When the architecture relies on registers to get maximum execution speed
then I too believe that registers are more important, however if the
instruction set had a richer set of truly orthogonal addressing modes
then it would seem that these too would be equally important, until you
look at the execution speeds. The only true single cycle mode is
register to register, as soon as you use indirect or indexed register
modes the clock cycles climb anyway. So I would probably prefer 2 sets
of 16 registers and simpler 1 bit modes in both src and dst given the
choice,(register or indexed modes), so by using just a single bit in the
operand to define the register mode the freed up bit can signal register
bank 1 or 2.
Al
On 9/08/2012 1:12 AM, Paul Curtis wrote:
>> Thanks to everyone for the very helpful advice and commentary.
>>
>> After (many years ago) much assembly language programming on PDP-11 and
>> MOS Technology 6501/6502 series, I clearly expected too much in terms of
>> the claims of nicely-orthogonal instruction set for the MSP430 (in my
>> opinion, rich addressing modes are more valuable than numerous
>> registers...)
> I think you're wrong: registers are much more precious than addressing
> modes.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>
>
then I too believe that registers are more important, however if the
instruction set had a richer set of truly orthogonal addressing modes
then it would seem that these too would be equally important, until you
look at the execution speeds. The only true single cycle mode is
register to register, as soon as you use indirect or indexed register
modes the clock cycles climb anyway. So I would probably prefer 2 sets
of 16 registers and simpler 1 bit modes in both src and dst given the
choice,(register or indexed modes), so by using just a single bit in the
operand to define the register mode the freed up bit can signal register
bank 1 or 2.
Al
On 9/08/2012 1:12 AM, Paul Curtis wrote:
>> Thanks to everyone for the very helpful advice and commentary.
>>
>> After (many years ago) much assembly language programming on PDP-11 and
>> MOS Technology 6501/6502 series, I clearly expected too much in terms of
>> the claims of nicely-orthogonal instruction set for the MSP430 (in my
>> opinion, rich addressing modes are more valuable than numerous
>> registers...)
> I think you're wrong: registers are much more precious than addressing
> modes.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>
>
Reply by ●August 8, 20122012-08-08
FWIW The SPARC architecture has a single large set of registers and keeps a
pointer to the subset of registers that are currently accessible. The idea
being to preserve a portion of the register set by simply shifting the window
pointer.
If more need to be saved then the normal manner of saving registers is used for those. I always thought it was a rather elegant solution.
Have Fun!
Reg
--- On Wed, 8/8/12, Onestone wrote:
> From: Onestone
> Subject: Re: [msp430] Re: (corrected) Assembler BIS instruction and register indirect as d
> To: m...
> Date: Wednesday, August 8, 2012, 11:39 AM
> When the architecture relies on
> registers to get maximum execution speed
> then I too believe that registers are more important,
> however if the
> instruction set had a richer set of truly orthogonal
> addressing modes
> then it would seem that these too would be equally
> important, until you
> look at the execution speeds. The only true single cycle
> mode is
> register to register, as soon as you use indirect or indexed
> register
> modes the clock cycles climb anyway. So I would probably
> prefer 2 sets
> of 16 registers and simpler 1 bit modes in both src and dst
> given the
> choice,(register or indexed modes), so by using just a
> single bit in the
> operand to define the register mode the freed up bit can
> signal register
> bank 1 or 2.
>
> Al
>
> On 9/08/2012 1:12 AM, Paul Curtis wrote:
> >> Thanks to everyone for the very helpful advice and
> commentary.
> >>
> >> After (many years ago) much assembly language
> programming on PDP-11 and
> >> MOS Technology 6501/6502 series, I clearly expected
> too much in terms of
> >> the claims of nicely-orthogonal instruction set for
> the MSP430 (in my
> >> opinion, rich addressing modes are more valuable
> than numerous
> >> registers...)
> > I think you're wrong: registers are much more precious
> than addressing
> > modes.
> >
> > --
> > Paul Curtis, Rowley Associates Ltdhttp://www.rowley.co.uk
> > SolderCore Development Platform http://www.soldercore.com
> >
> >
> >
> >
> >
> >
> >
> >
If more need to be saved then the normal manner of saving registers is used for those. I always thought it was a rather elegant solution.
Have Fun!
Reg
--- On Wed, 8/8/12, Onestone wrote:
> From: Onestone
> Subject: Re: [msp430] Re: (corrected) Assembler BIS instruction and register indirect as d
> To: m...
> Date: Wednesday, August 8, 2012, 11:39 AM
> When the architecture relies on
> registers to get maximum execution speed
> then I too believe that registers are more important,
> however if the
> instruction set had a richer set of truly orthogonal
> addressing modes
> then it would seem that these too would be equally
> important, until you
> look at the execution speeds. The only true single cycle
> mode is
> register to register, as soon as you use indirect or indexed
> register
> modes the clock cycles climb anyway. So I would probably
> prefer 2 sets
> of 16 registers and simpler 1 bit modes in both src and dst
> given the
> choice,(register or indexed modes), so by using just a
> single bit in the
> operand to define the register mode the freed up bit can
> signal register
> bank 1 or 2.
>
> Al
>
> On 9/08/2012 1:12 AM, Paul Curtis wrote:
> >> Thanks to everyone for the very helpful advice and
> commentary.
> >>
> >> After (many years ago) much assembly language
> programming on PDP-11 and
> >> MOS Technology 6501/6502 series, I clearly expected
> too much in terms of
> >> the claims of nicely-orthogonal instruction set for
> the MSP430 (in my
> >> opinion, rich addressing modes are more valuable
> than numerous
> >> registers...)
> > I think you're wrong: registers are much more precious
> than addressing
> > modes.
> >
> > --
> > Paul Curtis, Rowley Associates Ltdhttp://www.rowley.co.uk
> > SolderCore Development Platform http://www.soldercore.com
> >
> >
> >
> >
> >
> >
> >
> >
Reply by ●August 8, 20122012-08-08
On Wed, 8 Aug 2012 16:42:08 +0100, you wrote:
>> Thanks to everyone for the very helpful advice and commentary.
>>
>> After (many years ago) much assembly language programming on PDP-11 and
>> MOS Technology 6501/6502 series, I clearly expected too much in terms of
>> the claims of nicely-orthogonal instruction set for the MSP430 (in my
>> opinion, rich addressing modes are more valuable than numerous
>> registers...)
>
>I think you're wrong: registers are much more precious than addressing
>modes.
What was done to the MSP430 wasn't a logical tradeoff. They
simply screwed up. They could have managed the instruction
design in a way that didn't screw up the inability for a PC
relative function call, if nothing else. But if interested, I
can lay out a design that provides the 12 working registers
and doesn't nearly as badly injures the rest. What they did
is subject it to blind choices, not crafted design.
Jon
>> Thanks to everyone for the very helpful advice and commentary.
>>
>> After (many years ago) much assembly language programming on PDP-11 and
>> MOS Technology 6501/6502 series, I clearly expected too much in terms of
>> the claims of nicely-orthogonal instruction set for the MSP430 (in my
>> opinion, rich addressing modes are more valuable than numerous
>> registers...)
>
>I think you're wrong: registers are much more precious than addressing
>modes.
What was done to the MSP430 wasn't a logical tradeoff. They
simply screwed up. They could have managed the instruction
design in a way that didn't screw up the inability for a PC
relative function call, if nothing else. But if interested, I
can lay out a design that provides the 12 working registers
and doesn't nearly as badly injures the rest. What they did
is subject it to blind choices, not crafted design.
Jon
Reply by ●August 8, 20122012-08-08
On Wed, 8 Aug 2012 11:23:24 -0700 (PDT), you wrote:
> FWIW The SPARC architecture has a single large set of
> registers and keeps a pointer to the subset of registers
> that are currently accessible. The idea being to preserve a
> portion of the register set by simply shifting the window
> pointer.
>
> If more need to be saved then the normal manner of saving
> registers is used for those. I always thought it was a
> rather elegant solution.
Just about anyone could have improved the MSP430 instruction
design with a day's thought and a short list of mistakes to
solve. (There are several.) No need for such a sweeping
change. But your point is also worth taking, too.
Jon
> FWIW The SPARC architecture has a single large set of
> registers and keeps a pointer to the subset of registers
> that are currently accessible. The idea being to preserve a
> portion of the register set by simply shifting the window
> pointer.
>
> If more need to be saved then the normal manner of saving
> registers is used for those. I always thought it was a
> rather elegant solution.
Just about anyone could have improved the MSP430 instruction
design with a day's thought and a short list of mistakes to
solve. (There are several.) No need for such a sweeping
change. But your point is also worth taking, too.
Jon
Reply by ●August 8, 20122012-08-08
Perhaps I'm too engrossed in some of the mythology regarding the MSP430
origins, but my understanding was that it was designed by Ti's analog
group in Germany, primarily to meet a need for new ex eastern european
nations, now moving into the EEC, to meter energy usage, which had
previously been free. If that is really the case then could they have
been expected to be well versed in instruction set design, or to really
care?
At this time Ti were very DSPcentric, within Ti DSP was king,at times it
seemed that Ti corporate in the US actually hated the poor little MSP430
when it first came out, certainly they made no real effort to support it
until well after it had taken off and gained popularity with a sizable
group of engineers. yes it isn't pretty, but at the time I liked it a
lot better than Microchip, AVR, Motorola and 80xx stuff, and still
mostly do.
Al
On 9/08/2012 4:23 AM, Jon Kirwan wrote:
> On Wed, 8 Aug 2012 11:23:24 -0700 (PDT), you wrote:
>
>> FWIW The SPARC architecture has a single large set of
>> registers and keeps a pointer to the subset of registers
>> that are currently accessible. The idea being to preserve a
>> portion of the register set by simply shifting the window
>> pointer.
>>
>> If more need to be saved then the normal manner of saving
>> registers is used for those. I always thought it was a
>> rather elegant solution.
> Just about anyone could have improved the MSP430 instruction
> design with a day's thought and a short list of mistakes to
> solve. (There are several.) No need for such a sweeping
> change. But your point is also worth taking, too.
>
> Jon
>
origins, but my understanding was that it was designed by Ti's analog
group in Germany, primarily to meet a need for new ex eastern european
nations, now moving into the EEC, to meter energy usage, which had
previously been free. If that is really the case then could they have
been expected to be well versed in instruction set design, or to really
care?
At this time Ti were very DSPcentric, within Ti DSP was king,at times it
seemed that Ti corporate in the US actually hated the poor little MSP430
when it first came out, certainly they made no real effort to support it
until well after it had taken off and gained popularity with a sizable
group of engineers. yes it isn't pretty, but at the time I liked it a
lot better than Microchip, AVR, Motorola and 80xx stuff, and still
mostly do.
Al
On 9/08/2012 4:23 AM, Jon Kirwan wrote:
> On Wed, 8 Aug 2012 11:23:24 -0700 (PDT), you wrote:
>
>> FWIW The SPARC architecture has a single large set of
>> registers and keeps a pointer to the subset of registers
>> that are currently accessible. The idea being to preserve a
>> portion of the register set by simply shifting the window
>> pointer.
>>
>> If more need to be saved then the normal manner of saving
>> registers is used for those. I always thought it was a
>> rather elegant solution.
> Just about anyone could have improved the MSP430 instruction
> design with a day's thought and a short list of mistakes to
> solve. (There are several.) No need for such a sweeping
> change. But your point is also worth taking, too.
>
> Jon
>
Reply by ●August 8, 20122012-08-08
--- In m..., David Feldman wrote:
> (re-posting to fix minor typos)
>
> I am doing some programmed bit-serial I/O using MSP430 assembly language and would like to improve execution speed. My target device is MSP430G2553.
>
> My code includes a number of source lines all very similar (but obviously not identical) to this:
>
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
>
> As CPU cycles are very valuable ...
I think your "original code" has the same effect as:
bis.b #4, &P2OUT ; one
nop
nop
nop
nop ; two
nop
nop
nop
nop ; three
nop
nop
nop
nop ; four
Thus you can eliminate some or all of the "nop" above to save CPU cycles.
> (re-posting to fix minor typos)
>
> I am doing some programmed bit-serial I/O using MSP430 assembly language and would like to improve execution speed. My target device is MSP430G2553.
>
> My code includes a number of source lines all very similar (but obviously not identical) to this:
>
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
>
> As CPU cycles are very valuable ...
I think your "original code" has the same effect as:
bis.b #4, &P2OUT ; one
nop
nop
nop
nop ; two
nop
nop
nop
nop ; three
nop
nop
nop
nop ; four
Thus you can eliminate some or all of the "nop" above to save CPU cycles.
Reply by ●August 9, 20122012-08-09
On Thu, 09 Aug 2012 05:50:48 +0930, you wrote:
>Perhaps I'm too engrossed in some of the mythology regarding the MSP430
>origins, but my understanding was that it was designed by Ti's analog
>group in Germany, primarily to meet a need for new ex eastern european
>nations, now moving into the EEC, to meter energy usage, which had
>previously been free. If that is really the case then could they have
>been expected to be well versed in instruction set design, or to really
>care?
I don't think that pure analog designers decided to suddenly
become instruction set designers and wear all hats in this
design, for several reasons. But I would guess they didn't
look too hard when finding someone to do that task. Perhaps
you are right -- they didn't care.
Still, when taking this to a general embedded engineering
public there remains no real excuse in not cleaning this up.
They had already done all the hard work on low power and it
would decidedly NOT have been a yeoman's work to tidy things
up a bit. I've done a complete CPU design before (not low
power of course about which I greatly respect the talent
involved), built and tested it, and looking over what went
wrong here it would not have been a difficult challenge, nor
expensive (in a cash sense.)
>At this time Ti were very DSPcentric, within Ti DSP was king,
Their 320C30 and 320C40 were terrible in their day. Used
them, didn't like the parts. And I really disliked the fact
that TI could NOT figure out, after many weeks of
consultations with "their supposed best team at corporate" on
the phone, by email, and otherwise, could not explain why
their parts didn't do what their documentation said they
would do and had no noticeably interest in actually caring,
either. They actually just said that they didn't know why,
agreed it was a mystery, and spent NO MORE TIME on it once
they admitted the problem. They didn't even change the docs
to let others know what I found. And it was important.
By comparison, Analog Devices were saints. When I uncovered a
CPU bug in their ADSP2111 chip, they worked VERY HARD and
showed great concern. They asked me for my test code, used
it, and tracked the problem down to their FAB. They changed
FABs for the parts and it fixed the problems and I had good
parts coming in about 6 months later. And given that they
changed FABs, and given my experience IN a FAB, I know they
had to work their ass off to do that.
TI doesn't fix things, doesn't care to. But they do make a
lot of good stuff, just the same. So it's a mixed bag. If I
use their parts and they test out okay, then I'm fine. If I
use their parts and they don't test out okay, I waste little
time going elsewhere. I'll write a note and send it on. But I
won't hold my breath. I just go find something else.
A problem is in investment of personal time and in cash
related to all the tools one buys. This is time and money.
Microchip has $500 tools. They add up. But I also know that I
get support, too. Both for their chips (which they fix if I
run into a serious problem, and they have on several
occasions so I am not talking through my hat -- I've had a
silicon fix in my hands in about 2 months from them) and
their tool support, which they support long after they no
longer sell them anymore. In fact, they still support the
oldest tool I own of theirs and it is more than 20 years old.
On the other hand, I love the MSP430's hardware, those parts
of it I've used a lot anyway. Who can beat a B7 timer unit?
Or the incredible clocking systems? And the price is
certainly right for someone wanting to get started with them.
>at times it
>seemed that Ti corporate in the US actually hated the poor little MSP430
>when it first came out, certainly they made no real effort to support it
>until well after it had taken off and gained popularity with a sizable
>group of engineers. yes it isn't pretty, but at the time I liked it a
>lot better than Microchip, AVR, Motorola and 80xx stuff, and still
>mostly do.
Well, that may explain a lot. It's success was perhaps a
pleasant, but unexpected surprise.
Jon
>Perhaps I'm too engrossed in some of the mythology regarding the MSP430
>origins, but my understanding was that it was designed by Ti's analog
>group in Germany, primarily to meet a need for new ex eastern european
>nations, now moving into the EEC, to meter energy usage, which had
>previously been free. If that is really the case then could they have
>been expected to be well versed in instruction set design, or to really
>care?
I don't think that pure analog designers decided to suddenly
become instruction set designers and wear all hats in this
design, for several reasons. But I would guess they didn't
look too hard when finding someone to do that task. Perhaps
you are right -- they didn't care.
Still, when taking this to a general embedded engineering
public there remains no real excuse in not cleaning this up.
They had already done all the hard work on low power and it
would decidedly NOT have been a yeoman's work to tidy things
up a bit. I've done a complete CPU design before (not low
power of course about which I greatly respect the talent
involved), built and tested it, and looking over what went
wrong here it would not have been a difficult challenge, nor
expensive (in a cash sense.)
>At this time Ti were very DSPcentric, within Ti DSP was king,
Their 320C30 and 320C40 were terrible in their day. Used
them, didn't like the parts. And I really disliked the fact
that TI could NOT figure out, after many weeks of
consultations with "their supposed best team at corporate" on
the phone, by email, and otherwise, could not explain why
their parts didn't do what their documentation said they
would do and had no noticeably interest in actually caring,
either. They actually just said that they didn't know why,
agreed it was a mystery, and spent NO MORE TIME on it once
they admitted the problem. They didn't even change the docs
to let others know what I found. And it was important.
By comparison, Analog Devices were saints. When I uncovered a
CPU bug in their ADSP2111 chip, they worked VERY HARD and
showed great concern. They asked me for my test code, used
it, and tracked the problem down to their FAB. They changed
FABs for the parts and it fixed the problems and I had good
parts coming in about 6 months later. And given that they
changed FABs, and given my experience IN a FAB, I know they
had to work their ass off to do that.
TI doesn't fix things, doesn't care to. But they do make a
lot of good stuff, just the same. So it's a mixed bag. If I
use their parts and they test out okay, then I'm fine. If I
use their parts and they don't test out okay, I waste little
time going elsewhere. I'll write a note and send it on. But I
won't hold my breath. I just go find something else.
A problem is in investment of personal time and in cash
related to all the tools one buys. This is time and money.
Microchip has $500 tools. They add up. But I also know that I
get support, too. Both for their chips (which they fix if I
run into a serious problem, and they have on several
occasions so I am not talking through my hat -- I've had a
silicon fix in my hands in about 2 months from them) and
their tool support, which they support long after they no
longer sell them anymore. In fact, they still support the
oldest tool I own of theirs and it is more than 20 years old.
On the other hand, I love the MSP430's hardware, those parts
of it I've used a lot anyway. Who can beat a B7 timer unit?
Or the incredible clocking systems? And the price is
certainly right for someone wanting to get started with them.
>at times it
>seemed that Ti corporate in the US actually hated the poor little MSP430
>when it first came out, certainly they made no real effort to support it
>until well after it had taken off and gained popularity with a sizable
>group of engineers. yes it isn't pretty, but at the time I liked it a
>lot better than Microchip, AVR, Motorola and 80xx stuff, and still
>mostly do.
Well, that may explain a lot. It's success was perhaps a
pleasant, but unexpected surprise.
Jon
