|
|
View previous topic :: View next topic |
Author |
Message |
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
Problem with version 4 |
Posted: Wed May 30, 2007 1:35 am |
|
|
Hello,
ii am using for my work your compiler 3.249
Now i have downloaded for a test the new version demo 4.032
When compiled with this new version, an old program is no more functioning.
Here enclosed is the substantial part of the code.
Code: |
#define MAXIN 4
...
typedef struct
{
bit enable:1;
bit contact:1;
bit polar:1;
bit pin:1;
bit status:1;
bit allarme:1;
bit gia_chiamato:1;
unsigned int8 delay_sample;
unsigned int16 delay;
unsigned int16 counter;
} input_struct;
input_struct in_data[MAXIN];
....
#int_TIMER1
void TIMER1_isr()
{
unsigned int8 t;
...
for (t = 0; t < MAXIN; t++)
{
if (in_data[t].polar)
{
in_data[t].status = in_data[t].enable & (in_data[t].pin ^ in_data[t].contact);
}
}
...
}
|
With:
in_data[0].polar = 1, in_data[0].enable = 1, in_data[0].pin = 1, in_data[0].contact = 1,
i obtain now:
in_data[0].status = 1,
while with the previous compiler it was right: 0.
Thanks |
|
|
inservi
Joined: 13 May 2007 Posts: 128
|
|
Posted: Wed May 30, 2007 1:52 am |
|
|
Hello,
Are you sure that in_data[0].polar = 1, in_data[0].enable = 1, in_data[0].pin = 1, in_data[0].contact = 1 when
in_data[t].status = in_data[t].enable & (in_data[t].pin ^ in_data[t].contact);
is executed ?
dro. _________________ in médio virtus |
|
|
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
|
Posted: Wed May 30, 2007 2:53 am |
|
|
inservi wrote: | Hello,
Are you sure that in_data[0].polar = 1, in_data[0].enable = 1, in_data[0].pin = 1, in_data[0].contact = 1 when
in_data[t].status = in_data[t].enable & (in_data[t].pin ^ in_data[t].contact);
is executed ?
dro. |
Yes is executed |
|
|
Ttelmah Guest
|
|
Posted: Wed May 30, 2007 2:53 am |
|
|
One question:
Are you using pointer arithmetic anywhere?. If so, have you read the threads about this?.
V4, now uses standard 'C' behaviour for pointer arithmetic, while in the past, V3, always handled pointers as if they addressed bytes. This could easily be having implications to what is happening, or being seen to happen to values.
The only way to be sure that the values are what you 'think' they are, would be to copy them to a temporary variable at the moment the interrupt is entered, and inspect this. My suspicion would be that the arithmetic is 'right', but that the values are being incorrectly initialised somewhere in the code, possibly because of pointer problems...
I have initialised the bits to '1', and run the subroutine on V4.038, and the status bit is 0 after it runs.
Best Wishes |
|
|
inservi
Joined: 13 May 2007 Posts: 128
|
|
Posted: Wed May 30, 2007 3:19 am |
|
|
Hello,
I think also for a pointer problem as Ttelmah.
My question was bad typed here is the corrected one :
Quote: | Are you sure that
in_data[0].polar = 1, in_data[0].enable = 1, in_data[0].pin = 1, in_data[0].contact = 1
when
in_data[t].status = in_data[t].enable & (in_data[t].pin ^ in_data[t].contact);
is executed ?
|
dro _________________ in médio virtus |
|
|
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
|
Posted: Wed May 30, 2007 7:33 am |
|
|
Obviously, after i have seen the problem, but before it was submitted to you, i have
tested the software with some extra variables. See below.
With a breakpoint inside the if, with t = 0, and after execution of all the code, i have:
enable0 = 1, pin0 = 1, contact0 = 1, status0 = 0, st0 = 1, in_data[0].status = 1.
Code: |
...
#define MAXIN 4
...
typedef int1 bit;
typedef struct
{
bit enable:1;
bit contact:1;
bit polar:1;
bit pin:1;
bit status:1;
bit allarme:1;
bit gia_chiamato:1;
unsigned int8 delay_sample;
unsigned int16 delay;
unsigned int16 counter;
} input_struct;
input_struct in_data[MAXIN];
....
bit enable0, pin0, contact0, status0, st0;
#int_TIMER1
void TIMER1_isr()
{
unsigned int8 t;
...
for (t = 0; t < MAXIN; t++)
{
if (in_data[t].polar)
{
in_data[t].status = in_data[t].enable & (in_data[t].pin ^ in_data[t].contact);
// Extra code:
enable0 = in_data[0].enable;
pin0 = in_data[0].pin;
contact0 = in_data[0].contact;
status0 = enable0 & (pin0 ^ contact0);
st0 = in_data[0].status;
// ----------
}
}
...
} |
|
|
|
inservi
Joined: 13 May 2007 Posts: 128
|
|
Posted: Wed May 30, 2007 9:28 am |
|
|
Hello,
can we consider that exactly the same code work well when compiled with version 3.x ?
dro _________________ in médio virtus |
|
|
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
|
Posted: Wed May 30, 2007 9:58 am |
|
|
inservi wrote: | Hello,
can we consider that exactly the same code work well when compiled with version 3.x ?
dro |
yes we can ! |
|
|
inservi
Joined: 13 May 2007 Posts: 128
|
|
Posted: Thu May 31, 2007 4:29 am |
|
|
Hello,
Could-you try with the #device CCS3 directive.
Here are the defferences betwween v3.x and v4.x
#device CCS3
* ADC default is 8 bits (#device ADC=8)
* boolean = int8 is compiled as: boolean = (int8 & 1)
* Overload directive is required if you want to overload functions
* Pointer size was set to only access first bank (PCM *=8, PCB *=5)
* var16 = NegConst8 is compiled as: var16 = NegConst8 & 0xFF (no sign extension)
* Compiler will NOT automatically set certain #fuses based upon certain code conditions.
* rom qualifier is called _rom
# #device CCS4
* ADC default is 8 bits (#device ADC=8)
* boolean = int8 is compiled as: boolean = (int8 & 1)
* You can overload functions without the overload directive
* If the device has more than one bank of RAM, the default pointer size is now 16 (#device *=16)
* var16 = NegConst8 is will perform the proper sign extension
* Automatic #fuses configuration (see next section)
dro. _________________ in médio virtus |
|
|
Ttelmah Guest
|
|
Posted: Thu May 31, 2007 9:44 am |
|
|
Unfortunately, while it is 'worth a try', there are some slightly more fundamental changes (like the pointer one), that this doesn't affect. It is worth remembering here, that this was always a 'fault' with V3, which allowed some shortcuts to be used, but it is one that the CCS directive, doesn't change....
There are a couple of other changes to the 'boolean' behaviour, which might actually be causing the problem, however for me, it is not repeatable, with the sum giving the right result from three different V4 compilers now..
I suspect it could actually be fixed by casting one item up to an int8 in the equation, or possibly by using a 'logical' combination, rather than a bitwise combination (whose effect on a single bit field, should be the same).
Interestingly, the fact it works in the tests being done by the original poster, when the result of the first part, is passed in a temporary variable, suggests the problem may be with something like losing an internal temporary variable, rather than fundamental to the arithmetic (this has in the past been a common little 'catcher', in some lines of code).
As a separate comment though, I would suggest perhaps 'rethinking' how this is done, since it results in very bulky and slow interrupt code. Accessing a single bit in an array like this, results in this line, needing about 65 instructions to execute. Repeating this 4*, makes this part of the handler, run to nearly 300 instructions alone.
Though less elegant, getting rid of the loop, and accessing the values manually, with:
Code: |
in_data[0].status = in_data[0].enable & (in_data[0].pin ^ in_data [0].contact);
in_data[1].status = in_data[1].enable & (in_data[1].pin ^ in_data [1].contact);
in_data[2].status = in_data[2].enable & (in_data[2].pin ^ in_data [2].contact);
in_data[3].status = in_data[3].enable & (in_data[3].pin ^ in_data [3].contact);
|
Result in a total of just 76 instruction times...
Even better, redesigning the data, so that the various bits are themselves held as arrays in single byte (one byte for status, one for pin, etc.), allows the whole operation to be done using bytewide logical operators, dropping the length to just 11 instructions.
This is one of the 'caveats' of a high level compiler, where sometimes structures that are nice for the human, really do make code bulky/slow...
Best Wishes |
|
|
Max
Joined: 15 Dec 2003 Posts: 51 Location: Italy
|
|
Posted: Thu May 31, 2007 10:35 am |
|
|
Many thanks for your very interesting suggestions.
Maybe i will try some. |
|
|
Jimy Guest
|
Problem with version 4 |
Posted: Thu Jul 12, 2007 2:32 pm |
|
|
Hello Max,
as I can see the array of structures in watch of mplab, unsupported Struct appears to me the following message. Thanks |
|
|
|
|
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
|