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
<kustaa.nyh...@planmeca.com>wrote:
> 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
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
