Searching \ for '[OT:] I say it is spinach and to hell with it!' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serial/spis.htm?key=spi
Search entire site for: 'I say it is spinach and to hell with it!'.

Exact match. Not showing close matches.
PICList Thread
'[OT:] I say it is spinach and to hell with it!'
2005\08\17@180556 by Rich Painter

picon face
part 1 10509 bytes content-type:multipart/signed; protocol="application/x-pkcs7-signature"; (decoded 7bit)

This is a cryptographically signed message in MIME format.

--------------ms040609070408020904090706
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

subject=Re:[OT:] I say it is spinach and to hell with it!
source= http://www.piclist.com/piclist/2005/08/15/202822a.txt?

---
Rich Painter
http://www.piclist.com/member/RP-PEI-VC8
PIC/PICList FAQ: http://www.piclist.com

I'm new to piclist so try not to pounce on me too hard...  An associate of mine
advised me to join and in particular suggested I read this thread.  So, here I am.

I have been programming since 1974, first with FORTRAN for several years, then
assemblers off and on for 6 years while doing more FORTRAN and then C.  I have
been writing C almost exclusively since 1981. Most, if not all, on much larger
systems than PICs, the current discussion topic.  I don't do C++ or Java and
likely never will.

I believe that a good C programmer using a good C compiler will outperform in
both overall code performance and especially development schedule any assembler.
 There are a good number of studies that show this and I personally have
experienced it a lot.

I have all the docs, k&r from day 1, k&r 2nd ed., the ansi and iso specs and the
latest "c99" stuff and use them all.  Yes, C has changed over time.  Some of you
say not for the best and others are more or less content.  I think a lot of good
things have come about in the newer versions and I use what works best and is
best for the application.

I have worked with many version on many platforms.  The core of C is the
language spec and this I've seen to be highly adhered to by nearly all the
vendors I've used.  But what most programmers need are the "supporting" features
embodied in all the libraries.  Here is where the "interface" to the OS, or bare
hardware as in PICs, happens and also many of the differences, major or minor,
between vendors and platforms occur.  This is how it should be.

So, when one moves from one platform or vendor to another one will see differences.

My first PIC project has been underway for many months.  I selected the
Microchip dsPIC 6012.  Since I am pretty good at C and there was a C compiler
available I decided to try it.  I have, since almost from its inception, used
the GNU gcc C compiler.  It has a  good history, strong support, good code and
widely available on platforms.  Learning that Microchip based their dsPIC C on
this compiler offered me some faith and comfort.

I have had some problems with Microchip's "system": IDE, ICD2 and C30.  Details
aside, most are integration issues.  I have reported (almost) every one of the
things I found "hinky", some were C issues.

Because of architecture, just as all of you have already debated here, there are
differences that *may* be badly implemented, faulty or simply annoy us.  I have
needed and used the long long data type and have had problems.  Their
implementation may not be too good.  We have not routed the cause yet.  On their
behalf I will say that this area has not been optimized like other parts of
their floating point and other math functions.  Their developers have also been
working with me to resolve the issues I have encountered and I thank them for
their efforts.

One departure I think is not right is the notion that data type "double" is not
really double.  In fact, even if one uses "double" it will not be a double but
rather a float unless a special compiler flag is used.  This also affects the
sprintf() conversion types because they don't promote the floats to double when
using as args to sprintf() and its cousins.  This you and I have a bitch about.
 This I have not yet raised with them, but I will.  There "C coded device"
library, including source is very weak.  I have not used it.  I use
interrupt-driven interfaces and none of their "samples" do this.

I also don't like their departure from using standard "composite ORed single-bit
masks".  They use "ANDed multi-bit masks" that were so hard to get used to and
couldn't be used for bit testing I completely abandoned their include files and
use my own.  Masks based on single bits can be used for both setting and
detecting a given bit's functions in hardware.  NOT so with these bizarre
multi-bit masks.  In fact I have never seen this done before in the 24 years I
have been developing C!

Your conjecture that "C30" means it is a C variant I say is completely false
(excepting the double-float issue).  I think it is a name given to indicate it
is for the dsPIC line only, differentiating it from their other non-gcc-based C
compiler.  If you read their C30 User's Guide (51284d) you will see the
standards compliance section where they spell out any differences.  This is
admirable and in line with what gcc does.  Do the other vendors do this?  I
don't know.

