ASM newbie question #2: Relocatable Mode / Variables

[This N°9]

I have a understanding problem concering variables/relocatable mode:

if I build a module and I need a variable "x", I define it in a udata-section in the .asm file. I understand that it's address will then be calculated by the linker later. But what happens if somebody includes the .inc file of the module in his program directly? where will be the variable/label then, how is it's address calculated then?

Or asked differently, how are "variables" defined for non-relocatable mode? is the only way to use EQU or is there another way?

I'am building a module to drive FRAM IC's. To drive these with 1MHZ clock speed, I provide (optional) iic-functions located in a separate .inc file. This one uses a 1-byte-buffer. The module can use the mios_iic@400kHz or the dedicated iic@1MHZ then. If "#define FRAM_MIOS_IIC 1" is set, the fram_iic.inc will be included.

Do I have to define the buffer needed in fram_iic.inc in fram.asm, or is there a way to locate it in fram_iic.inc itself?

[stryd_one]

what happens if somebody includes the .inc file of the module in his program directly? where will be the variable/label then, how is it's address calculated then?

Or asked differently, how are "variables" defined for non-relocatable mode? is the only way to use EQU or is there another way?

They can locate the memory themselves, with the EQU in the app.

If "#define FRAM_MIOS_IIC 1" is set, the fram_iic.inc will be included.

Do I have to define the buffer needed in fram_iic.inc in fram.asm, or is there a way to locate it in fram_iic.inc itself?

I would put it in the inc file. You just need to be a bit crafty about where you put the 'code' directive. (as in, it'll have to go in the inc file too).  Then again, if someone is writing in ASM and including the inc file directly, chances are they'll be able to reserve the space themselves, so you could make the code look a bit cleaner.... Your call :)

[This N°9]

They can locate the memory themselves, with the EQU in the app.

Ok, I see. Couldn't they just also use the .asm file, no need to care about memory locations? I don't plan to write any application in asm, I just wonder and want to understand this whole relocate-thing and all this better.

I would put it in the inc file. You just need to be a bit crafty about where you put the 'code' directive.

Or maybe I just use the same condition I use to (conditionally) include the fram_iic.inc to (conditionally) set up the variable(s)?

Some other question: As I understand both code space and memory are addressed from 0x00. I found some example on the WWW that tells me I can set up variables in memory like this:

        ORG    0x20
Wert    RES    1       ; Wert bedeutet ab sofort 0x20, Wert ist eine 1 Byte große  Variable
Pointer RES    3       ; Wert bedeutet ab sofort 0x21, Pointer kann als 3 Byte große  Variable dienen
Temp    RES    1       ; Wert bedeutet ab sofort 0x24 

sorry for the german.. but isn't ORG just for code space addresses or does it also work with memory?  ???

[stryd_one]

Ok, I see. Couldn't they just also use the .asm file, no need to care about memory locations?

Yeh they could - although if you're coding in ASM, you may have good reason to specifically locate the code at a certain address.... But it's not a 'must'.

isn't ORG just for code space addresses or does it also work with memory?  ???

That directive has voodoo powers ;)

I found this good summary:

  org <address>

  org <address>, <mode>

  org <mode> Specify origin for program code, register file or data EEPROM. <mode> is "code" for program code, "reg" for register file and "edata" for data EEPROM. If mode is not given, it is determined automatically from first instruction that generates output to the hex file. After that the mode cannot be changed without another ORG statement. When ORG is used with only the mode parameter, the address continues from the last value for that mode.

Although, the MPASM user's guide says nothing about it.... I will have to defer to TK again on that one ;)

[This N°9]

That directive has voodoo powers

Ahh.. ok. It's neither in the gputils doc nor in the MPASM doc.. It's a bit weired with this harvard architecture stuff.. One thing I also wonder is which directives apply only for code / memory sections. DB/DW/DATA etc. for example seems to apply for both, RES only for memory?

I guess that the assembler uses internally one pointer for Data space and one for Program space? For example IDATA seems to allocate both memory and code space. Is the label used for the IDATA section then pointing to data/code as well, in dependency of the command used?

IDATA

      <label> IDATA <expression>

Only for relocatable mode. Creates a new initialized data section in the output object le. <label>

species the name of the section. If <label> is not specied the default name “.idata†will be used.

<expression> is optional and species the absolute address of the section. Data memory is allocated and

[glow=red,2,300]the initialization data is placed in ROM. The user must provide the code to load the data into memory.[/glow]

    See also: CODE, UDATA

[stryd_one]

Well yeh, those are for initialized data, so it reserves the memory in RAM for the data to be held, and places the initial values in codespace, then when your app starts it uses your provided code to copy the data from ROM to RAM.

[This N°9]

yeah but the label used with IDATA is for both codespace and ram then?

[stryd_one]

I dunno I always initialised it myself ;)

[This N°9]

one more question:

I'am writing my faster iic-driver right now, in the specs of the chip I have some timing parameter like:

data in setup (SDA set to SCL high): min. 100ns

bus free before new transmission: min. 500ns

start/stop condition hold time: min. 250ns

etc.

can I really go to the edge of the timing params, is this not save in respect to maybe a longer cable connecting the IC to the core? how are slew rates of pin outputs on the PIC? For ex. "data in setup" is exactly one instruction cycle, so if I go to the edge I would not to have a nop between the SDA set and the SCL hight set.

[TK.]

These are timing constraints which usually have to be measured with a scope, because there are too many parameters which affect the slew rate (e.g. cable length, input impedance of the target device), not only the one specified in the PIC datasheet...

Best Regards, Thorsten.

[stryd_one]

Yeh totally. I was going to suggest something a little less professional than a scope, which is simply: just try it out and see how ya go ;)

You can check out all the parameters and come up with a theoretical limit, but even if you consider everything and make all the correct calculations, which as TK said is not practical and many would extend that to not possible... Well it might just not work out like that.

Something I found useful is to define a few appropriately named macros to use wherever I needed a set of nops, and then I only had to edit the top of the file where all the delays were defined, for quick rebuild/retests. Start off with extremely long delays and whittle them down as you test (thoroughly). When you start getting errors, you've whittled too far ;)

[This N°9]

I think the most critical part will be the slew rates. I have only a few spots in the code where I can't do anything else between setting SDA and SCL than inserting NOP's.

Can I assume that the inner-chip timings that have nothing to do with the outer wiring are quite reliable values (like 'start condition hold time' or 'scl low data out valid' ) ?

What are your experiences with slew rates? What is a good worst case value for a PIC out pin, with, say a cable of 20cm ? Sure there is also the slave device itself that influences this.

Something I found useful is to define a few appropriately named macros to use wherever I needed a set of nops, and then I only had to edit the top of the file where all the delays were defined

I think I will do this, somthing like a 'save mode' that slows down a bit the whole story but makes it saver against outer influences. The thing is, with 1MHZ clock @ 10MIPS, you really don't have that much cycles left to fill up with nop's  :)