1
\$\begingroup\$

enter image description hereI’m trying to implement an automated parking lot using an 8051. I’m using stepper motors to function as gates at the entrance and the exit of the parking lot that open whenever the IR sensors placed at the entrance/exit detects a vehicle passing by. I’m also keeping a count of the available slots in the lot using the sensors and I’m displaying it using two multiplexed seven segment displays. The code functions flawlessly within simulation tools like proteus but doesn’t work at all upon physical assembly. I have physically assembled the 7 segment part of the program (the sub routine called disp) which worked properly. I don’t understand why it stops functioning once I integrate the codes for the stepper motors and the IR Sensors. Here’s the code:

    
org 0000h 
mov r6,#02h
mov r1,#0fh
mov r2,#0f0h
mov dptr,#table


;from maincode:
mov p2,#11H
clr p1.7
setb c
l1:jnb p1.1,ent
l2:jnb p1.2,exit
mov a,r6
acall disp
jnc l2
sjmp l1

ent:mov a,r6
dec a
mov r6,a
mov p2,#12H
l3:acall disp
jnb p1.1,l3
mov p2,#11H
mov a,r6
jz m5
sjmp l1
m5:clr c
setb p1.7
sjmp l2
exit:
clr p1.7
setb c
mov a,r6
inc a
mov r6,a
mov p2,#21H
l4:acall disp
jnb p1.2,l4
mov p2,#11H
sjmp l1







disp:mov a,r6
anl a,r1
movc a,@a+dptr
mov p3,a
setb p1.5
mov r5,#05h
mov th0,#00h
mov tl0,#00h
dj1:acall delay1
djnz r5,dj1
clr p1.5
mov th0,#00h
mov tl0,#00h
mov r5,#05h
dj4:acall delay1
djnz r5,dj4

mov a,r6
anl a,r2
swap a
movc a,@a+dptr
mov p3,a
setb p1.6
mov r5,#05h
mov th0,#00h
mov tl0,#00h
dj2:acall delay1
djnz r5,dj2
clr p1.6
mov th0,#00h
mov tl0,#00h
mov r5,#05h
dj3:acall delay1
djnz r5,dj3
ret




delay1:mov r7,#14h
m8:SETB TR0
AGAIN:JNB TF0,AGAIN
CLR TR0
CLR TF0
djnz r7,m8
RET

table:db 0c0h,0f9h,0a4h
end

And here’s 7 segment display part of the program that i tested separately:


org 0000h
    
mov r6,#02h
mov r1,#0fh
mov r2,#0f0h
mov dptr,#table

disp:mov a,r6
anl a,r1
movc a,@a+dptr
mov p3,a
setb p1.5
mov r5,#05h
mov th0,#00h
mov tl0,#00h
dj1:acall delay1
djnz r5,dj1
clr p1.5
mov th0,#00h
mov tl0,#00h
acall delay1

mov a,r6
anl a,r2
swap a
movc a,@a+dptr
mov p3,a
setb p1.6
mov r5,#05h
mov th0,#00h
mov tl0,#00h
dj2:acall delay1
djnz r5,dj2
clr p1.6
mov th0,#00h
mov tl0,#00h
acall delay1
sjmp disp

delay1:MOV R1,#00AH
R:SETB TR0
AGAIN:JNB TF0,AGAIN
CLR TR0
CLR TF0
DJNZ R1,R
RET

table:db 0c0h,0f9h,0a4h
end
\$\endgroup\$
6
  • \$\begingroup\$ (While a ULN2003 doesn't have 8 drivers to connect in pairs, I might do that for the 3 pairs possible. (and distribute between packages, but that's a mixed blessing at best.)(That's a funny model showing unconnected ULN2003 inputs as undefined.)) \$\endgroup\$
    – greybeard
    Commented Mar 30 at 13:32
  • \$\begingroup\$ Can you be more specific regarding exactly who's / which 8051 derivative you are using? A "real" Intel 8051 would not worked wired up this way. The Address Lines / GPIO lines are always being used for both features and need to be latched for one or the other at the destination. \$\endgroup\$
    – st2000
    Commented Mar 30 at 13:44
  • 2
    \$\begingroup\$ Do you have an actual as-built schematic? The simulation schematic lacks some necessary connections such as E and COM for the ULN2003A chips. \$\endgroup\$ Commented Mar 31 at 0:33
  • 1
    \$\begingroup\$ I get code like that from a disassembler. I then add comments to it. I’d suggest when you write the cod you add comments. My guess is you sit in delay loops and other tasks stop whilst that happens. Re-arrange your code so that you loop at a given rate. Each time through the loop you evaluate your logic and update the outputs. Count loops to create non-blocking delays. Design your code first, then write the assembler. \$\endgroup\$
    – Kartman
    Commented Mar 31 at 5:18
  • 1
    \$\begingroup\$ Please format your code by indenting mnemonics, aligning the operands, and so on. Currently it is barely readable. Add (abstract) comments to show your intent. \$\endgroup\$ Commented Mar 31 at 10:46

1 Answer 1

0
\$\begingroup\$

I can't see what it is you're trying to do. In particular, the actions on "r1", "r2" and "r6" make no sense and you're using "a" superfluously.

In the second, shorter, version, "r6" is always 2. "r1" is 0fh the first time "disp" is passed through and is 0 each subsequent time "disp" is passed through, so the table lookup (rendered in pseudo-C as "table[r1 & r6]") will be 0f9h the first time and 0c0h each subsequent time. The second table lookup would be rendered in pseudo-C as table[(r2 & r6) << 4] = table[0] = 0c0h, because "r2" is 0f0h the whole time, so that r2 & r6 is 0 and "swap a" isn't doing anything except turning 00h into 00h.

The first, longer, version is doing something totally different with "r6" and you're doing a superfluous "mov a, r6" before the "acall disp" after "l2". The "disp" routine doesn't use "a" as input. It sets it to "r6". Also, because "a" is superfluous upon each call to "disp", there is no reason to write "r6" into "a" when incrementing it (after "exit") or decrementing it (after "ent"), since you can just write "inc r6" and "dec r6" directly, without passing anything through "a".

You really have to rewrite both versions and think through and explain more clearly what it is you're trying to get the routines to do. They're internally inconsistent.

The only part that's going to do anything consistent is the part that's removed from all the action on "r1", "r2" and "r6"; and that is, "delay1", and the actions on "r5", "p1.5", "p1.6", "th0" and "tl0". That part is consistent, on internal grounds, and apparently that's what you're referring to when you say that things are working in simulation, as well as physically. That's the part running the numeric displays.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.