AVR Freaks

Why have you got a function declaration in the middle of that? There's already a declaration for eeprom_read_byte in and it is:

then you are trying to change that with a malformed parameter type (don't cast in a declaration) and one parameter missing

Try simply something like:

That gives you a location in EEMEM (EEPROM) to hold values and keeps you "Disp" counting variable in RAM, writing it after each update to the EEPROM variable you defined then reading it back.

HI abcminiuser
This is really a good stuff.I want similar directive for flash.
i also want to know the syntax of defining interrupts in avr-gcc.

It's when you use ++ with a POINTER that ++ increases it by the size of the type that the pointer points at. But these EEPROM "addresses" are really integers not pointers - that's why there's a typecast converting their interpretation to "pointer to unsigned 16 bit integer" before the value is passed to the e_r_w() function. So the ++ in this case will always increment by one.

If you want the increments to be by the number of bytes of the data type then declare 'address' as a pointer in the first place in which case the typecast will not be required:

Now 'address' points at location 0x0008.

All this does kind of raise the question of what on earth are you doing with absolute addressing of EEPROM anyway? You have heard of "EEMEM" and the "linker" have you?

If I write:

then that reads a character from eeprom and also the fourth word of the data array in eeprom. You and I don't know (and have no reason to need to know) where the linker has chosen to locate 'c' and data[3]. It could be 0x0006 or it could be 0x003C - but who cares - like named variables in RAM the linker, not you, decides where they will be located.

Yes. You can start with default values if you want too:

If you build this then as well as a .hex you'll get a project.eep which can be programmed into EEPROM using ISP and will set the locations set aside for data[0]..data[3] to 4, 91, 217 and 38.

After the for() loop has been run the four locations will now contain 0, 1, 2 and 3

Cliff

PS It probably helps if you actually read the article at the start of this thread - all this is explained in better detail than I can manage.

A block is a block is a block. Only difference is that your words each are double the size of a byte, so I'd think that you'd

It might be overkill, but with a few nice manouvres, including use of sizeof(), we could probably get rid of the literal value 2 above.

Not quite, the size field in e_w_b() is always BYTES so assuming the 'size' that is transmitted and stored into the 'size' variable isn't really the "size" but rather the "number of data values about to follow" then in the uint16_t case you need to double the value as each entry in the array occupies 2 bytes, not 1.

To avoid confusing yourself and, more importantly, the NEXT reader of your code I'd reconsider whether 'size' is a good name to use here. I think I'd choose something like 'num_elements' and on the e_w_b() line I'd do something like:

BTW, once again, by having the distant source transmit 'address' as the EEPROM location you are pre-empting the linker so it now becomes your responsibility to position everything in EEPROM and make sure there are no overlaps and so on.

element[0] is just as good as element[n] to test for size but all arrays have element[0] but not all necessarily go up to n which is why I used [0]

You can over-ride positioning with linker scripts or --section-starts but what's the point?

If you want to you can forget the linker and named variables altogether and just do something like:

Now you are responsible for the EEPROM layout but you have to be very cautious of errors. Say you wrote:

Looks very similar doesn't it? But a write to 'my_long' will over-write the second byte of the int. The linker is far better at laying things out that you or I.

Another idea if you need a fixed layout is:

The only "unknown" position in this is the actual base address of ee_vars in EEMEM but if it's the only EEMEM variable (holding all the variables you want) it's a fair bet it's at 0x0000.

You can now add variables and maintain the layout as long as they are always added to the end of the struct{}

Cliff

then in the LDFLAGS use:

which will have the same effect as using EEMEM but guarantees that 'ee_var' is located at 0x0000 in the EEPROM.

With this in mind you may want to use 0x810001 in the --section-start above.

Cliff

PS I locked the cross post in GCC to avoid accidents. If you like I can split this last part of this thread off as a separate thread with a name similar to the GCC thread and move it there but I think the foregoing IS on topic for this thread in fact.

PPS to answer the question you asked in GCC you can use --section-start on code, RAM and EEPROM. The only differences are that code addresses start at 0x000000, RAM at 0x800000 and EEPROM at 0x810000 but in all you use __attribute__((section(".yourname"))) and then later --section-start=.yourname=0x??????

I know it's slightly off topic but anything in code flash by it's very nature is not going to be "variable" but if you are talking about constant arrays I don't see why it matters to you where the linker chooses to place them though the --section-start with __attribute__section() will do the trick but this time you are in even more dangerous territory as some of what goes into code flash MUST be positioned by the linker so you don't want to risk any overlaps (putting fixed data at the very end of the flash is usually pretty safe). But, unless this is about replacing pages of data with SPM I don't see any point in trying to preempt the linker.

This thread is not for diagnosing EEPROM usage problems. It is for discussing the article in the first post.

Moderator.

PS As for your warnings. Take for example:

where:

Now look at the prototype in eeprom.h:

uint16_t is "unsigned int". When you use just "int" then by default it is interpreted as "signed int".

THAT is why you get a signedness warning. Either cast or use the right type.

Also consider:

and the prototype in eeprom.h

It's warning about param2 which is the "void * __dst" in the prototype and which you cast as "(const void*)". The warning is about the loss of the const qualifier.