EmbeddedRelated.com
Forums
Memfault Beyond the Launch

WHERE'S ALL THE SMALL FOOTPRINT STUFF?

Started by "One...@bigpond.net.au [msp430]" November 4, 2014
I know I've moaned before, but potentially the best part that Ti built
was the MSP430F2131. It's problems were simple, no SBW interface, no
comms. It's plusses were a very small footprint, decent I/O count and
reasonable memory. As they've added to their portfolio they've
concentrated on the high end big memory high pin count stuff, or the
very low pin count, like 16 pin QFN packages, which usually just fall
short on pin count. Sadly the 2121 and 2131 were orphan parts, an odd
transition into the 2 series without the SBW. I looked at the
MSP430G2131 and thought here was the answer to my prayers, but it seems
to be nothing more than an MSP430F2002 with possibly a slightly better
Brownout detector, how about uniformity in numbering Ti??

Most of the stuff I design has small physical requirements, like, in the
past a 0.45" (11.43mm) sq wireless multi-sensor device, a sub 0.25gm
(.008oz) motion and temp logger, and a 6x8mm (.235 x .315) motion temp
and light logger with optical comms. All of these used the 2131 or 2121
because nothing else had the pin count I needed, but in all cases my
data rates were limited by the need to bit bang comm ports. Once again I
find myself in that situation, I have a 10mm diameter limit on one
design and a 5x8mm limit on the other, and this time I need a faster
comm system. The closest I can get is the MSP430G2432, nothing remotely
close in FRAM, which would be my preference, and nothing else I can find
in a 4 x 4 mm QFN24 package. The other problem I've often encountered
is the lack of a DAC. In these small designs I don't have space (or
budget) for an external DAC, and surprisingly need one quite often. For
this design I've been forced out of the MSP430. For the first time in 14
years I've been unable to find a part that does what I need
economically, and am jumping ship to the Microchip PIC16LF1709, a 20 pin
QFN part with DAC, UART, SPI and plenty of other resources. Yes it's 8
bit, yes it has that evil PIC architecture, but I was once a huge fan of
the small PIC's, and don't see this as an insurmountable problem.

Whinge over

Al

Beginning Microcontrollers with the MSP430

This is off-topic (and nearly sacrilegious) in an msp430 group, but the
smallest microcontrollers I know of at the moment are the Freescale
Kinetis devices - they have 20 pin devices in less than 2x2 mm, with
Cortex M0+ cores (far nicer than PIC's !).

On 04/11/14 07:38, Onestone o...@bigpond.net.au [msp430] wrote:
>
> I know I've moaned before, but potentially the best part that Ti built
> was the MSP430F2131. It's problems were simple, no SBW interface, no
> comms. It's plusses were a very small footprint, decent I/O count and
> reasonable memory. As they've added to their portfolio they've
> concentrated on the high end big memory high pin count stuff, or the
> very low pin count, like 16 pin QFN packages, which usually just fall
> short on pin count. Sadly the 2121 and 2131 were orphan parts, an odd
> transition into the 2 series without the SBW. I looked at the
> MSP430G2131 and thought here was the answer to my prayers, but it seems
> to be nothing more than an MSP430F2002 with possibly a slightly better
> Brownout detector, how about uniformity in numbering Ti??
>
> Most of the stuff I design has small physical requirements, like, in the
> past a 0.45" (11.43mm) sq wireless multi-sensor device, a sub 0.25gm
> (.008oz) motion and temp logger, and a 6x8mm (.235 x .315) motion temp
> and light logger with optical comms. All of these used the 2131 or 2121
> because nothing else had the pin count I needed, but in all cases my
> data rates were limited by the need to bit bang comm ports. Once again I
> find myself in that situation, I have a 10mm diameter limit on one
> design and a 5x8mm limit on the other, and this time I need a faster
> comm system. The closest I can get is the MSP430G2432, nothing remotely
> close in FRAM, which would be my preference, and nothing else I can find
> in a 4 x 4 mm QFN24 package. The other problem I've often encountered
> is the lack of a DAC. In these small designs I don't have space (or
> budget) for an external DAC, and surprisingly need one quite often. For
> this design I've been forced out of the MSP430. For the first time in 14
> years I've been unable to find a part that does what I need
> economically, and am jumping ship to the Microchip PIC16LF1709, a 20 pin
> QFN part with DAC, UART, SPI and plenty of other resources. Yes it's 8
> bit, yes it has that evil PIC architecture, but I was once a huge fan of
> the small PIC's, and don't see this as an insurmountable problem.
>
> Whinge over
>
> Al
>

