AW: Re: Digest from [email protected]

Hi Bob

It is normal that arithmetic operations will extend (or sign extend) but
this should not cause any problems. Sign extending from signed to unsigned
or unsigned to signed can of course cause errors but as long as the compile
know the types (which it does . i.e. that you define these as you need them)
there shouldn't be any problems.

It is correct to zero extend an unsigned short to unsigned long.
When extending a signed short to signed long it will depend on the first bit
- if it is zero it will zero extend. If it is 1 it will one extend (to keep
it negative).
I don't understand the problem at the moment and I think that in your case
you should really work with unsigned values (the pulse samples are always
positive values). If you are getting a sign extension to a negative number
this is very unexpected and points to an intermediate variable with
un-matching type. I have used CW for a couple of years in a number of
projects and never had any difficulties of this nature.

Perhaps it would be useful to show the C and assembler in this specific
case. You can right click the file in the CW explorer and right mouse click
to get the context menu and the disassemble command. Then there will be C
and assembler mixed, which could throw light on the matter.

Regards

Mark



-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]] Im
Auftrag von Robert Ritchey
Gesendet: Montag, 15. September 2008 16:33
An: [email protected]
Betreff: [ColdFire] Re: Digest from [email protected]

Hi Mark,
Thanks for that too.  I am afraid I am mostly a 
hardware guy so this is about the
only C compiler I have right now. In the past I 
did most of my work in assembly
on the MSP430.

Which brings me to one last question if I could 
impose.  Basically what I am doing
here is capturing a pulse by a time to determine 
the pulse width.  I capture the
rising and falling edges on a counter that is modulo 16 bits.  The MSP430 is
a
16-bit machine so to get the pulse width I just 
subtracted the falling edge from the
rising edge value and got a positive value.  The 
reason I went to signed shorts on
the coldfire is that I saw in the assembly it was 
loading the shorts with zero extend
and then doing a 32-bit subtract.  I don't think 
this will give me the correct value so
I went to signed shorts and it does.  You 
suggested going to unsigned shorts but
I don't think this will work.  Am I missing something simple here?   Thanks,

At 12:00 AM 9/15/2008 -0500, [email protected] wrote:
>From: "Mark Butcher" <[email protected]>
>To: <[email protected]>
>Subject: AW: [ColdFire] Re: Digest from  [email protected]
>Date: Sun, 14 Sep 2008 22:57:40 +0200
>
>Hi Bob
>Just a side note. I work with several compilers and the CW warnings are in
>fact quite extreme and I do in fact keep them off since otherwise the
>casting required also becomes rather extreme.
>My solution is to compile the project with GCC and Visual-Studio
C-compilers
>and ensure that they don't give any warnings - assuming that this is the
>case, then I am satisfied.
>Regards
>Mark
>
>
>
>-----Ursprüngliche Nachricht-----
>Von: [email protected] [mailto:[email protected]] Im
>Auftrag von Robert Ritchey
>Gesendet: Sonntag, 14. September 2008 16:44
>An: [email protected]
>Betreff: [ColdFire] Re: Digest from [email protected]
>
>Hi Mark,
>Thank you very much for the detailed explanation.  Its very clear now.
>I think with this help I can make some informed decisions on how to
>declare variable types.
>
> >
> >typedef struct
> >      {
> >      short            RiseEdge;                       /* Pulse rising
> >edge time                       */
> >      short            FallEdge;                       /* Pulse
> >falling edge time                      */
> >      } ChanInStruct;
> >
> >bool TxPulseOffset(short *Offset)
> >{
> >      short   PulseWidth;
> >                     /* Pulse width                          */
> >      PulseWidth = (short)(pRxChannelInput->FallEdge -
> >pRxChannelInput->RiseEdge);        /* Pulse width is falling minus rising
>*/
> >}

-Bob
--------------------------------------------------------------------
Robert Ritchey
Quest Engineering & Development, Inc.
Suite B/8
6125 South Ash Avenue
Tempe, AZ 85283
Tel: (480) 460-2652
FAX: (480) 460-2653
E-Mail: [email protected]
E-Mail: [email protected]
E-Mail: [email protected]
E-Mail: [email protected]
WWW: www.QuestEngDev.com/
WWW: www.Smart-Fly.com/
-------------------------------------------------------------------- 

---
[email protected]              Send a post to the list.
[email protected]        Join the list.
[email protected]    Join the list in digest mode.
[email protected]     Leave the list.

---
[email protected]              Send a post to the list.
[email protected]        Join the list.
[email protected]    Join the list in digest mode.
[email protected]     Leave the list.