writing 256 bytes to eeprom

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