Even so, on the whole C30 is a good compiler.  The code generated for most
"normal" stuff is good.  Their weak side is the floating and long long types.  I
currently have about 5000 lines of C (and comments and includes) for my chip
code and use just a small amount of floats and a few long long.

I have not used any other PIC C compiler so I don't know how others compare to
the dsPIC and C30.  You can bash C30 all you want but you will only get smidgen
of concurrence from me.  I suspect any of the other C vendors for PICs will have
some warts too.

I will continue to use C, Microchip's or not, when programming PICs because I
can get much more done with the same schedule, have benefits of HLL without the
code penalty, and continue to use long-ago-developed code (reuse) for stuff I
have proven reliability for.

I'll take your questions now!

rich


--------------ms040609070408020904090706
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII5TCC
As0wggI2oAMCAQICAw24sTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMTAxMjEzMjUyWhcNMDYwMTAxMjEzMjUy
WjBCMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBw
YWludGVyQGllZWUub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAug6HQA5h
BaTxQFRUVPzkIqXC3O27z7HeEJxvFcLZnx6eBllV6vcbkskAbGWuuVWdTTQVChrjuHlkO24q
64lSzGear/QSbA5KhQIfhHA14nMetDIxQ79rZmTVi1fqObLJKKc7I3+2OPBvWrJ56yqnbLpq
FM8SAZkJwQa38ySTy4+brA5zgUM4wh/6/5K9AzFD1oAuzwmvRMI6f8AxwyVfkdyccLoNIRWZ
oe2I+qcl4KHoTony6w2cTw62/EyPmgyT2GdrOsM/yV/TuvieV1vzFxqfNHvsyTKpvQpXyPSP
ex6xVW2BYhCJxUBplcCi/VtWA7SUHxakFPrNXncQHouO+QIDAQABoy0wKzAbBgNVHREEFDAS
gRBwYWludGVyQGllZWUub3JnMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAWR+n
3SfdYSASyGuaV0tFljOKds7vpBcUJtpCEGe1Tvr4vMYpw6HfWXcveRswhh/3nWQBQCq7bwC+
YkRTMM2pPaINhR891nUWHuR43w4TOBLQKAX6MvdAu438GK7/mxf7dRPZEN6Cy9rkPBZz07T1
0nUU39qu2u46r8zaadAVOGUwggLNMIICNqADAgECAgMNuLEwDQYJKoZIhvcNAQEEBQAwYjEL
MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq
BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDEwMTIx
MzI1MloXDTA2MDEwMTIxMzI1MlowQjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJl
cjEfMB0GCSqGSIb3DQEJARYQcGFpbnRlckBpZWVlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBALoOh0AOYQWk8UBUVFT85CKlwtztu8+x3hCcbxXC2Z8engZZVer3G5LJ
AGxlrrlVnU00FQoa47h5ZDtuKuuJUsxnmq/0EmwOSoUCH4RwNeJzHrQyMUO/a2Zk1YtX6jmy
ySinOyN/tjjwb1qyeesqp2y6ahTPEgGZCcEGt/Mkk8uPm6wOc4FDOMIf+v+SvQMxQ9aALs8J
r0TCOn/AMcMlX5HcnHC6DSEVmaHtiPqnJeCh6E6J8usNnE8OtvxMj5oMk9hnazrDP8lf07r4
nldb8xcanzR77Mkyqb0KV8j0j3sesVVtgWIQicVAaZXAov1bVgO0lB8WpBT6zV53EB6LjvkC
AwEAAaMtMCswGwYDVR0RBBQwEoEQcGFpbnRlckBpZWVlLm9yZzAMBgNVHRMBAf8EAjAAMA0G
CSqGSIb3DQEBBAUAA4GBAFkfp90n3WEgEshrmldLRZYzinbO76QXFCbaQhBntU76+LzGKcOh
31l3L3kbMIYf951kAUAqu28AvmJEUzDNqT2iDYUfPdZ1Fh7keN8OEzgS0CgF+jL3QLuN/Biu
/5sX+3UT2RDegsva5DwWc9O09dJ1FN/artruOq/M2mnQFThlMIIDPzCCAqigAwIBAgIBDTAN
BgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTES
MBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UE
CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0
aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK
MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTX
p6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYB
Af8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl
cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYD
VQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2as
Zw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe
JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHT
HUb/XV9lTzGCAzswggM3AgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD
b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp
bCBJc3N1aW5nIENBAgMNuLEwCQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3
DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUwODE3MjIwNTUzWjAjBgkqhkiG9w0BCQQxFgQU2svO
eXgwuHoxibu4UFLIlXgKOe4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG
9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYB
BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECAw24sTB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo
YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG
cmVlbWFpbCBJc3N1aW5nIENBAgMNuLEwDQYJKoZIhvcNAQEBBQAEggEAsLpOWfcqQSJjmOL7
eQRvxmG2KfCu+/Pw+lOsJDQMWXTxPbXxXlIddK//2sDw2V3OzEZwmJit1OuFxqrbP5NrtAmw
uRPpRtAHjfTaJyfhUnzSCjrvSLIkkaDLGr3g9CT+JkPW7l7zahJNoK3H5R+WONCAlZGYRt1p
VN3tK9ZoLefD3G3fb2lOV7BI+FLCgXC20Wx88DhbQ0k0uBzfsO4iKPW/GXvMthF4uXU1dYav
eyXi9xIqGsPAr2pzSlIbyDJlBD8v3cvp/VC2dHOe0PW4n1eYL9uXJwXQzEBPqdd/M2HpCIJL
J7stFzPReck26Wq2yM4WQWnlppoi/X0d71IZeQAAAAAAAA==
--------------ms040609070408020904090706--


