Hi Raphael!

Accesing via generic pointers would be amazing. If you had time, I would
love to see it implemeted.
The __eeprom keyword can wait, hehe!

Maybe I could help you with implementation of eeprom reads and writes. I
could start with device/lib/pic16/libsdcc/gptr/*.c which I think that I
understand, and send the patch to you so you can check if it's ok. I don't
know what to do in src/pic16/gen.c, though.

After reading the code in the repository, I think that code memory reads
via pointers are implemented but code memory writes are not, right?

Thank you very much.

On Sat, Apr 14, 2012 at 11:59 PM, Raphael Neider <rnei...@web.de> wrote:

> Hi,
>
> > I had always used a library with the following functions to read/write
> > eeprom memory:
> >
> > uint8_t eeprom_read(uint8_t address);
> > void eeprom_write(uint8_t address, uint8_t value);
> > uint8_t eeprom_write_and_verify(uint8_t address, uint8_t value);
> >
> > Reading the SDCC manual again, I started thinking that it may also be
> done
> > using pointers without needing this functions. Can it be done? If yes,
> how?
>
> 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. Basically, adjustments need
> to be done in two places: device/lib/pic16/libsdcc/gptr/*.c must
> certainly be adjusted to actually implement EEPROM access, and
> src/pic16/gen.c must probably be adjusted to generate EEPROM access on
> certain pointer dereferences. One might want to introduce/enable some
> keyword (__eeprom?) to allocate objects in EEPROM space like
> __eeprom uint8_t in_eeprom; /* initialisers will be more difficult */
> but that may not be too urgent.
>
> Best regards
> Raphael
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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

Reply via email to