TI MSP430

SMS wrote:
> 
> 
> The coupon expires on April 15th, so hurrry.


Thanks, got it done.

donald

In article <443bce7c$0$1520$742ec2ed@news.sonic.net>, 
scharf.steven@geemail.com says...
> Jonathan Kirwan wrote:
> > On Tue, 11 Apr 2006 22:54:01 +1000, Clifford Heath
> > <no@spam.please.net> wrote:
> > 
> >> SMS wrote:
> >>> You can buy the development tool (USB 
> >>> stick) for 1/2 price ($10), with the coupon code MS681LXD.
> >> Ok, I give up. Where do I enter the coupon code?
> >> ti-estore is happy to let me order at $20, but $10?
> > 
> > (1) Go to: http://www.ti.com/ez430
> > (2) Click on: "Order Now!", right side of screen.
> > (3) Click on: "Add to basket" after entering a quantity.
> > (4) Click on: "Checkout" near top.
> > (5) You will be asked to log on -- do so.
> > (6) Fill out address, if it isn't already, on the 'ship to' page.
> > (7) Click on "continue"
> > 
> > You will be then taken to the page which offers a "COUPON" field near
> > the bottom on the left side and just above the two fields called "SHIP
> > VIA" and "PAY WITH".   There is also a button called "REDEEM COUPON"
> > adjacent and just to the right of the field where you can enter the
> > coupon code.
> 
> The coupon expires on April 15th, so hurry.

..but be aware that it's severely backordered.
I placed my order (full price) on 25-February; I'm still waiting...

--Gene

Gene S. Berkowitz wrote:
...

>>The coupon expires on April 15th, so hurry.
> 
> 
> ..but be aware that it's severely backordered.
> I placed my order (full price) on 25-February; I'm still waiting...
> 
Well, they just told me in the verification email that it was to be 
shipped at the end of April.

Here's hoping...

John Perry

John Perry <jp@no.spam> writes:
> Well, they just told me in the verification email that it was to be
> shipped at the end of April.

Did they say *which* April?

DJ Delorie wrote:
> John Perry <jp@no.spam> writes:
> 
>>Well, they just told me in the verification email that it was to be
>>shipped at the end of April.
> 
> 
> Did they say *which* April?

:-)

jp

On Tue, 11 Apr 2006 21:39:27 -0400, Gene S. Berkowitz
<first.last@comcast.net> wrote:

>> The coupon expires on April 15th, so hurry.
>
>..but be aware that it's severely backordered.
>I placed my order (full price) on 25-February; I'm still waiting...

I ordered some in mid-February, as well.  Received the two on March
13th.  I've got a _bunch_ more on order, though.  Just placed last
week.  We'll see.