part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2005\08\17@191642 by olin piclist

face picon face
Rich Painter wrote:

<nothing>

Do you realize that your message showed up as empty, at least in Outlook
Express?  All I saw was the footer added by the list server.

And no, I don't want to hear about how this is Outlook's fault whether it is
or not.  I'm just letting you know that I didn't see your message, if indeed
you included one.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\08\17@191823 by Rich Painter

picon face
subject=Re:[OT:] I say it is spinach and to hell with it!
source= http://www.piclist.com/piclist/2005/08/15/202822a.txt?

---
Rich Painter
http://www.piclist.com/member/RP-PEI-VC8
PIC/PICList FAQ: http://www.piclist.com

I'm new to piclist so try not to pounce on me too hard...  An associate of mine
advised me to join and in particular suggested I read this thread.  So, here I am.

I have been programming since 1974, first with FORTRAN for several years, then
assemblers off and on for 6 years while doing more FORTRAN and then C.  I have
been writing C almost exclusively since 1981. Most, if not all, on much larger
systems than PICs, the current discussion topic.  I don't do C++ or Java and
likely never will.

I believe that a good C programmer using a good C compiler will outperform in
both overall code performance and especially development schedule any assembler.
  There are a good number of studies that show this and I personally have
experienced it a lot.

I have all the docs, k&r from day 1, k&r 2nd ed., the ansi and iso specs and the
latest "c99" stuff and use them all.  Yes, C has changed over time.  Some of you
say not for the best and others are more or less content.  I think a lot of good
things have come about in the newer versions and I use what works best and is
best for the application.

I have worked with many version on many platforms.  The core of C is the
language spec and this I've seen to be highly adhered to by nearly all the
vendors I've used.  But what most programmers need are the "supporting" features
embodied in all the libraries.  Here is where the "interface" to the OS, or bare
hardware as in PICs, happens and also many of the differences, major or minor,
between vendors and platforms occur.  This is how it should be.

So, when one moves from one platform or vendor to another one will see differences.

My first PIC project has been underway for many months.  I selected the
Microchip dsPIC 6012.  Since I am pretty good at C and there was a C compiler
available I decided to try it.  I have, since almost from its inception, used
the GNU gcc C compiler.  It has a  good history, strong support, good code and
widely available on platforms.  Learning that Microchip based their dsPIC C on
this compiler offered me some faith and comfort.

