how can I keep some code in flash / global (or static) variable management

[mdeneen]

Posted on March 26, 2009 at 07:28

how can I keep some code in flash / global (or static) variable management

[domen2]

Posted on May 17, 2011 at 13:04

You're not making sense to me :p

Either you do it with linker script at compile/link time. Or use a pointer which you change at runtime?

[mdeneen]

Posted on May 17, 2011 at 13:04

My goal is to create a set of libraries which will reside in a write-protected flash segment. A function will be placed at a fixed address which will let the main program query what functions are available. I don't see this part being difficult.

I'm fine with reserving a flash segment, but I'd like to avoid doing that with RAM. Is the only way to configure global variable memory locations by altering the linker script? I'd love to do it at run-time.

Am I making sense? :)

[relaxe]

Posted on May 17, 2011 at 13:04

You're almost making sense to me, only you need to describe a bit more... Let me help:

Is this request about preventing code theft -OR- making a programmable device where you need a protected space for the runtime interpretter while having user code in flash?

[paulsmitton9]

Posted on May 17, 2011 at 13:04

You are making sense to me. It's an interesting question.

Firstly, I'd keep as many variables as possible local.

(i do that anyway, it saves memory and is safer)

Secondly, I'd group all global variables in a Struct(s).

(i do that anyway, it's much tidier, a bit oo-ish)

And then create the struct in memory at run time, and pass

its address to the flash code everytime you call a function.

Just make sure your flash functions are all looking for

a pointer to a struct containing their global variables.

[paulsmitton9]

Posted on May 17, 2011 at 13:04

I'd definitely keep the ISR's out of the static area and just call static functions from within them. Not sure if this makes what i was saying any clearer:

Code:

typedef struct

{

u32 Brightness;

u32 Contrast;

u8 Text[256]

}

LcdStateTYPE;

void StaticPutCharOnLcd(LcdStateTYPE LcdState, u8 TheChar, u32 CharPos)

{

LcdState.Text[CharPos] = TheChar;

UpdateLcd(LcdState);

}

int main(void)

{

LcdStateTYPE LcdState;

StaticInitialiseLCD(LcdState);

StaticSetLedContrast(LcdState, 5);

StaticSetLedBrightness(LcdState, 6);

StaticPutCharOnLcd(LcdState, (u8)'a', 10);

}

Obviously the declaration of LcdState could be local to say main or global, or malloced.

[mdeneen]

Posted on May 17, 2011 at 13:04

Paul got it. :)

Let me describe what I am trying to do, and why I want to do this.

Here's what my flash will look like:

Code:

<BR>+----------+ <BR>|Bootloader| <BR>+----------+ <BR>|''static'' | <BR>|functions | <BR>+----------+ <BR>|main code | <BR>+----------+ <BR>

I want the main code to be able to call the static functions in a different flash segment. These static functions never (well, hopefully) change. I have no need to flash these over and over again.

I also don't want my main code to know that much about them, because they might be different depending on what else is connected to the board. For example, if I change the LCD controller, I want the main code to remain the same. The code in the static functions section knows how to deal with this new LCD controller, my main program doesn't really care how it works. It just wants to plot a pixel, or a line etc.

These static functions normally require some sort of global variable or context. I can define structure interfaces that get passed in for each call, and that gets me part of the way. The ISRs will need to put/get the data to/from SOMEWHERE, and I can't pass a structure to them. (edit: perhaps ISRs do not belong in this static segment.)

So, in summary, I was hoping that there was some way of specifying the start address of global variables at run time, but I am certain that is done at link time. Another choice is to segregate memory, and say that RAM from 0x????... -> 0x????... is reserved for the static function segment and the rest is reserved for the main code.

The reason why I want to do this is two fold. First, it lets me abstract some of the hardware a bit so I can have the same bin run on multiple devices. Secondly, this will be delivered over a cellular network, and I want to minimize data transfer as much as possible.

Am I making any sense yet? :)

Mark

[ This message was edited by: mdeneen on 25-02-2009 21:56 ]

[marknorman9]

Posted on May 17, 2011 at 13:04

How do you intend to keep the address of the library functions the same if you have to modify them? Sounds like you will need a set of fixed offset ( re-direction ) functions at the top of that flash section to do that. Plus some padding to allow for future expansion. Or how about an address server into which you pass a function ID and it returns the address. If any of the parameters change you will have to manage version compatibility between the main app and the static code. Don't try this if you want to keep you sanity :o

I'm thinking of using something like this for a dual image loader manager, but the complexity is starting to freak me out.

[mdeneen]

Posted on May 17, 2011 at 13:04

I've given this some thought. I think I am still going to place my ISRs up in the static section. In my case, it is more of a BIOS. Because of this, I will reserve a small amount of memory for the static section, probably 64 bytes. This gives me enough room to hold a pointer for each peripheral while allowing a little room for expansion.

My structures will look something like this:

Code:

typedef struct

{

u32 Brightness;

u32 Contrast;

u8 Text[256];

u32 *p;

} LcdStateTYPE;

..with the p pointer being null. If I need to add to the structure, I can tack on another structure through the pointer, without changing the interface or its size.