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
Didn't find your answer? Ask the community — no account required.
M
martin griffith
many people find hyperterminal is rubbish
formatting link
sorry, cant help you with the code, but at least you can see if it's the PC or the 8051
martin
J
James Arthur
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
Two things for starters:
you initialise the serial port each iteration - this is unnecessary
You add 30H to convert to hex - this may create characters that hyperterminal cannot print.
Ian
M
mpm
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
[....]
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
--
kensmith@rahul.net forging knowledge
Q
quad
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
and since the same DPTR is used to refer to the
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
S
shibinkidd
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
Debugged the code finally. There was also some flaw in relative addressing. Thanks a lot for your kind responses! Regards Quad
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.