STM32F10x_StdPeriph_Lib

[SvenW]

Har just börjat labba med STM32, och använder biblioteket STM32F10x_StdPeriph_Lib_V3.3.0
Så vitt jag kan se finns det ett par problem:

1:
Man skulle vilja ha en manual med exempel som visar hur biblioteket används.
Finns det en bra sådan?
-- Vill dock icke se någon microsoftifierad wizard som visar bilder på hur man kryssar i rutor !!!

2:
Biblioteket tar rätt stora minnesresurser i STM32-processorn. Ca 10 Kbyte för bara tre periferifunktioner!
I de fall konfigurationen är känd vid kompileringen borde det gå att göra
initieringen av processorns register betydligt mer resurssnålt.

Finns det något bra alternativ till STM32F10x_StdPeriph_Lib, eller går det att
konfigurera detta på något sätt så att mer av jobbet görs vid
kompileringstillfället? Knep?

Ett alternativ är att ställa registren med hemsnickrad kod,
men detta kräver en hel del av en annan knapp resurs, nämligen egen tid och förmåga.
Hur gör ni?

[Micke_s]

1: STM32F10x_StdPeriph_Lib_V3.4.0 har i alla fall en windows hjälpfil i sig.

2: Ta en större processor med mer minne, alla funktioner blir ju inte länkade.

[Carmis]

1: Om du kollar i kodfilerna finns även bra kommentarer för att förstå hur biblioteket fungerar.

2: Du har säkert redan gjort det. Men se till att du bara länkar de filer du behöver i biblioteket.

[SvenW]

Tack för svaren!

Att använda större processor känns bara inte som en helt elegant metod!

Det står mycket riktigt en del i kommentarerna. Det tar väl bara lite tid att vänja sig vid terminologin.

Det ser ut som det länkas till en hel del rutiner som nog inte behövs.
Om jag använder en timer så inkluderas alla rutiner som finns i filen stm32f10x_tim.o.
Hur får man bort de onödiga? (Använder gnu toolchain från CodeSourcery)

[Micke_s]

den borde bara ta det som används. i ride7 så visas det i IDE:n för varje fil vad allt kommer ta. Sedan när man har kört hela projektet så länkas bara det som behövs in. Kanske är en inställning på projektet...

[SvenW]

Ja, det borde gå.
I gnu toolchain så handlar det om vilka flaggor man sätter i Makefilen.
Men jag misstänker att det kanske behövs något mer, ett alternativt sätt att bygga biblioteket.
Jag vet bara inte riktigt hur

[sodjan]

Utan att veta exakt hur just denna utvecklingsmiljö fungerar...

Är det inte ofta så att om man länkar in *objekt* filer i ett projekt så
är det vanligast att hela den aktuella objektfilen kommer med. Om man
länkar mot en "lib" (en fil med flera objektmoduler) så kan länkaren
plocka de objektmoduler (som var för sig i princip är separata objektfiler)
som används. Problemet är bl.a att om man har en objektfil som kommer
från *en* källkodsfil så behövs det inga speciella symboltabeller för anrop
mellan funktioner inom samma objektfil. Dessa symboltabeller används
normalt för "symbol resolution" under själva länkningen av länkaren för
att veta vad som ska med eller inte.

Så min gissning är att om man länkar in en .o fil som länkas hela
filen in. Alternativet är att ha separata .o filer för varje funktion
(t.ex som en .lib) där länkaren kan "välja och vraka" bland modulerna.

men som sagt, det behöver ju inte stämma in på alla miljöer, speciellt
om man har en miljö där alla källkodsfiler och .o filer normalt kommer
från ett och samma "språk".

[SvenW]

Jo!
Jag tror det är precis som du (Sodjan) säger.
Jag vet bara inte hur jag får till den varianten, att bygga ett 'riktigt' bibliotek, där länkaren kan välja och vraka.

[sodjan]

Problemet är ju att om du inte har tillgång till källkoderna så kan du inte
bygga nya (och mindre) objektfiler. Att enbart lägga ihop de befintliga
objektfilerna till en LIB har mest praktiska fördelar (färre filer att hålla
reda på och enklare/kortare kommandon för att länka) men efter länkning
så borde slutresultatet bli det samma. Det har alltså ingen igentlig
betydelse om en viss objektmodul kommer från en LIB eller om den
kommer från en egen fil, det ger samma resultat och har samma funktion.

Om resonemanget stämmer så måste objektfilerna byggas om från grunden.
Det blir mer jobb för länkaren men sannolikt bättre "granularitet" i slutresultatet.

Fortfarande dock förutsatt att mitt resonemang "håller"...

[SvenW]

Jo, jag har tillgång till källkoden. C-kod. Så det skall nog i princip gå att göra det på elegant sätt. Men hur ???
Men, annars kan jag ju alltid klippa och klistra i källkoden, men det är att göra det svårt för sig, misstänker jag!

[Micke_s]

kompilatorn ska ha "-ffunction-sections", lägger varje funktion i en egen sektion.
linkern ska ha "--gc-sections" till sig, skräpsamlaren för sektioner, tar bort oanvända sektioner...

Jag brukar kasta in källkodsfilerna istället för använda biblotek.
http://elinux.org/Function_sections

[SvenW]

Det kanske kunde vara något att prova. Jag skall försöka läsa på lite om detta.
Dock orkar jag inte just denna kväll, men tack för tipset

[sodjan]

från http://gcc.gnu.org/ml/libstdc++/2000-06/msg00081.html :

`-ffunction-sections'
`-fdata-sections'
Place each function or data item into its own section in the output
file if the target supports arbitrary sections. The name of the
function or the name of the data item determines the section's name
in the output file.

Use these options on systems where the linker can perform optimizations
to improve locality of reference in the instruction space.

Ja ja, det är nog lite jobb att "go this route"...

Kolla också (sök) efter "Selective Function Compile" i
https://my.st.com/public/STe2ecommuniti ... fault.aspx
Första träffen stämmer bra in på din fråga...

[SvenW]

Jaha. Där ser man! Man är sällan först med ett problem!
Fantastiskt att allt går att hitta på nätet! Morgondagen är räddad.
Men just nu håller ögonen på att falla ihop.
Tack allihop för en lärorik ikväll

[SvenW]

Har nu, dagen efter, provat de där flaggorna.
Programmet (main.elf) reducerades från ca 8 Kbyte till 2 Kbyte.
En väsentlig skillnad!
Er hjälp besparade mig mycken tid. Samt 6Kbyte