cannot find the reason for such a strange behavior


Closed Thread
Results 1 to 18 of 18
  1. #1
    Join Date
    Jun 2016
    Posts
    60

    Default cannot find the reason for such a strange behavior

    Code:
    if Flg_15 = True then
    
    
    @ INT_DISABLE  RX_INT                               ; disable RX_INT interrupts
    
    
    
    
    
    
    if Head = 15 & FlagTime = False then
    W2 = 0
    gosub XB1adc
    gosub XB2adc
    'gosub XB3adc
    
    
    CIndex = 0
    gosub XBee_Value
    
    
    Pulse[0] = "1"
    Pulse[1] = "5"
    Pulse[2] = "0"
    Pulse[3] = " "
    Pulse[4] = "A"
    Pulse[5] = "0"
    Pulse[6] = "="
    Pulse[7] = Decode[3]
    Pulse[8] = Decode[2]
    Pulse[9] = Decode[1]
    Pulse[10] = Decode[0]
    
    
    CIndex = 1
    gosub XBee_Value
    
    
    Pulse[11] = " "
    Pulse[12] = "A"
    Pulse[13] = "1"
    Pulse[14] = "="
    Pulse[15] = Decode[3]
    Pulse[16] = Decode[2]
    Pulse[17] = Decode[1]
    Pulse[18] = Decode[0]
    
    
    
    
    CIndex = 2
    gosub XBee_Value
    
    
    Pulse[19] = " "
    Pulse[20] = "A"
    Pulse[21] = "2"
    Pulse[22] = "="
    Pulse[23] = Decode[3]
    Pulse[24] = Decode[2]
    Pulse[25] = Decode[1]
    Pulse[26] = Decode[0]
    
    
    '------------------
    CIndex = 3
    gosub XBee_Value
    
    
    Pulse[27] = " "
    Pulse[28] = "A"
    Pulse[29] = "3"
    Pulse[30] = "="
    Pulse[31] = Decode[3]
    Pulse[32] = Decode[2]
    Pulse[33] = Decode[1]
    Pulse[34] = Decode[0]
    
    
    CIndex = 4
    gosub XBee_Value
    
    
    Pulse[35] = " "
    Pulse[36] = "A"
    Pulse[37] = "4"
    Pulse[38] = "="
    Pulse[39] = Decode[3]
    Pulse[40] = Decode[2]
    Pulse[41] = Decode[1]
    Pulse[42] = Decode[0]
    
    
    
    
    CIndex = 5
    gosub XBee_Value
    
    
    Pulse[43] = " "
    Pulse[44] = "A"
    Pulse[45] = "5"
    Pulse[46] = "="
    Pulse[47] = Decode[3]
    Pulse[48] = Decode[2]
    Pulse[49] = Decode[1]
    Pulse[50] = Decode[0]
    '------------------
    CIndex = 6
    gosub XBee_Value
    
    
    Pulse[51] = " "
    Pulse[52] = "A"
    Pulse[53] = "6"
    Pulse[54] = "="
    Pulse[55] = Decode[3]
    Pulse[56] = Decode[2]
    Pulse[57] = Decode[1]
    Pulse[58] = Decode[0]
    
    
    CIndex = 7
    gosub XBee_Value
    
    
    Pulse[59] = " "
    Pulse[60] = "A"
    Pulse[61] = "7"
    Pulse[62] = "="
    Pulse[63] = Decode[3]
    Pulse[64] = Decode[2]
    Pulse[65] = Decode[1]
    Pulse[66] = Decode[0]
    
    
    
    
    CIndex = 8
    gosub XBee_Value
    
    
    Pulse[67] = " "
    Pulse[68] = "A"
    Pulse[69] = "8"
    Pulse[70] = "="
    Pulse[71] = Decode[3]
    Pulse[72] = Decode[2]
    Pulse[73] = Decode[1]
    Pulse[74] = Decode[0]
    
    
    '------------------ Start CRC Function
    W0 = 0
    For DMY = 0 To 74
    W0 = W0 + Pulse[DMY]
    next DMY
    DMY = W0//256
    Pulse[75] = (255 - DMY)
    
    ' -------------------- End CRC function
    
    
    gosub Check_Status
    if Id > 51 then goto Skip_AK_15
    
    
    Hserout ["AT+CIPSEND=",Id,44,55,55,13,10]
    HSERIN 500,Skip_AK_20, [WAIT (">"), DMY]
    Hserout [str Pulse\76,10]
    
    
    
    
    endif
    
    
    Skip_AK_15:
    Flg_15 = false
    @ INT_ENABLE  RX_INT                                ; enable RX_INT interrupts
    goto Skip_All
    endif
    The above subroutine reads adc values from two XBee and send the values out to a client, via ESP. All works fine except the CRC function that yields every time "253" whatever adc values are trasmitted!
    All I am doing is to add up all the bytes in the word variable W0, extract the low byte and subtract this value to 255. But all I find everytime in Pulse[75] is the value 253. On the client the same algoritm yields the correct value!

    I cannot find the reason for such a strange behaviour. What am I doing wrong? Any help is appreciated!

    Pic 18F2620 @ 8 MHz + ESP8266 + XBee

    Alberto

  2. #2
    Join Date
    Nov 2005
    Location
    Bombay, India
    Posts
    947


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    Not very obvious since you haven't shown the variable declarations. I would guess your DMY variable is a word type which might be giving you the problem. Or, is there some other code section that is overwriting the Pulse[75] location?

  3. #3
    Join Date
    Jun 2016
    Posts
    60


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    Thank you Jerson for your prompt answer!

    I confirm that DMY variable is declared as byte and the byte variable pulse[75] is only used with the following two lines of code:

    pulse[75] = (255 - DMY)

    and

    Hserout [str Pulse\76,10]

    Both lines are inside the subroutine.

    Alberto
    Last edited by Alberto; - 31st October 2016 at 20:01.

  4. #4
    Join Date
    May 2013
    Location
    australia
    Posts
    2,386


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    I cannot find the reason for such a strange behaviour. What am I doing wrong? Any help is appreciated!
    as jerson implies the problem most likely lies in the code not provided.

    I suggest you make a complete compliable minimal example that demonstrates the problem, code snippets are impossible to debug if the problem is eslewhere
    Warning I'm not a teacher

  5. #5
    Join Date
    May 2013
    Location
    australia
    Posts
    2,386


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    I did it this once for you , problem is definitely elsewhere

    and

    DMY = W0//256
    Pulse[75] = (255 - DMY)
    can be simplified to

    Pulse[75] =~w0



    Code:
    #CONFIG
                 __config        _CONFIG1,    _FOSC_INTOSC & _CP_OFF & _WDTE_ON  &  _PWRTE_ON  &  _MCLRE_ON  & _CLKOUTEN_OFF
                  __config      _CONFIG2, _PLLEN_ON & _LVP_OFF
    #ENDCONFIG
    
      
    
    
    
    DEFINE OSC 32
    
        OSCCON=$70
       ANSELA=0
       ANSELC=0
      
       
       
       TRISA = %111110
       TRISC = %11111111        ' set PORTC I/O
     
    
    
     j var byte
     k var word
     l var byte
     pulse var byte[76]
     decode var byte[4]
     w0 var word
     dmy var byte
     
     
     
      
        DEFINE DEBUG_REG PORTA
        DEFINE DEBUG_BIT 0      ;  if not used for pwr  
        DEFINE DEBUG_BAUD 9600
        DEFINE DEBUG_MODE 0     
        pause 2000
        Debug "Start",13 ,10      
     
     
     
     
     
     
     
     
     
     
      main:
     
    
    
        gosub XBee_Value
        
        
        Pulse[0] = "1"
        Pulse[1] = "5"
        Pulse[2] = "0"
        Pulse[3] = " "
        Pulse[4] = "A"
        Pulse[5] = "0"
        Pulse[6] = "="
        Pulse[7] = Decode[3]
        Pulse[8] = Decode[2]
        Pulse[9] = Decode[1]
        Pulse[10] = Decode[0]
        
        
    '    CIndex = 1
        gosub XBee_Value
        
        
        Pulse[11] = " "
        Pulse[12] = "A"
        Pulse[13] = "1"
        Pulse[14] = "="
        Pulse[15] = Decode[3]
        Pulse[16] = Decode[2]
        Pulse[17] = Decode[1]
        Pulse[18] = Decode[0]
        
        
        
        
    '    CIndex = 2
        gosub XBee_Value
        
        
        Pulse[19] = " "
        Pulse[20] = "A"
        Pulse[21] = "2"
        Pulse[22] = "="
        Pulse[23] = Decode[3]
        Pulse[24] = Decode[2]
        Pulse[25] = Decode[1]
        Pulse[26] = Decode[0]
        
        
        '------------------
    '    CIndex = 3
        gosub XBee_Value
        
        
        Pulse[27] = " "
        Pulse[28] = "A"
        Pulse[29] = "3"
        Pulse[30] = "="
        Pulse[31] = Decode[3]
        Pulse[32] = Decode[2]
        Pulse[33] = Decode[1]
        Pulse[34] = Decode[0]
        
        
    '    CIndex = 4
        gosub XBee_Value
        
        
        Pulse[35] = " "
        Pulse[36] = "A"
        Pulse[37] = "4"
        Pulse[38] = "="
        Pulse[39] = Decode[3]
        Pulse[40] = Decode[2]
        Pulse[41] = Decode[1]
        Pulse[42] = Decode[0]
        
        
        
        
    '    CIndex = 5
        gosub XBee_Value
        
        
        Pulse[43] = " "
        Pulse[44] = "A"
        Pulse[45] = "5"
        Pulse[46] = "="
        Pulse[47] = Decode[3]
        Pulse[48] = Decode[2]
        Pulse[49] = Decode[1]
        Pulse[50] = Decode[0]
        '------------------
    '    CIndex = 6
        gosub XBee_Value
        
        
        Pulse[51] = " "
        Pulse[52] = "A"
        Pulse[53] = "6"
        Pulse[54] = "="
        Pulse[55] = Decode[3]
        Pulse[56] = Decode[2]
        Pulse[57] = Decode[1]
        Pulse[58] = Decode[0]
        
        
    '    CIndex = 7
        gosub XBee_Value
        
        
        Pulse[59] = " "
        Pulse[60] = "A"
        Pulse[61] = "7"
        Pulse[62] = "="
        Pulse[63] = Decode[3]
        Pulse[64] = Decode[2]
        Pulse[65] = Decode[1]
        Pulse[66] = Decode[0]
        
        
        
        
    '    CIndex = 8
        gosub XBee_Value
        
        
        Pulse[67] = " "
        Pulse[68] = "A"
        Pulse[69] = "8"
        Pulse[70] = "="
        Pulse[71] = Decode[3]
        Pulse[72] = Decode[2]
        Pulse[73] = Decode[1]
        Pulse[74] = Decode[0]
        
        
        '------------------ Start CRC Function
        W0 = 0
        For DMY = 0 To 74
        W0 = W0 + Pulse[DMY]
        next DMY
        DMY = W0//256      ;  why  ?
        Pulse[75] = (255 - DMY) ;  why   ?
        ;  this line could replace the above two lines  ie   Pulse[75]=~w0
        l=~w0  ;debug    proof of above
        j=w0   ;debug
        
        ' -------------------- End CRC function
        
        Debug 13 ,10 ,#w0,9,#dmy,9,#j ,9,#Pulse[75],9 ,#l
        pause 1000 
     goto main  
        
    
     XBee_Value:
     for j=0 to 3
       random k
      Decode[j]=k
     next
     return
    Last edited by richard; - 1st November 2016 at 00:56. Reason: grammer
    Warning I'm not a teacher

  6. #6
    Join Date
    Jun 2016
    Posts
    60


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    Thank you Richard for the time taken to help me.
    Yes the problem definetly was outside the subroutine. A stupid thing that I do very often, but this time I could not find it without somebody else telling me the problems was elsewhere! I did define byte variable Pulse as : "Pulse Var byte [75]" and wanted to load the 76th byte!

    As far as not using the simpler code "Pulse[75] =~w0", it comes from having had several trouble in the past trying to tranfer the value "1" from a byte variable into a bit variable that I came to the conclusion that it was better working with bit to bit ; byte to byte and word to word.

    So, "DMY = W0//256" was extacting the low byte from the word variable W0 into the byte variable "DMY"


    Tested Pulse[75] =~w0 and found it working! so very likely the problem is only with bit variable!

    Again, Tank you very much for the precious help received.

    Alberto
    Last edited by Alberto; - 2nd November 2016 at 12:20.

  7. #7
    Join Date
    May 2013
    Location
    australia
    Posts
    2,386


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    no problem alberto glad to see you got the issues resolved , it always serves as another good example of why code snippets for debugging are a pointless exercise.
    snippets are fine to discuss or explain methodology but that's about all.


    it comes from having had several trouble in the past trying to tranfer the value "1" from a byte variable into a bit variable
    if you can find the troublesome code i'd like to have a look at it with the view to seeing why it fails
    Warning I'm not a teacher

  8. #8
    Join Date
    Jun 2016
    Posts
    60


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    if you can find the troublesome code i'd like to have a look at it with the view to seeing why it fails
    Door_Lock var PortB.4
    DmyFlg var bit
    Report var byte[8]


    Report[2] = !Door_Lock + 48 ' (didn't work! can't remember if it fails with True or false)

    The work around was

    DmyFlg = Door_Lock
    DmyFlg = !DmyFlg
    Report[2] = DmyFlg + 48

    Sorry, not exactly as I mentioned in my previous post! I should say "bit into byte"

    Alberto

  9. #9
    Join Date
    May 2013
    Location
    australia
    Posts
    2,386


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    The work around was

    DmyFlg = Door_Lock
    DmyFlg = !DmyFlg
    Report[2] = DmyFlg + 48
    I'M not sure you solution is correct

    I did a few experiments as follows and conclude that,

    if you invert a bit var (or bit alias) wether logical or bitwise only bit 0 in the result is valid , I you go on to use the result mathematically then all the other bits need to be masked off

    for a correct calculation



    D_Lck !D_Lck ~D_Lck D_Flg !D_Flg ~D_Flg R+!L R+~L R+!F R+~F
    WRONG
    0 65535 65535 0 65535 65535 47 47 47 47
    CORRECT
    0 255 65535 0 65535 65535 49 49 49 49
    WRONG
    1 65280 65534 1 65280 65534 48 46 48 46
    CORRECT
    1 0 65534 1 65280 65534 48 48 48 48
    WRONG
    0 65535 65535 0 65535 65535 47 47 47 47
    CORRECT
    0 255 65535 0 65535 65535 49 49 49 49





    Code:
       TRISC = %11101111        ' set PORTC I/O
     
    
     D_Lck var Portc.4
     D_Flg var bit
     Report var byte[4]
     
     
        DEFINE DEBUG_REG PORTA
        DEFINE DEBUG_BIT 0      ;  if not used for pwr  
        DEFINE DEBUG_BAUD 9600
        DEFINE DEBUG_MODE 0     
        pause 2000
        Debug "Start",13 ,10      
     
     Debug 13 ,10 ,"D_Lck",9 ,"!D_Lck",9, "~D_Lck",9, "D_Flg",9, "!D_Flg",9, "~D_Flg" ,9, "R+!L" ,9, "R+~L" ,9, "R+!F" ,9, "R+~F"
    main:
     PORTC.4=!PORTC.4
     D_Flg=D_Lck 
     Debug 13 ,10 ,"WRONG"
     Report[0] = !D_Lck + 48 
     Report[1] = ~D_Lck + 48 
     Report[2] = !D_Flg + 48 
     Report[3] = ~D_Flg + 48 
     Debug 13 ,10 ,#D_Lck,9 , #!D_Lck,9, #~D_Lck ,9, #  D_Flg ,9,  #!D_Flg, 9,# ~ D_Flg ,9,# Report[0] ,9,# Report[1] ,9,# Report[2] ,9,# Report[3]
     Debug 13 ,10 ,"CORRECT"
     Report[0] = (!D_Lck&1) + 48 
     Report[1] = (~D_Lck&1) + 48 
     Report[2] = (!D_Flg&1) + 48 
     Report[3] = (~D_Flg&1) + 48 
     Debug 13 ,10 ,#D_Lck,9 , #!D_Lck,9, #~D_Lck ,9, #  D_Flg ,9,  #!D_Flg, 9,# ~ D_Flg ,9,# Report[0] ,9,# Report[1] ,9,# Report[2] ,9,# Report[3]
      
     
     
     
      pause 1000
     
      goto main
    Last edited by richard; - 5th November 2016 at 02:47.
    Warning I'm not a teacher

  10. #10
    Join Date
    Jun 2016
    Posts
    60


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    Today I have finaly found the time to implement the corrections to my code!

    I have corrected the number of bytes int the array Pulse from 75 to 80. Next I have changed the following two lines of code:

    Code:
    DMY = W0//256
    Pulse[75] = (255 - DMY)
    with the simple form suggested by Richard

    Code:
    Pulse[75] = ~W0

    Compiled (22Kb of code) and updated the mcu. Power up and checked the packet transmitted via esp NOOOO! CRC is still txed as 253 all the time!

    I did change the code again setting Pulse[75] = 123 (costant value) and re-checked. Well this time CRC was txed as 123! This proved that there is no byte corruption in the code, but the problem should be in setting the byte variable Pulse[75].

    So I did change the setting of Pulse[75] = 123 to Pulse[75] = W0.lowbyte. Re-checked and it worked! CRC was txed correctly!

    Hence I added : Pulse[75] = ~ Pulse[75] (inverting bits) and CRC was still txed as 253!!!!

    I have removed Pulse[75] = ~ Pulse[75] and kept the CRC as the low byte of the packet sum that works!

    But as I stated in this thread title: "I cannot find the reason for such a strange behavior"

    Alberto
    Last edited by Alberto; - 8th November 2016 at 15:49.

  11. #11
    Join Date
    May 2013
    Location
    australia
    Posts
    2,386


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    try as I might I cannot produce any code where
    Pulse[75] = ~W0
    gives an incorrect result , the problem is elsewhere
    I believe you are just masking the real problem/s
    my challenge to you is :-
    provide some fully compliable code that demonstrates the problem , I would bet you cannot


    Pulse[75] = ~W0 converts to a 1 line macro when compiled

    Code:
    NOT?WB  _w0, _Pulse + 00075h
    where can that go wrong ?
    Warning I'm not a teacher

  12. #12
    Join Date
    Jun 2016
    Posts
    60


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    my challenge to you is :-
    provide some fully compliable code that demonstrates the problem , I would bet you cannot
    To do that I should send to you all the project! Which is not possible!

    But if you read better my first post, you will realize that I do see the CRC value of 253 on the client side, which is an android tablet. The CRC is sent by the pic via esp8266 (as you can easily observe from my code in post 1) and received by the android tablet (acting as a client via an apk written in basic4android by myself). Now the state of the art is: 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!

    At this stage if we exclude the pic then the problem could be the esp or my apk! Need time to investigate in the meantime I will not invert the byte value (action that doesn't add much to the CRC) since everything works very well at the moment.

    Alberto

  13. #13
    Join Date
    May 2013
    Location
    australia
    Posts
    2,386


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    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.
    Warning I'm not a teacher

  14. #14
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,518


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    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.

  15. #15
    Join Date
    May 2013
    Location
    australia
    Posts
    2,386


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    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}
    Code:
    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
    Code:
    array[z] = w0.lowbyte  ; not inverted
    is correct where as

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

    can produce and incorrect result in that, when read back array[z] is always $fd
    Last edited by richard; - 12th November 2016 at 03:49.
    Warning I'm not a teacher

  16. #16
    Join Date
    May 2013
    Location
    australia
    Posts
    2,386


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    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



    Code:
     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
    Warning I'm not a teacher

  17. #17
    Join Date
    Jun 2016
    Posts
    60


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    Following your suggestion I did check both bytes value (inverted and not inverted) txed by the pic 18f2620, removing everything and using a terminal connected to the pic in place of the esp8266. Well both bytes are txed correctly! This esclude the pic as responsible for such a wierd behavior and leave the esp8266 (the server) and the android (the client) as the probable responsible.

    Next step is to write a small vb program using socket to act as a client and verify what the esp send out. I will post the result soon.

    Alberto

  18. #18
    Join Date
    Jun 2016
    Posts
    60


    Did you find this post helpful? Yes | No

    Default Re: cannot find the reason for such a strange behavior

    Finally I have got the VB program working! (I got rusty programming in VB)

    The values are received as a string and decoded extracting the ASCII value from any single character of the string. Comparison with what has been sent was ok all the time for all the values including the CRC values (both inverted and not inverted).

    So now I have to blame only ANDROID for the strange behavior, but still difficult to understand (at least for me) why the problem is only with the inverted byte! But since I have not too much knowledge of this OS, I could not dig any further at the moment.

    Thanks to all.

    Alberto

Similar Threads

  1. Strange behavior on PORTB on a PIC18F26K20
    By Dosbomber in forum mel PIC BASIC Pro
    Replies: 7
    Last Post: - 29th September 2016, 00:31
  2. Strange Behavior 12F1822
    By nobner in forum mel PIC BASIC Pro
    Replies: 10
    Last Post: - 3rd February 2012, 09:11
  3. Strange LCD Behavior
    By chips123 in forum mel PIC BASIC Pro
    Replies: 1
    Last Post: - 1st November 2009, 01:48
  4. Strange behavior - PORTG.2, 18F8720
    By Charles Linquis in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 12th January 2009, 00:30
  5. Strange electrical behavior with PIC16F684
    By xnihilo in forum mel PIC BASIC Pro
    Replies: 10
    Last Post: - 28th March 2008, 07:58

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts