5 k lookup table

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

Dear All,
for a simple solution of a complex positioning issue I am considering to use a lookup table.
It is a 2 dimensional matrix of appr. 50 x 70 word-elements ( 7-8 kbytes) to be stored in an EEPROM
My preferred idea is to implement it as one array.
I fear that it is not possible.

The ATMEGA 128 (DIP 40, what I prefer) )has 4kB of EEPROM, which is not sufficent. Perhaps I may come along with some interpolation.
Using an external EEPROM like AT24Cxx is also a possibility.
I have no experience with external memories yet.
In the samples I²c there is an example how to access this EEPROM. Then calculation of the address will be a challenge for me.

To me it is not clear how to fill the initial values into the EEPROM.

If you have some advise how to create and use a lookup table of this size please be so kind to let me know.

best regards
Christian

(BASCOM-AVR version : 2.0.8.3 )

MWS · Joined: 22 Aug 2009 Posts: 2262

The obvious solutions:
- reduce the array through interpolation to fit the supporting points into 4k
- use Flash instead of EEProm
- create a formula to approximate the array
- use external EEProm
The limited information you gave does not allow to tell what's better.

O-Family · Joined: 23 May 2010 Posts: 320 Location: Japan

What format is the data you want to store?
If it is byte or word data or a character string, it is easy to look up by using the [DATA] instruction.
In addition, if it is a binary format or a data file, it can be incorporated with the [$INC] instruction and operated with the [RESTORE] instruction and [READ] instruction.

JC · Joined: 15 Dec 2007 Posts: 586 Location: Cleveland, OH

Some good ideas suggested above.

Perhaps ordering a couple of EEPROM chips and working with them, as a sub-project, would be the “best” approach.
If you order some, be careful in the chip’s description! Many ore listed as XYZ size in BITS, not Bytes, so be careful.

An option I don’t see mentioned above would be using a form of data compression for the table. If the data elements in at least one part of the 2-dimentional array increase linearly, (e.g. 0, 1, 2, 3, 4, …, 49, 50), then the upper byte of the two byte Word data doesn’t change from one value to the next with every entry. You have a long string of entries with the same upper byte data value in a row, as the lower byte increases. You could, therefore, “compress” the data. Don’t store the upper byte with every lower byte.
The lookup algorithm would have to be a little bit smarter to understand the compressed data format, instead of the trivial, expected format.
How much compression, and byte savings you get, depends upon how the data set looks.

Storing, for example, for one of the array’s variables:
0, 0
0, 1
0, 2
0, 3
…
0, 253
0, 254
0, 255
1, 0
1, 2
1, 3

Uses a lot of space.
If you stored the first Word for a block of data as the full word, using two bytes, and then just stored the lower byte until the upper bye changed, you would save a lot of room.
The 2nd variable of the 2-Dim array would likely require the use of both Bytes for the value.
Still, you could almost obtain a 25% reduction in the storage space, if the data set makes this approach useable.

Regarding writing the original data to the EEPROM ( s ):
Will the EEPROMs be soldered to the final project’s PCB, or in a socket?
If in a socket, then one could put them in a breadboard, with a Nano, (with its USB interface), and use a PC to download the data to the Nano, (or other micro), which then loads the data into the EEPROMS.

When you write this software be sure to also write a subroutine to read back the EEPROM’s data to verify that it was all written as you intended.
One might verify the data Byte-by-Byte, after writing the full chip, or page-by-page, as it is written.

If the EEPROMs will be soldered into the final project’s PCB, then remember that the board could have TWO programs, one which downloads and stores the EEPROM data, and then once that is done a second program is downloaded to the micro to actually do what the project is suppose to do. Make sure you build in an interface for downloading the data for the first program to use!

If the data is calculatable, then obviously one could have the first program just calculate the data array and store it.

If that is the case, however, then one could likely just calculate the data as needed within the program. If the uC isn’t fast enough to calculate the data as needed, then switch to an XMega. They run at 32 MHz instead of 16 or 20 MHz, in spec, so one gets a LOT more processing power per mSec.

Good luck with your project!

JC

MWS · Joined: 22 Aug 2009 Posts: 2262

MWS · Joined: 22 Aug 2009 Posts: 2262

