writing 256 bytes to eeprom

[astouffer]

Say I want to write this 256 bytes of data to the eeprom of a 16F876A.

$3C,$F0,$C0,$03,$04,$08,$3F,$FC
$42,$08,$21,$04,$0C,$8C,$20,$82
$81,$04,$12,$08,$14,$4A,$20,$81
$81,$04,$02,$C8,$24,$49,$20,$81
$81,$04,$02,$C8,$C4,$48,$20,$81
$81,$04,$02,$08,$04,$88,$20,$82
$81,$04,$02,$08,$04,$08,$3F,$FC
$81,$04,$C2,$0B,$04,$08,$20,$C0
$81,$04,$22,$0C,$04,$08,$20,$A0
$81,$04,$12,$08,$04,$08,$20,$90
$81,$04,$12,$C8,$04,$08,$20,$88
$81,$04,$12,$C8,$04,$08,$20,$84
$81,$04,$12,$08,$04,$08,$20,$82
$42,$08,$21,$04,$04,$08,$20,$81
$3C,$F0,$C0,$03,$04,$00,$20,$81
$00,$00,$00,$00,$00,$00,$00,$00
$00,$00,$00,$00,$00,$00,$00,$00
$7F,$F8,$03,$0F,$80,$0F,$3F,$3E
$80,$04,$80,$10,$40,$88,$20,$41
$80,$04,$40,$20,$20,$48,$20,$80
$80,$04,$40,$20,$13,$48,$20,$80
$80,$04,$40,$20,$13,$48,$20,$80
$80,$08,$40,$20,$10,$88,$20,$80
$40,$10,$40,$20,$10,$08,$3F,$40
$3C,$20,$40,$20,$10,$08,$20,$3C
$02,$40,$40,$20,$10,$08,$20,$02
$01,$80,$40,$20,$10,$08,$20,$01
$01,$00,$41,$20,$13,$08,$20,$01
$01,$00,$42,$20,$13,$08,$20,$01
$81,$00,$42,$20,$20,$08,$20,$01
$42,$00,$9A,$10,$40,$08,$20,$82
$3C,$00,$1A,$0F,$80,$0F,$20,$7C

How would this block sit in the code space? Surely not 32 variables defined and then these 32 lines. If it needs 32 lines then its as simple as incrementing the write command with a for loop. The manual says each eeprom write is 10ms long. Does that mean writing all 256 bytes takes 320ms?

[Darrel Taylor]

Not exactly sure what you're doing.

But it might be easier to use EEPROM or DATA statements, and let the programmer write the data.
<br>

[astouffer]

The data is for that non addressable lcd I'm playing around with. Changing even one pixel requires all 256 bytes be written over again. Originally my plan was to have a default array loaded in ram and then write different parts to make changes and then send out the whole thing again.

Doing some thinking now it makes more sense to have the template and digits all in codespace and selectively read out the right chunks. The display doesn't care what speed data is received, as long as it gets all 256 bytes.

[Darrel Taylor]

Oh, for the NKK display. I should have realized.

Are you trying to display dynamic data like changing numbers, or just static labels for the button?
<br>

[Jerson]

If each of these 256 bytes is a fixed character, Icon, etc, you can just create a font table and place it in Code space as arrays of bytes and pull them out using the Lookup command. Much more easier than using EEPROM or DATA. There is an article of strings in code space out here. That might be a good starting point for you.

[astouffer]

Darrel: Yes the data is changing numbers. Four digits would need updated. Its mostly for an initial setup of a piece of equipment. A user adjusts the speed to the correct level and then starts using it.

Jerson: That answers one other question. A digit on the display is an array in code space. So the static part of the display is a large array and then each digit is a smaller array. Then lookup is used with shiftout to send the the right parts? I saw some postings about font tables but wasn't sure if they were right for this application.

[Jerson]

That answers one other question. A digit on the display is an array in code space. So the static part of the display is a large array and then each digit is a smaller array. Then lookup is used with shiftout to send the the right parts? I saw some postings about font tables but wasn't sure if they were right for this application
Actually, all graphics are nothing but arrays of bytes. So, yes, it is right for your application. I would say, draw the background, draw the numbers and you have a valid display to look at.

[Darrel Taylor]

It sounds easy till you actually try it.

And with this NKK display, if you want to change anything, you have to redraw everything.
Change one number and it has to remember everything else that was on the screen too.

