cannot find the reason for such a strange behavior

[richard]

To do that I should send to you all the project! Which is not possible!

that I understand but my point is that cause and effect are seemingly unrelated

IF I DO NOT INVERT THE BYTE VALUE THE CRC RECEIVED IS CORRECT IF I DO INVERT INVERT THE BYTE VALUE THE CRC RECEIVED IS ALWAYS 253!

I don't doubt this is occurring for you but I believe the real cause is either elsewhere or that pbp has a major flaw . you can of course ignore this but it means your project may infact still have a flaw in it than will resurface some point further on . it should not be too difficult to simply paste together the relevant sections of you project code to demonstrate the failure point.

[HenrikOlsson]

Are you using any interrupts and if so of which type, pure ASM, DT-INTS with PBP ISR etc?

Perhaps PBP uses an internal variable when inverting and that variable gets corrupted by some other code (as in an interrupt).

I'm with Richard on this, to prove to yourself that is, or isn't, the actual inverting that is the problem you need to write a fully compilable snippet of code that shows this happening.

Richards code below shows (I think) the ~operator working but not really, at least not that I can see, in the exact way you're using it. Ie inverting the value within an array and writing the value back to the same location in the array. If there IS a problem with ~operator then you shouldn't have too much of a problem writing a small code snippet that the rest of use can verify.

Load an array up with values, print it out. Invert one of the values, print it out.
Don't use Bluetooth connections and android apps and other "weird" things, use a simple wired connection back to a terminal program.

/Henrik.

[richard]

Richards code below shows (I think) the ~operator working but not really, at least not that I can see, in the exact way you're using it

thanks for that henrik lets see if we can agree to the problem definition it's possible the badgers have moved the goalposts.

my assumption is
the elements of a byte array [of less than 256 bytes] are summed from the first element to the penulitmate element into a word var
the low byte of this word var is inverted and placed into the last element.
the allegation is that :-
{note .w0 is the word sum of the array}

array[z] = ~w0   ;  where  w0 ia a word and the [byte]array is of z+1 elements

can produce and incorrect result in that, when read back array[z] is always $fd
or that

IF I DO NOT INVERT THE BYTE VALUE THE CRC RECEIVED IS CORRECT

which i assume to be

array[z] = w0.lowbyte  ; not inverted

is correct where as

array[z] = w0.lowbyte
array[z] = ~array[z]  ; inverted

can produce and incorrect result in that, when read back array[z] is always $fd

[richard]

forgot to add I have tried 4 ways to implement this , none of which produces any error .
the subroutine below is run 1/sec in a working packet radio system with heaps or interrupts ,
no sign of sky falling yet


ps the result is displayed on a glcd using my glcd include as previously described in this forum

 w0 var word
 Report var byte[4]
 albo   var byte[4]
 I var byte




alberto: 
  random w0
 albo[0] = w0
  random w0
 albo[1] = w0
  random w0 
 albo[2] = w0
 w0=0
 for i =0 to 2
    w0=w0+albo[i]
 next
crc: ;   label to examine listing if required
 ;method 0
 albo[3] = ~w0
Report[0] =  albo[3]

 ;method 3
@ NOT?WB _w0,_Report+3

 ;method 2
 Report[2] = w0 //256
 Report[2] = ~ Report[2]

 ;method 1
asm
  CHK?RP _w0
  MOVF _w0,W
  CHK?RP _Report 
  MOVWF  _Report +1
  COMF   _Report +1,F
  RST?RP
ENDASM 
 
ecrc:
IF (Report[0]-Report[1])-(Report[2]-Report[3]) THEN
  ARRAYWRITE BUFF,["The sky is falling",0]  
  led_cnt=KEY_BEEP_TIME   ;  set off the alarm
  led_times=2                    ; twice for good measure
ELSE 
  ARRAYWRITE BUFF,[#Report[0]," ",#Report[1]," ",#Report[2]," ",#Report[3],0]
endif 
  GLCD_CLR 0,43,100,8
  GLCDC  1 ,43
  GLCDSTR  BUFF
 return