eeprom

datasheet says that
32k/64k eeprom is capable of 32 byte pagge write
if more than 32 bytes are transmitted then data address will roll over and previous data will be overwritten

i hav resolved this problem but i want to confirm whether i hav done it correct

my code :
savedata ()
{ data buffer[0]=data0; data buffer[1]=data1; data buffer[2]=data2; data buffer[3]=data3; if(j == 32) Write(4,360); else if(j == 36) Write(4,364); else Write(4,(320+j));

j=j+4; if(j == 40) j = 0;
}

data0 to data3 is one set, this way i hav 9 more sets=total 10 sets

where (320+0) to (320+28) my data is stored from set0 to set7 (32 bytes are over-one page is over)

Write(4,(320+j))-- 4 locations from (320+j)

and when j=32 it is 8th set written at 360 to 363

when j=36 it is 9th set written at 364 to 367

datasheet says that
32k/64k eeprom is capable of 32 byte pagge write
if more than 32 bytes are transmitted then data address will roll over and previous data will be overwritten

i hav resolved this problem but i want to confirm whether i hav done it correct

my code :
savedata ()
{ data buffer[0]=data0; data buffer[1]=data1; data buffer[2]=data2; data buffer[3]=data3; if(j == 32) Write(4,360); else if(j == 36) Write(4,364); else Write(4,(320+j));

j=j+4; if(j == 40) j = 0;
}

data0 to data3 is one set, this way i hav 9 more sets=total 10 sets

where (320+0) to (320+28) my data is stored from set0 to set7 (32 bytes are over-one page is over)

Write(4,(320+j))-- 4 locations from (320+j)

and when j=32 it is 8th set written at 360 to 363

when j=36 it is 9th set written at 364 to 367

www.danlhenry.com/.../keil_code.png

savedata ()

{

data buffer[0]=data0;

data buffer[1]=data1;

data buffer[2]=data2;

data buffer[3]=data3;

if(j == 32) Write(4,360);

else if(j == 36) Write(4,364);

else Write(4,(320+j));

j=j+4;

if(j == 40) j = 0;

}

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.