Forum Need help with the following Homework assignment… Design a fire alarm system using a 8051 microcontroller. The specs are as follows: A) If the alarm is detected (one of the switches is activated) it should start flashing 4 LEDS (4 on the right (LEDS 1-4) and 4 on the left (LEDS 5-8), alternating). B) If the alarm is not detected, the display should show only 2 middle LEDS (LEDS 4 & 5) steadily ON (not flashing) indicating NORMAL operation. This is the code I’ve come up with so far, but I appear to be stuck. I would appreciate and assistance. Thank you.
Code…
ORG 0H ;Program starting location MOV A, #0 ; MOV P2, A ; MOV A, #OFFH ; MOV P1, A ;
INPUT: MOV A, P1 ;
HERE: JNB A, HERE ; MOV P2, #1 ;
DELAY: MOV R3, #15 ; OUTER: MOV R2, #240 ; INNER: DJNZ R2, INNER ; DJNZ R3, OUTER ; RET
SDELAY: MOV R5, #45 ;put 45 in R5 H3: MOV R4, #242 ;put 242 in R4 H2: MOV R3, #255 ;put 255 in R5 H1: DJNZ R3, H1 ;Decrement R3 keep @ H1 if not zeroed DJNZ R4, H2 ;Decrement R4 keep @ H2 if not zeroed DJNZ R5, H3 ;Decrement R5 keep @ H3 if not zeroed RET ;Return & Go back to line after ACALL
;--------------------
END
1) Why not use the proper formatting, as clearly explained directly above the message input box?
2) Why not think carefully about what to comment and how to use labels and variables?
MOV A, #0 ; MOV P2, A ;
What would make a reader know if this is intended to clear any LED?
MOV A, #OFFH ; MOV P1, A ;
What would make a reader know if this is intended to make P1 into eight "input"?
What reader would know what is connected to P1 and what the values in A would then actually represent? And are all pins of P1 relevant?
HERE: JNB A, HERE ;
Hmm - how well do "here" explain this? And how do you expect to leave this loop?
MOV P2, #1 ;
What reader would know what the magic value #1 will actually control on that port?
What was your intention with "RET"?
SDELAY: MOV R5, #45 ;put 45 in R5 H3: MOV R4, #242 ;put 242 in R4 H2: MOV R3, #255 ;put 255 in R5
Suddenly you have started to write comments - but what value is a comment that tells the reader that yu put the value 45 into a register? Is the reader not expected to understand the assembler instructions?
And what is the difference between the label DELAY and SDELAY - can that difference be understood by the label names?
And do you think label names "H2" and "H3" really gives much help to a reader? And what was the actual meaning of all these numbers? Arbitrary numbers or intended to produce a specific result? You know it's possible to declare named constants in assembler?
RET ;Return & Go back to line after ACALL
So we suddenly have an ACALL? Where? And would the comment be correct if the caller decides on a LCALL instead?
Remember that your task is to spend own time getting stuck. Reviewing. Rewriting. Getting stuck. Reviewing. Rewriting. Testing. Rreviewing. Rewriting. Testing.
Rinse/repeat until you have a final solution that works. That's how you learn. Trying to short-circuit that process will not help you with the following assignments or when it's time for the final tests to pass the course.
also, over the entru window, if you looked, you would see how to place source code.
I second Pers comments re comments H3: MOV R4, #242 ;put 242 in R4 does not say squat, and where a comment would be useful, there is none.
general re comments
actually you con, in most cases 'comment' in two ways a) a comments and b) meaningful lables
e.g.
typedef enum { ALL_LEDS_OFF = 0xFF ... ... }t_led_bits
and #define Po LED-PORT
then
mov LED_PORT,#ALL_LEDS_OFF
is self commenting
do not fall for the fallacy that C is self commenting,that is only true with meaningful lables
No language is self-commenting.
The language and symbols may help tell a story of what is done. But it can't tell why it is done.
Very unlikely that this is what you want.
JNB if Jump If Not Bit.
A is NOT a bit. It's the ACC register.
It will assemble, but do you want to really test the bit that has the address of ACC?
OK.Per {is "some statements using meaningful names are self explanatory to the extent that a comment would be superfluous"
I am a great believer in commenting intentions, but have seen too many comments of actions like mov LED_PORT,#ALL_LEDS_OFF // turn LEDs off that makes the essential comments disappear in the haze.
mov P0,#255 // shuld, of course be commented but mov LED_PORT,#ALL_LEDS_OF // is self-explanatory
thus, using meaningful names you can (never say never) avoid commentig actions, which makes you intention comments stand out
"[...] that makes the essential comments disappear in the haze."
Yes, the primary goal for any author is to begin with figuring out who the intended reader is.
And writing comments that duplicates the actual action of the code indicates that the intended audience is the coder himself - and that the coder isn't really 100% convinced that the instructions are really doing what he/she thinks/hopes they will do.
In my world, the software comments should be directed at a reader who are already reasonably well versed in the used programming language. So only when something tricky is happening would it be meaningful to augment the code with some explanation of the actual actions (assuming the code can't be rewritten in a way that the trickiness can be removed without introducing other issues).
But I think the schools are failing when teaching programming since they more tend to teach "the code should be well documented" as meaning "there should be a high amount of comments".
It's so trivial to do:
delay_ms(1000); // delay 1000 milliseconds
and explain the action instead of telling the reader why there is a need for a one-second delay - or if the delay time was arbitrarily selected and 500ms or 2000ms would have worked just as well.
Not sure I can fully agree with that.
Quite frequently I will write comments that indicate what the code is doing; not at the 'load index with 10', but reset index or some-such. In your eyes it might look like simple duplication, but there are many, many times where looking through the code afterwards (maybe years later) has highlighted a difference between code and comment; which has then caused me to re-think what is happening. It's essentially a double check for the mundane and it is something that has certainly worked well with the projects I've been involved with.
not at the 'load index with 10', but reset index or some-such in my school index = 10 and such is outlawed index = CHARACTER_LOOP_COUNT accomplishes exactly what you refer to without a comment
one of the most frequent causes for what I call "superfluous comment" is "magic numbers", if you did not use :magic numbers" less comments would be needed.
I am all for comments, but quoting Per "commenting does not just mean lots of comments". Using meaningful names makes a lot of thus useless comments disappear and then the meaningful comments will not disappear in the haze, but stand out.
Magic numbers are certainly something to be avoided, but manifests are definitely not always the best solution.
Many is the time I've seen someone write something like mov uart_ctrl, UART_ENABLE_TX .Code looks fine, people say it's self commenting. But then it's wrong. Nothing is there to say that it should be an or operation rather than a mov.
index = CHARACTER_LOOP_COUNT
Fine if you only happen to have one requirement for such a value in a module. Not so good if there are a number of them there. Too easy to devise clever names as:
#define CHARACTER_LOOP_COUNT1 10 #define CHARACTER_LOOP_COUNT2 107 #define CHARACTER_LOOP_COUNT3 19 #define CHARACTER_LOOP_COUNT4 33 #define CHARACTER_LOOP_COUNT5 27
I'm wary of people who insist on tight rules. We have recently had [another] new development lead. He insists that we all train up and learn his current best practices. Trouble is, his code always seems to fail. Of course, it's never his current best practices that are anything to do with it and he would rather blame all other code that doesn't follow his practices. So far, his fail score is way higher than mine!
The only absolute rule is that there can be no absolute rule - an inflexible tree snaps in the storm.
But the general idea is to know and understand rules before starting to bend them. It's much better to cherry-pick what works well than spending the day trying to hammer down a square peg in a round hole.
should be something like #define FETCH_CHARACTER_LOOP_COUNT 10 #define IMAGE_CHARACTER_LOOP_COUNT 107 #define RESPONSE_CHARACTER_LOOP_COUNT 19 #define COMPARE_CHARACTER_LOOP_COUNT 33 #define DISPLAY_CHARACTER_LOOP_COUNT 27
your version STILL uses "magic numbers"
oh yes, I have seen this "workaround": typedef enum {ONE, TWO, THREE, FOUR}
the idea is that you dismiss those that play games like this