This question has probably been answered a thousand times but it's worthy
of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or WDTCTL
or WDTHOLD or BCSCTL1. I could go down through all the header files, find all
the #define statements and try to sort them out using the often absent comment
statements, but that doesn't make much sense. Obviously I missed something
But I don't see them in the TI literature like slau131, slau157, etc.
I'm sure most of them must be explained somewhere and conveniently
annotated, not just strewn without comment though the programming examples like
fiberglas laundry lint.
But none of the programming guides I have seen so far even have the word pin or
output, seemingly the sort of information one might desire in programming
language guide for a dedicated systems microprocessor.
Can anyone help me, please? Help! PS-For the always unhelpful few, the answer,
"there are too many of them" is a really ludicrous answer considering 99% of the
programs are written with less than 200. Sincerely, Doc K. And thanks ahead of
time.
Looking for the #define rosetta stone
Started by ●July 1, 2012
Reply by ●July 1, 20122012-07-01
Doc K,
It's typical nowadays for microcontroller families to have separate architecture documents that describe hardware and programmers' models common to all or selected members of the family.
If you were using a MSP430G1xx device you might consider looking at:http://www.ti.com/lit/ug/slau049f/slau049f.pdf
If you were using a MSP430G2xx device you might consider looking at:http://www.ti.com/lit/ug/slau144i/slau144i.pdf
Here's the TI Reference page for MSP430:https://sites.google.com/site/msp430ref/ti-reference-library
(Note, the link to "slau144h" on the TI Reference page is a dead link.)
Depending on which sub-family of MSP430 devices you're using, you might find a more specifically appropriate User's Guide.
Best Wishes,Coop, AA1WW
To: m...
From: k...@gunstar1.com
Date: Sun, 1 Jul 2012 21:08:18 +0000
Subject: [msp430] Looking for the #define rosetta stone
This question has probably been answered a thousand times but it's worthy of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or WDTCTL or WDTHOLD or BCSCTL1. I could go down through all the header files, find all the #define statements and try to sort them out using the often absent comment statements, but that doesn't make much sense. Obviously I missed something But I don't see them in the TI literature like slau131, slau157, etc. I'm sure most of them must be explained somewhere and conveniently annotated, not just strewn without comment though the programming examples like fiberglas laundry lint.
But none of the programming guides I have seen so far even have the word pin or output, seemingly the sort of information one might desire in programming language guide for a dedicated systems microprocessor.
Can anyone help me, please? Help! PS-For the always unhelpful few, the answer, "there are too many of them" is a really ludicrous answer considering 99% of the programs are written with less than 200. Sincerely, Doc K. And thanks ahead of time.
It's typical nowadays for microcontroller families to have separate architecture documents that describe hardware and programmers' models common to all or selected members of the family.
If you were using a MSP430G1xx device you might consider looking at:http://www.ti.com/lit/ug/slau049f/slau049f.pdf
If you were using a MSP430G2xx device you might consider looking at:http://www.ti.com/lit/ug/slau144i/slau144i.pdf
Here's the TI Reference page for MSP430:https://sites.google.com/site/msp430ref/ti-reference-library
(Note, the link to "slau144h" on the TI Reference page is a dead link.)
Depending on which sub-family of MSP430 devices you're using, you might find a more specifically appropriate User's Guide.
Best Wishes,Coop, AA1WW
To: m...
From: k...@gunstar1.com
Date: Sun, 1 Jul 2012 21:08:18 +0000
Subject: [msp430] Looking for the #define rosetta stone
This question has probably been answered a thousand times but it's worthy of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or WDTCTL or WDTHOLD or BCSCTL1. I could go down through all the header files, find all the #define statements and try to sort them out using the often absent comment statements, but that doesn't make much sense. Obviously I missed something But I don't see them in the TI literature like slau131, slau157, etc. I'm sure most of them must be explained somewhere and conveniently annotated, not just strewn without comment though the programming examples like fiberglas laundry lint.
But none of the programming guides I have seen so far even have the word pin or output, seemingly the sort of information one might desire in programming language guide for a dedicated systems microprocessor.
Can anyone help me, please? Help! PS-For the always unhelpful few, the answer, "there are too many of them" is a really ludicrous answer considering 99% of the programs are written with less than 200. Sincerely, Doc K. And thanks ahead of time.
Reply by ●July 1, 20122012-07-01
I probably should have posted the TI URL for the MSP430x2xx User's Guide.
It's at:
http://www.ti.com/lit/ug/slau144i/slau144i.pdf
Coop, AA1WW
http://www.ti.com/lit/ug/slau144i/slau144i.pdf
Coop, AA1WW
Reply by ●July 1, 20122012-07-01
Martin replied to my query: "There should be a hardware specific header file
that contains most of your I/O registers. I find that they generally map pretty
well with the microcontroller reference/user guides. I am currently using
MSP430FG4619 so the header file I use is msp430xg46x.h."
I agree, and I failed to explain, this is what I have been trying to avoid. I'm looking for something that can be used for training young mugwumps including myself, succinct, alphabetical, cataloged, with examples, something more, at the risk of God's wrath, like the PIC Basic manual. A simple annotated list would be a great start. But tragically, while slau209 and slau049 are excellent 600 page treatises on the infinite complexities of modern programming, like the 2500 page Health Care Bill, remarkably odiferous to the various senses by being devoid of words like "output pins" or "hold the reset line high" or "the analog lines can be used to extend digital I/O, here's how."
I agree, and I failed to explain, this is what I have been trying to avoid. I'm looking for something that can be used for training young mugwumps including myself, succinct, alphabetical, cataloged, with examples, something more, at the risk of God's wrath, like the PIC Basic manual. A simple annotated list would be a great start. But tragically, while slau209 and slau049 are excellent 600 page treatises on the infinite complexities of modern programming, like the 2500 page Health Care Bill, remarkably odiferous to the various senses by being devoid of words like "output pins" or "hold the reset line high" or "the analog lines can be used to extend digital I/O, here's how."
Reply by ●July 1, 20122012-07-01
On Sun, Jul 1, 2012 at 6:29 PM, vineyard wrote:
> Martin replied to my query: "There should be a hardware specific header file that contains most of your I/O registers. I find that they generally map pretty well with the microcontroller reference/user guides. I am currently using MSP430FG4619 so the header file I use is msp430xg46x.h."
>
> I agree, and I failed to explain, this is what I have been trying to avoid. I'm looking for something that can be used for training young mugwumps including myself, succinct, alphabetical, cataloged, with examples, something more, at the risk of God's wrath, like the PIC Basic manual. A simple annotated list would be a great start. But tragically, while slau209 and slau049 are excellent 600 page treatises on the infinite complexities of modern programming, like the 2500 page Health Care Bill, remarkably odiferous to the various senses by being devoid of words like "output pins" or "hold the reset line high" or "the analog lines can be used to extend digital I/O, here's how."
At the end of every chapter in each of the family reference guides
there is a section on register usage. This section shows all of the
register address names and the corresponding bit flags.
If you have a PDF reader that does TOC indexing (like Preview on the
Mac) it is *very* easy to navigate the TI datasheets. I found the
need to do some work under Windows not too long ago and I was amazed
at how much each and every PDF reader I tried there sucked so damn
hard, so I *can* feel your pain here.
Perhaps you might want to find a PDF editor and splice together all of
the relevant register sections in the datasheets together into a
single document or quick-reference printout.
-p.
> Martin replied to my query: "There should be a hardware specific header file that contains most of your I/O registers. I find that they generally map pretty well with the microcontroller reference/user guides. I am currently using MSP430FG4619 so the header file I use is msp430xg46x.h."
>
> I agree, and I failed to explain, this is what I have been trying to avoid. I'm looking for something that can be used for training young mugwumps including myself, succinct, alphabetical, cataloged, with examples, something more, at the risk of God's wrath, like the PIC Basic manual. A simple annotated list would be a great start. But tragically, while slau209 and slau049 are excellent 600 page treatises on the infinite complexities of modern programming, like the 2500 page Health Care Bill, remarkably odiferous to the various senses by being devoid of words like "output pins" or "hold the reset line high" or "the analog lines can be used to extend digital I/O, here's how."
At the end of every chapter in each of the family reference guides
there is a section on register usage. This section shows all of the
register address names and the corresponding bit flags.
If you have a PDF reader that does TOC indexing (like Preview on the
Mac) it is *very* easy to navigate the TI datasheets. I found the
need to do some work under Windows not too long ago and I was amazed
at how much each and every PDF reader I tried there sucked so damn
hard, so I *can* feel your pain here.
Perhaps you might want to find a PDF editor and splice together all of
the relevant register sections in the datasheets together into a
single document or quick-reference printout.
-p.
Reply by ●July 1, 20122012-07-01
I think that you are seeking the impossible. The reason is that every
family of micros and different grades within those families use
significantly different register set ups, and often very different
hardware peripherals. So a file that covered DMA for the 1 series would
be useless for the 24xx/26xx series, and even more useless for the 54xx
series. UART modules particularly differ greatly aross the board. At the
very least, within the same family they will use different pins and
ports. The header files supplied with Kickstart are a reasonable base
point, but the field names are often over verbose, and the comments
often inane. The first thing I do is strip out all the references to
C/C++ and all underscores used in names, then add a bunch of memory
mapping defines at the end of the file.
If you don't use a large variety of different MSP430's then this can be
a start point to a limited set of headers that can be simple edited for
a new micro. It is long winded, but by going through the largest , most
common file for each family you use, and then adding your own meaningful
comments you will at least have a base point. A large slice of this file
will also translate across several more common peripherals across
different families but I don't see a way to a single header file that is
not insanely complex as it would have to account for all the different
I/O pin configurations for each different family member. For example the
F2274 and F2618 both have analog inputs but pin allocation varies
widely. While the F21x2 and 2274 are very close, but still have several
differences. i think trying to cater for this in a global fashion would
be a mess.
I think the closest you might come would be a file that defined basic
I/O, like ports 1 & 2, and perhaps TimerA. For each family then add the
most complex member of that family you use, and make that a base for
that family, but I still think there would be so much to edit for each
specific family member.
I agree that this is one of the most onerous parts of programming this
family, but haven't found a way around it.
Sorry
Al
On 2/07/2012 6:38 AM, vineyard wrote:
> This question has probably been answered a thousand times but it's worthy of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or WDTCTL or WDTHOLD or BCSCTL1. I could go down through all the header files, find all the #define statements and try to sort them out using the often absent comment statements, but that doesn't make much sense. Obviously I missed something But I don't see them in the TI literature like slau131, slau157, etc. I'm sure most of them must be explained somewhere and conveniently annotated, not just strewn without comment though the programming examples like fiberglas laundry lint.
> But none of the programming guides I have seen so far even have the word pin or output, seemingly the sort of information one might desire in programming language guide for a dedicated systems microprocessor.
> Can anyone help me, please? Help! PS-For the always unhelpful few, the answer, "there are too many of them" is a really ludicrous answer considering 99% of the programs are written with less than 200. Sincerely, Doc K. And thanks ahead of time.
>
>
family of micros and different grades within those families use
significantly different register set ups, and often very different
hardware peripherals. So a file that covered DMA for the 1 series would
be useless for the 24xx/26xx series, and even more useless for the 54xx
series. UART modules particularly differ greatly aross the board. At the
very least, within the same family they will use different pins and
ports. The header files supplied with Kickstart are a reasonable base
point, but the field names are often over verbose, and the comments
often inane. The first thing I do is strip out all the references to
C/C++ and all underscores used in names, then add a bunch of memory
mapping defines at the end of the file.
If you don't use a large variety of different MSP430's then this can be
a start point to a limited set of headers that can be simple edited for
a new micro. It is long winded, but by going through the largest , most
common file for each family you use, and then adding your own meaningful
comments you will at least have a base point. A large slice of this file
will also translate across several more common peripherals across
different families but I don't see a way to a single header file that is
not insanely complex as it would have to account for all the different
I/O pin configurations for each different family member. For example the
F2274 and F2618 both have analog inputs but pin allocation varies
widely. While the F21x2 and 2274 are very close, but still have several
differences. i think trying to cater for this in a global fashion would
be a mess.
I think the closest you might come would be a file that defined basic
I/O, like ports 1 & 2, and perhaps TimerA. For each family then add the
most complex member of that family you use, and make that a base for
that family, but I still think there would be so much to edit for each
specific family member.
I agree that this is one of the most onerous parts of programming this
family, but haven't found a way around it.
Sorry
Al
On 2/07/2012 6:38 AM, vineyard wrote:
> This question has probably been answered a thousand times but it's worthy of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or WDTCTL or WDTHOLD or BCSCTL1. I could go down through all the header files, find all the #define statements and try to sort them out using the often absent comment statements, but that doesn't make much sense. Obviously I missed something But I don't see them in the TI literature like slau131, slau157, etc. I'm sure most of them must be explained somewhere and conveniently annotated, not just strewn without comment though the programming examples like fiberglas laundry lint.
> But none of the programming guides I have seen so far even have the word pin or output, seemingly the sort of information one might desire in programming language guide for a dedicated systems microprocessor.
> Can anyone help me, please? Help! PS-For the always unhelpful few, the answer, "there are too many of them" is a really ludicrous answer considering 99% of the programs are written with less than 200. Sincerely, Doc K. And thanks ahead of time.
>
>
Reply by ●July 1, 20122012-07-01
If there is a nifty shortcut to this part of the learning process, it would be
worthwhile. I think what's happening here is that as the semiconductor
integration soars, even the entry-level members of a microcontroller family
contain a vast number of features each of which is controlled by a set of
special function registers. Additionally a programmer needs to know at least a
bit of the memory architecture of the part/family being used.
Embedded system programming requires some more experience in general than classic application programming (graphical or not) because of the diverse set of integrated features implemented in a diverse set of processor architectures (and for other reasons as well). This is compounded by the body of knowledge accumulating around application of various sensors, actuators, communications interfaces, and user interfaces.
One approach that seems to have gained success is the Arduino style where many of the embedded features are implemented in C++ classes that capture the functionally of the particular I/O special function registers and expose them in arguably easier-to-grasp programming interfaces coupled, hopefully, with existing example code employing the desired feature(s).
The BASIC Stamp approach similarly simplifies the programming interface so that newcomers to microcontrollers can be up and running programs (albeit simple programs) very quickly using features whose complexities are hidden behind simplified programming contructs.
True embedded developers are often trying to accomplish a design with multiple constraints often led by cost so they are likely to make the effort to fully parse the documentation. It's for this very reason that developers often choose to remain within a microcontroller family with which they have experience unless faced with significant advantages in using a different family. And TI, Microchip, Atmel, Renesas, etc. have very agressively expanded their families to cover impressive ranges of cost and functionality.
So, to Doc K's original point, I have to agree that apart from code libraries that implement and simplify the features you want to use, there are no shortcuts around understanding a useful synopsis of the microcontroller family's architecture including memory organization, interrupts, I/O features, and the development tools.
Coop, AA1WW
--- In m..., Onestone wrote:
>
> I think that you are seeking the impossible. The reason is that every
> family of micros and different grades within those families use
> significantly different register set ups, and often very different
> hardware peripherals. So a file that covered DMA for the 1 series would
> be useless for the 24xx/26xx series, and even more useless for the 54xx
> series. UART modules particularly differ greatly aross the board. At the
> very least, within the same family they will use different pins and
> ports. The header files supplied with Kickstart are a reasonable base
> point, but the field names are often over verbose, and the comments
> often inane. The first thing I do is strip out all the references to
> C/C++ and all underscores used in names, then add a bunch of memory
> mapping defines at the end of the file.
>
> If you don't use a large variety of different MSP430's then this can be
> a start point to a limited set of headers that can be simple edited for
> a new micro. It is long winded, but by going through the largest , most
> common file for each family you use, and then adding your own meaningful
> comments you will at least have a base point. A large slice of this file
> will also translate across several more common peripherals across
> different families but I don't see a way to a single header file that is
> not insanely complex as it would have to account for all the different
> I/O pin configurations for each different family member. For example the
> F2274 and F2618 both have analog inputs but pin allocation varies
> widely. While the F21x2 and 2274 are very close, but still have several
> differences. i think trying to cater for this in a global fashion would
> be a mess.
>
> I think the closest you might come would be a file that defined basic
> I/O, like ports 1 & 2, and perhaps TimerA. For each family then add the
> most complex member of that family you use, and make that a base for
> that family, but I still think there would be so much to edit for each
> specific family member.
>
> I agree that this is one of the most onerous parts of programming this
> family, but haven't found a way around it.
>
> Sorry
>
> Al
>
> On 2/07/2012 6:38 AM, vineyard wrote:
> > This question has probably been answered a thousand times but it's worthy of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or WDTCTL or WDTHOLD or BCSCTL1. I could go down through all the header files, find all the #define statements and try to sort them out using the often absent comment statements, but that doesn't make much sense. Obviously I missed something But I don't see them in the TI literature like slau131, slau157, etc. I'm sure most of them must be explained somewhere and conveniently annotated, not just strewn without comment though the programming examples like fiberglas laundry lint.
> > But none of the programming guides I have seen so far even have the word pin or output, seemingly the sort of information one might desire in programming language guide for a dedicated systems microprocessor.
> > Can anyone help me, please? Help! PS-For the always unhelpful few, the answer, "there are too many of them" is a really ludicrous answer considering 99% of the programs are written with less than 200. Sincerely, Doc K. And thanks ahead of time.
> >
> >
> >
> >
> >
> >
> >
> >
Embedded system programming requires some more experience in general than classic application programming (graphical or not) because of the diverse set of integrated features implemented in a diverse set of processor architectures (and for other reasons as well). This is compounded by the body of knowledge accumulating around application of various sensors, actuators, communications interfaces, and user interfaces.
One approach that seems to have gained success is the Arduino style where many of the embedded features are implemented in C++ classes that capture the functionally of the particular I/O special function registers and expose them in arguably easier-to-grasp programming interfaces coupled, hopefully, with existing example code employing the desired feature(s).
The BASIC Stamp approach similarly simplifies the programming interface so that newcomers to microcontrollers can be up and running programs (albeit simple programs) very quickly using features whose complexities are hidden behind simplified programming contructs.
True embedded developers are often trying to accomplish a design with multiple constraints often led by cost so they are likely to make the effort to fully parse the documentation. It's for this very reason that developers often choose to remain within a microcontroller family with which they have experience unless faced with significant advantages in using a different family. And TI, Microchip, Atmel, Renesas, etc. have very agressively expanded their families to cover impressive ranges of cost and functionality.
So, to Doc K's original point, I have to agree that apart from code libraries that implement and simplify the features you want to use, there are no shortcuts around understanding a useful synopsis of the microcontroller family's architecture including memory organization, interrupts, I/O features, and the development tools.
Coop, AA1WW
--- In m..., Onestone wrote:
>
> I think that you are seeking the impossible. The reason is that every
> family of micros and different grades within those families use
> significantly different register set ups, and often very different
> hardware peripherals. So a file that covered DMA for the 1 series would
> be useless for the 24xx/26xx series, and even more useless for the 54xx
> series. UART modules particularly differ greatly aross the board. At the
> very least, within the same family they will use different pins and
> ports. The header files supplied with Kickstart are a reasonable base
> point, but the field names are often over verbose, and the comments
> often inane. The first thing I do is strip out all the references to
> C/C++ and all underscores used in names, then add a bunch of memory
> mapping defines at the end of the file.
>
> If you don't use a large variety of different MSP430's then this can be
> a start point to a limited set of headers that can be simple edited for
> a new micro. It is long winded, but by going through the largest , most
> common file for each family you use, and then adding your own meaningful
> comments you will at least have a base point. A large slice of this file
> will also translate across several more common peripherals across
> different families but I don't see a way to a single header file that is
> not insanely complex as it would have to account for all the different
> I/O pin configurations for each different family member. For example the
> F2274 and F2618 both have analog inputs but pin allocation varies
> widely. While the F21x2 and 2274 are very close, but still have several
> differences. i think trying to cater for this in a global fashion would
> be a mess.
>
> I think the closest you might come would be a file that defined basic
> I/O, like ports 1 & 2, and perhaps TimerA. For each family then add the
> most complex member of that family you use, and make that a base for
> that family, but I still think there would be so much to edit for each
> specific family member.
>
> I agree that this is one of the most onerous parts of programming this
> family, but haven't found a way around it.
>
> Sorry
>
> Al
>
> On 2/07/2012 6:38 AM, vineyard wrote:
> > This question has probably been answered a thousand times but it's worthy of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or WDTCTL or WDTHOLD or BCSCTL1. I could go down through all the header files, find all the #define statements and try to sort them out using the often absent comment statements, but that doesn't make much sense. Obviously I missed something But I don't see them in the TI literature like slau131, slau157, etc. I'm sure most of them must be explained somewhere and conveniently annotated, not just strewn without comment though the programming examples like fiberglas laundry lint.
> > But none of the programming guides I have seen so far even have the word pin or output, seemingly the sort of information one might desire in programming language guide for a dedicated systems microprocessor.
> > Can anyone help me, please? Help! PS-For the always unhelpful few, the answer, "there are too many of them" is a really ludicrous answer considering 99% of the programs are written with less than 200. Sincerely, Doc K. And thanks ahead of time.
> >
> >
> >
> >
> >
> >
> >
> >
Reply by ●July 2, 20122012-07-02
Thanks for the help. Got a good cross section of thinking. Reminds me of my
grandfather's tool shop, machinist, farmer, foreman for GE. In the wood
floor of his tool shop was a bumblebee's nest which he insisted on
encouraging, cute little guys. Ultimately, he was so right, but it took me a
while and a whole set of odd clothing to figure out why. He never lost or went
looking for a single tool :-)
--- In m..., "aa1ww" wrote:
>
> I probably should have posted the TI URL for the MSP430x2xx User's Guide. It's at:
> http://www.ti.com/lit/ug/slau144i/slau144i.pdf
>
> Coop, AA1WW
>
--- In m..., "aa1ww" wrote:
>
> I probably should have posted the TI URL for the MSP430x2xx User's Guide. It's at:
> http://www.ti.com/lit/ug/slau144i/slau144i.pdf
>
> Coop, AA1WW
>
Reply by ●July 2, 20122012-07-02
Hi,
Go to family user guide of your device and thumb through it *look at the
registries specifically*.
Jake G
On Sun, Jul 1, 2012 at 2:08 PM, vineyard wrote:
> **
> This question has probably been answered a thousand times but it's worthy
> of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or
> WDTCTL or WDTHOLD or BCSCTL1. I could go down through all the header files,
> find all the #define statements and try to sort them out using the often
> absent comment statements, but that doesn't make much sense. Obviously I
> missed something But I don't see them in the TI literature like slau131,
> slau157, etc. I'm sure most of them must be explained somewhere and
> conveniently annotated, not just strewn without comment though the
> programming examples like fiberglas laundry lint.
> But none of the programming guides I have seen so far even have the word
> pin or output, seemingly the sort of information one might desire in
> programming language guide for a dedicated systems microprocessor.
> Can anyone help me, please? Help! PS-For the always unhelpful few, the
> answer, "there are too many of them" is a really ludicrous answer
> considering 99% of the programs are written with less than 200. Sincerely,
> Doc K. And thanks ahead of time.
>
>
>
--
Thomas J. Grajewski
Engineer
Go to family user guide of your device and thumb through it *look at the
registries specifically*.
Jake G
On Sun, Jul 1, 2012 at 2:08 PM, vineyard wrote:
> **
> This question has probably been answered a thousand times but it's worthy
> of 1001. You see these wonderful names like TACCR0 and P1DIR or WDTPW or
> WDTCTL or WDTHOLD or BCSCTL1. I could go down through all the header files,
> find all the #define statements and try to sort them out using the often
> absent comment statements, but that doesn't make much sense. Obviously I
> missed something But I don't see them in the TI literature like slau131,
> slau157, etc. I'm sure most of them must be explained somewhere and
> conveniently annotated, not just strewn without comment though the
> programming examples like fiberglas laundry lint.
> But none of the programming guides I have seen so far even have the word
> pin or output, seemingly the sort of information one might desire in
> programming language guide for a dedicated systems microprocessor.
> Can anyone help me, please? Help! PS-For the always unhelpful few, the
> answer, "there are too many of them" is a really ludicrous answer
> considering 99% of the programs are written with less than 200. Sincerely,
> Doc K. And thanks ahead of time.
>
>
>
--
Thomas J. Grajewski
Engineer
Reply by ●July 2, 20122012-07-02
On Mon, Jul 2, 2012 at 12:19 AM, vineyard wrote:
> Thanks for the help. Got a good cross section of thinking. Reminds me of my grandfather's tool shop, machinist, farmer, foreman for GE. In the wood floor of his tool shop was a bumblebee's nest which he insisted on encouraging, cute little guys. Ultimately, he was so right, but it took me a while and a whole set of odd clothing to figure out why. He never lost or went looking for a single tool :-)
To further the machinist analogy, remember that machinists often spend
as much time making custom tools as they do final parts. Things are
absolutely no different in software development. A good software
developer will spend as much time developing tools (libraries,
front-ends, quick-reference sheets, etc.) as producing final parts.
It is worth noting that the Arduino toolset has been ported to the
MSP430 under the name "Energia". It is not complete, but it is
usable. If you want to use something like this, be aware that you pay
a *huge* penalty in performance for the hardware abstraction. This
can be a great way to get simple (or even not so simple) tasks done,
but it is a *terrible* way to learn about microcontroller development.
When developing for the MSP430, I suggest you concentrate on a single
family of components, as all of the chips within the family will have
the same peripheral set. The G2/Value Line is a great place to start
as the chips are relatively inexpensive and all of them are available
in DIP packaging.
As mentioned, SLAU144 is the document you want to be working from as
it described all of the features in common to chips in the G2 family.
And yes, if you want to be able to use chips in this family to their
fullest extent, yes, you really do need to understand everything in
that 600-odd page document. Fortunately, each of the peripherals
function independently (for the most part -- all of them will depend
on clocking for example) so you really only need to learn one at a
time. Furthermore, you generally only need to learn a small part
about a peripheral to get it working. There are smaller datasheets
for each chip which provide the specifics on that chip -- most
importantly which peripherals the chip contains and their pinouts.
This is all very confusing to grok as a newbie. Here is a very quick
overview of the MSP430 families:
https://sites.google.com/site/msp430ref/msp430-lineup
I have broken the G2 family out in detail here:
https://sites.google.com/site/msp430ref/msp430-lineup/msp430g2xxx
Links to primary reference documents can be found here:
https://sites.google.com/site/msp430ref/ti-reference-library
In the Family User Guide section, note the links to the Quick
Datasheets. Here is the link to the set of quick datasheets for the
G2 series:
http://www.ti.com/mcu/docs/quickdatasheets.tsp?familyId37
-p.
> Thanks for the help. Got a good cross section of thinking. Reminds me of my grandfather's tool shop, machinist, farmer, foreman for GE. In the wood floor of his tool shop was a bumblebee's nest which he insisted on encouraging, cute little guys. Ultimately, he was so right, but it took me a while and a whole set of odd clothing to figure out why. He never lost or went looking for a single tool :-)
To further the machinist analogy, remember that machinists often spend
as much time making custom tools as they do final parts. Things are
absolutely no different in software development. A good software
developer will spend as much time developing tools (libraries,
front-ends, quick-reference sheets, etc.) as producing final parts.
It is worth noting that the Arduino toolset has been ported to the
MSP430 under the name "Energia". It is not complete, but it is
usable. If you want to use something like this, be aware that you pay
a *huge* penalty in performance for the hardware abstraction. This
can be a great way to get simple (or even not so simple) tasks done,
but it is a *terrible* way to learn about microcontroller development.
When developing for the MSP430, I suggest you concentrate on a single
family of components, as all of the chips within the family will have
the same peripheral set. The G2/Value Line is a great place to start
as the chips are relatively inexpensive and all of them are available
in DIP packaging.
As mentioned, SLAU144 is the document you want to be working from as
it described all of the features in common to chips in the G2 family.
And yes, if you want to be able to use chips in this family to their
fullest extent, yes, you really do need to understand everything in
that 600-odd page document. Fortunately, each of the peripherals
function independently (for the most part -- all of them will depend
on clocking for example) so you really only need to learn one at a
time. Furthermore, you generally only need to learn a small part
about a peripheral to get it working. There are smaller datasheets
for each chip which provide the specifics on that chip -- most
importantly which peripherals the chip contains and their pinouts.
This is all very confusing to grok as a newbie. Here is a very quick
overview of the MSP430 families:
https://sites.google.com/site/msp430ref/msp430-lineup
I have broken the G2 family out in detail here:
https://sites.google.com/site/msp430ref/msp430-lineup/msp430g2xxx
Links to primary reference documents can be found here:
https://sites.google.com/site/msp430ref/ti-reference-library
In the Family User Guide section, note the links to the Quick
Datasheets. Here is the link to the set of quick datasheets for the
G2 series:
http://www.ti.com/mcu/docs/quickdatasheets.tsp?familyId37
-p.
