I am going to store the makeup of patterns for my Water Curtain in EEPROM.

Now the question is how will I find the pattern?

Here is my A1 pattern:

A1

00000000000000111000000000000000
00000000000001111100000000000000
00000000000011000110000000000000
00000000000110000011000000000000
00000000001100000001100000000000
00000000001111111111100000000000
00000000011111111111110000000000
00000000110000000000011000000000
00000001100000000000001100000000
00000011000000000000000110000000
00000110000000000000000011000000
00001100000000000000000001100000

This will be stored in EEPROM as:

A1
00000000
00000011
10000000
00000000
00000000
00000111
11000000
00000000
00000000
00001100
01100000
00000000
00000000
00011000
00110000
00000000
00000000
00110000
00011000
00000000
00000000
00111111
11111000
00000000
00000000
01111111
11111100
00000000
00000000
11000000
00000110
00000000
00000001
10000000
00000011
00000000
00000011
00000000
00000001
10000000
00000110
00000000
00000000
11000000
00001100
00000000
00000000
01100000

My EEPROMS are:

24AA128 16K x 8 (128 Kbit) Serial Electrically Erasable PROM (EEPROM)

AT24C1024B Two-wire Serial EEPROM 1M (131,072 x 8)

Since there is no DOS (disk operating system) the data will just be written to the EEPROM serially.

Unless someone has a clever alternate method.

So if A1 is written to EEPROM address 500 it will occupy address location 500 - 547.

If my Water Curtain PlayList calls for A1 how will the mcu find it?

For development I have been hard coding the address but obviously that will not work.

There will be 100s of patterns the PlayList will be essentially random Playlist[A1,B1,H1,E1,L1,L1,O1,A1,B1]

The Playlist might be composed of any pattern sequence.

There will be some standard selections like [HELLO] but that is another question.

How do I do "random" selection from the EEPROM?

The EEPROM will pe populated from a pc using a USB/I2C module.

I sure appreciate the help,

Ralph

Didn't we already have this conversation?

I would start the EEPROM with two bytes indicating the number of patterns to play, followed by the address of each pattern.

Then each pattern would start with one byte indicating the number of rows in the pattern.

Then each row would have four bytes for the solenoid data, and one byte for the duration.

Well sorta, I need more specifics.

In other words yes, but I do not understand.

Lets start here:

[quote] start the EEPROM with two bytes indicating the number of patterns to play [/quote]

Why store the number of patterns to play on the EEPROM, that is dynamic and to me should be in Program Memory i.e. a variable.

The number of patterns to play will be constantly changing.

[quote] followed by the address of each pattern. [/quote]

That's the gotcha, how do I know the address of the pattern?

[quote] Then each pattern would start with one byte indicating the number of rows in the pattern.

Then each row would have four bytes for the solenoid data, and one byte for the duration. [/quote]

This I understand.

Now how do I reference the EEPROM memory?

That is where I am lost, how do I know to start at memory location 500 or whatever the first byte location is?

It seems as though I need a look-up table!

If so what would that look-up table look like?

I would imagine using two bytes per record so it would look like 000000A100000500 and 0000Z2700130001.

So once I built the PlayList I would parse the look-up table stored on the EEPROM to get the pattern address?

Is this how it could/should be done? Noter had said a look-up table was one method but did not elaborate or say anything about other methods?

And then should I worry about standard patterns [HELLO] or should parsing the look-up table be fast enough?

Could I parse the look-up table at startup and have the look-up table in memory?

Ralph

The number of patterns to play will be constantly changing.

Oh, you talked about a play-list so I thought the show was all pre-programmed. So you're getting new commands at run-time from the PC over USB or something?

how do I know the address of the pattern?

Because you're then one that put them on the EEPROM in the first place. If you don't know where you put them, who would? Whatever program you're using to upload the patterns and the instructions to the EEPROM would also write these addresses.

Maybe we're just not on the same page, so let me back up. This is what I'm picturing:

You have a bunch of patterns stored in EEPROM. A pattern is something like the letter "A" or some other shape. A pattern consists of one byte giving the number of rows, and for each row it is 4 bytes for the solenoid info and one byte for the duration.

You have a play-list. It tells you which patterns to play, in which order. Maybe once in a while you want to play a pattern selected at random from a specific subset of patterns.

Do I have that much right? Do you want the play-list to be stored in the EEPROM, or in the MCU's program memory?

