Modern eeprom programming

[GK]

I'm updating/modernizing and project from over a decade ago. Part of the process involves re-writing ROM data that was originally stored on UV-erasable EPROMs. I used to generate my EPROM data by typing it out in notepad like this (a few lines from a custom/extended 256 character ASCII set):

Code: [Select]

   
        .byte 0
.byte 96
        .byte 100
        .byte 8
        .byte 16
        .byte 32
        .byte 76
        .byte 12

I would then use an (already ancient back then) DOS based assembler called TASM to convert the text file to an object file. Using the *.obj the EPROM was then programed with an old "universal programmer" which I no longer have.

As the old UV EPROMS are now old hat and no longer available, I'm left to redesign the system with serial EEPROMs instead and having the data shifted into fast working SRAMs at boot-up.

However since the original design, I haven't done anything with standalone EEPROM memory at all. What are the currently preferred devices for serial 8-bit EEPROMs (2 to 16 kbyte) and what is the cheapest and quickest way to get them programmed? So far there doesn't appear to be exactly a plethora of devices to choose from (or just less than what I was expecting) and I see a lot of devises taged discontinued or obsolete. Is my old text file + assembler still the modern way to go about it?

[Kjelt]

What are the currently preferred devices for serial 8-bit EEPROMs (2 to 16 kbyte)

Choice is between I2C or SPI as protocol. You can search Farnell for instance with "eeprom" and select in the filter max. 128kBits and get 118 hits, mostly Atmel, Microchip 24AAxx, 24LCxx , ST has some devices but Microchip is dominant.

what is the cheapest and quickest way to get them programmed?

Buy on ebay the TL866 eprom programmer (<$50) with the fitting zero insertion sockets. Read out the code from your old eprom with it , select the new device and program it. Could be a matter of 2 minutes without retyping the data. But the layout of the redesign would be more work, shifting from parallel eprom to serial eeprom.

[KerryW]

Many EPROMs are available from Electronic Goldmine, 27C16, C32, C64, C128 and C256, for example.

[GK]

OK, thanks for the replies. Unfortunately I also need to extensively modify the existing ROM data, so I can't get around some tedious data entry.

However I'm now wondering if I need standalone EEPROM ICs at all. I've now got a full CCS compiler suite for Microchip parts, with support for the full range of uC's. I haven't delved into much yet at all but it's a big step up from what I used to use. I'm used to my old preferred PIC uC line up that had tiny program memories of 2k, 4k or 8k.

However the modern uC that I'm now selecting for my preferred device line up have much larger program memories - 32k, 64k, 128k.... So surely I could just plonk all of my ROM data onto the boards main processor now?

Would anyone have any C programming tips on what would be the most efficient way of integrating several kilobytes of ROM data into a program listing for 16 bit PIC MCU's? Would I just dimension some large arrays?

[GK]

Oh, crap. Does anyone know how to look up a hard disc ID in Windows 7?
I don't have enough remaining data quota this month to download Quartus and my "MaxPlus Baseline" licence has long since expired.

Incidentally, the project in question is a video games machine, running my own version of Space Invaders.
 

[amyk]

What type of EPROM are you replacing? There are pin-compatible EEPROMs for some of them, e.g. 28Cxx series for the 27Cxx.

[GK]

What type of EPROM are you replacing? There are pin-compatible EEPROMs for some of them, e.g. 28Cxx series for the 27Cxx.

45nS access time 27C. It is the working character ROM in a video generator, addressed by the video RAM. The 28C parallel EEPROMs though seem to be too slow (120, 150nS access times). I'd like to replace the video ROM with a fast SRAM, loading the SRAM with the character set at boot up.
 

[amyk]

What type of EPROM are you replacing? There are pin-compatible EEPROMs for some of them, e.g. 28Cxx series for the 27Cxx.

45nS access time 27C. It is the working character ROM in a video generator. The 28C parallel EEPROMs though seem to be too slow (120, 150nS access times). I'd like to replace the video ROM with a fast SRAM, loading the SRAM with the character set at boot up.

