Maker Pro
Maker Pro

8051 - counter

Q

quad

Jan 1, 1970
0
MOV A,#90H
MOV DPTR,#FF13H // LOAD CTRL WORD(90H) TO CONTROL REG(FF13) PA-
IN,PB-OUT,PC-OUT
MOVX @DPTR,A

MOV R1,#0Fh //COUNTER VALUE
MOV A,R1
MOV R2,A //R2 STORES THE CTR VALUE OF EACH ITERATION OF THE
PROGRAM

REPEAT: MOV DPTR,#FF11H
MOV A,R2 // MOVE ACC VALUE TO PORT B(FF11 - O/P PORT)
MOVX @DPTR,A

MOV DPTR,#FF10H
MOVX A,@DPTR // GET VALUE ON PORT A AND MOVE TO ACC

ADD A,#30H // CONVERT ACC VALUE TO HEXA

MOV TMOD,#20H
MOV TH1,#FDH
MOV TL1,#00H // MOVE ACC CONTENTS TO SERIAL PORT
MOV TCON,#40H
MOV SCON,#58H
MOV SBUF,A

HERE: JNB TI,HERE
CLR TI // TI = SCON.1

DEC R2
CJNE R2,#0,REPEAT // REPEAT FOR CTR VALUES STARTING FROM "OF" TO
"00"



PROBLEM: output comes on hyperterminal only for the first time.
Subsequent counter values are not getting printed. Anything to be
changed in tcon,scon,tmod? Or some clk freq to be changed, delay
given? Or anything else to be reset or cleared? Please clarify

Thanks
Quad
 
J

James Arthur

Jan 1, 1970
0
MOV A,#90H
MOV DPTR,#FF13H // LOAD CTRL WORD(90H) TO CONTROL REG(FF13) PA-
IN,PB-OUT,PC-OUT
MOVX @DPTR,A

MOV R1,#0Fh //COUNTER VALUE
MOV A,R1
MOV R2,A //R2 STORES THE CTR VALUE OF EACH ITERATION OF THE
PROGRAM

REPEAT: MOV DPTR,#FF11H
MOV A,R2 // MOVE ACC VALUE TO PORT B(FF11 - O/P PORT)
MOVX @DPTR,A

MOV DPTR,#FF10H
MOVX A,@DPTR // GET VALUE ON PORT A AND MOVE TO ACC

ADD A,#30H // CONVERT ACC VALUE TO HEXA

MOV TMOD,#20H
MOV TH1,#FDH
MOV TL1,#00H // MOVE ACC CONTENTS TO SERIAL PORT
MOV TCON,#40H
MOV SCON,#58H
MOV SBUF,A

HERE: JNB TI,HERE
CLR TI // TI = SCON.1

DEC R2
CJNE R2,#0,REPEAT // REPEAT FOR CTR VALUES STARTING FROM "OF" TO
"00"

PROBLEM: output comes on hyperterminal only for the first time.
Subsequent counter values are not getting printed. Anything to be
changed in tcon,scon,tmod? Or some clk freq to be changed, delay
given? Or anything else to be reset or cleared? Please clarify

Thanks
Quad


1) You are converting and outputting the value of Port A, not your
counter R2.
2) Your hexadecimal-to-ASCII routine doesn't work for all possible
inputs.
3) If the first character prints correctly, then the baud rate is
okay.
4) Good luck on your assignment!

Best,
James Arthur
 
I

Ian Bell

Jan 1, 1970
0
quad said:
PROBLEM: output comes on hyperterminal only for the first time.
Subsequent counter values are not getting printed. Anything to be
changed in tcon,scon,tmod? Or some clk freq to be changed, delay
given? Or anything else to be reset or cleared? Please clarify


Two things for starters:

1. you initialise the serial port each iteration - this is unnecessary

2. You add 30H to convert to hex - this may create characters that
hyperterminal cannot print.

Ian
 
M

mpm

Jan 1, 1970
0
PROBLEM: output comes on hyperterminal only for the first time.

Several things:
1 - The serial port only needs initialization once. Relocated at
beginning of code.
2 - I assume you have the correct baud rate, etc? I note there's no
mention of the PCON.7 bit.
3 - You definitely need a more robust HEX-to-ASCII conversion. Simply
adding 30H won't cut it.
4 - I don't understand your use of the DPTR. (Perhaps mapped or
dictated by your hardware??)
5 - Also, your comments do not follow your code. For example, the
lines:

MOV A,R2 // MOVE ACC VALUE TO PORT B(FF11 - O/P PORT)
and
MOV TL1,#00H // MOVE ACC CONTENTS TO SERIAL PORT

Both of these lines simply load inernal registers.
There is no interaction with the hardware pins (port or serial port).

6 - Finally, when using immediate addressing and the hex value begins
with something other than "0" through "9", it is customary (often
REQUIRED!) that you use a leading zero. This allows your assembler
to correctly assemble/relocate the Code. (Otherwise, the opcode could
get mis-interpreted as a Label, or as an address in memory - in other
words a "location" not the "value".)

