Problem with version 4

[Max]

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.

[inservi]

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]

[Ttelmah]

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]

Hello,

I think also for a pointer problem as Ttelmah.

My question was bad typed here is the corrected one :

[Max]

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.

[inservi]

Hello,

can we consider that exactly the same code work well when compiled with version 3.x ?

dro
_________________
in médio virtus

[Max]

[inservi]

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]

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:

[Max]

Many thanks for your very interesting suggestions.
Maybe i will try some.

[Jimy]

Hello Max,

as I can see the array of structures in watch of mplab, unsupported Struct appears to me the following message. Thanks