I agree with you on the DSP front. I hate Ti DSP's, I've tried several,
from the early 320C30, through the 24xx parts, and several of the newer
parts. And to may they simply don't compare to the old ADSP21xx parts. I
once crammed a 2400bps codec into a 2105 and even had a little room to
spare. And algebraic programming for DSP functions seems a no brainer.
The only thing I wasn't a big fan of was the complex header files
(compared to some other DSP's). Of course it sucked current like a
toothless parrot, but it was still a great machine I felt. I was a huge
fan of Microchip for many years, from the pre-microchip era, when I used
lots of little PICs as individual axis controllers for a FAB robot,
until the mid to late 90's when I was caught by 2 year delays in the
release of some parts, and ended up switching to the MSP after trying
AVR and a couple of others.

As you say the timers are one of the best peripherals around, and
compared to Microchip and AVR there is never a shortage of them on most
parts. The clock system has varied heaps over the years, but mostly has
become better each time, even the comm peripherals, though not truly
spectacular, are simple and quite powerful. I am able to get excellent
communication at 460800baud, for example, just using the pre-calibrated
DCO at 16MHz with a regulated voltage and across a decent temperature
range. More importantly it takes very few lines of code to implement
either a UART or an SPI control. Perhaps the worst peripheral though is
the DMA, since it isn't a 'true' independent module, but steals CPU
cycles. There are times when using the DMA is actually slower than
running your own code.

Al

On 9/08/2012 3:32 PM, Jon Kirwan wrote:
> 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
>

Beginning Microcontrollers with the MSP430

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

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

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
>

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

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

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

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

> 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

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