Using a 16F876A doesn't help much, with a maximum array size of 96 bytes, you can't just hold the entire display in a nice neat buffer to modify and resend when needed.

I'm playing with the 4x10 mode now. Much less RAM used.
But still haven't got my rows and columns figured out yet.
<br>

[astouffer]

I'm playing with the 4x10 mode now. Much less RAM used.
But still haven't got my rows and columns figured out yet.

At work we made an excel sheet with color coded columns and formulas to give the hex numbers when blocks are filled in. On Monday I'll post it here for others who want to do similar things.

If you do 32 shiftout lines it makes the hex file over 10kb in size. Yesterday I had success in writing the contents to the eeprom and then reading the whole thing in a 256 count for loop. That hex file was something like 1.5kb.

A 16F876A is not a requirement. I chose it for the two pwm channels and this display idea came up later. Skimask's post about using the nokia lcd gave me insight on how to write to the eeprom. He used the 18F series for its bigger eeprom and faster speed. I found the PIC18F4620 which matches his specs and also has multiple pwm channels. Do you think thats better suited?

[Darrel Taylor]

Feel free to continue what you're doing.
But I think you'll be deleting it all very soon.

EEPROM is not the way to go.

The 876A will do.
It's limitations made the GLCD idea extremely hard to do is all I was pointing out.
Done as a character display, instead of a graphic display, the 876A has plenty of room and speed.
<br>

[skimask]

I had started to re-do some of my GLCD code to support these things last night...then I got to wondering what they cost.
$40USD at Digikey! No thanks!
But obviously, I agree, EEPROM, not good.
If you've already got half of a circuit built for the 16F876A, just switch over to an 18F2620 (or 2685 for even more code space). Practically the same pinout and aside from a few register changes (and config changes :) ), it'll almost drop right in.
In my latest project, if I wasn't using so much of the onchip ram for other things, I'd keep the font table in a large array and use it from there. As it is, I only keep the alpha & number character 'font' in an array and keep the rest in the eeprom.
The '4620 has ~3900-ish bytes of ram. You should be able to double-buffer one screen in the ram easily, modify it there, then shift the whole thing out in one shot, if that's the way you want to go.
Could use an external FRAM for buffering the data though...

[Archangel]

...then I got to wondering what they cost.
$40USD at Digikey! No thanks!
...
How can you put a price on <b>COOL</b> ? Especially for a one off Car project . . . Just imagine your GEO with all those cool . . . :D

[skimask]

How can you put a price on <b>COOL</b> ? Especially for a one off Car project . . . Just imagine your GEO with all those cool . . . :D
Right again...(not a GEO, just an old Chevy Sprint)

Cool Points > USD

[astouffer]

Yeah the $40 price probably keeps most hobbyists away from those displays. They really are about the size of a key on your keyboard.

This project is at the prototype stage now so changing pics is no problem. I'll order a few 18F2620 and start looking at the datasheet.


The '4620 has ~3900-ish bytes of ram. You should be able to double-buffer one screen in the ram easily, modify it there, then shift the whole thing out in one shot, if that's the way you want to go.

What command would write the screen into ram, writecode? The digits to be displayed are arrays of bytes? When an update is needed, the corresponding array of byte(s) is written to the specified ram location? I have an understanding of what needs done, now just putting it into code :o

[skimask]

Yeah the $40 price probably keeps most hobbyists away from those displays.
$40 doesn't keep this hobbyist away from anything...just don't have a use for them at the moment...Wait a minute! Since when did I have to have a use for something to buy something!!! :D


What command would write the screen into ram, writecode?
First thing you have to do is quit thinking about the on chip ram as some sort of special place to put data. Every variable you make is stored in on chip ram, every array, every byte, every x var byte : x = 10 x is ram, ram is x.
If you have an 18F2620 and you:
temp var byte[1023]
You have just allocated 1024 bytes of on chip to be declared as an array by the name of temp to be accessed with a statement such as temp[586] = 56.

[astouffer]

First thing you have to do is quit thinking about the on chip ram as some sort of special place to put data. Every variable you make is stored in on chip ram, every array, every byte, every x var byte : x = 10 x is ram, ram is x.
If you have an 18F2620 and you:
temp var byte[1023]
You have just allocated 1024 bytes of on chip to be declared as an array by the name of temp to be accessed with a statement such as temp[586] = 56.

Ah things are becoming less foggy now. As you might have guessed I'm new to programming in general. Thanks for being patient :D