I have had some problems with Microchip's "system": IDE, ICD2 and C30.  Details
aside, most are integration issues.  I have reported (almost) every one of the
things I found "hinky", some were C issues.

Because of architecture, just as all of you have already debated here, there are
differences that *may* be badly implemented, faulty or simply annoy us.  I have
needed and used the long long data type and have had problems.  Their
implementation may not be too good.  We have not routed the cause yet.  On their
behalf I will say that this area has not been optimized like other parts of
their floating point and other math functions.  Their developers have also been
working with me to resolve the issues I have encountered and I thank them for
their efforts.

One departure I think is not right is the notion that data type "double" is not
really double.  In fact, even if one uses "double" it will not be a double but
rather a float unless a special compiler flag is used.  This also affects the
sprintf() conversion types because they don't promote the floats to double when
using as args to sprintf() and its cousins.  This you and I have a bitch about.
  This I have not yet raised with them, but I will.  There "C coded device"
library, including source is very weak.  I have not used it.  I use
interrupt-driven interfaces and none of their "samples" do this.

I also don't like their departure from using standard "composite ORed single-bit
masks".  They use "ANDed multi-bit masks" that were so hard to get used to and
couldn't be used for bit testing I completely abandoned their include files and
use my own.  Masks based on single bits can be used for both setting and
detecting a given bit's functions in hardware.  NOT so with these bizarre
multi-bit masks.  In fact I have never seen this done before in the 24 years I
have been developing C!

Your conjecture that "C30" means it is a C variant I say is completely false
(excepting the double-float issue).  I think it is a name given to indicate it
is for the dsPIC line only, differentiating it from their other non-gcc-based C
compiler.  If you read their C30 User's Guide (51284d) you will see the
standards compliance section where they spell out any differences.  This is
admirable and in line with what gcc does.  Do the other vendors do this?  I
don't know.

Even so, on the whole C30 is a good compiler.  The code generated for most
"normal" stuff is good.  Their weak side is the floating and long long types.  I
currently have about 5000 lines of C (and comments and includes) for my chip
code and use just a small amount of floats and a few long long.

I have not used any other PIC C compiler so I don't know how others compare to
the dsPIC and C30.  You can bash C30 all you want but you will only get smidgen
of concurrence from me.  I suspect any of the other C vendors for PICs will have
some warts too.

I will continue to use C, Microchip's or not, when programming PICs because I
can get much more done with the same schedule, have benefits of HLL without the
code penalty, and continue to use long-ago-developed code (reuse) for stuff I
have proven reliability for.

I'll take your questions now!

rich


2005\08\17@192810 by Jinx

face picon face

> Rich Painter wrote:
>
> <nothing>
>
> Do you realize that your message showed up as empty, at least
> in Outlook Express?  All I saw was the footer added by the list
> server.

Looked OK here with OE Olin, although I notice your reply has an
extra Re: (perhaps because the OP included : with the OT ?)

BTW Rich, my brother realises he'll never be a "Rich Painter (and
decorator)" with 3 school-age kids to feed and clothe ;-)

2005\08\17@204747 by William Chops Westfield

face picon face

On Aug 17, 2005, at 3:05 PM, Rich Painter wrote:

> I selected the Microchip dsPIC 6012.
>        :
> I have needed and used the long long data type and have had problems.  
> Their implementation may not be too good.
       :
> One departure I think is not right is the notion that data type
> "double" is not really double.

Ah.  It hadn't occurred to me that the dsPIC compiler would be
one of the places where people would be beginning to use floating
point in a big way, and that there might be flaws in that area.

On the smaller PICs, floating point is generally strongly avoided.

(indeed, FP is avoided on many embedded platforms for somewhat
historic performance reasons.  Cisco's IOS is well over 20M
of binary with no floating point to speak of...)

BillW

2005\08\19@122331 by Herbert Graf

flavicon
face
On Wed, 2005-08-17 at 17:47 -0700, William Chops Westfield wrote:
> Ah.  It hadn't occurred to me that the dsPIC compiler would be
> one of the places where people would be beginning to use floating
> point in a big way, and that there might be flaws in that area.
>
> On the smaller PICs, floating point is generally strongly avoided.
>
> (indeed, FP is avoided on many embedded platforms for somewhat
> historic performance reasons.  Cisco's IOS is well over 20M
> of binary with no floating point to speak of...)

