Sign in

username:

password:



Not a member?

Search Comp.Arch.Embedded



Search tips

embedded by Keywords

68HC11 | 68HC12 | 8051 | 8052 | ARM | ARM7 | Asic | AT91 | AT91RM9200 | Atmel | AVR | AVRStudio | Bootloader | CFP | CompactFlash | Cygnal | Cypress | Dataflash | DSP | eCos | EEPROM | Embedded Linux | Emulator | Endian | Ethernet | Firewire | FPGA | Freescale | GCC | GNUARM | GSM | H8 | HDLC | I2C | Infineon | Interrupts | Java | JTAG | LCD | LED | LPC2000 | MCU | Microchip | MMC | MPLAB | MSP430 | PC104 | PCB | PCI | PCMCIA | PowerPC | Rabbit | RS232 | RS485 | RTOS | SBC | SDRAM | Sensor | SPI | STK500 | UART | UML | USART | USB | Verilog | VHDL | VxWorks | Xilinx

Ads

Discussion Groups

Discussion Groups | Comp.Arch.Embedded | Re: Problems reading data EEprom on Pic 16F88

There are 4 messages in this thread.

You are currently looking at messages 0 to 4.

Re: Problems reading data EEprom on Pic 16F88 - Gary Kato - 05:57 14-11-04

I think you are confusing EEPROM with the File Registers. Their adresses
overlap each other. When you do this:

  movlw   h'BB'
  movwf  count1

You are moving BB into the File Register at location 20. This is not altering
EEPROM which can only be addressed using the EEADR register.

When you read from EEPROM location 20, this is a different place than File
Register location 20. This is why you get FF instead of BB.

You can change the values in simulated EEPROM by using the EEPROM window. In
MPLAB, look under the View menu and you will see EEPROM. This will open a
window showing you what is in the EEPROM. This will initially be all FF. If you
run your code to read_eeprom, you will see that address 20 in the File Register
window will change to BB, but address 20 in the EEPROM window will not change.
Click on address 20 in the EEPROM window and you can manually change the value.
You will then find that your EEPROM read code will work.





Re: Problems reading data EEprom on Pic 16F88 - Sergio Masci - 10:10 14-11-04

Gary Kato <g...@aol.com> wrote in message
news:2...@mb-m10.aol.com...
> I think you are confusing EEPROM with the File Registers. Their adresses
> overlap each other. When you do this:
>
>   movlw   h'BB'
>   movwf  count1
>
> You are moving BB into the File Register at location 20. This is not
altering
> EEPROM which can only be addressed using the EEADR register.
>
> When you read from EEPROM location 20, this is a different place than File
> Register location 20. This is why you get FF instead of BB.
>
> You can change the values in simulated EEPROM by using the EEPROM window.
In
> MPLAB, look under the View menu and you will see EEPROM. This will open a
> window showing you what is in the EEPROM. This will initially be all FF.
If you
> run your code to read_eeprom, you will see that address 20 in the File
Register
> window will change to BB, but address 20 in the EEPROM window will not
change.
> Click on address 20 in the EEPROM window and you can manually change the
value.
> You will then find that your EEPROM read code will work.

I think Gary has nailed this.

Think about it this way: you have 368 bytes of RAM on the 16f88, you also
have 256 bytes of data EEPROM which are seperate to your RAM. If you write
to address $20 in RAM it goes to RAM and not to EEPROM, if you write to
address $20 in EEPROM it goes to EEPROM and not to RAM. Address $20 is a
different location for both devices.

Regards
Sergio Masci



Re: Problems reading data EEprom on Pic 16F88 - Simon - 13:44 14-11-04

You're absolutely correct - I was confused between EEPROM and general
purpose registers.  I thought they were one and the same thing.

So thank you for your help.  I have now got the EEPROM read and write
working 100%.
I have also now realised that the task I originally set out to do is
much simpler than I thought - I should have read up on "Indirect
Addressing, INDF and FSR Registers" in the first place.

Still it's all useful stuff to be learning.
Best wishes,
Simon.

p.s. Incidentally I was also puzzled by the __config directive of the
16F88 - apparently it has 2 config words unlike most of the PIC16X
series that only have one. When I first started using the 16F88, my
single line __config directive gave an error (Argument out of range
(not a valid config register address)).  So I had a look at the
p16f88.inc file in the MPCHIP_Tools folder and looked at the MPLAB
help file.  So now I use the format:
__config	_config1, _hs_osc......
__config	_config2, _IESO_ON & .......
Although the MPASM help file only explicitly says that is necessary on
the PIC18C devices.
Anyway, it works for me that way!

g...@aol.com (Gary Kato) wrote in message news:<2...@mb-m10.aol.com>...
> I think you are confusing EEPROM with the File Registers. Their adresses
> overlap each other. When you do this:
> 
>   movlw   h'BB'
>   movwf  count1
> 
> You are moving BB into the File Register at location 20. This is not altering
> EEPROM which can only be addressed using the EEADR register.
> 
> When you read from EEPROM location 20, this is a different place than File
> Register location 20. This is why you get FF instead of BB.
> 
> You can change the values in simulated EEPROM by using the EEPROM window. In
> MPLAB, look under the View menu and you will see EEPROM. This will open a
> window showing you what is in the EEPROM. This will initially be all FF. If you
> run your code to read_eeprom, you will see that address 20 in the File Register
> window will change to BB, but address 20 in the EEPROM window will not change.
> Click on address 20 in the EEPROM window and you can manually change the value.
> You will then find that your EEPROM read code will work.

Re: Problems reading data EEprom on Pic 16F88 - Lady Chatterly - 00:05 15-11-04

