Addressmod issues

[miro]

This is an interesting feature, but I am not sure whether it works as expected - any hint on what is the type of the "start_address" and "end_address" in the addressmod()?

[Ttelmah]

It depends on your processor.
The maximum range of memory that can be handled via addressmod, is limited to what can be handled by the memory type used to address the RAM, less the RAM the processor already has. So if (for instance) you have #device *=16 (the largest size supported on normal PICs), the range of addresses available must fit into an int16 range, less whatever RAM the processor already has.
The whole 'point' is to make an external memory behave as if it is part of the RAM of the processor, so the available address range is limited to what the processor could potentially support.
Realistically, if you need more than 64K for variable storage, look at a different processor family. If you don't need it to be accessible through named variables, treat it as a data store, and don't use addressmod.

Best Wishes

[miro]

[miro]

The data space of my FRAM is 0x00000-0x3FFFF (256kByte)

addressmod (FRAM, fram_read_function, fram_write_function, 0x0000, 0x3ffff);

I am writing the FRAM with random data and reading back and comparing the data with the same sequence of random data. These are the results - all are without an error (tick=1ms, v4.128).

FRAM unsigned int8 buffer[200000];
ELAPSED TICKS_rd&comp= 1942

FRAM unsigned int16 buffer[100000];
ELAPSED TICKS_rd&comp= 1141

FRAM unsigned int32 buffer[50000];
ELAPSED TICKS_rd&comp= 734

FRAM unsigned int64 buffer[25000];
ELAPSED TICKS_rd&comp= 526

So it seems to me the addressmod can handle large data spaces (>64kB).

However, I cannot mix the above array with variables (a mcu crash) in the FRAM space.

And, for example:

FRAM unsigned int64 buffer[X];

X=999 ok
X=1000 crashes the mcu
X=1001 crashes the mcu
X=1002 compiler complains: Not enough RAM for all variables
X=1003 crashes the mcu
X=1050 ok

[Ttelmah]

OK.
On the PIC 24, yes, you can address larger sizes, _but_ you will find people having problems, with large and complex structures, even when they are in the main memory, and not mapped via addressmod.
There are hidden limits in the CCS code, with numbers of variables in a structure, arrays of structures exceeding sizes used in parts of the arithmetic, and developing overflow problems, etc. etc..

I'd really say you are hundreds of times 'safer', to not use addressmod, and instead treat such an array in FRAM, as a linear data file, with you retrieving the required index yourself, rather than trying to let CCS handle it.

Historically the old problem of the stack not being large enough will also hit even worse with addressmod. The compiler uses a large lump of stack space which seems to be the size of the entity you transfer using addressmod, so your stack size needs to be increased to (say) 512+sizeof(largest addresmod variable), if you are not going to hit problems from this....

Best Wishes

[miro]

I've tried #build(stack=2000) but it does not help much. The mixing vars and arrays in FRAM space does not work at least in my code. It would be great if the guys will fix that and provide more info how it works and how to use it, though.