Domanda

Sto cercando di programmare ARM usando Eclipse + CDT + yagarto (gnu toolchain) + OpenOCD. In diversi progetti di esempio (dal sito di yagarto ad esempio) ho trovato script di linker (* .ld) in cui sono state specificate molte informazioni di collegamento (insieme alle definizioni delle sezioni). In realtà non ho mai affrontato questi file prima (IAR non ne ha bisogno) e li trovo un po 'difficili da capire a prima vista. Quindi la mia domanda è: posso usare un singolo file di script per il mio processore di destinazione (STR710FZ2T6) con tutti i miei progetti o devo familiarizzare con la scrittura di questi script e scriverli per ogni progetto. Se posso utilizzare un singolo file per tutti i progetti per un determinato processore di destinazione, può darmi dei consigli su dove trovarlo così universale.

È stato utile?

Soluzione

Suppongo che ogni terza persona abbia uno script o una soluzione diversa. Ci sono una serie di problemi che devono essere risolti, diversi linker risolveranno questi in modi diversi. Penso che GNU abbia reso troppo difficile se non la magia nera.

Per un sistema incorporato spesso si avrà un flash o eeprom o qualche altra forma di memoria di sola lettura per l'avvio. Come altri processori, ARM ha una tabella vettoriale per dirlo essenzialmente dove si trova il codice di reset e interrompere, ecc. Quindi quella tabella deve trovarsi in un posto specifico e devi dire al linker di metterlo in quel posto specifico (prima) .

Uno degli script che mi piace usare è:

MEMORY
{
    bob (RX) : ORIGIN = 0x0000000, LENGTH = 32K
    joe (WAIL) : ORIGIN = 0x2000000, LENGTH = 256K
}

SECTIONS
{
    JANE : { startup.o } >bob
}

Di solito uso ram e rom come nomi invece di bob e joe ma dimostrando qui che non importa quali siano i nomi sono solo etichette.

Un'altra variazione sul tema:

MEMORY
{
    rom(RX)   : ORIGIN = 0x00000000, LENGTH = 0x8000
    ram(WAIL) : ORIGIN = 0x20000000, LENGTH = 0x2000
}

SECTIONS
{
    .text : { *(.text*) } > rom
}

Il primo ti permette di mettere i file sulla riga di comando del linker in qualsiasi ordine ma devi avere la tabella vettoriale nel file startup.o. Quest'ultimo ti consente di usare qualunque nome di file ma il primo file sullo script del linker deve avere la tabella vettoriale.

arm-thumb-elf-gcc -Wall $(COPS) vectors.o putget.o blinker2.c -T memmap -o blinker2.elf

O direttamente con ld

arm-thumb-elf-ld vectors.o putget.o blinker2.o -T memmap -o blinker2.elf

L'RX dice al linker di mettere in lettura ed eseguire cose in quella sezione di memoria e il WAIL è praticamente tutto il resto. Se ad esempio hai un solo ariete, puoi mettere tutte le bandiere RXWAIL sulla linea che indica dove si trova la ariete. A seconda del caricatore in quel caso, puoi fare affidamento sul file elf che dice al caricatore da dove iniziare la ramificazione o puoi semplicemente rendere il punto di ingresso l'inizio del binario e il caricatore può essere più semplice. I bracci (non la corteccia-m3) hanno un'istruzione di ramo come primo vettore per il vettore di ripristino, quindi puoi semplicemente fingere di costruire una tabella di vettori comunque per una soluzione di ram e funzionerà.

Ci sono una serie di problemi con questa soluzione che non mi danno fastidio. Inizializzo le variabili nel mio codice, non durante la dichiarazione.

Questo

int rx;

int main ( void )
{
  rx = 7;

anziché

int rx=7;

int main ( void )
{

Inoltre non presumo mai che una variabile sia zero all'avvio del codice, lo inizializzo sempre su qualcosa prima di iniziare. Il tuo codice di avvio più lo script del linker in team possono lavorare insieme per rendere più semplice l'automazione del ripristino del codice bss e la copia dei dati di inizializzazione diversi da rom alla RAM all'avvio. (that int rx = 7; sopra richiede del codice che copia il valore 7 da qualche parte nella rom e lo scrive nella posizione di memoria in ram allocata per la variabile rx in modo che quando main () inizia il 7 è lì.

Il mio codice di avvio è anche abbastanza semplice come risultato di questo metodo:

.globl _start
_start:
    b reset
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang
    b hang

hang : b hang

reset:
    ldr sp,=0x10004000
    bl main
    b hang

Vedrai o leggerai le soluzioni che consentono al codice di avvio e allo script del linker di lavorare insieme per non dover codificare in modo rigido puntatori, spazio di archiviazione, cose del genere, ancora una volta puoi mettere molto lavoro in avvio complicato script di codice e linker per ottenere un po 'di automazione e forse salvare un po' di lavoro, forse no. L'automazione, se / quando funziona, può e ridurrà l'errore umano e questo può essere una buona cosa, anche se stai cambiando spesso chip o stai cercando di scrivere un bit di codice che funziona in una famiglia di chip, potresti volere anche questa automazione .

La mia linea di fondo è SÌ, puoi vivere con un solo script linker per tutto il tuo lavoro ARM. Ma devi adattare il tuo lavoro a quello script. Probabilmente non troverai uno script che funzioni con il codice di esempio di tutti. Più complicata è la sceneggiatura, più difficile sarà prendere in prestito. Sì, i miei script sopra possono probabilmente essere eseguiti sulla riga di comando di ld, ma molto tempo fa (gcc 2.95) non riuscivo a farlo funzionare, quindi ho sviluppato lo script minimo sopra e li ho usati da allora. Ho dovuto modificare il secondo script per qualche motivo, ma con 4.x.x, sicuramente 4.4.x sono in grado di utilizzare uno dei due.

Altri suggerimenti

Non esiste uno script di linker universale. Questi script sono molto importanti, poiché definiscono la posizione in memoria (RAM o ROM) in cui verranno posizionate le varie sezioni di dati e programmi. C'è qualcosa di equivalente nei compilatori IAR (file xcl se ricordo bene). Ovviamente hai usato solo quelli predefiniti fino ad ora.

C'è un bel documento su STR7xx chiamato " Utilizzo degli strumenti open source per STR7xx Cross Sviluppo " ;. Puoi trovare un link nella homepage di yagarto. Ti consiglio di dare un'occhiata e provare a capire come funzionano i file linker. Esistono anche altri file di configurazione di cui devi avere una certa comprensione.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top