Here's an example. Let's say I have 3 patterns, called "A1", "B1", and "C1". Let's assume that each one takes 61 bytes. Let's also say I have a playlist that looks like [A1, C1, B1, A1, A1, B1, C1, C1, A1, C1, B1].

When you write the patterns to the EEPROM, that program will keep track of the address of each pattern. Something like this pseudo code:

address = 0x4000     // size of 16k EEPROM

pattern_bytes = 0x0C, 0x00, 0x03, 0x80, 0x00, 0x10, ...
address = address - length_of(pattern_bytes)
map["A1"] = address
write_to_eeprom(address, pattern_bytes);

pattern_bytes = 0x0C, 0xFF, 0xFC, 0x7F, 0xFF, 0x7F, ...
address = address - length_of(pattern_bytes)
map["B1"] = address
write_to_eeprom(address, pattern_bytes);

etc.

So now the program knows that A1 is stored at address 0x3FC3, B1 is stored at 0x3F86, and C1 is stored at 0x3F49, etc.

Now it writes the playlist starting at EEPROM address 0:

0x0B       11 patterns in the playlist
0x00

0xC3       address of A1
0x3F

0x49       address of C1
0x3F

0x86       address of B1
0x3F

0xC3       address of A1
0x3F

0xC3       address of A1
0x3F

0x86       address of B1
0x3F

0x49       address of C1
0x3F

0x49       address of C1
0x3F

0xC3       address of A1
0x3F

0x49       address of C1
0x3F

0x86       address of B1
0x3F

When the MCU runs, it starts at address 0 of the EEPROM, reads the "11" and knows the playlist is 11 patterns long. Then it reads the address of the first pattern, plays that pattern, and then gets the next address, plays that pattern, etc.

In general we are on the same page about how to get a pattern and what to do with it.

Here is the problem,

[quote] When you write the patterns to the EEPROM, that program will keep track of the address of each pattern. [/quote]

"that program" !!!

How will "that program" tell the mcu the addresses?

The patterns will be written to the EEPROM by a pc.

The mcu will need to know the addresses of the patterns but how?

There is no communication between the pc and mcu the only thing they have in common is the EEPROM.

[quote] Because you're then one that put them on the EEPROM in the first place. If you don't know where you put them, who would? [/quote] Correct!

I am writing a Python program to parse a "Patterns.txt" file. This program will parse each line of the pattern, break the 32 bit pattern down into 4 8 bit bytes. The first Byte will be written to a designated memory address.

So for my A1 pattern:

00000000 will be written to say EEPROM address 00000500 ...

A2 will be written to 00000548 ... (assuming 48 bytes per pattern)

A3 will be written to 00000596 ...

Now how do I tell the mcu to start at EEPROM 00000500 for A1 or to find A3 starting at 00000596.

Thanks a lot bretm I really appreciate your input and patience.

Now using a look-up table is getting complicated in my thinking I keep adding components.

I started with:

000000A1 00000500.

Now I need to pass a I2C address reference. I could have 8 different EEPROMS with distinct addresses(EEPROM1,EEPROM2,EEPROM3,EEPROM4,EEPROM5,EEPROM6,EEPROM7 and EEPROM8).

I "might" need to set a variable with the number of bytes, 48 for A1. Or set the number of bytes in a "for" statement.

I could put a timing parameter in here also but I think I will add a fifth byte to the EEPROM memory.

So if A1 is on EEPROM4 I would need:

000000A1
EEPROM4
00000500
00000048

4 bytes to store these parameters seems excessive.

Well this part is going well, anybody want to talk about my Python file parsing and I2C/USB coding chalenges?

Ralph

How will "that program" tell the mcu the addresses?

By storing the addresses in the EEPROM as part of the play-list.

Now how do I tell the mcu to start at EEPROM 00000500 for A1 or to find A3 starting at 00000596.

You don't have to, as long as the playlist is stored in the EEPROM. Once it's in the EEPROM it no longer looks like "A1, A3, B2, C5" but instead looks like "address of A1, address of A3, address of B2, address of C5". That's only two bytes per entry.

Is your playlist going to be stored in EEPROM or in PROGMEM? If you're trying to store it on the MCU, then you just have to have "that program" also generate a C header file that contains the addresses of the patterns:

#define A1 500
#define A2 548
#define A3 596
// etc.

And then your playlist looks like

PROGMEM uint16[] playlist = { A1, A3, B2, C5 };

Sorry:

PROGMEM uint16 playlist[] = { A1, A3, B2, C5 };

