LPCxpresso+11U68: Jako poznat konec obsazene flash?

Pavel Hudecek edizon na seznam.cz
Neděle Srpen 14 00:14:40 CEST 2016


Díky za nakopnutí správným směrem, nějak mi to nedošlo:-)

Tak teď už jen linker hlásí, že nezná _sdata.

Ale když jsem koukal do .map, tak to vypadá, že správně je asi samotný 
_etext. Po něm jsou už jen věci s adresami od 0x10000000 a 0x20000000 a 
_edata je na 0x10000148.

Ale skutečně nevím, čím bych si pomohl, kdybych zvolil pevné místo pro ty 
data. Mě to přijde jen jako komplikace: Když zvolím malou velikost, můžu 
narazit na to, se se mi tam nevejdou, v horším případě na to narazí zákazník 
až se rozhodne např. přidat další jazyk. Když zvolím moc, zas se může stát, 
že to budu muset občas měnit, když bude program moc velký.

Řešení s _etext je bezúdržbové. A kdyby se ukázalo, že to je nějaké 
složitější, tak mě nakonec napadlo, že bude nejjednodušší, když se to uloží 
na adresu __top_Flash - velikostDat a pro jistotu se podívá, jestli tam jsou 
všude FF a zahlásí error, když ne:-).

PH

-----Původní zpráva----- 
From: konfera na efton.sk
Kompilator samozrejme nema ziadny magicky sposob ako uhadnut nazvy symbolov, 
ktore su definovane linkerom (t.j. v case az po kompilacii). Musite ich v C 
zdrojovom texte deklarovat ako externe smerniky. Je to zdokumentovane v 
dokumentacii k linkeru.

Linker skript moze pokojne byt sucastou projektu, t.j. Jeho modifikacie su 
prenosne na ine projekty. Nevidim ani nejaky zasadny problem v tom 
modifikovat "defaultny" linker skript. Aj tak sa jedna o postup 
neprenositelny medzi prekladacmi, a ani tie symboly nie su nijako normovane 
(co znamena aj to, ze ja osobne by som si ich pred  pouzitim preveril, ako 
presne su v danom "defaultnom" linker skripte pouzite.

Ten Vas argument mimochodom nijako nediskvalifikuje umiestnenie tych pevnych 
dat na pevnej adrese podla navrhu pana kolegu Stengla.


-----Original Message-----
From:  "Pavel Hudecek" <edizon na seznam.cz>
Dkuji všem za námty, nejvíc by se mi líbil ten první:
_etext + (_edata - _sdata)

Ale kompiler všechny 3 vci hlásí jako undeclared.
Jinak by to bylo super.

Pevn definovaná oblast se mi nelíbí, protože pokud by tam nkdy pišel
procesor s vtší flashkou, bude to kvli poteb vtšího místa pro ty
externí data.

Tak te ješt jak rozchodit tu první variantu, pokud možno v programu (bez
úprav linker skriptu), aby se to dalo teba dát do knihovny pro snadné
použití v jiných projektech.

PH

-----Pvodní zpráva----- 
From: konfera na efton.sk

Ano, pan Kolega Stengl ma, ako obvykle, pravdu...

> Linker script pro GCC umí díru v sekci .text?

Myslite, ci to vie linker. Nie, nevie. Ale bolo to spomenute ako plan B pre
buducnost, ktora nemusi byt pravdepodobna. Vyzadovalo by si to teda rucne
oznacovat funkcie, ktore maju ist do "vysokej pamate".

Ale su aj ine riesenia, podla situacie, napriklad do "vysokej pamate"
prehodit spomenute inicializatotry, pripadne nejake rozsiahle konstantne
data.

> To by bylo bezva.

To hej. Uz aj ja som to potreboval.

No ale ten linker je open source, takze sup sup... ;-)

wek


-----Original Message-----

Linker script pro GCC umí díru v sekci .text?
To by bylo bezva.

Díky za info.
PL

**************************

Dne 13.8.2016 v 20:41 Josef ©tengl napsal(a):
> kdy¾ bude vìt¹í FLASH za nìjaký èas, tak se tento blok prostì pøeskoèí. 



Další informace o konferenci Hw-list