hgrueneis · Joined: 04 Apr 2009 Posts: 902 Location: A-4786 Brunnenthal

Ferroelectric Nonvolatile RAM are available in many memory sizes.
Most are with fast I2C (TWI) or SPI (some up to 40 MHz).
Advantage: no wait for writes and decades of data retention and close to unlimited writes.
Regular eeprom are very limited in write cycles and slow.
Flash memory needs a lot of control.

Regards
Hubert

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

I want to control the position of the slit in the dome of my small astronomical observatory. The problem is that there are 2 telescopes based on an equatorial mount. They have a appr. 40 cm offset from the central position. Both telescopes must have a free view through the slit. Distance between the optical axis is 40 cm. Which is another offset. The slit has a free opening of 60 cm. So the offsets matter.
Doing a calculation considering just one telescope is a bit complicated but not rocket science. Having to consider the offset of the second telescope makes it difficult. The optics does not look perpendicular through the slit but sometimes tilted.
So the idea is to measure the position and put the data in a lookup table.
For the horizontal position of the slit I intend to go with a resolution of 1 degree. This means around 360 different positions in azimuth. This I cannot cover with the datatype BYTE but with WORD.
As I know how the movement is going to be for the next e.g. 8 hours I can load only the required values from the EEPROM. Speed is not an issue.
Measuring will be a time consuming work. Also putting the data into a EEPROM is a challenge. So reading the data from an ASCII file via a loading program is a good idea.

BR
Christian

MWS · Joined: 22 Aug 2009 Posts: 2262

hgrueneis · Joined: 04 Apr 2009 Posts: 902 Location: A-4786 Brunnenthal

if it was me, I would use a digital compass and degree sensors(or pots with calculation), to control everything with steppers or servos.

Regards
Hubert

hgrueneis · Joined: 04 Apr 2009 Posts: 902 Location: A-4786 Brunnenthal

It would be fairly easy to do bar strip for all the units and have it more exact than one degree. I would rather implement a sensor based system. Then you could control the opening also depending on the use of telescope1 or 2 or both. Advantage: No map, just coordinates.
And you can get that from the Stellarium program. And if you use only one scope, then you have a narrower opening which will give you less light pollution..

Regards
Hubert

autoguider · Joined: 24 Sep 2007 Posts: 82 Location: Aachen

Hubert,
you got it absolutely right.These are the other options.
Digital compass has to be very much tilt compensated. The telescope tube may point to the zenith. This is a 90° tilt vs. the horizontal plane.
I will also follow this way as an alternative.
I am also looking for e.g. ultrasonic sensors to detect the slit.
The challenge comes because I have to cope with 2 optics and 2 offsets and I must not put the sensors in the opening of the telescope. They have to be on the tube and change their position.
Perhaps matlab or another software may be useful to model it.
Regretfully I have no experience with such a software.

I think reduction in angular resolution so that I can use bytes will help. With bytes the resolution is 1.4 degrees accuracy. This will be sufficient.
I did some modeling just for 1 telescope and for stepper motors. The formulae are not that complicated but you need to calculate with ellipses and not just with circles.
The lookup table would be just brute force.
Sensing would be my preferred solution.

Using a sensor for magnetic fields requires to check and compensate influences of steel and motors in the proximity. And I have a steel pier and at least 2 motors with appr. 2 A each.
Maybe ultrasonic sensors or radar sensors are the solution.

It will become a nice challenging project.

best regards
Christian

MWS · Joined: 22 Aug 2009 Posts: 2262

AdrianJ · Joined: 16 Jan 2006 Posts: 2483 Location: Queensland

Since its essentially a geometric problem, I would solve it by doing some analytic geometry to derive actual math expressions for the values you are trying to find, then just evaluate the formula in real time anytime you want a result. You sre going to need that calculation anyway to create your data array, why not just do it in real time ? Might take some work to implement the math in Bascom, but its far more flexible in case of a change to the geometry of the system.

O-Family · Joined: 23 May 2010 Posts: 320 Location: Japan

Rather than forcing a weak microcomputer to perform advanced calculations, it is possible to have a powerful personal computer perform calculations, or output simple calculation results such as Excel to a text file and incorporate it into the microcomputer.
I think that may be more accurate and easier.
I hope there will be many suggestions that match the level of the creator.