On 4/15/12 00:59, "Raphael Neider" <rnei...@web.de> wrote:
>
>It is planned (but obviously not yet implemented) to allow access to
>EEPROM via the generic pointer mechanism. EEPROM would be mapped into
>the generic address space at 0x40.0000..0x7F.FFFF; 0x00.0000-0x3F.FFFF
>is code/program memory, 0x40.0000-0x7F.FFFF is supposed to be EEPROM,
>and 0x80.0000-0xFF.FFFF is data memory. Once this feature is
>implemented, access to EEPROM is as simple as
>
>uint8_t __at(0x400000) eeprom_start;
>uint8_t * const eeprom = &eeprom_start;
>
>uint8_t eeprom_read(uint8_t address) {
> return eeprom[address];
>}
>
>void eeprom_write(uint8_t address, uint8_t value) {
> eeprom[address] = value;
>}
>
>uint8_t eeprom_write_and_verify(uint8_t address, uint8_t value) {
> volatile uint8_t *ee = (volatile uint8_t *)eeprom;
> ee[value] = value;
> return (ee[value] ^ value); /* or whatever is desired for verification
>*/
>}
>
>If desired, I can try to implement this.
I realize I'm late to this party and that this has already gone forward,
but just want to give my view on this.
I'm not in favor of having this sort of functionality, especially not for
writing EEPROM. On a philosophical level it goes agains the spirit of C,
which is to give kind of 'raw' access to the underlaying hardware, not
high level functionality.
On practical level it is not nice to hide potentially long, complex
and slow subroutine behind an innocent looking pointer access. Pointer
access is by nature very low level access to raw memory.
The benefit is very small and the potential for confusion and subtle
bugs down the line when target code is maintained is great (think
about concurrency and potential to overlook such an innocent looking
pieces of code).
I realize no one needs to use this, and I would advice against using it,
better use an explicit subroutine call, but even so I think it is a
mistake to provide this.
Read access is a borderline case given that general pointer access
is by necessity what it is in PIC but write is a definite no no IMO.
Just my 2 snt.
br Kusti
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