I'd say it's more then just performance reasons.

Floating point can be a very dangerous tool when doing things that
interact in the real world. Because of it's huge dynamic range it's very
easy for small errors to creep into calculations, eventually becoming
big errors.

A good example of this is something I encountered in my second year in
University.

During a mid term exam there was one question that I got stuck on. It
was a materials course, and there were huge ranges of numbers (numbers
of atoms, universal constants, etc.).

The question was quite simple, a few formulas and the answer should have
come out. But every time I did the calculations the result was obviously
wrong (obvious only if you understood the concepts behind the question).

On closer inspection I found that there was one area in the calculations
where a calculator ended up with an answer of zero. The reason being the
number was smaller then 1E-99, which most calculators out there simply
respond as "zero".

I did that portion of the calculation by hand and ended up with a
reasonable (and correct) answer. Most people got the wrong answer, and
complained to the Prof that the calculator indeed gave that answer.

The Prof came back simply with: don't blindly trust your calculator. I'm
convinced (although he never admitted it) that he purposely structured
that question in that way since he knew only people who TRULY understood
what all the formulas were for would get the correct answer. VERY
sneaky!

Similarly, in controller applications you can quickly get into trouble
if you do to many FP ops. If you don't properly check end cases you can
end up with inputs generating blatently wrong outputs.

Of course, this is easily done with fixed point as well. The difference
is people are more careful with fixed point. They consider the range of
numbers, the end cases, and choose a fixed point position base on those
results.

With FP people tend to think "I can handle ANY range" and end up causing
very bad things to happen.

FP is good if you understand what it really is and plan your inputs
properly to deal with the pitfalls.

Personally I've never needed to use FP in an embedded project. I'm not
saying I NEVER will, but so far I haven't.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\08\19@133314 by Spehro Pefhany

picon face
At 12:23 PM 8/19/2005 -0400, you wrote:


>Of course, this is easily done with fixed point as well. The difference
>is people are more careful with fixed point. They consider the range of
>numbers, the end cases, and choose a fixed point position base on those
>results.
>
>With FP people tend to think "I can handle ANY range" and end up causing
>very bad things to happen.

Another thing-it's not hard to get into trouble in real situations using
the "small" FP representations (like 24 bits). If you're just doing m*x+b
type stuff, then the problem never crops up, but if you're evaluating
an ill-conditioned polynomial etc. it's pretty easy to lose enough
bits to cause problems with real-world 3-4 decimal digit numbers. This is
not "round-off error". Conceptually, what happens is that two almost-equal
numbers in a partial result are subtracted, leaving many fewer bits than
were there originally. If possible, a better algorithm is one answer, but
that's not always convenient (for example, it may consume a LOT more code
memory if you substitute many low-order cubic splines for one or two poly
fits).

The FP math will be at least as good as the fixed-point math if the
number of bits *in the mantissa* is at least as many as the bits in the
fixed-point numbers. The bits devoted to the exponent are essentially wasted
as far as this issue goes, since you handle the scaling manually during
programming.

Personally, I find myself using FP math more these days in instrumentation
and control firmware. Back in the old days, when every byte and every cycle
counted, it was most undesirable in most applications, but now it has its
place.

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\08\20@083043 by Gerhard Fiedler

picon face
Herbert Graf wrote:

> The question was quite simple, a few formulas and the answer should have
> come out. But every time I did the calculations the result was obviously
> wrong (obvious only if you understood the concepts behind the question).
>
> On closer inspection I found that there was one area in the calculations
> where a calculator ended up with an answer of zero. The reason being the
> number was smaller then 1E-99, which most calculators out there simply
> respond as "zero".
>
> I did that portion of the calculation by hand and ended up with a
> reasonable (and correct) answer.

That's why I think that they did a disservice to students when they stopped
teaching how to do such calculations with a slide rule. I was pretty much
the last generation that had to learn how to do this. While of course a
slide rule is pretty much obsolete now, the concepts of how to quickly
estimate the range of a numeric result are still as essential as ever.

Gerhard

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...