C'è uno svantaggio nell'assegnare un'enorme quantità di stack per un singolo array in un sistema embedded?

The only thing I'm conscious is that I have to make sure I actually have 1KB of stack free when entering this function.

Sì, e questo è un strong vincolo. Sarà meglio accertarsi staticamente di quanto tu abbia uno spazio così grande disponibile in pila. Se il codice è piccolo, se stai utilizzando un GCC recente per compilare il tuo codice, consulta questo .

A proposito, alcuni microprocessori economici potrebbero utilizzare un frame di chiamata "grande" più costoso di uno "normale" (ad esempio perché il loro set di istruzioni favorirebbe un offset di un byte dal puntatore dello stack). YMMV.

Inoltre, se stai codificando in C e se ritieni che il tuo array di grandi dimensioni possa avere il suo spazio riutilizzato per altri scopi, potresti considerare di farlo diventare membro del sindacato (con una variabile globale di% tipounion). Sì, è abbastanza brutto.

In alternativa, potresti prendere in considerazione la codifica di un allocatore di heap primitivo adatto alla tua applicazione (e potrebbe avere un'API diversa da malloc e free ....).

Le persone tendono ad essere prudenti con un grande stack, perché cresce all'indietro nella RAM e sovrascrive i valori delle variabili, portando a comportamenti inspiegabili. Diventa ancora peggio, perché è necessario conoscere l'indirizzo del puntatore dello stack più basso possibile e sottrarre la dimensione da allocare quando si immette la routine.

Questo è tutto un lavoro per la gestione della memoria hardware (dovrebbe generare trap o errori quando si verifica un overflow dello stack) o per il compilatore, dato che ha caratteristiche per questo tipo di analisi.

Altrimenti, puoi fare ciò che vuoi con la tua RAM.

Come le risposte precedenti hanno sottolineato, vorrei anche prima raccomandare di lasciare l'array statico se si adatta alla memoria. Nella maggior parte dei casi, è molto più importante avere un'impronta di memoria deterministica, anche se ciò significa che "rifiuti" la memoria per le variabili non utilizzate tutto il tempo. Mettere array di grandi dimensioni sul tuo stack lo farà fin troppo facilmente, e lo stack overflow tende a causare problemi difficili da trovare e difficili da riprodurre (se non puoi usare MMU per proteggere lo stack).

Il suggerimento di condividere il blocco con altri dati con unione è IMO valido, sebbene possa anche essere fonte di problemi difficili da trovare, se si individuano variabili errate in esso.

Se si sta esaurendo la memoria e si ha disperatamente bisogno di rendere le variabili di vita più breve per condividerla, prima di spostare la matrice in pila, vorrei prendere in considerazione l'aggiunta di allocazione dinamica della memoria, anche se ha i suoi svantaggi. In questo caso potrebbe non essere una risposta, in quanto l'array sembra abbastanza grande rispetto alla memoria disponibile.

Hai un'altra opzione se hai qualche tipo di memoria flash. Puoi scambiare la velocità di accesso per ram memorizzando i tuoi dati in flash e leggendo & cercando lì. Dovresti solo caricare un record alla volta nella ram. Sarà leggermente più complicato se è necessario essere in grado di aggiornare i record. Avrai bisogno di un meccanismo segmentato di usura. Ho fatto questo in passato e incluso un indice per accelerare l'accesso.

Soprattutto quando si lavora con sistemi embedded, si vuole che gran parte dei possibili errori si verifichino in fase di compilazione e niente mai fallisca in fase di esecuzione (sarebbe bello se potessimo ottenere ciò, anche se ...) .

Creare array di grandi dimensioni che potresti avere bisogno in stati arbitrari del tuo programma assegnato staticamente fa esattamente questo - Il linker ti avvertirà alla fine "questo non si adatta alla RAM", mentre l'allocazione dello stack semplicemente renderebbe il tuo programma in crash con - overflow di stack di debug.