This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

array inside interrupt function

I having trouble sending data out under interrupts from a buffer.

The buffer was declared in xdata and i have a counter that is used to index into it.

So when an interrupt occurs, the data is loaded into my SPI tx buffer, ie
SPIBUF = txbuffer[index];
index++;

All i seem to get is all zero's but if i use the index to send data i get something.
ie SPIBUF = index;

David

Parents
  • The external memory is inside an ASIC. I actually found something interesting.

    txbuffer[0] = 0xaa;
    txbuffer[1] = 0x11;
    txbuffer[2] = 0x22;

    // Try transmitting data;
    // NB 1 - txbuffer[0] = 0xaa;
    P1 = txbuffer[0]; // P1 has 7 segment displays connected to it.

    If i don't include NB 1 just before writing it to P1 then it displays 0x00 but if i put NB 1 in and hence initial location 0 again it displays the correct value.

    Is this something funny with the compiler or the ASIC?

    David

Reply
  • The external memory is inside an ASIC. I actually found something interesting.

    txbuffer[0] = 0xaa;
    txbuffer[1] = 0x11;
    txbuffer[2] = 0x22;

    // Try transmitting data;
    // NB 1 - txbuffer[0] = 0xaa;
    P1 = txbuffer[0]; // P1 has 7 segment displays connected to it.

    If i don't include NB 1 just before writing it to P1 then it displays 0x00 but if i put NB 1 in and hence initial location 0 again it displays the correct value.

    Is this something funny with the compiler or the ASIC?

    David

Children
  • So you're saying this works (ie, 0xAA appears on the 7 segment displays):

    txbuffer[0] = 0xaa; 
    txbuffer[1] = 0x11;
    txbuffer[2] = 0x22;
    txbuffer[0] = 0xaa; 
    P1 = txbuffer[0];
    But this doesn't work (0 appears on the 7 segment displays):
    txbuffer[0] = 0xaa; 
    txbuffer[1] = 0x11;
    txbuffer[2] = 0x22;
    P1 = txbuffer[0];

    Sounds like something funny with your ASIC's memory addressing?

    What is the full 'C' definition of txbuffer?

  • Better yet, what's the assembler code generated for the "example" code you posted?

    Jon

  • One guess is that txbuffer points to "nowhere". What is being read from the external data bus is only the charge left from a previous access.

    Try

    txbuffer[0] = 0xaa; 
    txbuffer[1] = 0x11;
    P1 = txbuffer[0];
    


    If you get an answer of 0x11, check the address of txbuffer.

  • Yes that is correct.

    My buffer is:
    xdata unsigned char txbuffer[BUFFSIZE]

    This is from the list file.
    ; SOURCE LINE # 548
    0044 900000 R MOV DPTR,#txbuffer
    0047 74AA MOV A,#0AAH
    0049 F0 MOVX @DPTR,A

    ; SOURCE LINE # 549
    004A A3 INC DPTR
    004B 7411 MOV A,#011H
    004D F0 MOVX @DPTR,A

    ; SOURCE LINE # 550
    004E A3 INC DPTR
    004F 7422 MOV A,#022H
    0051 F0 MOVX @DPTR,A

    ; SOURCE LINE # 551
    0052 A3 INC DPTR
    0053 7433 MOV A,#033H
    0055 F0 MOVX @DPTR,A

    ; SOURCE LINE # 552
    0056 A3 INC DPTR
    0057 7444 MOV A,#044H
    0059 F0 MOVX @DPTR,A

    ; SOURCE LINE # 553
    005A 900000 R MOV DPTR,#txbuffer
    005D E0 MOVX A,@DPTR
    005E F590 MOV P1,A
    ; SOURCE LINE # 567


    548 1 txbuffer[0] = 0xaa;
    549 1 txbuffer[1] = 0x11;
    550 1 txbuffer[2] = 0x22;
    C51 COMPILER V6.14
    551 1 txbuffer[3] = 0x33;
    552 1 txbuffer[4] = 0x44;
    553 1 P1 = txbuffer[0];

    The symbols in dscope when looking at the disassembly window make little sense, looks like other variables have been moved, something strange with dscope.
    For example:
    552: txbuffer[4] = 0x44;
    c:0x1938 A3 INC DPTR;
    c:0x1939 7444 MOV A,#QueueSize(0x44)
    c:0x193b F0 MOVX @DPTR,A
    553: P1 = txbuffer[0];
    Not sure about that one.

    This is from the memory map:
    txbuffer . . . . . . . . . . . . . . . PUBLIC XDATA ARRAY 0065H 50

    I guess it depends on whether DPTR has been loaded with the correct address for txbuffer.

    David

  • From that assembly listing, everything looks exactly correct.

    My guess is that your memory doesn't work correctly (or as you expect).


    552: txbuffer[4] = 0x44;
    c:0x1938 A3 INC DPTR;
    c:0x1939 7444 MOV A,#QueueSize(0x44)
    c:0x193b F0 MOVX @DPTR,A
    553: P1 = txbuffer[0];


    This is all exactly correct. The debugger disassembles your code. The disassembly EXACTLY matches the listing that you provided. Which, I might add, is exactly what it should be.

    This kinda reminds me of a project I looked at were the programmer duplicated every move into R0. For example,

       mov a, #12h
       mov r0, a
       mov r0, a
    
       mov a, @r0
    

    When asked why the double move into r0, he responded, "Because the first one didn't take."

    My question was, "If the first mov r0 didn't take, how do you know that the second one always would?"

    Jon

  • Thanks for the info.

    The disassembly looked funny because of the MOV A, #QueueSize which is another variable declared somewhere else.
    The listing made sense, the QueueSize in the disassembly though confused me.

    David