From: Diego H. <die...@di...> - 2012-04-26 14:52:22
|
I'm starting to think like Kustaa even tough I started this topic. Anyway, I went on testing, and I think that eeprom8_write and eeprom16_write are missing a return asm instruction. If eventually we don't want to have this eeprom pointer access feature, it would be nice to turn it into a library so you could do in your code: #include <eeprom.h> [...] eeprom_write(0xAA, 0x25); foo=eeprom_read(0xAA); [...] Thanks a lot On Mon, Apr 23, 2012 at 1:09 PM, Kustaa Nyholm <Kus...@pl...>wrote: > On 4/15/12 00:59, "Raphael Neider" <rn...@we...> 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 > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |