Catalina And EEPROM Usage

Wingineer19

Hello @RossH,

It's been quite some time since we've communicated via this forum. I hope things are going well with you, or at least better than they have been in recent times.

I've been wondering if there's any way I can get the Prop1 to work with my Project despite the fact it has many Menus it must present to the user. These Menus consume lots of memory and I couldn't get everything to fit even when running in CMM.

I then experimented with XMM using the Large Memory Model with external SRAM chips as well as the Small Memory Model using just the 64KB EEPROM that already exists on the FLiP module.

I must say that using the XEPROM driver with the Small Memory Model and executing the code directly from EEPROM coupled with an 8K HubRam cache does open up some possibilities and I definitely have ideas for future projects using this arrangement.

The advantage of using the XEPROM driver is that no additional hardware is required on the FLiP. The downside was the inability to execute a C program on any other cogs. However, you made a nice workaround by using shared memory and thus allowed the Small Memory Model code to startup and execute C code on other cogs.

But now I'm wondering why I can't just move all of the Menu items to EEPROM. This might free up enough of the hub memory I need to run my code in CMM on multiple cogs.

What I would effectively need is something like this:

const eeprom char *Menu1="This Is Menu1";
const eeprom char *Menu2="This Is Menu2";
const eeprom char *Menu3="This Is Menu3";
const eeprom char *MenuL="This Is The Last Menu";

void main(void)
{
 char OutStr[80];
 strload(OutStr,Menu1);
 tty_str(OutStr);
}

In this case strload() is a function I will write that will invoke the I2C functions to locate and read the desired string from EEPROM memory and copy it to OutStr. From here the tty_str() function will send it to the console port.

Of course the compiler doesn't offer the const eeprom char so I will have to create its functional equivalent. I can do this by writing a program that will save pre-formatted strings to EEPROM.

The strload() function will of course need to know the location of the desired string. Probably the simplest way would be to hardcode a big list of #define directives containing the address of each string.

Once the Menus have all been saved to EEPROM, I can load in my Project code that can then invoke the strload() function anytime it needs a Menu item. This function would have the location of the desired Menu item, fetch it from EEPROM, and copy it to the OutStr.

This scheme will probably work unless the payload program overwrites the entire EEPROM whenever it uploads the compiled program to memory.

So, the question to you is this: Does payload overwrite the entire 64KB of EEPROM of the FLiP or only the lower 32KB?

RossH

Hello @Wingineer19

Just letting you know I have seen your post. It's so long since I did anything on the P1 that I can't remember all the details off the top of my head. However, if you compile your program using Catalina's -e flag it generates a 32Kb ".eeprom" file, so my belief is that Catalina only ever programs the first 32kb and would leave the rest alone. I think you are safe to assume this is the case.

I will dig out my Hydra (it has 128k EEPROM) and make sure. This may take me a day or so. From memory, you had to use a separate program (the Hydra Asset Manager) to program the higher portions of the EEPROM - Catalina could not do it.

Ross.

RossH

Ah! This will take me longer than I expected. I just discovered the Hydra Asset Manager won't run under Windows 10. I have not tried to use it since I (very reluctantly) upgraded from Windows 7, and (as far as I recall) it is the only tool I had that could read and program EEPROMs beyond the first 32kb.

I'll have to find another PC to run it on. Or use another tool. If anyone knows of one, please let me know.

Ross.

avsa242

Windows seems to have some kind of compatibility mode for running sw meant for older versions (no experience with it personally...) - it's in the pop-up menu if you right-click the executable in a file manager. Have you tried this to see if it works?

RossH

@avsa242 said:
Windows seems to have some kind of compatibility mode for running sw meant for older versions (no experience with it personally...) - it's in the pop-up menu if you right-click the executable in a file manager. Have you tried this to see if it works?

Yes, I tried that. No luck. I still have an old XP machine I can probably use. Will try it today.

RossH

Hello @Wingineer19

I found a later version of the Hydra Asset Manager (1.09) that works ok under Windows 10, and I can confirm that if you use Catalina's -e option to generate a 32kb .eeprom file, and then payload's -e option to program the eeprom rather than just load the program to RAM then it programs only the first 32kb and does not affect the remainder of the EEPROM.

Tested on a Hydra, but should also work on a FLiP.

Ross.

Wingineer19

Hi @RossH,

Many thanks for verifying that payload only works with the lower 32KB of the EEPROM. If it had overwritten the entire EEPROM instead my idea obviously wouldn't have worked, and I would have no choice but to move on to the Prop2.

This will give me one last chance to see if I can somehow make the Prop1 (FLiP module) do what I want it to do. Today I verified that it has enough firepower in CMM mode to perform some linear algebra operations on some data I fed to it by providing me with a nice least squares solution.

Writing my own functions to create matrices, perform matrix multiplication, and matrix inversion was fun. I originally used calloc to dynamically create matrices via a CreateMatrix() function, along with a DestroyMatrix() function to eliminate them whenever I was done using them. However, I've heard some horror stories about using dynamic memory allocation on microcontrollers so I decided to create some fixed size matrices instead to be on the safe side. I guess I will just have to live with the memory penalty. But on the other hand I may just go ahead and tempt fate...

Now, on to the next part of distilling all of the Menus down to a list of formatted strings and writing them to the EEPROM. The FLiP will have to grab these strings from EEPROM and send them to the serial Console Port whenever a Menu selection is made. Since the I2C speed is comparable to the Console Port baud rate I'm assuming that any latency should hardly be noticeable to the user. That will be an interesting test.

Anyway, thanks again. Time to tackle all of those Menus now. This will take some time...