|
|
View previous topic :: View next topic |
Author |
Message |
DeniTCH
Joined: 09 Aug 2011 Posts: 6
|
Mystical long long datatype behaviour |
Posted: Tue Aug 09, 2011 5:55 am |
|
|
Hi, I am currently experiencing quite strange behavior when using variables of the long long type.
My compiler version is: 4.104, I am using PIC18F6680 with the following configuration:
Code: |
//------------------------------------------------------------------------------
// Configuration bits
//------------------------------------------------------------------------------
#pragma fuses HS // Use external crystal as clock source
#pragma fuses NOWDT // Disable watchdog timer
#pragma fuses NOPROTECT // Don't read/write protect program memory
//------------------------------------------------------------------------------
// Compiler magic
//------------------------------------------------------------------------------
#pragma use rs232(BAUD=19200, BITS=8, STOP=1, PARITY=N, XMIT=PIN_TX, RCV=PIN_RX)
#pragma use spi(BITS=8)
|
The problem is summarized in the following code:
Code: |
#include "system.h"
typedef unsigned long long DPULONG;
DPULONG testfunc()
{
DPULONG ret = 0x69736544;
printf("\r\nret=0x%LX",ret);
return ret;
}
void main() {
DPULONG i,j;
unsigned long long cnt;
init();
setup_spi(SPI_MASTER | SPI_H_TO_L | SPI_XMIT_L_TO_H | SPI_CLK_DIV_4 );
printf("%c[2J",0x1B);
printf("DTUsat-PPL Test\r\n");
i = testfunc();
j = 0 | testfunc();
printf("\r\ni=0x%LX,j=0x%LX,direct=0x%LX",i,j,testfunc());
while(1);
}
|
The terminal output of this code is:
DTUsat-PPL Test
ret=0x69736544
ret=0x69736544
ret=0x69736544
i=0x34343434,j=0x69736544,direct=0x69730000
I am expecting i,j and the direct function result to print the same number, however it does not. Is there anything I am misunderstanding regarding the long long datatype? I am looking forward to any responses to this issue!
Best regards
Denis |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Aug 09, 2011 8:19 pm |
|
|
You didn't post a compilable test program, so I added or commented out
whatever was required to make it compile. I installed vs. 4.104 and ran
it in MPLAB simulator. It works. This is the result in the Output window:
Quote: |
ret=0x69736544
ret=0x69736544
ret=0x69736544
i=0x69736544,j=0x69736544,direct=0x69736544
|
Here is part of the build results and .LST file:
Code: |
Executing: "C:\Program Files\PICC\Ccsc.exe" "PCH_Test.c" +FH +DF +LY -T -A +M -Z +Y=9 +EA -EW
Memory usage: ROM=1% RAM=1% - 1%
0 Errors, 0 Warnings.
Loaded C:\Program Files\PICC\Projects\PCH_Test\PCH_Test.cof.
BUILD SUCCEEDED: Tue Aug 09 19:16:23 2011
CCS PCH C Compiler, Version 4.104, xxxxx 09-Aug-11 19:16
Filename: C:\Program Files\PICC\Projects\PCH_Test\PCH_Test.lst
ROM used: 600 bytes (1%)
Largest free fragment is 64936
RAM used: 20 (1%) at main() level
23 (1%) worst case
Stack: 2 locations
|
This is the test program:
Code: |
#include <18F6680.h>
//------------------------------------------------------------------------------
// Configuration bits
//------------------------------------------------------------------------------
#pragma fuses HS // Use external crystal as clock source
#pragma fuses NOWDT // Disable watchdog timer
#pragma fuses NOPROTECT // Don't read/write protect program memory
#use delay(clock=20M)
//------------------------------------------------------------------------------
// Compiler magic
//------------------------------------------------------------------------------
#pragma use rs232(BAUD=19200, BITS=8, STOP=1, PARITY=N, XMIT=PIN_C6, RCV=PIN_C7)
#pragma use spi(BITS=8)
//#include "system.h"
typedef unsigned long long DPULONG;
DPULONG testfunc()
{
DPULONG ret = 0x69736544;
printf("\r\nret=0x%LX",ret);
return ret;
}
void main() {
DPULONG i,j;
unsigned long long cnt;
// init();
setup_spi(SPI_MASTER | SPI_H_TO_L | SPI_XMIT_L_TO_H | SPI_CLK_DIV_4 );
printf("%c[2J",0x1B);
printf("DTUsat-PPL Test\r\n");
i = testfunc();
j = 0 | testfunc();
printf("\r\ni=0x%LX,j=0x%LX,direct=0x%LX",i,j,testfunc());
while(1);
} |
|
|
|
DeniTCH
Joined: 09 Aug 2011 Posts: 6
|
|
Posted: Wed Aug 24, 2011 6:57 am |
|
|
I have found the error, which of course was on my side. The length of the "long" datatype was redefined higher in the build system, which we are using. As it was not written by me I had no idea. I am sorry for the inconvenience. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19552
|
|
Posted: Wed Aug 24, 2011 9:19 am |
|
|
This is one reason I prefer to be 'explicit' with data type sizes. The forms, int8, int16, and int32, are self documenting, and avoid using constructs like 'long long', which may have different meanings in other compilers, and can give problems if re-defined.....
Glad you have found it.
Best Wishes |
|
|
DeniTCH
Joined: 09 Aug 2011 Posts: 6
|
|
Posted: Fri Aug 26, 2011 1:26 am |
|
|
I have also decided to use the 'explicit' datatypes now, for exactly that reason. Trust no one, except yourself |
|
|
|
|
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
|