constant array at specific address

[janni]

Is there a way to fix a constant array at specified address in flash?
I'd like to be able to declare them during compilation but later be able to bootload either only code or code with constants.

It also speeds access to array elements if one can assume that only lowest address byte changes in arrays fitting within one page.

[Jerry Messina]

No, there are no provisions for placing const data at a particular address.
If you wanted to be able to do that it can be done in asm, but you'd need to define the data using asm 'db' or 'dw' instructions and deal with it yourself.
SF would have no direct access to the data since it wouldn't know about it.

As far as the speed goes, if you use the tableptr instructions there is no penalty for data crossing pages.
Here are a few functions I use:

Code: Select all

//
//-----------------------------------------------------------------
// table access and misc instructions
//-----------------------------------------------------------------
//
public inline sub TBLWT_(b as TABLAT)
    asm
        TBLWT*
    end asm
end sub

public inline sub TBLWT_POSTINC(b as TABLAT)
    asm
        TBLWT*+
    end asm
end sub

public inline sub TBLWT_POSTDEC(b as TABLAT)
    asm
        TBLWT*-
    end asm
end sub

public inline sub TBLWT_PREINC(b as TABLAT)
    asm
        TBLWT+*
    end asm
end sub

public inline function TBLRD_() as TABLAT
    asm
        TBLRD*
    end asm
end function

public inline function TBLRD_POSTINC() as TABLAT
    asm
        TBLRD*+
    end asm
end function

public inline function TBLRD_POSTDEC() as TABLAT
    asm
        TBLRD*-
    end asm
end function

public inline function TBLRD_PREINC() as TABLAT
    asm
        TBLRD+*
    end asm
end function

Just set the TABLEPTR to the address of the const data first.

[janni]

No, there are no provisions for placing const data at a particular address.

That's a pity. Is it too complicated to implement?

As far as the speed goes, if you use the tableptr instructions there is no penalty for data crossing pages.

Oh, but there is. The address has to be written to TBLPTR and frequently an offset has to be added before one starts to read from flash. Only then crossing page boundary goes without cost. Anyway, that's just additional advantage, basic problem is not being able to bootload just code when constants take a lot of memory. Also, taking into account that newer processors allow to write to flash only in large chunks or whole pages, changing data in flash through remote connection gets problematic if one cannot separate it from code.

[Jerry Messina]

I'd be more worried about the potential problems that separating the code from the data might cause.

There's only 128k of code max, and I've never run into a situation where the download time was excessive no matter what the interface was. YMMV.

[janni]

I'd be more worried about the potential problems that separating the code from the data might cause.

Hm, I always thought it's the other way around and never had problems with it. Separating data from code is actually pretty common and PIC compilers usually have a way to fix constants' locations. I'm surprised Swordfish Basic does not have this option.

There's only 128k of code max, and I've never run into a situation where the download time was excessive no matter what the interface was. YMMV.

Well, I don't like waiting but more importantly, my applications depend heavily on possibility of reconfiguring devices - that's where need of changing large blocks of data arises. Code and configuration are separate objects and may be separately changed.

[Jerry Messina]

Swordfish assembles code in absolute mode, so there's no linker involved that would make things like this easier.
Plus, there are features such as the consolidation of duplicate string data, and placing const data inline that would hamper some of it.
Depending on how the const data is accessed, it may not even exist as a separate data table.

All the const data (if it exists as such) is gathered up and placed towards the beginning of program memory.
Initially, const data was even limited to the first 64K but that has been extended (at the expense of larger code, which you don't like).

[janni]

Arrays accessed by index variable certainly need to be placed in flash separately but I see how it would complicate things if any such array could be moved around program memory. What about constants that would take one or more whole 256-byte sectors of program memory? Could they be at least aligned filling whole sectors (as flash writing goes), wherever compiler places them?

BTW, newer processors have Storage Area Flash placed at the end of program memory that is completely safe from accidental code execution. It would be good to have access to this region as constants placeholder.

P.S. In general it's not the larger code that I mind, it's the slow one .

[Jerry Messina]

It's funny you should mention SAF... I was just looking at that the other day to see if I could come up with a way to deal with that.

Writing functions that can read/write the SAF is no problem, but the only way I could come up with to be able to place an initialization record into the hex file is to do it in asm which makes it somewhat difficult to deal with. The compiler has no knowledge of data defined in asm blocks, so you'd be forced to reference everything via absolute addresses only.

Let me think about it some more and talk with David, as any change like that would require changes to both the frontend (the BASIC compiler) and the backend (the asm generator) code. I only have the ability to change the backend portion.

The way I've dealt with this in the past is a bit kludgy. First you declare a const array that's 2x larger than the flash erase block size. That ensures you reserve a flash page that can be erased. When you first run you need to move the data within the block so that it's page aligned. Then write functions that access the data assuming it's now page aligned. If it's one big array it's not too bad but if there are a number of different items it's a bit of a pain since you have to manage the placement of them manually.

[janni]

First you declare a const array that's 2x larger than the flash erase block size. That ensures you reserve a flash page that can be erased. When you first run you need to move the data within the block so that it's page aligned. Then write functions that access the data assuming it's now page aligned. If it's one big array it's not too bad but if there are a number of different items it's a bit of a pain since you have to manage the placement of them manually.

I would not mind wasting flash space to fill the gap between code and next page border if compiler did the offset calculation for first actual array element. Otherwise it's cumbersome to check after every compilation whether the constant placement hasn't changed (user constants are indeed placed near but not exactly at the beginning of code and then there are internal constants used to initialise variables that apparently precede user-declared constants).

I hope David will find some way to implement an option for page border-aligned constants or, better yet, for page(s)-filling constants placed at the end of flash (that would also ensure SAF implementation).

[Jerry Messina]

Just an update-

This has been addressed in the latest compiler version 2.2.3.8.
You can now place const arrays at a location in the flash memory space using the syntax
const mydata(10) as byte @($1000) = (1,2,3,4,5,6,7,8,9,10)

Due to the nature of the PIC18 the data must be located at an even memory address, and if the data length is an odd number of bytes it will automatically be padded to make it even (this is a function of MPASM and cannot be changed).

SF 2.2.3.8 is available via online update.