La calloc la vedo piuttosto necessaria, se no come dici tu torno al C, e cosi perderei la dinamicità dell'array.
Volendo puoi anche fare una classe che si limita a fornire un'interfaccia ma non crea niente al suo interno. Dichiari l'array del buffer all'esterno globale così lo usi all'interno della classe evitandoti la calloc().
Per interfaccia intendi una classe a cui si possa passare una matrice e questa fornisca i metodi per gestirla? scusa ma derivo dal C# dove il significato di interfaccia è tutta un altra cosa.
Si potrebbe essere una buona idea 
Mi dispiace però rinunciare all'heap sugli AVR, non ho ancora capito bene come mai l'heap va a pesare cosi tanto rispetto allo stack, mi potresti illuminare yoshi, mi faresti un enorme favore.
Grazie
PS ho modificato il codice della coda per riadattarlo per bene alla funzione di buffer migliorando il codice, ora lo aggiorno
L'allocazione dinamica della memoria sui microcontrollori è sconsigliata perché ti rende l'eseguibile più grosso e quindi in grossi progetti hai meno linee di codice disponibili ma soprattutto perché ti fa perdere il controllo della ram occupata se non gestita bene. Se hai un programma che alloca dinamicamente oggetti potrebbe succedere per una tua svista l'heap cresca troppo andando a collidere contro lo stack. La differenza tra stack ed heap è che il primo ha un'implementazione hardware cioè ha un registro che contiene gli indirizzi di ritorno delle chiamate a subroutine mentre heap no.
Tutto ciò ovviamente è condizionato da come il compilatore gestisce le risorse, lo stack ad esempio può essere implementato via software andando quindi in ram e causando possibili collisioni con l'heap.
Tutto ciò ovviamente non ti vieta di usare malloc,new ecc. se vuoi e se il compilatore lo consente solo che in futuro potrebbe essere necessario passare a qualche trucco statico per evitare problemi o salvare un po' di spazio quindi chi ben comincia è già a metà dell'opera.
P.S. A differenza del C# il C++ non è completamente a classi quindi non devi necessariamente creare una classe per qualsiasi cosa (infatti il main è una funzione e non un metodo).
P.P.S. Con interfaccia intendo l'insieme di metodi pubblici che ha una classe. Il solo file header definisce un'interfaccia.
Se parliamo di Atmel, lo stack è gestito tutto in RAM, come l'heap. Non ha una implementazione hardware.
Quando serve, il codice vi riversa il contenuto dei registri e da lì dentro li recupera. Sta all'utente rispettare la struttura LIFO dello stack per cui se metti nello stack A,B,C devi poi tirar fuori C,B,A, pena l'incasinamento di tutto. Il salvataggio e recupero del PC, Program Counter, cioè l'indirizzo della prossima istruzione che deve essere useguita dalla CPU, viene invece gestitoin automatico dal compilatore.
Quello che dice Yoshi è vero, cioè che con l'allocazione dinamica della memoria si rischia una bella collisione fra heap e stack: l'heap è posto dopo lo spazio riservato alle variabili statiche inizializzate ed a quelle non inizializzate e cresce verso l'alto mentre lo stack è posto a partire dall'ultima locazione della RAM e cresce verso il basso. Se non si sta attenti, si rischia che l'heap o lo stack o entrambi crescano più del previsto e si accavallino con risultati disastrosi per il codice.
Ok ok ho capito, quindi non ho vere e proprie limitazioni, semplicemente devo scendere a compromessi per una questione di spazio, ok questa è una buona notizia.
Ti ho chiesto dell'interfaccia, perché dal tuo post sembrava che intendessi per il temine interfaccia una classe completa che avesse l'unica differenza di non allocare variabili dinamiche al suo interno.
Non mi sento obbligato ad usare classi in C++ ma ho scelto di spostarmi ad esso, dal C puro, esclusivamente per avere il supporto di queste, come dicevi tu rende il codice più di classe 
anche se la classe da quello che sto capendo sui microcontrollori perde MOLTA importanza.
Edit: Ma il micro non rileva queste "collisioni"?
No, non le rileva. E' una gestione lasciata completamente all'utente.
Ecco perché si sconsiglia sempre di fare allocazione dinamica sulle MCU, sia per il sovraccarico sul codice che il compilatore e/o il programmatore deve inserire per gestire questa cosa sia per i ristretti quantitativi di RAM che possono portare a incidenti di questo tipo.
leo72:
Se parliamo di Atmel, lo stack è gestito tutto in RAM, come l'heap. Non ha una implementazione hardware.
@leo72
Niente stack hardware per atmel? Grazie dell'informazione :).
Sì, le classi se ci sono le usi per lo più come layout del codice e non per molto altro, ovviamente parlo sempre di MCU ad 8/16 bit.
yoshi93:
@leo72
Niente stack hardware per atmel? Grazie dell'informazione :).
Per lo meno per gli AVR8.
Tant'è che ad esempio l'Atmega2560, che è uno di quei pochi chip Atmel che può gestire anche RAM esterna, può spostare lo stack sulla memoria addizionale.
leo72:
Tant'è che ad esempio l'Atmega2560, che è uno di quei pochi chip Atmel che può gestire anche RAM esterna, può spostare lo stack sulla memoria addizionale.
Questa funzionalità c'è sui pic18 in poi, in aggiunta allo stack hardware se si devono gestire solo le chiamate assembly a subroutines.
@RobertoBochet:
Scusa se ti ho un po' spammato il thread, giuro che smetto 
:).
Figurati, "qui ci si è fatta una cultura" Io intanto sto continuando con il mio progetto, per il momento sto adoperando l'heap ma ho gia in programma una seconda versione esclusivamente a stack