![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
PCW compiler typedef'ed array issue |
Posted: Mon Feb 07, 2011 9:40 am |
|
|
I'm a experienced professional developer working on PCWH 4.017 for a medium term contract. The company currently doesn't have support for the IDE or compiler.
I want to know if this is a known problem. If so, does anyone know if it has been fixed. In other words is it worth my while trying to make a case for re-establishing support?
The problem is a compiler issue relating to typedef and arrays. The generated assembler code for arrays of ints and int32s is different when directly declared from that when declared through an equivalent typedef. If declared with a typedef the compiler generates code that treats each int or int32 as if they were int16, however it correctly addresses the ints or int32s! Note that when single variables are used instead of arrays the code is good.
Here is my test code. If the declare, which defines the type to test, is int8 or int32 then the problem occurs, however int16 is OK.
I am targeting the PIC18F8585 at 10MHz.
Code: | #include <18F8585.h>
#device ICD=TRUE
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES EC_IO //External clock
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOOSCSEN //Oscillator switching is disabled, main oscillator is source
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES PUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES MCLR //Master Clear pin enabled
#FUSES MCU //Microcontroller Mode
#FUSES NOWAIT //Wait selections unavailable for Table Reads or Table Writes
#FUSES ECCPE //Enhanced CCP PWM outpts multiplexed with RE6 thorugh RE3
#use delay(clock=10000000)
void main()
{
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_spi(SPI_SS_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
//Setup_Oscillator parameter not selected from Intr Oscillator Config tab
#define base int8 // or int16, or int32
typedef base typedef_type;
base int_byte;
typedef_type typedef_byte;
typedef base typedef_array_type[2];
// Declare two 4 byte arrays. One directly...
base int_array[2];
// ...one with an equivalent typedef.
typedef_array_type typedef_array;
int_array[0] = 0x01;
int_array[1] = 0x02;
// This should generate similar code to the above, with different addresses of course.
typedef_array[0] = 0x10;
typedef_array[1] = 0x20;
// Code for the typedef'ed array includes a spurious CLRF clearing a non-existant MS byte!
// Code for single variables is fine.
int_byte = 0x01;
typedef_byte = 0x02;
}
|
this is an extract from the lst file showing the resulting assembler:
Code: | .................... #define base int8 // or int16, or int32
.................... typedef base typedef_type;
....................
.................... base int_byte;
....................
.................... typedef_type typedef_byte;
....................
.................... typedef base typedef_array_type[2];
....................
.................... // Declare two 4 byte arrays. One directly...
.................... base int_array[2];
.................... // ...one with an equivalent typedef.
.................... typedef_array_type typedef_array;
....................
.................... int_array[0] = 0x01;
005C: MOVLW 01
005E: MOVWF 07
.................... int_array[1] = 0x02;
0060: MOVLW 02
0062: MOVWF 08
....................
....................
.................... // This should generate similar code to the above, with different addresses of course.
.................... typedef_array[0] = 0x10;
0064: CLRF 0A
0066: MOVLW 10
0068: MOVWF 09
.................... typedef_array[1] = 0x20;
006A: CLRF 0B
006C: MOVLW 20
006E: MOVWF 0A
....................
....................
.................... // Code for the typedef'ed array includes a spurious CLRF clearing a non-existant MS byte!
....................
.................... // Code for single variables is fine.
.................... int_byte = 0x01;
0070: MOVLW 01
0072: MOVWF 05
.................... typedef_byte = 0x02;
0074: MOVLW 02
0076: MOVWF 06
.................... }
0078: BRA 0078
|
As I don't have access to CCS support there's no chance of me raising this issue with them. All I really need to know is whether this is a known problem and if it has been fixed yet.
If you're still reading this then thanks for sticking with it!
RF_Developer |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Feb 07, 2011 1:00 pm |
|
|
I copied and pasted your code into an MPLAB project and compiled it with
PCH vs. 4.118. Here's the .LST file:
Code: |
.................... typedef base typedef_array_type[2];
....................
.................... // Declare two 4 byte arrays. One directly...
.................... base int_array[2];
.................... // ...one with an equivalent typedef.
.................... typedef_array_type typedef_array;
....................
.................... int_array[0] = 0x01;
005C: MOVLW 01
005E: MOVWF 07
.................... int_array[1] = 0x02;
0060: MOVLW 02
0062: MOVWF 08
....................
....................
.................... // This should generate similar code to the above, with different addresses of course.
.................... typedef_array[0] = 0x10;
0064: MOVLW 10
0066: MOVWF 09
.................... typedef_array[1] = 0x20;
0068: MOVLW 20
006A: MOVWF 0A
....................
....................
.................... // Code for the typedef'ed array includes a spurious CLRF clearing a non-existant MS byte!
....................
.................... // Code for single variables is fine.
.................... int_byte = 0x01;
006C: MOVLW 01
006E: MOVWF 05
.................... typedef_byte = 0x02;
0070: MOVLW 02
0072: MOVWF 06
.................... }
....................
|
|
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Mon Feb 07, 2011 3:33 pm |
|
|
And, the critical thing is the PCWH version here. Generally, the early V4 compilers, _were not useable_. The 'line' for a compiler that began to work reasonably well, was around the late 4.06x version. 4.017, I wouldn't even trust to compile a basic 'hello world' type program, let alone deal with typedef and an array. I keep the compilers I use for projects, and there is a large 'gap' in the sequence, going 3.249, then 4.070....
Just as a test, I stuck the typedefs into 4.099, and this too handled them OK.
Forget 4.017.
For many months, there was a sticky thread at the head of the forum, about the progress with the compilers. This was only removed, when they began to work.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Tue Feb 08, 2011 2:52 am |
|
|
Thanks, that pretty much answers my questions, and raises possibly nasty issues.
For a long while yesterday I thought I was going out with the fairies... before finding this problem.
I've worked round it by simply removing the affected typedefs. Not so tidy, but at least it works!
The long term implications are more worrying. Yes, I can perhaps persuade the company to upgrade, but I also have to persuade them that they have to use a commercially available tool that for fairly long periods has been known to have had significant functional shortcomings (i.e. is potentially unusable cr&p)... but then what software tool doesn't in one way or another?
By the way, does anyone else find the debugger's - possible legacy hangover - habit of displaying pointers as 8 bit only rather annoying, and massively timewasting?
Oh yes, and our two Mach X programmer/debuggers are only borderline usable as their comms locks up in some unknown way; commonly in the verify pass after loading ICD code but also while actively debugging. The CCS IDE's handling of these errors is very frustrating, necessitating lots of waiting (generally accompanied by groans, sighs, cusses and copious cups of tea) and killing of the IDE app and other similar drastic measures. I typically lose two or more hours to this every day. So much so that I've had to insist that we change to another ICD unit, probably Microchip's own MPLAB ICD3 (we apparently use the ICD2 for our small-scale production programming).
Anyway, thanks for the replies.
RF_Developer |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|