AVRFreaks.net

I do not have an AVR board.

The AT28C64B is accessed like a Static RAM for the read or write cycle without the
need for external components

But at the same time, just quoting one sentence out as a reason for not helping out is not reasonable.

the BP-1200 seems to be an ordinairy programmer.
It will probably just write to the EEPROM as if you would try to access external RAM.

all you need to do is define a start adress and then determine what offset commes first and what offste commes second.
so the fetch location adress will become: start+Offset1+offset2

Data, even a "table" is "just bytes". Can't you construct a binary image of your table and write it to the EEPROM?

Jim

Now we're starting to get the whole picture! Your BP1200 programmer should be able to program your device, but the issue is how to structure your data and get this into the programmer in order to store it into the flash chip. If the size of your two dimensions are a power of 2, then this makes things a bit easier for you as the address lines can be used easily to lookup the value you want. Eg: if X is 0..15 (2 ^4) and Y is 0..63(2^6) then address pins A0..3 are your X value, address pins A4..9 are your Y value. The other address pins would be tied to 0V. In order to create the data, I would use an assembler and type in your data tables. The assembler would take your data and create a .hex file which can be loaded into the programmer then into your flash chip. I assume the programmer can be connected to your PC?

Can i ask what generates the inputs? How fast are these generated and how fast do you need the solution. Realise that the output data will glitch when the inputs change unless you add extra logic to synchronise the output. At a guess it seems like you really need a microcontroller.

If all you have is a collection of single-bit inputs to the EEPROM, then the best you can do is a one dimensional table. You could allocate some inputs to be "row" and some as "column" but that would be an illusion. It would still be 1D.

What do you expect to get from this 2D organization that is not obtained from a 1D linear organization?

Jim

That still does not say why a multidimensional table is needed.

So, you have multiple ADCs? And you want a "dimension" for each ADC? Just flatten the table into a single linear address space. You can verify this in MATLAB very easily. The only question is how you figure where in the address space each data value goes.

And, of course, you will be dealing with 8-bit integer data, right? Your output bus is only 8 bits wide.

Jim

I am assuming, from previous comments, that each ADC represents a "dimension" in the OP's thinking. For any integer dimension index, there is only 1 "value". Hence, each dimension can represent a field out of the larger width address space, resulting in a linear address map with a 1;1 correspondence between a 13 bit address and an 8 bit value.

