CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

4.096 breaking apart int32

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
ljbeng



Joined: 10 Feb 2004
Posts: 205

View user's profile Send private message

4.096 breaking apart int32
PostPosted: Mon Nov 02, 2009 10:34 am     Reply with quote

I have the PIC24FJ128GA006 and PCWHD 4.096 compiler.

Here is what I am trying to do:
Code:

float readfile(int32 srval){
   int8 srv[4];
   clrbuff();
   if (srval > 0 ) {
      srval = 0x09080706;
      srv[0] = ((srval & 0xff000000)>>24);
      srv[1] = ((srval & 0xff0000)>>16);
      srv[2] = ((srval & 0xff00)>>8);
      srv[3] = ((srval & 0xff));
      fprintf(u1,"SEK %c%c%c%c\r",srv[0],srv[1],srv[2],srv[3]);
//other code not shown....


srval is forced to 0x09080706 for testing and srv has the following result:

Code:

srv,h = 0x09,0x08,0x00,0x06


What happened to srv[2]??? Should be 07.
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

Re: 4.096 breaking apart int32
PostPosted: Mon Nov 02, 2009 10:52 am     Reply with quote

ljbeng wrote:

Code:


      fprintf(u1,"SEK %c%c%c%c\r",srv[0],srv[1],srv[2],srv[3]);



You don't want %c, that prints a char based on the value of the param.

(and in your case would be weird ascii control chars)

Try printing the HEX values with %02X

what do you get then?

-Ben

p.s. consider checking the list file to see what those assignments come out as in ASM.

You can always try building a structure and working with that.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
ljbeng



Joined: 10 Feb 2004
Posts: 205

View user's profile Send private message

PostPosted: Mon Nov 02, 2009 11:21 am     Reply with quote

I need to print the ASCII character SEK then the actual hex values of the address, 4 bytes long, MSB first. The printf is not the problem, I can seek to the correct address and that is working.

What I am confused about is why I lose 1 of the hex values when I break the int32 into 4 bytes???
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Mon Nov 02, 2009 11:41 am     Reply with quote

Look at the list file and follow the assembly code to see if it makes sense.

You shouldn't unless it's a bug.

Have you considered building a struct like this:

Code:
typedef union _DWORD_VAL
{
    DWORD Val;
    WORD w[2];
    BYTE v[4];

    struct {
        WORD LW;
        WORD HW;
    } word;

    struct {
        BYTE LB;
        BYTE HB;
        BYTE UB;
        BYTE MB;
    } byte;

} DWORD_VAL;


Then you can access your bytes via the structure

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Mon Nov 02, 2009 11:53 am     Reply with quote

The below line isn't compiled correctly by PCD, just another bug, still present in V4.099 as well.
Code:
srv[2] = ((srval & 0xff00)>>8);


It should be noted, that the >> syntax for byte selection is also processed rather ineffectively by a lot of other embedded compilers, so bkamen is right to suggest a more effective variant to access individual bytes. The weird thing is however, that the ineffective >> construct is still used in many portable C codes, so it's absolutely inacceptable, that it's not understood correctly by PCD.

"I speak of none but the computer that is to come after me!" (Deep thought in Douglas Adams Hitchhikers Guide to the Galaxy)
bkamen



Joined: 07 Jan 2004
Posts: 1611
Location: Central Illinois, USA

View user's profile Send private message

PostPosted: Mon Nov 02, 2009 11:59 am     Reply with quote

FvM wrote:
The below line isn't compiled correctly by PCD, just another bug, still present in V4.099 as well.
Code:
srv[2] = ((srval & 0xff00)>>8);


I didn't have a chance to try that yet.. thanks for doing that.

FvM wrote:

It should be noted, that the >> syntax for byte selection is also processed rather ineffectively by a lot of other embedded compilers, so bkamen is right to suggest a more effective variant to access individual bytes. The weird thing is however, that the ineffective >> construct is still used in many portable C codes, so it's absolutely inacceptable, that it's not understood correctly by PCD.


Amen. I've noticed in some cases it's easy to goof up the bit shifting and get lost... so making a single construct of sorts (like the union) is a good way to test once and apply everywhere and be less error prone.

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D
ljbeng



Joined: 10 Feb 2004
Posts: 205

View user's profile Send private message

PostPosted: Mon Nov 02, 2009 12:05 pm     Reply with quote

Thanks. This seems to work....

Code:

int16 shr;
      srv[0] = ((srval & 0xff000000)>>24);
      srv[1] = ((srval & 0xff0000)>>16);
      shr = srval;//get the lower 16 bits to shr
      srv[2] = ((shr & 0xff00)>>8);
      srv[3] = ((shr & 0xff));
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Mon Nov 02, 2009 12:24 pm     Reply with quote

The CCS proprietary function for byte accesses is make8( ), it can be expected to generate minimal code in any case.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group