Thanks for the reply Richard, but there's actually nothing wrong with
supplying EEPROM data at compile time.
The code actually works fine with PIC16F, it's just PIC18F doesn't pad
extra 0x00's between each byte in the HEX file, whereas PIC16F generated
HEX files do.
If I force SDCC to use short instead of char then it works, but I have
to fudge the code with /2 everywhere - yuck!
Thanks,
Alan.
On Fri, 2010-10-15 at 15:45 +0100, Richard Gray wrote:
> In view of the silence on this subject, I'll just tell you about my (few)
> experiences of PIC EEPROM programming. I was using the 16F series, but I
> would
> imagine there are similarities.
>
> Programming the EEPROM on PICs, as I understand it is a runtime thing, rather
> than a program time (or compile time) thing. So, suppose that I wanted to
> store "1234" as a default lock combination in EEPROM, I would have to have
> the
> "1234" as a constant in the code space and program the EEPROM at the first
> actual execution of the code on the PIC chip. I seem to recall that
> programming the EEPROM is quirky too - and I think there's even an interrupt
> to indicate the write cycle is complete! I seem to recall that I had to write
> an assembler fragment to actually perform the write because the timing of the
> compiled C code wasn't right.
>
> There are issues which might be relevant to this, particularly if there's a
> power interruption during the write cycle leaving you with a corrupt EEPROM.
> I
> think I chose to ignore this scenario after due consideration, but it's
> something you need to be aware of.
>
> The code that I wrote was for a different compiler (and I haven't ported it
> to
> SDCC), but if you continue to be stuck I'll try and dig it out for you - you
> might glean something from it.
>
> On Friday 15 October 2010 15:03:19 Alan Hourihane wrote:
> > On Wed, 2010-10-13 at 16:24 +0100, Alan Hourihane wrote:
> > > Hi,
> > >
> > > I wonder if someone can help.
> > >
> > > I'm using a PIC18F242 / PIC18F2420 and sdcc 2.9.0 and currently using
> > > this code to pop things into EEPROM storage.
> > >
> > > __code unsigned char __at( 0xf00000 )
> > > values[] = {
> > > 0x00, 0x01,
> > > 0x02, 0x03,
> > > 0x04, 0x05,
> > > };
> > >
> > > Unfortunately, when I use the EEPROM read commands for index 0, I get
> > > 0x00, for index 1, I get 0x02, and index 2, I get 0x04.
> > >
> > > I've read articles that say the EEPROM needs to be padded to 16bits for
> > > the above PICs, and was hoping that I could declare with __eeprom
> > > instead of __code and sdcc would fix this up for me but it seems that
> > > __eeprom isn't done for PIC16. I don't want to have to declare as a
> > > 'short' as then it impacts the code itself to cater for /2 situations.
> > >
> > > Any help much appreciated ?
> >
> > Anyone got any clues ?
> >
> > Thanks,
> >
> > Alan.
> <snip>
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
