18F87J93 _eeprom=0?
Moderators: David Barker, Jerry Messina
18F87J93 _eeprom=0?
From the datasheet:
"Flash Program Memory has Word Write Capability for Data EEPROM Emulators"
I would have assumed this meant it had support for the Swordfish EEPROM library!?! Am I wrong? Is this a bug?
"Flash Program Memory has Word Write Capability for Data EEPROM Emulators"
I would have assumed this meant it had support for the Swordfish EEPROM library!?! Am I wrong? Is this a bug?
Re: 18F87J93 _eeprom=0?
And to have a stab at answering my own question...
Looking at the 18F87J90 Family Datasheet and the EEPROM.bas code, it looks like the device will support EEPROM, but the library is not compatible with this device.
Amongst other differences, the 87J90 appears to require erasing of pages (64 bytes) before word writes.
Is this a fair call? Anyone written routines for this device? Or am I writing my own?
Looking at the 18F87J90 Family Datasheet and the EEPROM.bas code, it looks like the device will support EEPROM, but the library is not compatible with this device.
Amongst other differences, the 87J90 appears to require erasing of pages (64 bytes) before word writes.
Is this a fair call? Anyone written routines for this device? Or am I writing my own?
- David Barker
- Swordfish Developer
- Posts: 1216
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
Re: 18F87J93 _eeprom=0?
> I would have assumed this meant it had support for the Swordfish EEPROM
> library!?! Am I wrong? Is this a bug?
Yes, you are wrong. EEPROM <> HEF - so it would be unfair to expect the EEPROM library to perform a function it was not designed to do. It is certainly not a bug. High Endurance Flash (HEF) sits at the top of normal program flash - I expect it's microchips way of keeping die costs down by replacing dedicated EEPROM. An absolute must read is this document
http://ww1.microchip.com/downloads/en/A ... 01673A.pdf
It even has some "C" code which you could port over. As with program FLASH, the normal sequence to write a word to memory is
(1) read single row into RAM
(2) write new word into RAM row at position <address>
(3) Erase device row
(4) write RAM row to device row
it's pretty straight forward, just requires more work than EEPROM. If you are uncomfortable with the concept, there are plenty of 18F devices with authentic EEPROM - use one of them instead for your design - or use an external EEPROM chip.
> library!?! Am I wrong? Is this a bug?
Yes, you are wrong. EEPROM <> HEF - so it would be unfair to expect the EEPROM library to perform a function it was not designed to do. It is certainly not a bug. High Endurance Flash (HEF) sits at the top of normal program flash - I expect it's microchips way of keeping die costs down by replacing dedicated EEPROM. An absolute must read is this document
http://ww1.microchip.com/downloads/en/A ... 01673A.pdf
It even has some "C" code which you could port over. As with program FLASH, the normal sequence to write a word to memory is
(1) read single row into RAM
(2) write new word into RAM row at position <address>
(3) Erase device row
(4) write RAM row to device row
it's pretty straight forward, just requires more work than EEPROM. If you are uncomfortable with the concept, there are plenty of 18F devices with authentic EEPROM - use one of them instead for your design - or use an external EEPROM chip.
-
- Swordfish Developer
- Posts: 1486
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: 18F87J93 _eeprom=0?
There's also AN1095 Emulating Data EEPROM for PIC18 and PIC24 MCUs and dsPIC DSCs and the DEE emulation library (in C)
see http://www.microchip.com/wwwAppNotes/Ap ... e=en530593
"Word Write Capability for Flash Program Memory for Data EEPROM Emulators" is a bit of marketing hype. While it's a true statement, pretty much ALL of the 18F chips have this capability.
While you can write 64 bytes at a time, you have to erase a rather large block. That means you would have to have an additional spare 1K page that you could copy the data to while you do the erase/edit or have a large 1K ram buffer.
see http://www.microchip.com/wwwAppNotes/Ap ... e=en530593
"Word Write Capability for Flash Program Memory for Data EEPROM Emulators" is a bit of marketing hype. While it's a true statement, pretty much ALL of the 18F chips have this capability.
Having dealt with bootloaders for the J series, the J90 family actually makes it harder to deal with than many other devices since it has an erase block size of 1K bytes.Amongst other differences, the 87J90 appears to require erasing of pages (64 bytes) before word writes.
While you can write 64 bytes at a time, you have to erase a rather large block. That means you would have to have an additional spare 1K page that you could copy the data to while you do the erase/edit or have a large 1K ram buffer.
- David Barker
- Swordfish Developer
- Posts: 1216
- Joined: Tue Oct 03, 2006 7:01 pm
- Location: Saltburn by the Sea, UK
- Contact:
Re: 18F87J93 _eeprom=0?
> is a bit of marketing hype.
Absolutely!
> That means you would have to have an additional spare 1K page that you
> could copy the data to while you do the erase/edit or have a large 1K ram buffer.
In that case, declare the read array inside your write function as local (not at the module level). This will ensure the RAM gets recycled.
Absolutely!
> That means you would have to have an additional spare 1K page that you
> could copy the data to while you do the erase/edit or have a large 1K ram buffer.
In that case, declare the read array inside your write function as local (not at the module level). This will ensure the RAM gets recycled.
Re: 18F87J93 _eeprom=0?
Not uncomfortable with the concept at all, just disappointed that the J90 is not compatible with the Swordfish EEPROM module. I got excited last week when I saw that the J90 supported EEPROM and that Swordfish had an EEPROM module... I thought it was going to be a doddle.David Barker wrote:it's pretty straight forward, just requires more work than EEPROM. If you are uncomfortable with the concept, there are plenty of 18F devices with authentic EEPROM - use one of them instead for your design - or use an external EEPROM chip.
I've inherited an existing (unfinished) design that is actually in production! So no luxury of changing the device for me! The original developer decided that touch screen calibration was either unnecessary or (more likely) too difficult. No surprise then that the end users have complained that the screen input 'doesn't work'. FTR I discovered - only today - that the code was ripped (uncredited) from the Wiki touch screen article/example, minus the calibration code.
We've modified (patched) the circuit for the resistive touch from 4-wire to 2-wire (reducing the ADC channels required to 2) and I've moved the ADC sampling into an ISR using CCP2/Timer1. It's not the first touch screen driver I've done, so I'll be implementing the same 3-point calibration algorithm I've used before. Of course I need somewhere to store the calibration values, hence the EEPROM. Not a great drama as I've got oodles of free programming flash and I'll only be writing a single chunk at any time, and rarely at that, so I can get away with a rather brain-dead implementation. On this subject - is there any doco/map file I can see to decide where my EEPROM should reside, or am I reduced to looking at the .hex file? eg. Is end-of-flash safe?
-
- Swordfish Developer
- Posts: 1486
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: 18F87J93 _eeprom=0?
It's a drag that the J90 doesn't HAVE eeprom. None of the J series do. Microchip makes it sound like it's no big deal, but using flash for EEPROM isn't the same ballgame.just disappointed that the J90 is not compatible with the Swordfish EEPROM module
The easiest thing is probably to place your "EEPROM" space at the top of memory. That way you can change the SF '_maxrom' setting so that it will always reserve that page. However, the config words for the J90 are kept in the last few bytes of the last page @ 0x1FFF8 (erase block 0x1FC00). Since you don't want to ever erase that page (or you chance bricking the device), I'd skip down to the next 1K block and reserve that one (0x1F800-0x1FBFF).
Then set
Code: Select all
#variable _maxrom = $01F800 // 126 KB of program ROM
Re: 18F87J93 _eeprom=0?
Awesome - thanks!Jerry Messina wrote:The easiest thing is probably to place your "EEPROM" space at the top of memory. That way you can change the SF '_maxrom' setting so that it will always reserve that page. However, the config words for the J90 are kept in the last few bytes of the last page @ 0x1FFF8 (erase block 0x1FC00). Since you don't want to ever erase that page (or you chance bricking the device), I'd skip down to the next 1K block and reserve that one (0x1F800-0x1FBFF).
Then setand that will keep SF from allocating code to that spaceCode: Select all
#variable _maxrom = $01F800 // 126 KB of program ROM
Re: 18F87J93 _eeprom=0?
And to provide closure on this one as well...
I've implemented my EEPROM read/write routines and it appears to work well. All based on the Microchip-supplied PIC18F EEPROM emulation code written in C, albeit much more fundamental as I expect to be writing the EEPROM only a handful of times through its lifetime.
The only gotcha for me was the note in the little shaded box at the bottom of page 95, regarding the value of TBLPTR prior to EECON1.WR being set. Left me scratching my head for an hour or so and I must admit the requirement still seems peculiar to me but, it is evidently quite important!
I've implemented my EEPROM read/write routines and it appears to work well. All based on the Microchip-supplied PIC18F EEPROM emulation code written in C, albeit much more fundamental as I expect to be writing the EEPROM only a handful of times through its lifetime.
The only gotcha for me was the note in the little shaded box at the bottom of page 95, regarding the value of TBLPTR prior to EECON1.WR being set. Left me scratching my head for an hour or so and I must admit the requirement still seems peculiar to me but, it is evidently quite important!
-
- Swordfish Developer
- Posts: 1486
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: 18F87J93 _eeprom=0?
Here's the datasheet note:... and I must admit the requirement still seems peculiar to me but, it is evidently quite important!
I think that comes from that fact (as the note says) that in order to update a 64-byte page, the TBLPTR has to be pointing to the page you want to update. Makes sense so far.Before setting the WR bit, the Table Pointer address needs to be within the intended address range of the 64 bytes in the holding register.
But, if you've used auto-increment instructions to load the page there's a good chance you'll be pointing to the NEXT page, hence the note.
Anyway, glad you've got it working!
Re: 18F87J93 _eeprom=0?
That would certainly make sense for 64 byte writes (which is what I do now), but initially I was trying to get 2-byte writes to work and had the same issue when TBLPTR was pointing to the 3rd byte in the table/page... still trying to wrap my head around what they could possibly be doing in silicon/microcode for that to matter... in fact I would have expected 3 bytes to be written instead of 2, but nothing got written!Jerry Messina wrote:Here's the datasheet note:... and I must admit the requirement still seems peculiar to me but, it is evidently quite important!I think that comes from that fact (as the note says) that in order to update a 64-byte page, the TBLPTR has to be pointing to the page you want to update. Makes sense so far.Before setting the WR bit, the Table Pointer address needs to be within the intended address range of the 64 bytes in the holding register.
But, if you've used auto-increment instructions to load the page there's a good chance you'll be pointing to the NEXT page, hence the note.
Anyway, glad you've got it working!
Anyway, all sorted now. FTR using auto pre-increment instead of post-increment.
Re: 18F87J93 _eeprom=0?
What a pity you guys had to go through all that. Moral is request help sooner!
In Dec 2014 I wrote an SF module for an automated GLCD touch screen calibrator running on 18F87J93 with stored non volatile calibration values. It was implemented by setting a DIP switch which would make the J93 go to "cal" mode. In the end the customer never used it because at the time they were in haste and wanted product out the door!
In Dec 2014 I wrote an SF module for an automated GLCD touch screen calibrator running on 18F87J93 with stored non volatile calibration values. It was implemented by setting a DIP switch which would make the J93 go to "cal" mode. In the end the customer never used it because at the time they were in haste and wanted product out the door!