writing 256 bytes to eeprom

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

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

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