Gast
#5088016
Mein "toller" MCU hat gesplitten SRAM.
Ich habe gelesen, dass man __attribute__((section("m_data_2"))) den
Compiler zwingen kann, Daten in einer sektion abzulegen.
Tut er aber nicht. Was soll ich tun?
Gast
#5088021
Ist die section m_data_2 auch im Linker Script angelegt?
Gast
#5088022
Linkerfile editieren?
Gast
#5088024
So versuche ich es mit den Variablen:
int variable[1000] __attribute__((section(".m_data_2")));
int variable2[1000] __attribute__((section(".m_data_2")));
Linker Skript:1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Gast
#5088028
Was bringt der denn für einen Output der Compiler? Michael H. schrieb: > Tut er aber nicht. Woran machst Du das fest? MemDump`?
Gast
#5088031
oder was sagt das mapfile?
Gast
#5088079
Michael H. schrieb: > Linker Skript: Das allein genügt nicht. Man braucht einen Eintrag im Bereich SECTIONS { ....... } analog zum "normalen" RAM. Der Eintrag besagt wie der Linker das RAM nutzen kann. Details wird sicherlich noch jemand posten der sich bessser damit auskennt. Inititalisierung beim Startup ist dann noch ein spezielleres Thema.
Michael H. schrieb: > m_data (RW) : ORIGIN = 0x1FFFC000, LENGTH = 0x00004000 > m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00004000 Da beide RAM-Bereiche aufeinanderfolgen - müssen die denn unterschiedlich sein? Das Leben dürftest Du Dir einfacher machen mit > m_data (RW) : ORIGIN = 0x1FFFC000, LENGTH = 0x00008000 Oder was hab' ich nicht verstanden?
Gast
#5088099
Rufus Τ. F. schrieb: > Michael H. schrieb: >> m_data (RW) : ORIGIN = 0x1FFFC000, LENGTH = 0x00004000 >> m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00004000 > > Da beide RAM-Bereiche aufeinanderfolgen - müssen die denn > unterschiedlich sein? > > Das Leben dürftest Du Dir einfacher machen mit > >> m_data (RW) : ORIGIN = 0x1FFFC000, LENGTH = 0x00008000 > > Oder was hab' ich nicht verstanden? Seh ich genauso. Wenn du uns noch über deine MCU aufklärst, kann mans dir sogar genau sagen.
Gast
#5088104
Woran mache ich das fest?
>`m_data' overflowed by 4660 bytes
Wenn er eine Sektion in den Ram schreiben würde, dann wären das 4000
bytes weniger.
Habe nun die Lösung gefunden: Man muss die Sektion im Linkerfile
definieren, und zwar mir (siehe unten). Dann kann man über .SecRam
darauf zugreifen.
.SecRam :
{
*(.myvars*);
} > m_data_2
Danke an alle für den Support.
Gast
#5088106
Das ganze ist der Freescale MKE14F. Angeblich würde man einen HardFault bekommen wenn der DMA an der grenze Ankommen würde. Eine Lösung wäre eine Variable an die Grenze zu legen. Z.B. uint8_t blocker=1; Aber wie sage ich Gcc dass er das an diese Adresse 0x20...0 legen muss?
Wenn du 2 RAM-Bereiche hast dann brauchst du möglicherweise auch einen extra Start-Up Code, der die beiden Bereiche initialisiert.
Michael H. schrieb: > Angeblich würde man einen HardFault bekommen wenn der DMA an der grenze > Ankommen würde Dann gehört das m.E. wohl eher nicht ins Linker-Script, sondern in die DMA-Initialisierung. Wenn ein DMA-Transfer die Grenze überschreiten würde, mußt Du ihn eben in zwei Transfers aufteilen.
Rufus Τ. F. schrieb: > Michael H. schrieb: >> m_data (RW) : ORIGIN = 0x1FFFC000, LENGTH = 0x00004000 >> m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00004000 > > Da beide RAM-Bereiche aufeinanderfolgen - müssen die denn > unterschiedlich sein? > > Das Leben dürftest Du Dir einfacher machen mit > >> m_data (RW) : ORIGIN = 0x1FFFC000, LENGTH = 0x00008000 > > > Oder was hab' ich nicht verstanden? Kommt auf die Anwendung an. Einige Cortexe teilen das RAM bei 0x20000000. Und je nach Anwendung kann das erhebliche Einflüsse auf die gesamtperformance haben wo man welche Dinge anlegt.