Un microcontrollore grande o molti microcontrollori piccoli?

Sono abituato a fare cose semplici e dirette con i microcontrollori, relativamente parlando. Cose come guidare i LED, far funzionare i motori, le routine di base, le GUI sugli LCD dei caratteri e così via, ma sempre solo un compito chiave con al massimo alcune piccole attività secondarie. Questo mi ha relegato in prodotti di fascia bassa poiché è davvero tutto ciò che serve in quei casi.

Vorrei iniziare a progettare cose più complesse, ma il lato superiore del continuum del microcontrollore non è qualcosa a cui sono stato ben esposto. Quindi, ho avuto un momento molto impegnativo cercando di scegliere un microcontrollore in cui farò un sacco di compiti contemporaneamente - non posso dire solo con un numero MIPS e una piedinatura soddisfacente se ha abbastanza potenza per fare quello che voglio fare.

Ad esempio, vorrei controllare 2 motori BLDC con routine PI, insieme ad alcune comunicazioni seriali e USB, una GUI e una serie di altre attività. Sono tentato di avere solo un microcontrollore per ciascun motore e poi uno per le varie attività, in modo da poter garantire che il sovraccarico delle varie cose non comprometta il funzionamento critico del motore. Ma non so se sia davvero una buona idea o un modo ingenuo di occuparsi delle cose.

Immagino che la mia domanda sia davvero doppia:

1. L'approccio all-in-one è una buona idea quando si deve fare molto multitasking o è meglio segmentare e isolare, e

2. Come posso scoprire intuitivamente se il microcontrollore che sto guardando ha abbastanza potenza di calcolo per fare ciò di cui ho bisogno in base al mio elenco di attività?

Sto osservando i dsPIC33 moderati fino ai SoC ARM che eseguono RTOS. Un modo sistematico per affinare ciò di cui ho bisogno mi aiuterebbe molto.

Le risposte alle tue domande sono diverse a seconda del tuo obiettivo finale. Se hai bisogno di una manciata o meno di questi dispositivi, dovresti rendere lo sviluppo più semplice e non preoccuparti del costo delle parti. Se hai intenzione di realizzarne mille o più, vale la pena analizzare le tue esigenze e ridurre i costi dell'hardware del dispositivo.

Piccole quantità

Se stai eseguendo una singola o piccola serie di questi dispositivi, i tuoi sforzi di sviluppo sommergeranno i costi per articolo e dovresti concentrarti su ciò che sarà più facile / veloce da sviluppare, piuttosto che sul costo / dimensione del microelettronico.

In generale, l'incapsulamento può ridurre la complessità, aumentando la produttività. Se hai alcuni requisiti in tempo reale difficili, come il controllo BLDC, i loop PID, ecc., Potresti trovare più velocemente l'uso di controller separati specificamente per quelle attività che comunicano con i controller in cui mantieni l'interfaccia utente e altri non-real- compiti a tempo.

Quindi, in questo caso, la risposta alle tue domande è:

L'approccio all-in-one è una buona idea quando si deve fare molto multitasking o è meglio segmentare e isolare, e

La scala punta leggermente verso la segmentazione e l'isolamento. Il motivo principale è che il debug di un sistema in tempo reale può richiedere molto tempo e mantenere tali attività sul proprio processore limita le variabili che devi misurare o controllare quando cerchi di scoprire perché qualcosa non funziona correttamente.

Come posso scoprire intuitivamente se il microcontrollore che sto guardando ha abbastanza potenza di calcolo per fare ciò di cui ho bisogno in base al mio elenco di attività?

In questo caso la differenza di costo tra un processore a 32 bit con molte risorse e un processore a 8 bit con risorse limitate è piccola rispetto alla quantità di tempo che trascorrerai lavorando allo sviluppo. Ci sono pochi motivi per provare a capire quanta potenza hai bisogno: basta ottenere il processore più grande che ritieni di poter sviluppare e utilizzarlo. Se in un secondo momento è necessario ottimizzare i costi di progettazione, è relativamente facile misurare l'utilizzo effettivo delle risorse del processore, quindi scegliere un processore minore in grado di gestire il carico effettivo. Fino ad allora, usa il più grande e non preoccuparti di trovare la "soluzione migliore".

Produzione di massa

Se prevedi di realizzare molti di questi dispositivi, un'attenta analisi comporterà un notevole risparmio sui costi. In generale, un microcontrollore più grande costerà meno di due microcontrollori in grado di sostituire il singolo microcontrollore, anche se ci sono certamente delle eccezioni a seconda delle attività specifiche richieste. A queste quantità, il costo dell'hardware sarà probabilmente molto più grande del costo di sviluppo, quindi dovresti aspettarti di dedicare più tempo all'analisi dei tuoi requisiti e allo sviluppo di quanto faresti se ne facessi solo alcuni.

