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\$ Commented Mar 30, 2024 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\$ Commented Mar 30, 2024 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, 2024 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\$ Commented Mar 31, 2024 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, 2024 at 10:46

1 Answer 1

Reset to default
1
\$\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\$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.