In article <6...@posting.google.com> s...@hotmail.com (Simon) wrote:
>
>Hi Gary,
>
>Thanks for your reply.  Sorry if I wasn't clear but when I said my
>program that wrote to EEPROM was was unsuccessful, I meant an earlier
>program that uses the procedure outlined in the 16F88 datasheet - uses
>EEADR EEDATA and EECON registers.

Are you often sorry?

>The code that I posted in my original message simply writes the value
>BB with MOVLW, MOVWF instructions and there is no problem with this.
>In the simulator, you see 'BB' appear as the value in count1.

Can you provide examples?

>The reason had I replaced Microchip's MOVF 	ADDR,W line with my own
>using movlw was because I had allocated ADDR a location in bank0
>(using the cblock directive).  However I have now tweaked the code -
>ADDR is located at 110 which is the same bank as EEADR so I can leave
>Microchip's code completely unaltered.

What makes you so positive?

>You're right, I was trying voodoo to make my program work - I had
>tried everything logical I could think of but without success.  Hence
>why I am posting here.

Why does it make you curious to be posting here?

>And yes as far as I know I am using CBLOCK correctly. (From the MPASM
>manual:
>>   Use this directive in place of or in addition to the equ directive. When creating non-relocatable (absolute)
code, cblock is often used to define variable address location names. Do not use cblock or equ to define variable
location names for relocatable code. )

Do you ask if you know they are using cblock correctly?

>Have I understood this correctly?  In the watch window, the count1
>register shows its address as 0020, as expected.

As a result of the many conflicts, no, there were no official Olympics
after 2004. However, it appears they may be revived in 2040.

>If anyone else thinks the code looks OK, I'd be very grateful if you
>could try assembling it and stepping through the simulator - see if
>you get the same issue that I have.

The civil war in the United States will start in 2004. I would
describe it as having a Waco type event every month that steadily
gets worse. The conflict will consume everyone in the US by 2012 and
end in 2015 with a very short WWIII.

>Thank you.

Bill clinton.

>So here is the second version of the code, with the unedited version
>of Microchip's code to read the EEPROM ...

There is one example of a theory involving "time shells" progressing
in size and intensity around a gravitational point from all matter.
The more massive the object, the larger and more influential the time
shells around it (like an onion). Another offshoot of this theory is
that kinetic energy is actually the conversion of stored energy in
the atom as it passes through time shells in a gravitational field.
John Titor spoke of this when he last visited.

>LIST 	N=90,ST=OFF,p=16F88
>	INCLUDE	P16f88.INC	;Register definitions
>	errorlevel 0,-302
>	__config	_config1, _hs_osc & _wdt_off & _pwrte_on & _cp_off  &
>_boden_off & _CCP1_RB0 & _WRT_PROTECT_OFF & _CPD_OFF & _LVP_OFF
>	__config	_config2, _IESO_ON & _FCMEN_ON

Cynics regard everybody as equally corrupt. Idealists regard everybody
as equally corrupt, except themselves.

>cblock	h'20'	;
>count1
>count2
>	endc

Will you stand by your friends always?

>cblock	h'110'	        ; I have put this register at 110
>ADDR				; so that it is in the same bank as
>	endc			; the EEADR SFR.
>				; So that I can leave the Microchip code exactly
>				; unchanged

Love makes the time pass. Time makes love pass.

>GOTO	INITIALISE
>	NOP
>	NOP
>	NOP

Advice should be viewed from behind.

>INITIALISE

Why are you apologizing?

>banksel	eedata		; Clearing these registers first to make it
>                                ; easier to spot changes in Watch
>Window
>	clrf	eedata
>	clrf	eeadr
>	clrf	addr
>	banksel	count1
>	clrf	count1
>	clrf	count2

While you sit by and watch your Constitution being torn away from you,
you willfully eat poisoned food, buy manufactured products no one
needs and turn an uncaring eye away from millions of people suffering
and dying all around you. Is this the "Universal Law" you subscribe
to?

>movlw	h'BB'		; Put value 'BB' in count1
>	movwf	count1		; this appears successfully in watch window
>	movlw	count1		; Move the location of count1 to W
>	banksel	addr		; (appears in watch as h'20' as expected)
>	movwf	addr		; and put that value in the ADDR register
>
>read_eeprom			; This section of code taken from 16F88 datasheet

The most overlooked advantage to owning a computer is that if they
foul up there's no law against whacking them around a little.

>BANKSEL EEADR 		; Select Bank of EEADR
>	MOVF 	ADDR,W 		;
>	MOVWF 	EEADR 		; Data Memory Address to read
>				; In watch window, EEADR succesfully contains
>				; h'20' at this point

Suddenly, Kerry becomes this God like hero.

>BANKSEL EECON1 		; Select Bank of EECON1
>	BCF 	EECON1,EEPGD 	; Point to Data memory
>	BSF 	EECON1,RD 	; EE Read
>	BANKSEL EEDATA 		; Select Bank of EEDATA
>				; In watch window, at this point, the value
>				; of EEDATA changes to h'FF'

Our computers are connected through an electrical bus. Three computers
linked together use the same signals from the gravity sensors and
clocks, using a Borda error correcting protocol for checking
integrity of the data and tripping the VGL system.

>MOVF 	EEDATA,W	; W = EEDATA

Are you positive that is why?

>; check to see if data read successful
>	banksel	count2
>	movwf	count2		; move the data value to count2

Can you tell me if it rained in New York on June 4th 1932? You are
from their future so should you know that?

>goto	$
>	end

Heck, we haven't even touched on "Z" field compression yet.

--
Lady Chatterly

"Second Admission that Lady Chatterly kicked your ass noted, Kenny
Kakes." -- Daedalus