The documentation, when the 'F' series was first released, was
attrocious, now it's pretty good. The only real issue is the lack of
hardcover availability of SLAUE10B and SLAU024.
Al
Everett M. Greene wrote:
> "David R. McCoy" <laserprojector2003@yahoo.com> writes:
> [snip]
>
>>I'm learning alot about this uC. As many times as I've
>>looked at the datasheet, there are still things that I'm
>>missing.
>
>
> Have fun with the errors, omissions, and ambiguities of
> the documentation...
--
Please remove capitalised letters to reply
My apologies for the inconvenience
Blame it on the morons that spam the net
Reply by Mark Borgerson●July 17, 20042004-07-17
In article <608b6569.0407161255.65dc04c1@posting.google.com>,
larwe@larwe.com says...
Thanks for the pointer. I also picked up a copy of "Embedded Systems
Design on a Shoestring" while I was there. Never too late for an old
nerd to learn a few new tricks! ;-)
Mark Borgerson
Reply by Lewin A.R.W. Edwards●July 16, 20042004-07-16
> The MSP430 appears to have growing popularity, and it seems a book
> on it, especially covering gotcha's and not just being a rehash of the
> TI docs, might actually sell enough copies to make it worthwhile.
Reply by Everett M. Greene●July 15, 20042004-07-15
Ben Bradley <ben_nospam_bradley@mindspring.com> writes:
> mojaveg@mojaveg.iwvisp.com (Everett M. Greene) wrote:
> >"David R. McCoy" <laserprojector2003@yahoo.com> writes:
> >[snip]
> >> I'm learning alot about this uC. As many times as I've
> >> looked at the datasheet, there are still things that I'm
> >> missing.
> >
> >Have fun with the errors, omissions, and ambiguities of
> >the documentation...
>
> This could be a separate thread, as TI is far from the only
> manufacturer to have less-than-wonderful documentation. I seriously
> considered writing some sort of "Programming and Using The..." book on
> the Zilog Z89371 DSP when I was learning/using/designing it in. I got
> my ass bit a bunch of times (not just the docummentation, but various
> features that didn't work, assembler silently and happily generating
> bad object code from a bad instruction, etc), and it would have been
> an invaluable, time-saving guide for avoiding gotcha's for anyone who
> would want to use that chip. For good or bad, it looks like few people
> wanted to use it.
> The MSP430 appears to have growing popularity, and it seems a book
> on it, especially covering gotcha's and not just being a rehash of the
> TI docs, might actually sell enough copies to make it worthwhile.
We could also get into a "discussion" of some manufacturers'
not producing hardcopies of their docs anymore. We each
get to produce our own at 10X the cost of the manufacturer
doing it.
Reply by Ben Bradley●July 14, 20042004-07-14
On Wed, 14 Jul 2004 08:13:18 PST, mojaveg@mojaveg.iwvisp.com (Everett
M. Greene) wrote:
>"David R. McCoy" <laserprojector2003@yahoo.com> writes:
>[snip]
>> I'm learning alot about this uC. As many times as I've
>> looked at the datasheet, there are still things that I'm
>> missing.
>
>Have fun with the errors, omissions, and ambiguities of
>the documentation...
This could be a separate thread, as TI is far from the only
manufacturer to have less-than-wonderful documentation. I seriously
considered writing some sort of "Programming and Using The..." book on
the Zilog Z89371 DSP when I was learning/using/designing it in. I got
my ass bit a bunch of times (not just the docummentation, but various
features that didn't work, assembler silently and happily generating
bad object code from a bad instruction, etc), and it would have been
an invaluable, time-saving guide for avoiding gotcha's for anyone who
would want to use that chip. For good or bad, it looks like few people
wanted to use it.
The MSP430 appears to have growing popularity, and it seems a book
on it, especially covering gotcha's and not just being a rehash of the
TI docs, might actually sell enough copies to make it worthwhile.
Reply by Everett M. Greene●July 14, 20042004-07-14
"David R. McCoy" <laserprojector2003@yahoo.com> writes:
[snip]
> I'm learning alot about this uC. As many times as I've
> looked at the datasheet, there are still things that I'm
> missing.
Have fun with the errors, omissions, and ambiguities of
the documentation...
Reply by Ben Bradley●July 14, 20042004-07-14
On Tue, 13 Jul 2004 17:21:44 GMT, onestone
<onestoneXYZ@ABCbigpond.net.au> wrote:
>Unbeliever wrote:
>
>> "Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
>>
>>
>>>If the MSP430 you are using has a hardware multiplier- you can simply
>>>flip bits from the MSB down to the LSB, test (by squaring the number),
>>>correct and move down to the next bit till you get to the LSB- and it
>>>will be pretty fast and compact.
>>>
>>
>>
>> Otherwise google on "Newton's method" or "Newton-Raphson". What could Sir
>> Isaac have achieved with a PC?
>
>Not much if he didn't have electricity and decided to drop it from a tree.
I recall the tagline:
"How do you accelerate a Macintosh? 9.8 meters/second."
>Al
Reply by David R. McCoy●July 13, 20042004-07-13
"onestone" <onestoneXYZ@ABCbigpond.net.au> wrote in message
news:%YUIc.93023$sj4.19808@news-server.bigpond.net.au...
> David R. McCoy wrote:
>
> > "Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
> > news:gft4f0puqf9ckmurmr66nv0mn5s2f5tjvb@4ax.com...
> >
> >>On Mon, 12 Jul 2004 02:57:49 GMT, the renowned "David R. McCoy"
> >><laserprojector2003@yahoo.com> wrote:
> >>
> >>
> >>>Hi All,
> >>>
> >>>What is TI talking about when they refer to the floating point
> >
> > package(FPP)?
> >
> >>>Is is able to be used on any of their uC?
> >>>
> >>>I need the uC to take the square root of a number and it seems that
I'll
> >>>have to use the FPP to do it. Is that true?
> >>
> >>Certainly not. But doing it that way might avoid having to write any
> >>code. If that's the only reason you need to include floating point
> >>math it will likely be quite inefficient wrt code size and speed.
> >>
> >>If the MSP430 you are using has a hardware multiplier- you can simply
> >>flip bits from the MSB down to the LSB, test (by squaring the number),
> >>correct and move down to the next bit till you get to the LSB- and it
> >>will be pretty fast and compact.
> >>
> >>Best regards,
> >>Spehro Pefhany
> >>--
> >>"it's the network..." "The Journey is the
reward"
> >>speff@interlog.com Info for manufacturers:
> >
> > http://www.trexon.com
> >
> >>Embedded software/hardware/analog Info for designers:
> >
> > http://www.speff.com
> >
> >
> > I don't believe that the uC that I'm using has a hardware multiplier but
> > I'll check.
>
> This suggests that you're in trouble anyway, since you don't know what
> features your target micro has. The F149 you are using has a hardware
> multiplier, but if I were you I'd use the floating point packet rather
> than try and write your own routine.
>
> > The calculation that I need to perform will only need to
> > perform 1 square root per event. The period between each event is
measured
> > in tens of seconds. Writing a routine that sets a bit and then squares
it &
> > tests sounds like it might be the way to go.
> >
> > thanks for everyones response.
>
> In a later post you state that you are using a compiler. Thus C. Most of
> the current C compilers have floating point procedures anyway. Probably
> even a sqr() function if not you need to do more than just include the
> header file, you must also include the *.lib file or source file that
> includes the actual functions.
>
> Al
>
Hi Al,
Ok. I can see that I'm stumbling on words now. I said "compiler" but I
meant "assembler". Sorry for the mixup. My C code abilities are very
limited. I'm trying to do this in Assembly since I'm more familiar with
that than C.
I also checked and yes, the F149 does have the hardware multiplier. I'm
learning alot about this uC. As many times as I've looked at the datasheet,
there are still things that I'm missing. Thanks.
I'll look into the FPP a bit closer and also evaluate some of the other
suggestions made here.
Thank you for your help. I may be back . . .
Reply by onestone●July 13, 20042004-07-13
David R. McCoy wrote:
> "Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
> news:gft4f0puqf9ckmurmr66nv0mn5s2f5tjvb@4ax.com...
>
>>On Mon, 12 Jul 2004 02:57:49 GMT, the renowned "David R. McCoy"
>><laserprojector2003@yahoo.com> wrote:
>>
>>
>>>Hi All,
>>>
>>>What is TI talking about when they refer to the floating point
>
> package(FPP)?
>
>>>Is is able to be used on any of their uC?
>>>
>>>I need the uC to take the square root of a number and it seems that I'll
>>>have to use the FPP to do it. Is that true?
>>
>>Certainly not. But doing it that way might avoid having to write any
>>code. If that's the only reason you need to include floating point
>>math it will likely be quite inefficient wrt code size and speed.
>>
>>If the MSP430 you are using has a hardware multiplier- you can simply
>>flip bits from the MSB down to the LSB, test (by squaring the number),
>>correct and move down to the next bit till you get to the LSB- and it
>>will be pretty fast and compact.
>>
>>Best regards,
>>Spehro Pefhany
>>--
>>"it's the network..." "The Journey is the reward"
>>speff@interlog.com Info for manufacturers:
>
> http://www.trexon.com
>
>>Embedded software/hardware/analog Info for designers:
>
> http://www.speff.com
>
>
> I don't believe that the uC that I'm using has a hardware multiplier but
> I'll check.
This suggests that you're in trouble anyway, since you don't know what
features your target micro has. The F149 you are using has a hardware
multiplier, but if I were you I'd use the floating point packet rather
than try and write your own routine.
> The calculation that I need to perform will only need to
> perform 1 square root per event. The period between each event is measured
> in tens of seconds. Writing a routine that sets a bit and then squares it &
> tests sounds like it might be the way to go.
>
> thanks for everyones response.
In a later post you state that you are using a compiler. Thus C. Most of
the current C compilers have floating point procedures anyway. Probably
even a sqr() function if not you need to do more than just include the
header file, you must also include the *.lib file or source file that
includes the actual functions.
Al
Reply by onestone●July 13, 20042004-07-13
Unbeliever wrote:
> "Spehro Pefhany" <speffSNIP@interlogDOTyou.knowwhat> wrote in message
>
>
>>If the MSP430 you are using has a hardware multiplier- you can simply
>>flip bits from the MSB down to the LSB, test (by squaring the number),
>>correct and move down to the next bit till you get to the LSB- and it
>>will be pretty fast and compact.
>>
>
>
> Otherwise google on "Newton's method" or "Newton-Raphson". What could Sir
> Isaac have achieved with a PC?
Not much if he didn't have electricity and decided to drop it from a tree.
Al