Posted by: David Brown




Thanks Dave. I have looked at the Kinetis parts, but I don't have time
to learn a new Micro, and I know the PICs pretty well. I write in
assembler, and have never used the ARM assembler, nor do I have tools
for it, while I do have tools for the PIC and MPLAB is free. In addition
the 6 bit DAC on the KL02P20 isn't enough for me.

Al

On 4/11/2014 6:10 PM, David Brown d...@westcontrol.com [msp430] wrote:
> This is off-topic (and nearly sacrilegious) in an msp430 group, but the
> smallest microcontrollers I know of at the moment are the Freescale
> Kinetis devices - they have 20 pin devices in less than 2x2 mm, with
> Cortex M0+ cores (far nicer than PIC's !).
>
> On 04/11/14 07:38, Onestone o...@bigpond.net.au [msp430] wrote:
>> I know I've moaned before, but potentially the best part that Ti built
>> was the MSP430F2131. It's problems were simple, no SBW interface, no
>> comms. It's plusses were a very small footprint, decent I/O count and
>> reasonable memory. As they've added to their portfolio they've
>> concentrated on the high end big memory high pin count stuff, or the
>> very low pin count, like 16 pin QFN packages, which usually just fall
>> short on pin count. Sadly the 2121 and 2131 were orphan parts, an odd
>> transition into the 2 series without the SBW. I looked at the
>> MSP430G2131 and thought here was the answer to my prayers, but it seems
>> to be nothing more than an MSP430F2002 with possibly a slightly better
>> Brownout detector, how about uniformity in numbering Ti??
>>
>> Most of the stuff I design has small physical requirements, like, in the
>> past a 0.45" (11.43mm) sq wireless multi-sensor device, a sub 0.25gm
>> (.008oz) motion and temp logger, and a 6x8mm (.235 x .315) motion temp
>> and light logger with optical comms. All of these used the 2131 or 2121
>> because nothing else had the pin count I needed, but in all cases my
>> data rates were limited by the need to bit bang comm ports. Once again I
>> find myself in that situation, I have a 10mm diameter limit on one
>> design and a 5x8mm limit on the other, and this time I need a faster
>> comm system. The closest I can get is the MSP430G2432, nothing remotely
>> close in FRAM, which would be my preference, and nothing else I can find
>> in a 4 x 4 mm QFN24 package. The other problem I've often encountered
>> is the lack of a DAC. In these small designs I don't have space (or
>> budget) for an external DAC, and surprisingly need one quite often. For
>> this design I've been forced out of the MSP430. For the first time in 14
>> years I've been unable to find a part that does what I need
>> economically, and am jumping ship to the Microchip PIC16LF1709, a 20 pin
>> QFN part with DAC, UART, SPI and plenty of other resources. Yes it's 8
>> bit, yes it has that evil PIC architecture, but I was once a huge fan of
>> the small PIC's, and don't see this as an insurmountable problem.
>>
>> Whinge over
>>
>> Al
>>
> Posted by: David Brown
>
>
>
>
I can't do anything about the DAC resolution (except suggest dithering -
the chip is fast enough if your rates are low). But I can point out
that the software tools for the Kinetis are free (all zero cost "free",
and mostly open source "free" as well), and jtag debuggers are cheap.

Assembly on the Cortex M devices is not too hard - it has more in common
with the msp430 than the PIC. But of course virtually everyone uses C
or C++ - the compilers are excellent.

But it is your call, of course.

