clotting issue, and just when things were coming back together in 2013 a
spider bite in my left ankle spread to my right leg, and went necrotic
in the bones of my foot, and my achilles. So no income whatsoever for 17
months, and $150 looks like Everest to a gnat. Hence I need to use what
is totally free, or already owned.

> I would think that after that lot, you'd be wanting to take things easy
> for a while!
Not really, I've spent too long on bed rest, unable to walk etc, plus
wuth no income whatsoever I need to pay the rent and put food on the
table, so, even if I didn't love what I do I'd not be able to rest. Good
job this is something I enjoy doing
> starting out in hardware in 1970 (as a hobby in 1962), with programming
> usually done by stepping a series of instruction sinto memory using keys.
> I actually find that especially on bigger processors, the compiler
> generates tighter object code than some of my assembly code would be.
> It certainly has no problem making optimal code for things like hardware
> register accesses - assuming you use appropriate C code, of course.
I haven't done a really large design for a while, my 11axis + GPS
tracking system is probably the biggest, but that runs happily on an
MSP430FR5949, my spinal cord stimulator is on a 2618 and that is mostly
for the I/O and large memory just to hold lots of tables.

Al

Posted by: Onestone

Beginning Microcontrollers with the MSP430

On 04/11/14 18:49, Onestone o...@bigpond.net.au [msp430] wrote:
>
> On 4/11/2014 8:24 PM, David Brown d...@westcontrol.com [msp430] wrote:
> > 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.
> There's the rub, a major spinal cord injury in 2000, then a titanium
> cage in my neck in 2007, a ruptured femoral aneurism in 2010, followed
> by major post surgical infection, causing heart, liver and kidney
> damage, then another aneurism event in 2011, leading to an ongoing blood
> clotting issue, and just when things were coming back together in 2013 a
> spider bite in my left ankle spread to my right leg, and went necrotic
> in the bones of my foot, and my achilles. So no income whatsoever for 17
> months, and $150 looks like Everest to a gnat. Hence I need to use what
> is totally free, or already owned.

I would think that after that lot, you'd be wanting to take things easy
for a while!

> >
> > 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 still plan to take a look, just because of the size issues, but time
> is also an issue.
> > Just as you use assembler macros to make assembly clearer (such as
> > using names Bitset or Bitclr rather than the PIC's hopeless mnemonics),
> Weirdly enough I used to use macros heaps, but with the advent of modern
> IDE's I find it easier to simply cut and paste, and I've never had an
> issue remembering mnemonics, even oddball stuff like BTFSC

I don't find things like BTFSC hard to remember, I just find them hard
to read and write. When doing PIC assembly, I used a macro "IfSet" for
that instruction, and indented the next line with a tab - it made flow
control far clearer.

> > 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've been writing in C since the early 80's probably, and used it on all
> PC/workstation programs from the Microvax 2 in the mid 80's. Itried it
> on microcontrollers, including the MSP430, but just go so frustrated
> that some of the things I like to do in assembler just don't translate
> into C, or don't translate easily, so I reverted to my favourite.
> >> 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.
> I get that, but to me the oft touted major benefit of C, or any other
> high level language, is the separation from the hardware, and I don't
> want to be separated. I think I can do a better job by directly managing
> the hardware myself, but I understand that with modern highspeed micros
> costing a few cents that there is little justification for most people
> to write in assembler any more. This probably stems from originally
> starting out in hardware in 1970 (as a hobby in 1962), with programming
> usually done by stepping a series of instruction sinto memory using keys.

I actually find that especially on bigger processors, the compiler
generates tighter object code than some of my assembly code would be.
It certainly has no problem making optimal code for things like hardware
register accesses - assuming you use appropriate C code, of course.

>
> For me, where most of my designs are extremely tiny, I can't afford to
> throw a part with 32k memory in a 40 pin package at a job, and things
> like a full JTAG connector are usually bigger than my entire design, but
> I'm guessing that there is a low pin count solution for the Kinetis,
> otherwise it would make no sens.
>
> Cheers
>
> Al
>

Posted by: David Brown

On 4/11/2014 8:24 PM, David Brown d...@westcontrol.com [msp430] wrote:
> 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.
There's the rub, a major spinal cord injury in 2000, then a titanium
cage in my neck in 2007, a ruptured femoral aneurism in 2010, followed
by major post surgical infection, causing heart, liver and kidney
damage, then another aneurism event in 2011, leading to an ongoing blood
clotting issue, and just when things were coming back together in 2013 a
spider bite in my left ankle spread to my right leg, and went necrotic
in the bones of my foot, and my achilles. So no income whatsoever for 17
months, and $150 looks like Everest to a gnat. Hence I need to use what
is totally free, or already owned.
>
> 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 still plan to take a look, just because of the size issues, but time
is also an issue.
> Just as you use assembler macros to make assembly clearer (such as
> using names Bitset or Bitclr rather than the PIC's hopeless mnemonics),
Weirdly enough I used to use macros heaps, but with the advent of modern
IDE's I find it easier to simply cut and paste, and I've never had an
issue remembering mnemonics, even oddball stuff like BTFSC
> 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've been writing in C since the early 80's probably, and used it on all
PC/workstation programs from the Microvax 2 in the mid 80's. Itried it
on microcontrollers, including the MSP430, but just go so frustrated
that some of the things I like to do in assembler just don't translate
into C, or don't translate easily, so I reverted to my favourite.
>> 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.
I get that, but to me the oft touted major benefit of C, or any other
high level language, is the separation from the hardware, and I don't
want to be separated. I think I can do a better job by directly managing
the hardware myself, but I understand that with modern highspeed micros
costing a few cents that there is little justification for most people
to write in assembler any more. This probably stems from originally
starting out in hardware in 1970 (as a hobby in 1962), with programming
usually done by stepping a series of instruction sinto memory using keys.

For me, where most of my designs are extremely tiny, I can't afford to
throw a part with 32k memory in a 40 pin package at a job, and things
like a full JTAG connector are usually bigger than my entire design, but
I'm guessing that there is a low pin count solution for the Kinetis,
otherwise it would make no sens.

Cheers

Al

Posted by: Onestone

My favourite MCu metric, uW/significant function.

Al

On 4/11/2014 8:26 PM, David Brown d...@westcontrol.com [msp430] wrote:
> 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
>
>
>
>

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

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

The PIC will have much lower power consumption than the Kinetis part.

Leon

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.

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