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
No language is self-commenting.
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