On Fri, 2010-10-15 at 16:44 +0200, Raphael Neider wrote:
> Hi,
>
> >> __code unsigned char __at( 0xf0 )
> >> values[] = {
> >>0x00, 0x01,
> >>0x02, 0x03,
> >>0x04, 0x05,
> >> };
> >>
> >> Unfortunately, when I use the EEPROM read commands for index 0, I get
> >> 0x00, for index 1,
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
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
On Fri, 2010-10-15 at 16:44 +0200, Raphael Neider wrote:
> Hi,
>
> >> __code unsigned char __at( 0xf0 )
> >> values[] = {
> >>0x00, 0x01,
> >>0x02, 0x03,
> >>0x04, 0x05,
> >> };
> >>
> >> Unfortunately, when I use the EEPROM read commands for index 0, I get
> >> 0x00, for index 1,
Hi,
>> __code unsigned char __at( 0xf0 )
>> 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.
Could you check whether/which of th
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( 0xf0 )
> values[] = {
> 0x00, 0x01,
>
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( 0xf0 )
values[] = {
0x00, 0x01,
0x02, 0x03,
0x04, 0x05,
};
Unfortunately, when I use the EE