Are you sure that's not 450ns (usually indicated with a -45 suffix)?

[GK]

Yes, quite sure. The video generator is 100% my own design, CPLD based (except for the external uC-accessed screen map RAM and character ROM). The ROM/RAM is addressed by the CPLD at the video clock rate and the data has to be ready when the next RGB pixel set is shifted out. 450nS wouldn't keep up by a long shot!

[codeboy2k]

Would anyone have any C programming tips on what would be the most efficient way of integrating several kilobytes of ROM data into a program listing for either 16 bit PIC MCU's? Would I just dimension some large arrays?

yep. 

static char theprom[ ] = { 0x01, 0x44, 0x33 };

You can write a program (perl, python, ruby, lua, etc) to create a single C file that reads your EEPROM data and creates the C code to initialize this array

You can use ints or long long words, but then it gets hairy with byte ordering, word sizes, etc.. you can do it if you really want to, but I wouldn't .. just use chars.

[amyk]

Yes, quite sure. The video generator is 100% my own design, CPLD based (except for the external uC-accessed screen map RAM and character ROM). The ROM/RAM is addressed by the CPLD at the video clock rate and the data has to be ready when the next RGB pixel set is shifted out. 450nS wouldn't keep up by a long shot!

A quick search shows that there are EEPROMs at that speed: http://www.winbond.com/NR/rdonlyres/90150BC6-A635-403C-9373-AF32651918A4/0/W27C512.pdf

[GK]

Yes, quite sure. The video generator is 100% my own design, CPLD based (except for the external uC-accessed screen map RAM and character ROM). The ROM/RAM is addressed by the CPLD at the video clock rate and the data has to be ready when the next RGB pixel set is shifted out. 450nS wouldn't keep up by a long shot!

A quick search shows that there are EEPROMs at that speed: http://www.winbond.com/NR/rdonlyres/90150BC6-A635-403C-9373-AF32651918A4/0/W27C512.pdf

Hmmm..... The usual suppliers only list the slower grades. However I still want to replace the ROM with a fast SRAM in any case, as in the current design the timing is already cutting it very fine. The D-flip flops (in the CPLD) that shift the RGB pixel status are clocked 62.5nS after the (15nS access time) screen location map RAM is addressed. Data has to then ripple through the 45nS ROM = 60nS total. Not much headroom! Ten+ years ago these were the fastest parts I could make it with!

[Kjelt]

yep. 
static char theprom[ ] = { 0x01, 0x44, 0x33 }; 

I would make it a const otherwise the array might be put in ram  .
Static only states about the file scope, that the object is not accessible by all parts of the program.

Also you want to look at the memory model and compiler manual for your target uC,  some uC's/compilers need an extra declaration such as @far of @near.

[GK]

yep. 
static char theprom[ ] = { 0x01, 0x44, 0x33 }; 

I would make it a const otherwise the array might be put in ram  .
Static only states about the file scope, that the object is not accessible by all parts of the program.

The const bit makes sense but I'm not entirely sure what you mean by the second sentence.

Also you want to look at the memory model and compiler manual for your target uC,  some uC's/compilers need an extra declaration such as @far of @near.

I haven't tried compiling anything for a 16 bit uC yet, but there are quirks with arrays. You an have a project with an array of so many bytes that compiled with plenty of ROM and RAM left, but add a few more bytes to the array and the compilation bombs out due to "lack of ROM/RAM". I've found in the past that I could not add another byte to an array due to memory limitation, but I could then define another separate array in addition, just as large as the first, without issue. To get a program to fit I have in the past resorted to using multiple smaller arrays as a workaround to not being able to fit a single large one.

[madshaman]

Note about where stuff in your program gets stored:

It's a combination of the c-runtime startup code, the linker script (or equivalent if you're not using gnu tools) and which section your symbols get assigned to.