L'approccio all-in-one è una buona idea quando si deve fare molto multitasking o è meglio segmentare e isolare?

L'approccio all-in-one sarà generalmente meno costoso durante la vita dell'intero progetto rispetto a più processori. Richiederà più tempo per lo sviluppo e il debug per assicurarsi che le varie attività non siano in conflitto, ma una progettazione rigorosa del software limiterà quasi quanto farebbe un hardware separato.

Come posso scoprire intuitivamente se il microcontrollore che sto guardando ha abbastanza potenza di calcolo per fare ciò di cui ho bisogno in base al mio elenco di attività?

Dovrai comprendere le attività che desideri eseguire e quante risorse prendono. Supponiamo che quanto segue fosse vero:

Le routine BLDC PI consumano X cicli di tempo del processore 100 volte al secondo e ciascuno richiede circa 50 byte di RAM per il funzionamento, 16 byte di EEPROM per l'ottimizzazione e 1k di flash per il codice. Ciascuno avrà bisogno di 3 periferiche PWM a sedici bit nel microcontrollore. Potrebbe essere necessario specificare il jitter, che avrà requisiti di latenza di interrupt specifici.

Le routine USB e seriali consumeranno Y cicli di tempo del processore in base alle necessità, 2k RAM, 64 byte EEPROM e 8k flash. Richiede USB e periferiche seriali.

La tua GUI consumerà Z cicli di potenza del processore 30 volte al secondo e avrà bisogno di 2k di RAM, 128 byte di EEPROM e 10k di flash. Utilizzerà 19 I / O per comunicazioni con LCD, pulsanti, manopole, ecc.

Al primo avvio, potrebbe essere difficile capire cosa siano effettivamente X, Y, Z e questo cambierà un po 'a seconda dell'architettura del processore. Tuttavia, dovresti essere in grado di capire, all'interno di una stima del ballpark, la quantità di ram, eeprom e flash di cui il tuo design avrà bisogno e di quali periferiche hai bisogno. Puoi scegliere una famiglia di processori che soddisfi i tuoi requisiti di memoria e periferiche e abbia una vasta gamma di opzioni di prestazioni all'interno di quella famiglia. A quel punto, per lo sviluppo, puoi semplicemente utilizzare il processore più potente della famiglia. Dopo aver implementato il tuo design, puoi facilmente spostare la famiglia in termini di potenza a un'opzione a basso costo senza modificare l'ambiente di progettazione o sviluppo.

Dopo aver fatto abbastanza di questi disegni, sarai in grado di stimare meglio X, Y e Z. Saprai che le routine BLDC PI, anche se eseguite spesso, sono piuttosto piccole e richiedono pochissimi cicli. Le routine USB e seriali richiedono molto ciclo, ma si verificano raramente. L'interfaccia utente richiede alcuni cicli frequentemente per trovare le modifiche, ma richiederà molti cicli raramente per aggiornare un display, ad esempio.

Vorrei separare il controllo del motore e disporre di un microcontrollore separato che include PWM (forse un PIC18) per ciascuno dei due motori BLDC, poiché il controllo PI è un compito isolato una volta avviato e una volta scritto il codice può usarlo su entrambi i micro. Puoi ricollegarli al microcontrollore principale tramite un'interfaccia come I²C e, se lo desideri, scaricare i parametri per il controllo PI da lì. Ciò ti consentirebbe di modificarli nella tua GUI.

Avrei quindi eseguito tutto il resto nel microcontrollore principale, come un PIC24 (un PIC32 è probabilmente eccessivo, in base alle attività che hai elencato). Inoltre i PIC24E più veloci possono funzionare quasi alla stessa velocità di un PIC32.

Quando scelgo un microcontrollore, per prima cosa valuto la quantità di flash e RAM di cui ho bisogno, quindi guardo la lunghezza della parola e la velocità del processore. Per i successivi, spesso il requisito più difficile da soddisfare è l'interrupt più veloce che ci si aspetta di gestire. Se stai producendo un suono a 16 KHz, ad esempio, e hai un interrupt ogni 62,5 µs, allora è meglio avere un microcontrollore con un tempo di istruzione in decine di nanosecondi, o non sarai in grado di servirlo e ottenere qualsiasi altro lavoro fatto.

C'è un approccio semi formale che puoi usare per aiutarti a generare la tua risposta. Consiglio vivamente di leggere il capitolo 2 di "Progettazione di sistemi integrati" di White, la maggior parte dei quali è disponibile su Google Libri .

Questo capitolo parla della progettazione di architetture di sistema e offre un approccio semi-formale su come incapsulare al meglio le attività. Mentre il capitolo riguarda in gran parte un sistema di controller, si estende facilmente a più controller. Ti aiuterà a immaginare quali risorse devono essere condivise e ti aiuterà a scegliere il tuo livello di incapsulamento per ogni attività.