Jon

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:443cbcd8@news.wineasy.se...
> Jonathan Kirwan wrote:
>> On 10 Apr 2006 09:13:11 +0100, David Brown
>> <david@westcontrol.removethisbit.com> wrote:
>>
>>> Jonathan Kirwan wrote:
>>>> On Sun, 09 Apr 2006 00:16:04 GMT, Marc Ramsey <marc@ranlog.comREMOVE>
>>>> wrote:
>>>>
>>>>> larwe wrote:
>>>>>> MSP430 is a truly elegant architecture, there's no denying it. von
>>>>>> Neumann simplicity, totally transparent handling of registers and
>>>>>> addressing modes; I really can't find much to fault with it (except
>>>>>> maybe the way info memory is handled). But:
>>>>> Of course, the architecture is a simplified version of the TMS9900 CPU, which 
>>>>> was derived from the TI 990 minicomputer, which was in turn a rip-off of the 
>>>>> PDP-11 ISA, with slight changes (fewer addressing modes, allowing twice as many 
>>>>> registers) to avoid patent issues...
>>>> I have a few comments about a pdp-11 comparison at:
>>>>
>>>>   http://users.easystreet.com/jkirwan/new/msp430.html
>>>>
>>>> Jon
>>> Your comments are (as far as I can tell) factually correct, but the reaction that 
>>> springs to mind is "so what?".
>>
>> hehe.  No problem.
>>
>>> As an embedded programmer, I really do not care how a particular embedded micro 
>>> compares to an old minicomputer cpu (other than for historic interest, of course - 
>>> in which case it definitely is interesting).  And as for possibly misleading 
>>> marketing from TI - it's not exactly new or unusual!
>>
>> I did point that out but that wasn't the point, which it appears I
>> didn't communicate well enough on the page.  My fault.
>>
>>> What is much more relevant is whether the register set and addressing modes of the 
>>> msp430 really are appropriate for their target applications, or whether they would 
>>> have been better off with the PDP-11 arrangement.  I'm far from convinced - 
>>> certainly, the example you gave (PC-relative CALL) is obscure indeed, and I think 
>>> the benefit of more registers well outweighs this missing feature.
>>
>> I completely disagree.  There is no question in my mind that the price
>> paid was too high -- for embedded applications, I mean.
>>
>>> One thing that is definitely missed, however, is all four addressing modes as the 
>>> destination for two-operand instructions.  At the very least, there should have 
>>> been a hack in the MOV instruction to allow @Rn and @Rn+ modes in the destination.
>>
>> The destination side is terrible.  And it leads to expanded code size
>> as well as slower execution on normal and common tasks.  I've looked
>> at weighing various algorithms (I write a LOT of assembly code, in my
>> practice) which I've hand-written both for the existing MSP-430 as
>> well as a hypothetical MSP-430 which was closer in instruction design
>> to the PDP-11 and it's almost always the case that the PDP-11
>> arrangement pays off in spades.
>>
>> They made the wrong choice.  IMHO, of course.
>>
>>> As for the missing PDP-11 addressing modes, they are not such a great loss.  The 
>>> indirect modes are almost entirely superfluous when you have enough registers to 
>>> hold pointers in registers, rather than having to have them in memory or on the 
>>> stack.  It's not often that pointers to pointers turn up, at least not in embedded 
>>> programming.  Auto-decrement modes are nice, but how often are they used in 
>>> practice?  *(p++) far outweighs *(--p), as long as you have a stack pointer and 
>>> push/pop instructions.  Perhaps it would be a useful mode for MOV, but not 
>>> otherwise.
>>>
>>> So if you want to say that the msp430 is not as close to the PDP-11 as TI 
>>> marketing seems to think, then I fully agree.  But if you think that's a bad 
>>> thing, then I disagree.
>>
>> Well, I use the MSP-430 and like it.  It's just sad to see how badly
>> an early choice demolished what might have been.  Especially, because
>> it wouldn't have required the invention of anything new at all and
>> also because there is ample code experience which, in my opinion,
>> argues very well against this choice.  The additional advantages of
>> having extra registers is more than offset by the damage caused by
>> loss of addressing modes.  The reduction in memory spills doesn't pay
>> for itself.
>>
>> Jon
>
> I agree entirely on the issue of the destination addressing modes (especially for 
> MOV - it's not nearly as important for other instructions).  As for the other 
> differences, I'm not convinced (although the fact that *you* are convinced is an 
> influence).  I'd have to look at it in a lot more detail some time.
>
> The trouble is, 16 bits is not quite enough to make a good instruction set, at least 
> not with 16 registers.  With 18 bits, you could get the best of both worlds.  Of 
> course, that leads to complications during program updates, and could cause 
> marketing folks to lose their tenuous grip on reality (like Microchip's "14-bit 
> microcontroller").


The PIC is a completely different creature. Its Harvard architecture makes the choice 
of an arbitrary instruction width (12/14/16 bits) on an 8 bit micro possible and quite 
normal.

The PIC gets a lot of heat in these arguments but it is effective, simple, tough, 
inexpensive, well represented, consistent in supply and widely available, making it a 
very good choice for embedded systems. Yes, coding it can be ugly, but it is extremely 
successful and popular due to the above points. The later PIC18Fxxxx devices code 
quite well.

I have yet to hear a PIC designer say "it took me longer because of the architecture". 
Just never happens.
Other issues have far greater influence on design success than architecture in most 
cases.


-Andrew M 

Jonathan Kirwan wrote:
> On 10 Apr 2006 09:13:11 +0100, David Brown
> <david@westcontrol.removethisbit.com> wrote:
> 
>> Jonathan Kirwan wrote:
>>> On Sun, 09 Apr 2006 00:16:04 GMT, Marc Ramsey <marc@ranlog.comREMOVE>
>>> wrote:
>>>
>>>> larwe wrote:
>>>>> MSP430 is a truly elegant architecture, there's no denying it. von
>>>>> Neumann simplicity, totally transparent handling of registers and
>>>>> addressing modes; I really can't find much to fault with it (except
>>>>> maybe the way info memory is handled). But:
>>>> Of course, the architecture is a simplified version of the TMS9900 CPU, 
>>>> which was derived from the TI 990 minicomputer, which was in turn a 
>>>> rip-off of the PDP-11 ISA, with slight changes (fewer addressing modes, 
>>>> allowing twice as many registers) to avoid patent issues...
>>> I have a few comments about a pdp-11 comparison at:
>>>
>>>   http://users.easystreet.com/jkirwan/new/msp430.html
>>>
>>> Jon
>> Your comments are (as far as I can tell) factually correct, but the 
>> reaction that springs to mind is "so what?".
> 
> hehe.  No problem.
> 
>> As an embedded programmer, 
>> I really do not care how a particular embedded micro compares to an old 
>> minicomputer cpu (other than for historic interest, of course - in which 
>> case it definitely is interesting).  And as for possibly misleading 
>> marketing from TI - it's not exactly new or unusual!
> 
> I did point that out but that wasn't the point, which it appears I
> didn't communicate well enough on the page.  My fault.
> 
>> What is much more relevant is whether the register set and addressing 
>> modes of the msp430 really are appropriate for their target 
>> applications, or whether they would have been better off with the PDP-11 
>> arrangement.  I'm far from convinced - certainly, the example you gave 
>> (PC-relative CALL) is obscure indeed, and I think the benefit of more 
>> registers well outweighs this missing feature.
> 
> I completely disagree.  There is no question in my mind that the price
> paid was too high -- for embedded applications, I mean.
> 
>> One thing that is definitely missed, however, is all four addressing 
>> modes as the destination for two-operand instructions.  At the very 
>> least, there should have been a hack in the MOV instruction to allow @Rn 
>> and @Rn+ modes in the destination.
> 
> The destination side is terrible.  And it leads to expanded code size
> as well as slower execution on normal and common tasks.  I've looked
> at weighing various algorithms (I write a LOT of assembly code, in my
> practice) which I've hand-written both for the existing MSP-430 as
> well as a hypothetical MSP-430 which was closer in instruction design
> to the PDP-11 and it's almost always the case that the PDP-11
> arrangement pays off in spades.
> 
> They made the wrong choice.  IMHO, of course.
> 
>> As for the missing PDP-11 addressing modes, they are not such a great 
>> loss.  The indirect modes are almost entirely superfluous when you have 
>> enough registers to hold pointers in registers, rather than having to 
>> have them in memory or on the stack.  It's not often that pointers to 
>> pointers turn up, at least not in embedded programming.  Auto-decrement 
>> modes are nice, but how often are they used in practice?  *(p++) far 
>> outweighs *(--p), as long as you have a stack pointer and push/pop 
>> instructions.  Perhaps it would be a useful mode for MOV, but not otherwise.
>>
>> So if you want to say that the msp430 is not as close to the PDP-11 as 
>> TI marketing seems to think, then I fully agree.  But if you think 
>> that's a bad thing, then I disagree.
> 
> Well, I use the MSP-430 and like it.  It's just sad to see how badly
> an early choice demolished what might have been.  Especially, because
> it wouldn't have required the invention of anything new at all and
> also because there is ample code experience which, in my opinion,
> argues very well against this choice.  The additional advantages of
> having extra registers is more than offset by the damage caused by
> loss of addressing modes.  The reduction in memory spills doesn't pay
> for itself.
> 
> Jon