I think the biggest problem here is you're printing non-printable
ASCII characters.
I didn't bother putting this on a simulator, but there are freeware
versions available for download. Though, something this simple
shouldn't demand simulation....

I suggest you go line-by-line and correct your comments.
Then, Google or write a better Hex-ASCII conversion.
Put the Serial init in a better place (though it won't hurt to keep
initializing it, it's just bad form and wastes horsepower). Correct
for leading zeros - It's a good habit to use a leading zero even if
you don't need them.

Finally, figure out what you really intend with the DPTR.

If you tell us what chip you're using, we might be able to comment on
any SRF's that might need setting. (I doubt this is the problem!)
But for example, the Dallas 87C530 has a bit tucked away to enable the
Serial RX, though the TX will work fine, etc... (I might have that
backwards?) Anyway, you get the idea...

Good luck.
If this is homework, you really should spend the time.
If not, it'd be no problem to send you some short ASCII/HEX routines.

-mpm
 
K

Ken Smith

Jan 1, 1970
0
quad wrote: [....]
2. You add 30H to convert to hex - this may create characters that
hyperterminal cannot print.

ADD A,#90H ; 0..F->90..9F With carries set
DA A ; 9A to 9F convert to 00 to 05
ADDC A,#40H ; 90..99->D0..D9, 00 to 05-> 41..46
DA A ; D0..D9 -> 30..39
 
Q

quad

Jan 1, 1970
0
Hello
Thanks a lot for all your kind responses. Actually, i'm connecting the
26pin parallel port of 8255 contained in my 8051 kit to the Xilinx
virtex Pro board, which has my circuit downloaded. For eg, when a 2
input OR gate is downloaded, i need to give 4 input
combinations(00,01,10,11) to the circuit(thro port B of 8255), and
read back the result thro port A. This result is given thro the serial
port of 8051 to my PC ( In fact, i need to use these results in a Java
program. Don't know how to do that too. I was just testing on
hyperterminal whether the right values were coming through the serial
port, and I realised that only the first value got printed, and the
subsequent values didn't come!!)

Since I'm evolving only digital circuits containing basic gates
(AND,OR,NOT,XOR, etc) i'll be getting only 1 or 0 as the result, in
which case, adding of 30 would give hex value 30 or 31 which would
print 0 or 1 correspondingly. That was the reason why I wasn't too
bothered abt the hex conversion.

In DPTR, I load the memory mapped address of the port I need to use.
(ie)Address of port B(FF11) to give output to virtex board, and
address of input port A(FF10) to get the result back from virtex
board.Since I use these port alternatingly - first port B to give
values to virtex board, and then switch to port A to get back the
result of the circuit, and since the same DPTR is used to refer to the
address of both the ports, I put the initialisation in the loop. Will
that create a problem? Is there any alternate way out?

In fact, I would need to use the Java Comm API to use the output from
serial port, in order to find if my circuit was working right!

Regards
Quad
 
M

mpm

Jan 1, 1970
0
and since the same DPTR is used to refer to the
address of both the ports, I put the initialisation in the loop. Will
that create a problem? Is there any alternate way out?

Time is short right now, but I'll try to reply a little later with
more detail.

DPTR is simply two 8-bit registers joined together to make a 16-bit
register.
It is a combination of DPH and DPL (Datapointer High, and Datapointer
Low).

Using 16 bits, you can use certain Opcodes to access all 64K of code
or data memory.

Some 8051's actually have dual DPTR's, but this is just a convenience.
You can always store the individual DPTR components (DPH & DPL) to any
other available registers and then re-load them when you need to. Or
you can even Push and Pop them on the stack.

The serial port has nothing to do with DPTR.
You can just initialize this one time, up front in your code and
forget about it.

In other words...
The Serial port is talking to Hyperterminal.
The DPTR is handling indirect memory fetch to your 8255.
Unless I'm missing something, these are two completly unrelated tasks.

Evidently, you have (2) high-memory address on the 8255 you are
concerned about, so you'll need two separate values for DPTR to reach
them. As as mentioned above, that's a total of (4) 8-bit values,
which could easily be stored in registers for safe-keeping, if needed.

Hope this helps.
-mpm
 
I hope you should have troubleshooted ur problems by now. If not,
would you be kind enough to send ur hardware/schematic (INCLUDING:
the wiring of serial port connectors.). Are u using a null modem
cable? Or is there any missmatch in GROUND ie. pin# 5 on a RS232's
DB9 connector.
If you want to see if really anything is being send serially, u can
download some ready made datalogging projects which displays the
incoming values through serial port in an oscilloscope like display.
Yes, there are such things somewhere up there. If you are having any
trouble in finding them, feel free to mail me.
Cause after two weeks of headbagging on a flawless code i was able to
debug my problem in hardware.
BYe cheers.
 
Q

quad

Jan 1, 1970
0
Debugged the code finally. There was also some flaw in relative
addressing. Thanks a lot for your kind responses!
Regards
Quad
 
Top