eeprom

Look again: www.danlhenry.com/.../keil_code.png

there's just one set of 'pre' and '/pre' tags around the complete code listing.

It's also explained here: http://www.keil.com/forum/tips.asp - you can see the link in the picture!

Don't use TABs - use spaces for indentation (TABs are unreliable)

Use the 'Preview' button to check it before you press 'Post'

Put some comments in your code to explain what you're trying to achieve!
(and, while you're doing it, think about whether the code does actually achieve that!)

Look again: www.danlhenry.com/.../keil_code.png

there's just one set of 'pre' and '/pre' tags around the complete code listing.

It's also explained here: http://www.keil.com/forum/tips.asp - you can see the link in the picture!

Don't use TABs - use spaces for indentation (TABs are unreliable)

Use the 'Preview' button to check it before you press 'Post'

Put some comments in your code to explain what you're trying to achieve!
(and, while you're doing it, think about whether the code does actually achieve that!)

Put some comments in your code to explain what you're trying to achieve!

what code??? NOTHING woithout comments is code, it is mere scribbles

Erik

Exageration!

if (ee_read_byte(EE_VERBOSE_FLAG_ADDR,&flag_verbose) == EE_OK
&&  flag_verbose) {
    ...
}

Depending on complexity of logic, you may be able to write significant number of code lines without the need for comments.

Comments should be added where meaningful - not obligatory just because.

what code??? NOTHING woithout comments is code, it is mere scribbles

where does that say "obligatory just because", it says "without comments"

taking your verbose example it would still need e.g. 'function headers' (comments) to be clear

erik

I suspect that this may well be one of those cases where the mere act of thinking about the code & writing the comments will probably reveal the problem to the OP...

It's not difficult to see what the code does - eg, copying individual data items into an array - the question is why the OP has done that, and how he thinks that will achieve his goal of writing to the EEPROM...

These are the questions that the comments need to answer!

"NOTHING woithout comments is code"

machine code generally does not contain comments...

And then someone invented assembler :)

Aren't you undermining your own argument there...?!

No, my argument is that some things can be documented by suitable use of symbol names.

Unless an algorithm is very complex, I don't like comments saying what it does - I want to be able to pick that up from the naming, and have more time spent on documenting why things are done.

Having comments telling "what" often leads to source code where the instructions does one thing, and the comments says something else.

thanx but my problem is solved my code was incorrect and i hav done it in different way
thanx

Having comments telling "what" often leads to source code where the instructions does one thing, and the comments says something else.

For me, I prefer to do just that; i.e., include the comments.

My reasoning - If the instructions and the comments do not match, then it is an immediate indication that (at least) one of them must be wrong.

In projects where the development team is 'just me', I need all the help I can get. This helps me to read through the code looking for 'sillies' more effectively.

When opening a project, you don't have time to compare code to comments to check if they match. And if they do not match - which is correct? A silly bug in the code, or the comment not being updated when the logic was updated?

I would definitely recommend that you concentrate on documenting the "why" and write the code in a way that it is enough to look at the code to see the "what".

When you open an old project and see something like

delay_ms(1000); // delay for 1000ms

you most definitely know what it does (or at least what it is expected to do, unless the delay_ms() function is broken). But the question is: Why do you call it? What happens if the delay is increased or decreased? Is the delay needed to let a voltage stabilize, or to make sure that the other side of a communication channel doesn't get overrun or... How has the delay value been deduced? Verified with oscilloscope and with xx% safety margin added? That is things you want to know, when you are in a rush to modify the code to add the next magic feature some customer has requested.

Per,

I would not argue with your content of the comment - Putting in the 'why' is far more important that repeating the obvious.

But if, for example, there is a line of code:

StartTx();  // Check for completion

I do find that on skimming over the code, I notice such obvious discrepancies.

i recall 'comments' from the assembler days such as
push acc ; save accumulator on stack
which, of course do not even deserve the name 'comment'.
however
push AR3 ; beware, the use of r3 is buried deep, do not remove
might have a purpose

I totally agree with the statement that why is the important thing to comment, However, as far as what there are cases:
// ........
// ........
// ........
// exit false if overlow occur

U1 DoSomeMathFunction(U8 Tom, U16 ***, U8 Harry)

i would hate to go through lots of lines of code to see what the exit flag signified.

Erik

I wanna know the difference between the follwing...

Linear Hall-Effect Sensors

Unipolar Hall-Effect Digital Switches

Omnipolar Hall-Effect Digital Switches

Bipolar Hall-Effect Digital Switches

Hall-Effect Digital Latches

First of all, you wrote a statement - was it inteded to be a question?

The functioning of different sensors isn't directly related to the Keil tools. Don't you think a hardware-orientthe inner workings of electronic components?ed forum might be a better choice when wondering about?

Besides, what does the sensors has to do with the use of EEPROM memories?