Reply by quickieaircraft●December 4, 20122012-12-04
Thank you, gentleman--I just wanted to follow up.
I can confirm that these are indeed exactly the issues I ran into. UCS and BCS
are different. Code is obviously not portable because all the predefined
constants are different. I found some UCS configuration code on a blog, which
seems to have given me enough of a start.
And I have confirmed, Grace supports the 2xxx revision family. I haven't
gotten SPI working yet--I'm working on that this week. I also wanted to
add that the Timer configuration seems to be different between the families.
Thanks again!
--- In m..., Thomas Grajewski wrote: >
> Hi All,
> Last time I looked at Grace it could only be used with the 2x line, aka it
> was made to work with the launch pad/ value line. I have personally
> switched from the 2618 to the 5438a and if memory serves me correctly it
> was not hard but, as Al mentioned, the clock is different and requires
> different init functions. I believe the UART, SPI, etc are very similar but
> even if they are not and if you program them correctly it should be easy to
> change between. The only other worry I have is the ports will not line up
> because that is a pretty big jump and I doubt the pins will be that nice,
> but yet again you may just be that lucky.
>
> Jake G.
>
> On Mon, Jul 9, 2012 at 10:02 AM, Onestone wrote:
>
> > **
> >
> >
> > Well, for a start they use different clock systems, the 2618 uses the
> > basic clock system+, while the 5528 uses the unified clock system, but,
> > even more basically they have different CPU cores. The 5528 has word
> > wide port options, and a totally incompatible pin out, so, even if you
> > strip back your usage to the minimum, and the UARTs have identical
> > structure in terms of register and bit allocations you will still need
> > to be wary of shifting pins for initialising the peripherals, as well as
> > shifting ports, for example on the 2618 USCIA1 is split cross ports 3 &
> > 5, whereas it resides entirely in port 4 on the 5528..
> >
> > I don't know what level you program in, I assume C, but I know Ti have
a
> > port configuration utility called GRACE (i think) i've never used
it,
> > but that might help remove some of the drudgery.
> >
> > Cheers
> >
> > Al
> >
> >
> > On 10/07/2012 1:00 AM, quickieaircraft wrote:
> > >
> > > For a newcomer to this field, these links are very helpful!
> > >
> > > I'm working on a board where the F2618 processor has been upgraded
to
> > F5528 processor. The i2c bus is in use, PWM signals being generated, and
an
> > SPI peripheral has been added, which I'll need to implement.
> > >
> > > Is it wishful thinking to hope that all I'll need to do to
accommodate
> > tho processor upgrade is to change the header files? If so, are there
> > particular items that are obviously going to need to be addressed?
> > >
> > > Thank you.
> > >
> > > --- 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
> > >>
> > >
> > >
> > >
> > >
> >
> > >
> > >
> > >
> > >
Hi All,
Last time I looked at Grace it could only be used with the 2x line, aka it
was made to work with the launch pad/ value line. I have personally
switched from the 2618 to the 5438a and if memory serves me correctly it
was not hard but, as Al mentioned, the clock is different and requires
different init functions. I believe the UART, SPI, etc are very similar but
even if they are not and if you program them correctly it should be easy to
change between. The only other worry I have is the ports will not line up
because that is a pretty big jump and I doubt the pins will be that nice,
but yet again you may just be that lucky.
Jake G.
On Mon, Jul 9, 2012 at 10:02 AM, Onestone wrote:
> **
> Well, for a start they use different clock systems, the 2618 uses the
> basic clock system+, while the 5528 uses the unified clock system, but,
> even more basically they have different CPU cores. The 5528 has word
> wide port options, and a totally incompatible pin out, so, even if you
> strip back your usage to the minimum, and the UARTs have identical
> structure in terms of register and bit allocations you will still need
> to be wary of shifting pins for initialising the peripherals, as well as
> shifting ports, for example on the 2618 USCIA1 is split cross ports 3 &
> 5, whereas it resides entirely in port 4 on the 5528..
>
> I don't know what level you program in, I assume C, but I know Ti have
a
> port configuration utility called GRACE (i think) i've never used it,
> but that might help remove some of the drudgery.
>
> Cheers
>
> Al
> On 10/07/2012 1:00 AM, quickieaircraft wrote:
> >
> > For a newcomer to this field, these links are very helpful!
> >
> > I'm working on a board where the F2618 processor has been upgraded
to
> F5528 processor. The i2c bus is in use, PWM signals being generated, and an
> SPI peripheral has been added, which I'll need to implement.
> >
> > Is it wishful thinking to hope that all I'll need to do to
accommodate
> tho processor upgrade is to change the header files? If so, are there
> particular items that are obviously going to need to be addressed?
> >
> > Thank you.
> >
> > --- 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 Onestone●July 9, 20122012-07-09
Well, for a start they use different clock systems, the 2618 uses the
basic clock system+, while the 5528 uses the unified clock system, but,
even more basically they have different CPU cores. The 5528 has word
wide port options, and a totally incompatible pin out, so, even if you
strip back your usage to the minimum, and the UARTs have identical
structure in terms of register and bit allocations you will still need
to be wary of shifting pins for initialising the peripherals, as well as
shifting ports, for example on the 2618 USCIA1 is split cross ports 3 &
5, whereas it resides entirely in port 4 on the 5528..
I don't know what level you program in, I assume C, but I know Ti have a
port configuration utility called GRACE (i think) i've never used it,
but that might help remove some of the drudgery.
Cheers
Al
On 10/07/2012 1:00 AM, quickieaircraft wrote: >
> For a newcomer to this field, these links are very helpful!
>
> I'm working on a board where the F2618 processor has been upgraded to
F5528 processor. The i2c bus is in use, PWM signals being generated, and an SPI
peripheral has been added, which I'll need to implement.
>
> Is it wishful thinking to hope that all I'll need to do to accommodate
tho processor upgrade is to change the header files? If so, are there
particular items that are obviously going to need to be addressed?
>
> Thank you.
>
> --- 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 Bob●July 9, 20122012-07-09
>are there particular items that are obviously going to
need to be addressed?< Since you didn't specifically mention it, I'll ask the
question: Have you compared the pinouts of the two chips?
--- In m..., "quickieaircraft" wrote: >
> For a newcomer to this field, these links are very helpful!
>
> I'm working on a board where the F2618 processor has been upgraded to
F5528 processor. The i2c bus is in use, PWM signals being generated, and an SPI
peripheral has been added, which I'll need to implement.
>
> Is it wishful thinking to hope that all I'll need to do to accommodate
tho processor upgrade is to change the header files? If so, are there
particular items that are obviously going to need to be addressed?
>
> Thank you.
>
> --- 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 quickieaircraft●July 9, 20122012-07-09
For a newcomer to this field, these links are very helpful!
I'm working on a board where the F2618 processor has been upgraded to F5528
processor. The i2c bus is in use, PWM signals being generated, and an SPI
peripheral has been added, which I'll need to implement.
Is it wishful thinking to hope that all I'll need to do to accommodate tho
processor upgrade is to change the header files? If so, are there particular
items that are obviously going to need to be addressed?
Reply by Alexander Espinosa●July 2, 20122012-07-02
look for chip datasheets and family user manuals for the specific reference
you´re using
bye
________________________________
From: vineyard
To: m...
Sent: Sunday, July 1, 2012 4:08 PM
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 Peter Johansson●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:
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 vineyard●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 :-)
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.
> >
> >
> >
> >
> >
> >
> >
> >
