Accessing shared data in ERAM - A solution for the confused

[AndyC]

[notzed]

These topics have some background:

viewtopic.php?f=13&t=1655
viewtopic.php?f=23&t=1660

I still think it's pants because you're still just hard-coding the address labels: you could just as easily use a struct and assign it with thestruct=(void *)0x7000; instead, rather than messing about with linker scripts. The thing the linker is for is assigning addresses and coalescing block with the same parameters, doing it with a pen and paper is mental.

As soon as you have multiple variables in different compilation units (or libraries) it all collapses into an unmanageable mess: you can't manually put everything in one struct.

[AndyC]

Surely there is a difference?

If you hard code the address the linker may put other data there, therefore you have two things occupying the same address.

If you modify the linker script as I posted above then this will not happen.

Doesn't seem like pants to me!

[sebraa]

You could always allocate a single dummy-block in a specific section, and then do accesses to that area through pointers, doing your own memory management. After all, that is how people use to implement malloc() and free() on embedded hardware (unless they run an operating system).

By the way, your ".section_fixed_x7000" overlaps both ".code" and ".data_bank3". I don't know whether the linker is bright enough to understand that. (In processors with different address spaces, it might or might not matter.)

[AndyC]

I must admit I thought the linker was bright enough, I took the idea from the matmul example which uses the same section.

I will fill up data_bank3 and see what happens.....

[AndyC]

You are right

section_fixed_x7000 loaded at [00007000,0000700f] overlaps section .data_bank3 loaded at [00006000,00007fff]

I will check the matmul link file, maybe that has the same problem!

[AndyC]

Yep the matmul example suffers from the same problem, great!

[AndyC]