writing 256 bytes to eeprom

[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?