David
On 04/11/14 09:00, Onestone o...@bigpond.net.au [msp430] wrote:
>
>
> Thanks Dave. I have looked at the Kinetis parts, but I don't have time
> to learn a new Micro, and I know the PICs pretty well. I write in
> assembler, and have never used the ARM assembler, nor do I have tools
> for it, while I do have tools for the PIC and MPLAB is free. In addition
> the 6 bit DAC on the KL02P20 isn't enough for me.
>
> Al
>
> On 4/11/2014 6:10 PM, David Brown d...@westcontrol.com [msp430] wrote:
>> This is off-topic (and nearly sacrilegious) in an msp430 group, but the
>> smallest microcontrollers I know of at the moment are the Freescale
>> Kinetis devices - they have 20 pin devices in less than 2x2 mm, with
>> Cortex M0+ cores (far nicer than PIC's !).
>>


Posted by: David Brown




And at the other end of the spectrum, I noticed earlier this evening that
some of the DIP parts have doubled in price over the past few months.
(Specifically my favorite part, the G2553)

-p.
I need too high a rate for dithering. I didn't know the tools were free,
I have old Kiel and IAR JTAG debuggers that I bought a few years ago,
that just might work.

I'm a dinosaur, good as the compilers might be I still prefer assembler,
then any mistakes I make are my own, and, having been writing in
assembler for close to 40 years I think I write as fast, for the work I
want to do as I would in C and get more out of it. A lot though is to do
with feel, neither C nor C++ was designed for embedded systems, and I
think the methods used to kludge it all together are ugly. I think
Bitset and Bitclr are far more intuitive, for example, than any C
alternative I've seen.

I guess I'm just as comfortable in assembler as anything else.

Al

On 4/11/2014 7:14 PM, David Brown d...@westcontrol.com [msp430] wrote:
> I can't do anything about the DAC resolution (except suggest dithering -
> the chip is fast enough if your rates are low). But I can point out
> that the software tools for the Kinetis are free (all zero cost "free",
> and mostly open source "free" as well), and jtag debuggers are cheap.
>
> Assembly on the Cortex M devices is not too hard - it has more in common
> with the msp430 than the PIC. But of course virtually everyone uses C
> or C++ - the compilers are excellent.
>
> But it is your call, of course.
>
> David
> On 04/11/14 09:00, Onestone o...@bigpond.net.au [msp430] wrote:
>>
>>
>> Thanks Dave. I have looked at the Kinetis parts, but I don't have time
>> to learn a new Micro, and I know the PICs pretty well. I write in
>> assembler, and have never used the ARM assembler, nor do I have tools
>> for it, while I do have tools for the PIC and MPLAB is free. In addition
>> the 6 bit DAC on the KL02P20 isn't enough for me.
>>
>> Al
>>
>> On 4/11/2014 6:10 PM, David Brown d...@westcontrol.com [msp430] wrote:
>>> This is off-topic (and nearly sacrilegious) in an msp430 group, but the
>>> smallest microcontrollers I know of at the moment are the Freescale
>>> Kinetis devices - they have 20 pin devices in less than 2x2 mm, with
>>> Cortex M0+ cores (far nicer than PIC's !).
>>>
>
> Posted by: David Brown
>
>
>
>
The only thing I don't like about the G2553 is the lack of a QFN part,
otherwise it would be my choice for most things. I can only assume that
the QFN parts are more expensive to make, perhaps by as much as $0.02

Al

On 4/11/2014 7:19 PM, Peter Johansson r...@gmail.com [msp430] wrote:
> And at the other end of the spectrum, I noticed earlier this evening
> that some of the DIP parts have doubled in price over the past few
> months. (Specifically my favorite part, the G2553)
>
> -p.
The PIC will have much lower power consumption than the Kinetis part.

Leon
On 04/11/14 10:08, Onestone o...@bigpond.net.au [msp430] wrote:
>
>
> I need too high a rate for dithering. I didn't know the tools were free,
> I have old Kiel and IAR JTAG debuggers that I bought a few years ago,
> that just might work.

Such tools will probably work using "OpenOCD" - it supports most jtag
debuggers, including ones you put together yourself from an FTDI chip.
But it's probably easier to use a PE Micro debugger for $150, at least
to start with - it's one less thing to worry about.

The CodeWarrior tools for Kinetis were free to a size limit of 64K
(IIRC), but the new KDS tools are entirely free and work on Linux and
Windows.

>
> I'm a dinosaur, good as the compilers might be I still prefer assembler,
> then any mistakes I make are my own, and, having been writing in
> assembler for close to 40 years I think I write as fast, for the work I
> want to do as I would in C and get more out of it. A lot though is to do
> with feel, neither C nor C++ was designed for embedded systems, and I
> think the methods used to kludge it all together are ugly. I think
> Bitset and Bitclr are far more intuitive, for example, than any C
> alternative I've seen.

Just as you use assembler macros to make assembly clearer (such as using
names Bitset or Bitclr rather than the PIC's hopeless mnemonics), you
can make functions in C with whatever name suits your purposes if you
don't like "port |= 0x0001;" style.

And while C (and C++) were not originally designed for embedded use,
they have gradually changed over the years with embedded development in
mind. At the same time, modern microcontroller cpu designs have had C
(and C++) as their target. So cpus such as the Cortex M series were
designed to be programmed in C. If you have ever worked with bigger
processors, you will quickly see that it is assembly that feels like a
"kludge", not C. You will also find that the "microcontroller" parts,
such as manipulating bits in a register, take a smaller and smaller
proportion of the program.

>
> I guess I'm just as comfortable in assembler as anything else.

That's fair enough.

When I started my professional work around 20 years ago, most of my code
was in assembler with only a little C. I made a number of msp430
systems in assembler, before gcc was available. But while I
occasionally fiddle around in assembler, and find it very useful to
understand assembler on all the processors I use, it is rare that I
write more than a few lines of assembly now. I don't miss it.

>
> Al
>
> On 4/11/2014 7:14 PM, David Brown d...@westcontrol.com [msp430] wrote:
>> I can't do anything about the DAC resolution (except suggest dithering -
>> the chip is fast enough if your rates are low). But I can point out
>> that the software tools for the Kinetis are free (all zero cost "free",
>> and mostly open source "free" as well), and jtag debuggers are cheap.
>>
>> Assembly on the Cortex M devices is not too hard - it has more in common
>> with the msp430 than the PIC. But of course virtually everyone uses C
>> or C++ - the compilers are excellent.
>>
>> But it is your call, of course.
>>
>> David
>> On 04/11/14 09:00, Onestone o...@bigpond.net.au [msp430] wrote:
>>>
>>>
>>> Thanks Dave. I have looked at the Kinetis parts, but I don't have time
>>> to learn a new Micro, and I know the PICs pretty well. I write in
>>> assembler, and have never used the ARM assembler, nor do I have tools
>>> for it, while I do have tools for the PIC and MPLAB is free. In addition
>>> the 6 bit DAC on the KL02P20 isn't enough for me.
>>>
>>> Al
>>>
>>> On 4/11/2014 6:10 PM, David Brown d...@westcontrol.com [msp430] wrote:
>>>> This is off-topic (and nearly sacrilegious) in an msp430 group, but the
>>>> smallest microcontrollers I know of at the moment are the Freescale
>>>> Kinetis devices - they have 20 pin devices in less than 2x2 mm, with
>>>> Cortex M0+ cores (far nicer than PIC's !).
>>>>

Posted by: David Brown




On 04/11/14 10:31, l...@btinternet.com [msp430] wrote:
>
>
> The PIC will have much lower power consumption than the Kinetis part.
>
> Leon
>

Perhaps, but it's not a given. The small Kinetis take very little power
- and the Cortex M0+ cpu core does far more work per mW than a PIC core.
So the Kinetis may have higher peak currents, but for the same job it
will spend far more of its time in low-power sleep modes.


Posted by: David Brown





Memfault Beyond the Launch