Most c-startup code (the thing that eventually calls main (or your choice of entry point if you override this default) will copy the data from where the program's image is stored (ROM/flash) into RAM if it isn't marked as const.

You might actually *want* this behaviour because it may take more cycles for the processor to read from ROM than RAM.

In this case you should still use const to inform the compiler (and potentially a complex loader via the object code) that you do not intend to modify the data, use compiler pragmas to assign the symbol to a custom (or convenient canonical) section and potentially a custom linker script to describe to the startup code and/or loader how the stuff in your custom section is to be relocated/mapped.

You can get super fancy when your system has various memory areas (some internal, some external) that run at different speeds; you may, for example, want to have certain functions run from the fastest memory possible or want certain LUTs in the fastest memory possible.

The situation is more convoluted because a good toolchain (like gnu) will let you use any startup code you want so you can pretty much do anything you want with whatever's in your image.

This appnote from Atmel illustrates what I'm rattling on about better than I can in a few sentences: http://www.atmel.ca/Images/doc32158.pdf

It may also help to read your toolchain's documentation in detail.

Cheers.

[Kjelt]

The const bit makes sense but I'm not entirely sure what you mean by the second sentence.

Just standard ansi C, if you use the static keyword you declare the variable/array behind it (it's scope) as just to be used in that file.
So this is no concern if you have a very small program which has only one main.c file but when you have multiple *.c files (components/modules) then you can not access that static variable/array from another file.

To get a program to fit I have in the past resorted to using multiple smaller arrays as a workaround to not being able to fit a single large one.

Was this with uC's that use bankswitching, so don't have one large memorymodel but multiple small ones?

[madshaman]

I highly recommend a thorough reading of this:

http://sourceware.org/binutils/docs-2.23.1/ld/index.html

And this:

http://elinux.org/Executable_and_Linkable_Format_(ELF)#ELF_file_layout

One *really* needs to understand how a C-program becomes a running program on real hardware, particularly on system which isn't simple like a modern PC (vanilla Von Neumann architecture, flat virtual address space supported by a full-fledged OS) from a perspective that doesn't involve magical IDEs with billions of bells and whistles.

It's a bit intimidating, but that's simply lack of familiarity, it's not hard to understand and (imho) can really help one understand what's actually going on when one builds a program for something like an embedded system or a complicated game console.

[GK]

To get a program to fit I have in the past resorted to using multiple smaller arrays as a workaround to not being able to fit a single large one.

Was this with uC's that use bankswitching, so don't have one large memorymodel but multiple small ones?

PIC16F. Don't know about "bankswitching". All I can find in the compiler reference manual on these topics is the following:

Out of ROM, A segment or the program is too large
A function and all of the INLINE functions it calls must fit into one segment (a hardware code page). For example, on the PIC16 chip a code page is 512 instructions. If a program has only one function and that function is 600 instructions long, you will get this error even though the chip has plenty of ROM left. The function needs to be split into at least two smaller functions. Even after this is done, this error may occur since the new function may be only called once and the linker might automatically INLINE it. This is easily determined by reviewing the call tree. If this error is caused by too many functions being automatically INLINED by the linker, simply add a #SEPARATE before a function to force the function to be SEPARATE. Separate functions can be allocated on any page that has room. The best way to understand the cause of this error is to review the call tree.


How can a constant data table be placed in ROM?The compiler has support for placing any data structure into the device ROM as a constant read-only element. Since the ROM and RAM data paths are separate in the PIC® , there are restrictions on how the data is accessed. For example, to place a 10 element BYTE array in ROM use:
BYTE CONST TABLE [10]= {9,8,7,6,5,4,3,2,1,0};
and to access the table use:
x = TABLE ;
OR
x = TABLE [5];
BUT NOT
ptr = &TABLE ;
In this case, a pointer to the table cannot be constructed.
Similar constructs using CONST may be used with any data type including structures, longs and floats.
Note that in the implementation of the above table, a function