1. Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
    Dismiss Notice

Is this machine code insufficient to chip timing or what?

Discussion in '8051/8951' started by mik3ca, Oct 23, 2017.

  1. mik3ca

    mik3ca Member

    Joined:
    Jun 24, 2017
    Messages:
    184
    Likes:
    1
    I tried another forum for answers to this, but all one suggested was to use tools which I currently don't have nor have access to at this time, so now I'll re-ask the question here in hopes I get a better answer:

    I'm having trouble performing basic communication between two IC's. and AT89S52 and an AT89C4051. Both are connected using 6 GPIO pins of which 4 of them on each microcontroller are high nibbles of port pins. I also share the same 4 nibble pins on the AT89S52 with an HM628128 RAM IC.

    The PCB trace length from pin to pin is less than 30mm. (I try to keep them as short as possible). and the clearance and trace width are 11 mils each, so I don't think that could cause the problem.

    I did however look at an answer to one other question I posted at https://electronics.stackexchange.c...-pin-given-only-capacitance-and-no-resistance, and someone mentioned that by connecting parts to the GPIO line, the capacitance increases and that can increase the time required to make the input value of a GPIO line at a stable state which is why I deliberately sprinkled in a few NOPS into my code in hopes that I satisfied the timing requirements, but perhaps I didn't?

    Initially I was going to post this on stackoverflow.com but for some reason I feel the problem has to do with poor timing with the hardware rather than software bugs. I did document it so everyone knows exactly what I'm trying to achieve. As you can see in code, I tried using synchronization but when it comes to receiving data, my code on the client stalls.

    Each microcontroller uses the same clock speed of 22.1184Mhz with 33pF pull-down ceramic capacitors attached to it.

    This is my code:
    Code (text):

    ; ****************************************************
    ; Client: AT89S52
    ; ****************************************************

    setmyID:
    ;send SETIDL command, #6, SETIDH, and #1 in that order to adapter
    mov A,#61h
    mov R5,A
    mov R6,#SETIDL
    swap A
    lcall cmd
    mov R6,#SETIDH
    mov A,R5
    lcall cmd
    ret

    cmd:
    ;reset triggers
    setb CLK
    setb RESULT

    ;only feed high nibble to adapter
    anl A,#0F0h
    mov R7,A
    nop ;trying to sync with adapter but failed?

    ;set high nibble of port to my command and leave low nibble alone
    mov A,D
    anl A,#0Fh
    orl A,R6
    mov D,A

    clr CLK ;lower clock line to tell adapter we have data
    nop
    jb RESULT,$ ;wait till adapter acknowledges it
    nop

    ;set high nibble of port to my data and leave low nibble alone
    mov A,D
    anl A,#0Fh
    orl A,R7
    mov D,A

    setb CLK ;raise clock line to tell adapter we have data
    nop
    jnb RESULT,$ ;wait till adapter acknowledges it

    ;Make high nibble of port value high so it accepts input
    nop
    mov A,D
    orl A,#0F0h
    mov D,A

    clr RESULT ;tell adapter were ready
    nop
    jb CLK,$ ;wait until adapter sends data

    ;grab the data (to accumulator)
    nop
    mov A,D
    anl A,#0F0h

    setb RESULT ;tell adapter we got the data
    nop
    jnb CLK,$ ;wait until adapter acknowledges this

    ;PROBLEM: code never reaches here :(
    ret


    ; ****************************************************
    ; Adapter: AT89C4051
    ; ****************************************************

    ;endless main loop in adapter. Ports are all setup to accept data at this point

    main:

    ;set lines high to accept input from client
    setb RESULT
    setb CLK

    jb RESULT,noout
    ;when client lowers RESULT line, its ready to receive data

    ;Load result (LASTR) onto the data line. LASTR only has data in high nibble.
    nop
    mov A,D
    anl A,#0Fh
    orl A,LASTR
    mov D,A

    clr CLK ;let client know we sent data

    nop
    jnb RESULT,$ ;wait until client is ready to continue

    ;Allow incoming data into high nibble
    nop
    mov A,D
    orl A,#0F0h
    mov D,A
    ;and we're done
    ajmp main
    noout:

    jb CLK,main
    ;here, client wants to send data to us CLK is now low.

    ;First incoming nibble is command number
    nop
    mov A,D
    anl A,#0F0h
    mov R4,A

    clr RESULT ;tell client we got the command
    nop
    jnb CLK,$ ;wait until client sends data
    nop
    mov A,D
    anl A,#0F0h
    ; function processing here (works) then restart loop
    ajmp main
     


    Correct me if my theory is wrong, but I was thinking my only two options are to either lower the crystal speed and/or use external pull-up resistors on the shared GPIO lines.

    I'm thinking if I use external resistors, things might work because then the waiting time to turn the output of a pin into a stable state is low. For example, if I use 4.7K pull-up for every pin and each pin on each device has about a 10pF capacitance, then worst case scenario (seeing that resistors are then in parallel):

    4700 * 0.000000000030 = 0.141uS

    But without the pull-up, I'd have to factor the resistance of each device and calculate the three in parallel. I'm gonna say 20K best case. so:

    20000 * 0.000000000030 = 0.6uS

    With a 22.1184Mhz clock, its about 0.53uS per instruction execution which is under 0.6uS. This is why I was thinking of including pull-ups.

    I'd rather not lower the clock speed but if its my only option then I will.

    Am I right with my theories or is there another solution?
     
  2. ci139

    ci139 Active Member

    Joined:
    Apr 12, 2012
    Messages:
    469
    Likes:
    37
    (i donno much about hw level uC-s)
    do you use same physical lines bidirectionally ?-- going from/to Z state is quite a long stuff
    consider twisted pair or another complementary (energy balanced) setup at permanent way direction
     
    Last edited: Oct 25, 2017
  3. mik3ca

    mik3ca Member

    Joined:
    Jun 24, 2017
    Messages:
    184
    Likes:
    1
    Yes as an attempt to read and write data quickly.

    The lines for communication are traces on the PCB itself and are no more than 30mm in length.

    I also tried pulling up the line with 4.7K external resistors and that did not help either.

    Ok, so right now, I'm using a 22.1184Mhz crystal with 8051. This means that instructions execute at 2Mhz. Data speed wouldn't be higher than 1Mhz since other instructions are being processed in-between time. Are you suggesting that I may be encountering a cross-talk issue? or does crosstalk not work at that low of frequency?
     
  4. dave

    Dave New Member

    Joined:
    Jan 12, 1997
    Messages:
    -
    Likes:
    0


     
  5. ci139

    ci139 Active Member

    Joined:
    Apr 12, 2012
    Messages:
    469
    Likes:
    37

    i didn't think the cross talk but the signal visibility at receiver side - but
    • energy to RF/EMF(ield) e.g. into air
    • the relative timing e.g. delta-time set(instruct) MCU to read it's inputs - dt - the actual time the data is read
      basically a timing/synchronization problem
    there is some protection/"termination" **circuitry internal to MPU that you should include as a design variable
    • for type-X? CMOS inputs the optimal pullup is about 5k (considering P-MOS being some 10x higher R.DS.ON) -- that however must include either a "pull down" or other **termination near at receiver input/-side
    https://electronics.stackexchange.c...a-port-high-in-the-intel-8051-microcontroller

    http://slideplayer.com/slide/9933897/ frame #40
    http://slideplayer.com/slide/8972140/

    . . .
     
    Last edited: Oct 26, 2017
  6. Nigel Goodwin

    Nigel Goodwin Super Moderator Most Helpful Member

    Joined:
    Nov 17, 2003
    Messages:
    39,294
    Likes:
    647
    Location:
    Derbyshire, UK
    ONLINE
    I think you're entirely wrong, and way over thinking your problems - I would say the problems are MUCH more likely to be software, rather than imaginary capacitance and RF etc.

    Why are you doing such a bizarre thing anyway?, it's like a time warp back to the 1980's :D
     
  7. mik3ca

    mik3ca Member

    Joined:
    Jun 24, 2017
    Messages:
    184
    Likes:
    1
    Ok software it is. And why? lower prices.
     
  8. ci139

    ci139 Active Member

    Joined:
    Apr 12, 2012
    Messages:
    469
    Likes:
    37
    there are strict rules for programming microcomputers - as - what everything should apply before you can do something - and what shouldn't be running when you run something else - this is processor and perhaps even ver. speciffic -- so i can't tell anything particular about 8051 or whatever you have there

    it is like you should carefully read all (and that means all - or if you know then all what is required for your particular app ???) avail tech. spec and commented code examples in www printed books . . . fun fun . . . i gess that's why they use some C OS compilers coz they likely automatically detect if you attempt to do something impossible as transfer in between two reg.-s in between which you can't

    i think it has not much to do with software prices
     

Share This Page