Sorry:

PROGMEM uint16 playlist[] = { A1, A3, B2, C5 };

Ah, finally the light between the cracks is coming through.

First of all I was never picturing the "PlayList" being stored on the EEPROM, sorry if somewhere I had implied that.

I have a more dynamic vision that would preclude using "header files".

"you just have to have "that program" also generate a C header file that contains the addresses of the patterns:" Gee wouldn't "quotes" be a great asset to/for this forum.

Well how would that "header file" get to the the mcu program file during the middle of the afternoon out on site?

To recompile the code to hold static information to me would not be feasible.

It has to all be dynamic.

I would have to change the "PlayList" dynamically, at any moment I might want to see a new routine.

I can not "recompile" to pass in a new PlayList and a new header file.

I think that is where the discrepancy in our view is.

For me the keyword is "Dynamic" the "Playlist" can not depend on compiled code but has to play the list as selected.

I think I have to put a look-up table into EEPROM1 with the address of the various "patterns".

I was looking for confirmation of this concept or hopefully clever alternatives.

I "think" (which is always dangerous ) that I need to put a look-up table at EEPROM address 100 ... which will record the "address" of each pattern.

It would certainly be "convenient" to "generate a C header file" that would be a easy way but I "think" I need a more "Dynamic" method.

Well hopefully someone can point out why/how I could use a "Header File" but to me that is illogical.

With all of the above said and hopefully clarified I think I need to expound further on my vision for the "Water Curtain" (I certainly hope others are finding this conversation as interesting as I am, if not I apologize).

Eventually I would like to be able to send a "text message" from a cell phone to the Water Curtain.

Therefore the "message" and EEPROM reference has to be completely random and Dynamic.

So if someone sent "Sally I Love you " from their cell phone, that is what I'd want to display.

Again I could not use a "C header file" as convient as that would be.

I think the concept of randomness, dynamic pattern generation has been the hangup in our discussion.

Or at least that is my understanding so far.

Now if there is a way to randomly generate an active header file, that would be very interesting.

I really really really appreciate all that has been contributed so far and I definitely will incorporate the concepts that have been presented so far.

I hope this will clarify my vision further.

Ralph

Ok, I get that the playlist is dynamic. But the header file doesn't contain the playlist, it just contains the pattern addresses. The patterns are static, right? I mean, if you receive a cell phone message, you're only going to be able to understand letters and codes that correspond to patterns that are stored in the EEPROM, right? And isn't the EEPROM pre-programmed?

So the EEPROM has a fixed set of patterns on it. The actual sequence of patterns you select is dynamic but each pattern itself is static. So the pattern addresses won't change in the field. So the contents of the header file won't change in the field. So it can be pre-compiled.

Or are you saying the EEPROM contents themselves will change out in the field?

When you receive a text message with the letter "A", how do you decide which pattern to show (A1, A2, etc.)?

The more I think about it the more the header file makes sense. Using a header file will put the pattern starting address into memory when compiled so that has to be a plus over reading from EEPROM.

Correct the addresses can be pre-compiled, I wonder how big the header file might become?

Currently I am using 32 bit wide patterns, for my curent setup this will become 80 bit max width.

If this all actually works, which is still unknown, I can picture 128bit and greater patterns.

Even with 32 bit width there could be a lot of variations for the letter A.

Well I'll worry about that later on right now I need to get it working.

Also in a remote sense the EEPROM contents "might" change in the field.

At least eventually I can picture, as I think I have said in the distant past, a tablet computer where people could do a sketch and then display the sketch in/on the water curtain. These sketches might want to be saved, so then yes the EEPROM contents would change in the field. This of course is very remote at the moment but fundamentally I know how to scan a drawing to produce a "pattern". I would use the basics of signature capture for handheld devices, you just scan a screen or drawing until you see something that is not white and register a dot. You would adjust for resolution. So at least in my mind it would be feasible to do sketch displays.

[quote] When you receive a text message with the letter "A", how do you decide which pattern to show (A1, A2, etc.)? [/quote]

See why quotes would be nice?

At the moment I have gotten as far as thinking there would have to be a default font.

There are various schemes where I could make the font selectable but certainly nothing easy or elegant, any ideas?

bretm, Thanks again you have really helped a lot, especially in making me think about what the heck I was trying to do.

The specifics of exactly how are still a bit sketchy but I think you and others have established a solid foundation to build off, Thank You.

Ralph