The mapping can be done, very easily in matlab, where all this originates. If we assume that each ADC output has been masked and shifted so that the top 4 or 5 bits form a a right-shifted integer (by that, I mean, from the set {0.1.2,...,15} or {0,1,2,...,31}. For a 5:4:4 set of input fields, the linear address is (in matlab) is simply A = ADC2*256 + ADC1*16 + ADC0. No Perl needed.
Hope this is more clear than it seems.

Jim

In what format is the lookup table now?

Do an integer division of the ADC value (by a power of 2). If you divide 0x123 by 16 = 0x10 in an integer division, you get 0x12 which has the effect of right shifting and masking in a single operation.

Then, simply sum the different values, each multiplied by a power of 2. These multiplications have the effect of left shifting while inserting 0s in the new low bit locations. For example, 0x12 * 16 gives you 0x120.

That is how you would construct a 1D table address in MatLab.

Jim

For the scheme I outlined to work, you have to assign a contiguous set of address bits to each input vector. That means that each vector will have a value range of 0 to (2**N)-1, where N is the number of bits in that vector. Thus, you would have maximum values like 7 or 15 or 31. 0-30 will easily fit into a 5 bit vector and 0-5 will fit into a 3 bit vector.

As far as your table values, an intel hex file will fill contiguous addresses. You can play some "games" and leave gaps, and so forth, but you are far better off filling with zeros (or something recognizable). Thus, if there are value combinations that you expect never to occur, pad them with dummy values. Then, your table will come out nicely.

Jim

The hex file format has an address, several other bytes, and the data for (typically) 8 bytes. The data is for the 8 memory addresses starting at the given address. The programmer converts this data into the signals needed to program the EEPROM.

So, the hex file has many lines, each line is for a block of 8 addresses, You could construct the file by hand though it would be tedious.

Jim

The address is the combined voltage/current vector, the data is the output state.

no it is the other way around.....
each address is a voltage and a current and at that address is the switch state that will be out putted when you select that address.

You DON'T program the current voltage information in the EEPROM. You must devise a mapping from current&voltage information to an address.

And at that mapped address you store/retreive the switch state.

I'm assuming 2 bits for both the ADCs. So 2x2=4 bits=2^4=16 different addresses. You connect the output of the current ADC to A0 and A1, of the voltage ADC to A2 and A3.

address=current+voltage*4

Table:

Therefore you should determine what comes from the ADC; e.g. what is its exact transfer function? An ADC does not generate output in nice engineering units.

I guess your table is now set up with engineering units with a few specific limit points. An EEPROM can't do this, you need to program it with all possible combinations of ADC values. The easiest way is to write a Matlab function that creates an output state for a given voltage and current, then with another function generate all possible combinations. After all, an ADC has a limited, finite number of states (generally between 8 to 16 bits, or 256 to 65536 states). Every extra bit doubles the table size though.

Though I think what you want is impossible. You would need something more elaborate than the EEPROM if you want the table to be sparse. Like a microcontroller

If you have this EEPROM chip programmed, where does it plug into?

But is there an ACTUAL tangible circuit you can touch and feel and admire? Or at least its design and not some preconceptualization sketch in Simulink?

Your ADC can be anywhere between 0 and MAX.
You never know what the next value of the ADC will be.
That is why it is said that you need to make a table for all possible values, so:
ADC conversion voltage 0 ... max
and
ADC conversion Current 0 ... max
this will then be a table with the size of volt_max * current_max
you cannot omit values as they might occur at any given point in time and then would give you a wrong switch state with potentially devastating results.....
Note that when you scale the voltage/current then you will loose accuracy, but will get a smaller table to build.
for instance an 8 bit converter will give 8^2*8^2 = 4096 entries
if you scale down to 4 bits resolution you only have to make 256 entries, but you loose that in accuracy.
If you have a micro controller then you could use that to do an interpolation between the points and gain back some of the lost acuracy.

You DON'T program the current voltage information in the EEPROM. You must devise a mapping from current&voltage information to an address.

First up you need to assign you adc bits to address lines. Eg:
1st adc A0..A5
2nd adc A6..A11
3rd adc A12

Obviously it helps if we work in binary or hexidecimal numbers.
Lets look at some number sequences:
ADC 2 = 0, ADC1 = 0 address is 0x0000
ADC2 = 0,ADC1 = 1 address is 0x0001
ADC2=0,ADC1 = 0x3f address is 0x003f

ADC2=1,ADC1=0 address is 0x0040
ADC2= 0x3f, ADC1=0 address is 0x0fc0
ADC2=0x3f,ADC1=0x3F address is 0x0fff

work it out using pencil and paper! What is stopping you from figuring this out yourself? Are you afraid to make a mistake? This is easy to test, so you can do some experiments and determine where you are going wrong fairly quickly. As I mentioned early on, I would use an assembler - if you don't have one then download one! There's plenty of free ones.

Another method is to use a program like XVI32 to enter the values then use a program like bin2hex to generate the hex file. Both these are free downloads.

don't forget that it might happen that one ADC converter is done while the other converter is still running(might be a single clock cycle, but can happen. you need to make sure the table can handle that OR that first both ADC's are read and when they are finished you update the EEPROM address...

Btw, I did try to download one of the assemblers online, but i ran into circles.

Forget about all that gibberish you've spreaded here before and just show us a picture of your system - just what/how many do you have inputs and outputs.

if you think it's gibberish, then you shouldn't be here helping people on the community.

I do not think it's gibberish - I do know it is.

And where should or shouldn't I be - it's not your forking business.

What mbedder is trying to tell you is that your technique is fraught with problems. If you're having trouble trying to solve the issue of the lookup table then you're really going to struggle with the other issues it will create. This was pointed out early and now we're up to four pages. Coceptually, using a memory device as a lookup table is calid. I've seen it used in old hard disk drives and a reasonably modern inverter welder.