Actually I will think these are more like PIC16F, actually lower spec
than many PIC16F, not even PIC18F.
Even though MSP430 is a 16bit MCU, but in terms of performance,
I always consider it to be similar to 8-bit MCUs like PIC18F and
AVR. Compared to other popular 16bit MCUs like those from
Infineon and Renesas, or PIC24, MSP430 is a bit weak on
the performance side. TI does not have real 8-bit offerings
(other than some specific 8051 variants), so it is using
MSP430 to compete with the 8-bit MCUs. MSP430X may
have better performance.
It does excel in the low power side, even though now vendors
like Atmel and Microchip are also catching up.
On Wed, Mar 3, 2010 at 5:48 PM, Xiaofan Chen <xiaofancKILLspamgmail.com> wrote:
> On Wed, Mar 3, 2010 at 1:45 AM, Mark Rages <.....markragesKILLspam.....gmail.com> wrote:
>> MSP430s, three for a dollar:
>>
>> www.ti.com/ww/en/mcu/valueline/index.shtml?DCMP=Value_Line
>>
>
> Actually I will think these are more like PIC16F, actually lower spec
> than many PIC16F, not even PIC18F.
>
> Even though MSP430 is a 16bit MCU, but in terms of performance,
> I always consider it to be similar to 8-bit MCUs like PIC18F and
> AVR. Compared to other popular 16bit MCUs like those from
> Infineon and Renesas, or PIC24, MSP430 is a bit weak on
> the performance side. TI does not have real 8-bit offerings
> (other than some specific 8051 variants), so it is using
> MSP430 to compete with the 8-bit MCUs. MSP430X may
> have better performance.
How are you quantifying performance here?
I've been using msp430 for a couple years and I like programming them
better than PIC. I've not run into any performance limitations. I
have been using the regular msp430s, though, not these cheap ones with
all the peripherals removed.
I like the architecture. Von Neumann and no banking to deal with, can
execute from RAM. Each pin has its own weak pullup resistor which can
pull up or down. ADC inputs are individually selectable. Clock speed
goes to 25MHz.
On Thu, Mar 4, 2010 at 8:08 AM, Mark Rages <markragesspam_OUTgmail.com> wrote:
> How are you quantifying performance here?
I was comparing the performance with the other leading 16bit
lines.
> I've been using msp430 for a couple years and I like programming them
> better than PIC. I've not run into any performance limitations.
Yes I believe that. It all depends on the applications.
> I have been using the regular msp430s, though, not these cheap ones with
> all the peripherals removed.
The value line is quite low end, even compared to PIC16F.
> I like the architecture.
Yes that is one of the main appeal of MSP430. MSPGCC is
another good thing. But it is not that well integrated to the
main line GCC, not as good as ARM or AVR, still at gcc 3.2.x.
The USB JTAG support under Linux of the various TI USB debuggers
is also troublesome from time to time (but it seems to be better now).
> Von Neumann and no banking to deal with, can
> execute from RAM. Each pin has its own weak pullup resistor which can
> pull up or down. ADC inputs are individually selectable. Clock speed
> goes to 25MHz.
25MIPS is similar to the 8-bit lines like AVR or the Silicon Labs 8051.
But it is not good as PIC24J and Infineon and Renesas 16 bit MCUs.
MSP430 is also lack in certain peripherals, like Ethernet and USB (ok, the
first USB MSP430 comes out) or CAN.
That being said, it is a nice MCU family. I even considered to use it
for a project once, only to find out poor documentation about the
16bit Sigma-Delta ADC and the true performance of the 16bit
Sigma-Delta is actually quite poor. TI admitted the document
deficiency at that time.
On Wed, Mar 3, 2010 at 7:22 PM, Xiaofan Chen <@spam@xiaofancKILLspamgmail.com> wrote:
> That being said, it is a nice MCU family. I even considered to use it
> for a project once, only to find out poor documentation about the
> 16bit Sigma-Delta ADC and the true performance of the 16bit
> Sigma-Delta is actually quite poor. TI admitted the document
> deficiency at that time.
I am actually looking at the SD16 ADC for a project right now. What
performance problem did you have with it? Maybe I should plan to use
an external ADC.
The problem with the TI's USB programmer / debugger is the usb->serial
chip they use, the tusb3410. This turkey needs a lot of external
parts and it needs firmware downloaded to its 8051 microprocessor. It
seems like Ubuntu manages to screw up the firmware download in a new
way with every new release. Some hobbyists have produced a clone of
the debugger using the superior FTDI usb->serial chip. (Google for
"goodFET"). Now that there are MSP430s with integrated USB, maybe TI
will migrate their PICkit-like ez430 to a single-chip design.
A problem with the MSP430 is a general supply shortage right now. It
doesn't seem like a good time to introduce a high-volume, low-cost
version when they have difficulty keeping up with the supply now. Or
maybe MSPs without analog peripherals can be produced at a different
fab.
There is a GCC4 port of the mspgcc toolchain at http://mspgcc4.sourceforge.net/. Development of mspgcc is rather
fragmented. From reading the generated code, I would say that mspgcc
does a better job then SDCC does for PICs.
On Thu, Mar 4, 2010 at 1:08 PM, Mark Rages <RemoveMEmarkragesTakeThisOuTgmail.com> wrote:
>> That being said, it is a nice MCU family. I even considered to use it
>> for a project once, only to find out poor documentation about the
>> 16bit Sigma-Delta ADC and the true performance of the 16bit
>> Sigma-Delta is actually quite poor. TI admitted the document
>> deficiency at that time.
>
> I am actually looking at the SD16 ADC for a project right now. =A0What
> performance problem did you have with it? =A0Maybe I should plan to use
> an external ADC.
I was looking at the SD16 unit inside the small F2013 parts. The
speed is a bit slow, the effective bits are even worse at the
speed we want. So we used an external ADC instead.
Our requirement was on the high side (1200Hz conversion
rate with true 12bit RMS, 600Hz with true 16bit RMS),
so we were only looking at F2013 very briefly and decided it is
not good enough. Actually none of the integrated ADC would
fulfill our requirements (there are other requirements as well),
not even the ADI uConverter or TI precision MCU or Silicon
Labs MCU.
At the time the literature (SLAU144B) for the SD-16 was
horribly wrong. It seems they corrected the literature in
SLAU144E version.
You can compared the formula I got in SLAU144B
and the new version.
On Thu, Mar 4, 2010 at 1:08 PM, Mark Rages <spamBeGonemarkragesspamBeGonegmail.com> wrote:
> The problem with the TI's USB programmer / debugger is the usb->serial
> chip they use, the tusb3410.
I have a TI ADC evaluation board (with the MMB3 base board and various
ADC/DAC daughter boards) in front of me which is also using
the TUSB3410 together with a MSP430F449.
> A problem with the MSP430 is a general supply shortage right now. It
> doesn't seem like a good time to introduce a high-volume, low-cost
> version when they have difficulty keeping up with the supply now. Or
> maybe MSPs without analog peripherals can be produced at a different
> fab.
TI seems to suffer the supply shortages right now. So companies
like ADI is promoting their parts to replace TI parts. Even Microchip
is looking at replacing certain TI parts due to supply shortage issues
with TI.
But nowadays, a lot of vendors are having delivery issues. I
do not think the economy is really getting that good. But the
delivery issues are really there.
> There is a GCC4 port of the mspgcc toolchain at
> http://mspgcc4.sourceforge.net/. Development of mspgcc is rather
> fragmented. From reading the generated code, I would say that mspgcc
> does a better job then SDCC does for PICs.
GCC for MSP430 is of course better than SDCC for PIC. ;-)
It would be good that MSPGCC is integrated into the main
gcc line. But I think that would not happen for a while.
I see that Freescale is also advertising new sub-$1 parts based on the
RS08 core.
www.freescale.com/webapp/sps/site/prod_summary.jsp?code=RS08KB&tid=FSHMINI_20100302
(RS08-based parts replaced the Atmel tiny11 as the cheapest uC when
the tiny11 was discontinued.)
I think that at the moment, the robust 8bit uCs still beat
theoretically cheaper 32bit CPUs when you total up systems cost. That
the ARM has 32kB of memory is pretty immaterial if your code only
takes 512 bytes, while the 20mA pin drive might be more useful.
("It's all about the blinky lights!")
An interesting question from a business perspective is whether PICs
are more expensive because they cost Microchip more to produce, or
just because microchip CAN charge more. It can be hard to track PIC
prices per functionality; older chips don't disappear the way they do
from other vendors; they just stop getting cheaper while newer chips
with better functionality are introduced at a lower price. (most
recently the "enhanced midrange" chips, I think. PIC16F1xxx) And who
knows how much PICs really sell for in large volumes (when things
become "negotiable.") It can be a good position to be in, to not have
to advertise very low prices just to attract customers.
(Atmel, Freescale, and NXP both frequently appear on lists of
companies in questionable financial shape. No so Microchip.)
> An interesting question from a business perspective is whether PICs
> are more expensive because they cost Microchip more to produce, or
> just because microchip CAN charge more.
It is mostly because that they cost Microchip to produce due to
the older process nodes they are in (older PIC16F and PIC18F).
Microchip can not charge more than ST and TI anyway. It
can probably be able to charge more than Atmel and has to
charge more than Atmel.
> It can be hard to track PIC
> prices per functionality; older chips don't disappear the way they do
> from other vendors; they just stop getting cheaper while newer chips
> with better functionality are introduced at a lower price. (most
> recently the "enhanced midrange" chips, I think. PIC16F1xxx)
Enhanced PIC16F1xxx only appeals to existing PIC16F customers.
Similarly, PIC32 seems to only appeals existing PIC customers
as far as I know.
Existing PIC customers will be still be using PICs. But I do not
see many other customers who use ARMs to switch to PIC24/PIC32.
At least that is what I get from talking to some other guys,
including Microchip guys.
> And who knows how much PICs really sell for in large volumes (when things
> become "negotiable.") It can be a good position to be in, to not have
> to advertise very low prices just to attract customers.
> (Atmel, Freescale, and NXP both frequently appear on lists of
> companies in questionable financial shape. No so Microchip.)
>
But now we are talking about other big guys like TI and ST who
are in the picture as well. They are much more stronger in terms
of finance position than Atmel/Freescale/NXP/Renesas-NEC.
I am not saying that Microchip MCUs will soon lost its position
as No 1 in 8-bit or doing quite badly soon. It is still a good
company to work with due to its good support. But I believe
that Microchip will have to enhanced the PIC24/PIC32/PIC18
line and lower the cost in order to compete in the near
future. I do not see the advantages to use any PIC18/PIC24/PIC32
right now compared to 32bit ARM Cortex M3 MCUs.
Buying SST may be a good first step. I am not sure if they
want to bite the bullet and license ARM Cortex cores
(or buy another MCU companies with ARM cores).
It may happen, who knows.
> Existing PIC customers will be still be using PICs. But I do not
> see many other customers who use ARMs to switch to PIC24/PIC32.
> At least that is what I get from talking to some other guys,
> including Microchip guys.
Microchip owns its IP which is a big advantage over ARM based
licensed IP. In volume applications Microchip would have a
significant advantage.
When the volumes are high enough price will dominate the
choices made by customers.
>> Existing PIC customers will be still be using PICs. But I do not
>> see many other customers who use ARMs to switch to PIC24/PIC32.
>> At least that is what I get from talking to some other guys,
>> including Microchip guys.
>
> Microchip owns its IP which is a big advantage over ARM based
> licensed IP. In volume applications Microchip would have a
> significant advantage.
IP is only a part of the equation. The other big part is
the wafer fab. As far as I know, Microchip's fabs are not
that advanced in terms of the process capability.
> When the volumes are high enough price will dominate the
> choices made by customers.
That is right. And the reality is that Microchip does not
compete well with the low price parts from folks like
TI/ST/NXP/Atmel in terms of 32bit MCUs.
> On Thu, Mar 4, 2010 at 8:38 PM, Walter Banks <EraseMEwalterbytecraft.com> wrote:
>
>>> Existing PIC customers will be still be using PICs. But I do not
>>> see many other customers who use ARMs to switch to PIC24/PIC32.
>>> At least that is what I get from talking to some other guys,
>>> including Microchip guys.
>>
>> Microchip owns its IP which is a big advantage over ARM based
>> licensed IP. In volume applications Microchip would have a
>> significant advantage.
>
> IP is only a part of the equation. The other big part is
> the wafer fab. As far as I know, Microchip's fabs are not
> that advanced in terms of the process capability.
>
>> When the volumes are high enough price will dominate the
>> choices made by customers.
>
> That is right. And the reality is that Microchip does not
> compete well with the low price parts from folks like
> TI/ST/NXP/Atmel in terms of 32bit MCUs.
>
And for 32bit PIC32, MIPS owns big trunk of the IP.
And even C30 libraries are largely copyright by MIPS.
>Xiaofan Chen wrote:
>
> > Existing PIC customers will be still be using PICs. But I do not
> > see many other customers who use ARMs to switch to PIC24/PIC32.
> > At least that is what I get from talking to some other guys,
> > including Microchip guys.
>
>Microchip owns its IP which is a big advantage over ARM based
>licensed IP. In volume applications Microchip would have a
>significant advantage.
'Could' have a significant advantage. The design work and documentation has
to be paid for somehow, and the ARM work is spread over a number of customers,
including foundries.
It's not clear to me that the ARM business model is any less or more
competitive in high volumes. Certainly their current volumes would appear to
be comparable to those from Microchip, with 5+ bn shipped, and 5 billion
units per year forecast for 2011. Most likely the ASP would be considerably
higher for the ARMs, at least for now.
>When the volumes are high enough price will dominate the
>choices made by customers.
I'm a bit intrigued by the initiative from some mfrs to supply ROM'd
code such as USB stacks and FAT file systems along with the device so
code stored in user flash only has to do API calls. If ROM takes up
significantly less silicon real estate (multi-level?) than an equivalent
amount of flash and/or is significantly faster this could be a winner.
> That is right. And the reality is that Microchip does not
> compete well with the low price parts from folks like
> TI/ST/NXP/Atmel in terms of 32bit MCUs.
What about in 8/16 bit parts and in Asia.
I'm told thatthe prices we can easily see 'here" are only a starting
point for Aian pricing.
The TI processor being quoted here at 33c in 1k was 25c in 100k.
That was their entry level part.
You can see uChip pricing down to around 30c in 'the West' so I'd
imagine that in real volume in Asia the entry level is say 20 cents.
(May not do overly much though :-) ).(But, even the lowliest processor
is vastly better than none at all.)
> Microchip owns its IP which is a big advantage over ARM based
> licensed IP.
But not PIC32, which is licensed from MIPS, right?
> [PICs cost more because] that they cost Microchip to produce due to
> the older process nodes they are in (older PIC16F and PIC18F).
I'm not entirely convinced. While this is part of the conventional
wisdom, and I'm by no means an expert in semiconductor economics,
State-of-the-art Fabs are extremely expensive to build, to the point
where fewer and fewer companies own their own fabs, and it's been
suggested that the limit to Moore's law will be economic rather than
physical. In the long run it may work out Microchip running "big"
chips on their old but owned-and-paid-for vs other vendors running
modern chips on third-party fabs that are still trying to recoup their
construction costs, and I'm not sure how those will compare...
On Fri, Mar 5, 2010 at 7:14 AM, William "Chops" Westfield
<RemoveMEwestfwspam_OUTKILLspammac.com> wrote:
>
>> Microchip owns its IP which is a big advantage over ARM based
>> licensed IP.
>
> But not PIC32, which is licensed from MIPS, right?
That is why I say Walter Banks' comment is not valid for
PIC32. MIPS owns majority of the IP.
>> [PICs cost more because] that they cost Microchip to produce due to
>> the older process nodes they are in (older PIC16F and PIC18F).
I did not say this is the only reason, but it is part of the reason.
>
> I'm not entirely convinced. While this is part of the conventional
> wisdom, and I'm by no means an expert in semiconductor economics,
> State-of-the-art Fabs are extremely expensive to build, to the point
> where fewer and fewer companies own their own fabs, and it's been
> suggested that the limit to Moore's law will be economic rather than
> physical. In the long run it may work out Microchip running "big"
> chips on their old but owned-and-paid-for vs other vendors running
> modern chips on third-party fabs that are still trying to recoup their
> construction costs, and I'm not sure how those will compare...
>
Yes for big players, it may still be necessary to have your
own fabs. Some IDM companies are shrinking their fab and use
Fab-lite technology. TI may be one of them, and now they
have big delivery problem. Bigger players like ST, TI will have
their fabs.
On the other hand, just look at Microchip. They use outside
fabs for high end parts, including PIC32 and those 3.3v only device
without EEPROM and lousy Flash life (PIC18J, PIC24F, dsPIC33, PIC32).
I think the new K (PIC18K, PIC24K) device are produced in-house
with better Flash life. So at least for Microchip, it is more economic to
produce the bigger chips outside. SST buy may help Microchip to
have better Flash technology.
BTW, why Microchip's analog product can never catch up
with ADI or Maxim or TI? Because they use the same process of
the MCU to product analog parts whereas ADI/Maxim/TI have
dedicated proprietary process for the analog parts.
On Fri, Mar 5, 2010 at 12:22 AM, Russell McMahon <EraseMEapptechnzspamspamBeGonegmail.com> wrote:
>> That is right. And the reality is that Microchip does not
>> compete well with the low price parts from folks like
>> TI/ST/NXP/Atmel in terms of 32bit MCUs.
>
> What about in 8/16 bit parts and in Asia.
> I'm told that the prices we can easily see 'here" are only a starting
> point for Asian pricing.
> The TI processor being quoted here at 33c in 1k was 25c in 100k.
> That was their entry level part.
> You can see uChip pricing down to around 30c in 'the West' so I'd
> imagine that in real volume in Asia the entry level is say 20 cents.
> (May not do overly much though :-) ).(But, even the lowliest processor
> is vastly better than none at all.)
>
That is a different market. The brutal consumer market seems
totally different from my filed. Occasionally I read some Chinese
forum on the low cost 8-bit MCUs. But that is about it. I am not
interested in 20 cents MCUs yet, and hopefully I do not need to
be in those situation any time soon (to count cents when doing
costing).
midwesttelecine.com
