Is this machine code insufficient to chip timing or what?

[mik3ca]

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:

; ****************************************************
; 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?

 

[ci139]

(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

 

[mik3ca]

do you use same physical lines bidirectionally

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.

consider twisted pair or another complementary (energy balanced) setup at permanent way direction

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?

 

[ci139]

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

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

. . .

 

[Nigel Goodwin]

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

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

 

[mik3ca]

Ok software it is. And why? lower prices.

 

[ci139]

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