I agree entirely on the issue of the destination addressing modes 
(especially for MOV - it's not nearly as important for other 
instructions).  As for the other differences, I'm not convinced 
(although the fact that *you* are convinced is an influence).  I'd have 
to look at it in a lot more detail some time.

The trouble is, 16 bits is not quite enough to make a good instruction 
set, at least not with 16 registers.  With 18 bits, you could get the 
best of both worlds.  Of course, that leads to complications during 
program updates, and could cause marketing folks to lose their tenuous 
grip on reality (like Microchip's "14-bit microcontroller").

David Brown wrote:
> The trouble is, 16 bits is not quite enough to make a good instruction 
> set, at least not with 16 registers.  With 18 bits, you could get the 
> best of both worlds.  Of course, that leads to complications during 
> program updates, 

Why ? - there are 18 bit opcode (soft) uC now, see the
PicoBlaze/PacoBlaze and Mico8.
There is also a Flash uC with 22 bit opcodes.

> and could cause marketing folks to lose their tenuous 
> grip on reality (like Microchip's "14-bit microcontroller").

:)

-jg

Jim Granville wrote:
> David Brown wrote:
>> The trouble is, 16 bits is not quite enough to make a good instruction 
>> set, at least not with 16 registers.  With 18 bits, you could get the 
>> best of both worlds.  Of course, that leads to complications during 
>> program updates, 
> 
> Why ? - there are 18 bit opcode (soft) uC now, see the
> PicoBlaze/PacoBlaze and Mico8.

18-bit opcodes are particularly well suited to soft processors, since 
FPGA ram banks come in widths of 9 rather than 8.  So for a Harvard 
architecture soft cpu, 18 bit wide opcodes are an obvious choice (unless 
you are going for a full 32-bit cpu).  But if you want an architecture 
which can execute code from normal data ram, or which can easily update 
its own software, you are going to get complications mixing 18-bit code 
images with 16-bit data transfers (unless, of course, your data path is 
18 bits).  It is by no means impossible, but it's more complicated.

> There is also a Flash uC with 22 bit opcodes.
> 
>> and could cause marketing folks to lose their tenuous grip on reality 
>> (like Microchip's "14-bit microcontroller").
> 
> :)
> 
> -jg
>