Offre una varietà di punti di vista da considerare, uno dei quali mostrerò di seguito, ma ci sono molte manipolazioni utili. Questo, ovviamente, non ha molto senso da solo, ma spero che ti incoraggi a dare un'occhiata al capitolo.

Per quanto riguarda "come faccio a sapere se ho un controller sufficiente", la mia preferenza è quella di mettere quanta più energia possibile nella mia sandbox di progettazione, e quindi capire quante risorse posso ridurre una volta che il design è in buone condizioni modo. La differenza di prezzo tra un microcontrollore da $ 10 e un microcontrollore da $ 3 per scopi di prototipazione potrebbe essere solo settimane di ritocco e di rotazione dei pollici in attesa di nuove parti, mentre il design può sempre continuare a muoversi se hai abbastanza potenza.

Lavoro su un sistema che è ampiamente quello che stai descrivendo: motori, IO, display, 3x UART + SPI + I2C in esecuzione su un Coldfire 52259 (midrange 32-bit ~ 80MHz micro) e non è troppo difficile, anche se ottenere l'architettura del software è importante: abbiamo molte cose in esecuzione su hardware e interrupt (tutto ciò che l'hardware può gestire da solo, eseguiamo hardware e servizi con interruzioni) lasciando il ciclo main () per fare tutto il servizio di pulizia.

Personalmente non mi piace la maggior parte dei RTOS che ho visto, nella parte bassa gonfiano un progetto, aggiungono un'altra cosa da imparare e otterrai prestazioni migliori dall'hardware facendo le cose direttamente (usando le funzioni hardware disponibili + interrupt) piuttosto che fingere con il software.

Di fascia alta, in questi giorni sembra esserci un così piccolo margine tra un MCU che è abbastanza complesso e abbastanza potente da beneficiare davvero di un RTOS e qualcosa (SoC) che esegue appena Linux incorporato.

Tuttavia, in quel caso direi che c'è un certo valore nell'uso di piccoli microprocessori economici per gestire le funzioni critiche (controllo del motore EG dove il tempismo o l'arresto a un limite è fondamentale) sotto il comando della CPU "cervello" principale, quindi non ti affidi su un sistema operativo "non in tempo reale" per fare qualcosa in modo tempestivo.

La risposta di tutti gli altri è migliore, ma devo aggiungere un po 'che può essere utile. Questo potrebbe essere un po 'fuori dal segno e mi piacerebbe aggiungerlo come commento, ma c'è una regola da 50 rep :(

La risposta breve dipende, vedi sopra ma perché non pensare anche ai vantaggi del processore.

Perché non pensare ai vantaggi di processori più piccoli. Dopo tutto, questa è una domanda sui processori. Per compiti matematici e determinati non iterativi, più processori possono produrre una spinta logaritmica. La regola di Amdahl afferma che è possibile ottenere un impulso$\frac{1}{((1-p)+\frac{p}{s})}$ma questo arriva. P è la percentuale di calcolo che può essere divisa e s è l'accelerazione (dipende dal numero di operazioni, hardware; ecc.).

Naturalmente, costo, facilità di implementazione; ecc. sono importanti e anche più importanti da considerare.

La risposta può dipendere dai dettagli di implementazione. Alcune attività sono più facili da implementare in modo pulito e robusto su microcontrollori separati. Il consumo di energia può anche essere una considerazione: in generale una singola micro gestione di più attività richiederà meno energia rispetto a più micro che gestiscono singole attività.

"Potenza" è secondario alla capacità di soddisfare i propri vincoli in tempo reale.

Se si hanno due uscite PWM ed entrambe devono passare allo stesso tempo, è necessario disporre del parallelismo necessario per poterlo fare. Se disponi di un controller PWM dedicato che si occupa del tempo esatto, funzionerà, anche con un microcontrollore piuttosto piccolo, mentre una soluzione basata su GPIO sarà enormemente complessa anche se è disponibile molta potenza di elaborazione.

Per la maggior parte dei protocolli, i moderni MCU hanno implementazioni integrate di quelle parti del protocollo che hanno vincoli in tempo reale, quindi se riesci a trovare un MCU che ha le periferiche richieste e ha la velocità della CPU richiesta per gestire i flussi di dati (cioè il requisito in tempo reale degenera in un requisito soft in tempo reale del modulo "sarà in grado di leggere dal FIFO prima che sia pieno, e più veloce di quanto si riempia"), sarebbe la scelta ottimale.

Se non esiste una soluzione di questo tipo, le opzioni sono o spostare le funzioni in controller separati, utilizzando una soluzione CPU + FPGA (ad esempio FPGA con core ARM rigido) o una soluzione FPGA pura (facoltativamente con una CPU soft, a seconda dei requisiti di complessità).