Perché questo apparentemente è ok su un microcontrollore ma di solito non lo si desidera su un microprocessore?

È anche indesiderato su un microcontrollore per lo stesso motivo: spreca energia.

Ho ragione quando penso che ATmega stia effettivamente funzionando al 100%

Corretto.

e perché è così a bassa potenza da non causare problemi di calore evidenti?

Corretto. Tuttavia, se esegui il tuo microcontrollore su batteries, devi pensare seriamente a non sprecare energia. Su una piccola cpu come AtMega328P non causerà problemi di calore, ma ridurrà sicuramente la durata della batteria.

Tutte le CPU, siano esse potenti desktop o piccoli microcontrollori, utilizzano gli stessi metodi:

1- Riduci la velocità o la tensione di clock.

2- Spegni l'hardware non necessario.

3- Vai a dormire e svegliati su un evento (questo è un caso speciale di spegnimento dell'hardware non necessario, in questo caso la cpu è spenta).

In AtMega328P puoi implementare anche questo. Puoi utilizzare un clock più lento se non hai bisogno di tutta la straordinaria potenza del core a 8 bit, puoi spegnere le periferiche non necessarie ... e la più importante è la modalità sleep.

Dovresti leggere il manuale per i dettagli, poiché ci sono diverse modalità di sospensione che differiscono per latenze di riattivazione, quali periferiche rimangono online e in grado di riattivare la CPU, se i dati della RAM vengono conservati o persi, ecc. Ma fondamentalmente l'idea è: quando è in modalità sleep, la cpu viene arrestata quindi utilizza molta meno energia. Quando si verifica un interrupt, questo risveglia la CPU ed elabora l'interrupt.

Ovviamente devi usare la modalità sleep corretta e configurarla correttamente in modo che la periferica che deve riattivare la CPU (ad esempio, un timer o un interrupt GPIO) non venga spenta. Se tutto è spento, dovrai usare NMI o anche Reset per riattivarlo, in quest'ultimo caso riavviandolo.

Se tutto ciò che fa la tua applicazione è aspettare gli interrupt, come:

• Pin Change Interrupt (PCI) per rilevare la pressione di un pulsante o un segnale in arrivo

• Timer

• Dati ricevuti da UART o USB

• etc

Quindi non è necessario ruotare il ciclo principale.Dopo aver configurato tutto all'avvio, avvierai il ciclo principale con un'istruzione "vai a dormire".L'istruzione successiva verrà eseguita dopo che la CPU si sarà svegliata, elaborerà tutti gli interrupt in sospeso e tornerà al ciclo principale.Quindi il ciclo principale può, se necessario, fare qualcosa sugli eventi ricevuti, se non sono stati interamente gestiti dal codice di interruzione ... e poi tornare a dormire.

Anche se non stai utilizzando batterie, una bassa corrente di standby può alimentare l'alimentatore switching da rete per saltare i cicli e sprecare molta meno energia.

Su un microcontrollore (più specificamente, su una scheda Arduino Uno che utilizza il microcontrollore ATmega 328P) normalmente userei un loop infinito per controllare gli ingressi ecc (in Arduino land, questa è normalmente la funzione loop ()). Se lascio questa funzione vuota, tuttavia, non causa alcun problema.

Pattern di programmazione classico, con un ciclo principale ...

Su un desktop / laptop con una CPU Intel i7, ecc. se eseguissi un ciclo infinito simile (senza niente da fare o molto poco da fare), la CPU sarebbe bloccata a ~ 100% e in genere le ventole ecc. ( un ritardo potrebbe essere aggiunto per evitare ciò, ad esempio).

... potremmo scrivere diversi cicli principali.

Questo stesso loop principale sarebbe una cattiva pratica anche su un microcontrollore, perché anche quello esegue la CPU di quello a pieno carico, il che brucia energia. Non farlo, soprattutto se usi la batteria.

I moderni core della CPU hanno meccanismi di sincronizzazione. Ciò consente alle persone di implementare qualcosa come "lascia che l'esecuzione di questo ciclo dorma fino a quando non è trascorso 1 ms o finché questa condizione non è cambiata".

Questo è fondamentalmente il fulcro di qualsiasi sistema operativo multi-task - e praticamente tutti i sistemi operativi che meritano quel nome lo sono ormai. Sui microcontrollori, troverai spesso i cosiddetti RTOS (sistemi operativi in ​​tempo reale), che garantiscono quanto puoi essere sicuro che l'esecuzione di qualcosa sia iniziata dopo così tanti nanosecondi, perché è tipico del caso d'uso di microcontrollori, mentre sui desktop e sulle CPU dei server di solito si trovano sistemi operativi multiprocessing simultanei completi che offrono meno garanzie sui tempi, ma offrono un insieme molto più ampio di funzionalità e astrazione dell'ambiente hardware e software.

Non conosco l'ambiente di esecuzione di Arduino abbastanza bene da rilasciare affermazioni qualificate al riguardo, sto cercando questo mentre scrivo: Arduino non sembra progettato per questo - si aspetta davvero che tu giri alacremente. Poiché non ha funzionalità di "rendimento", la "pulizia" che esegue tra le chiamate al tuo loop non può essere chiamata quando usi la funzione delay incorporata. Uffa! Cattivo design.

Quello che faresti in un design sensibile alla potenza e / o alla latenza, useresti un RTOS per il tuo microcontrollore - FreeRTOS è piuttosto popolare, per la serie ARM Cortex-M, mbed ha molta trazione, io personalmente come ChibiOS (ma non penso che sia una buona scelta quando si passa dagli schizzi di Arduino), la Linux Foundation sta spingendo Zephyr (su cui sono in conflitto); in realtà, c'è una vasta gamma di scelte e il produttore del tuo microcontrollore di solito ne supporta uno o più tramite i loro IDE.

Perché questo apparentemente è ok su un microcontrollore ma di solito non lo si desidera su un microprocessore?

Non è proprio OK, è un modello di progettazione insolito, infatti, per i microcontrollori, che tipicamente fanno le cose a intervalli regolari o reagiscono a stimoli esterni. Non è normale che tu voglia "usare più CPU possibile" su un microcontrollore continuamente.

Ci sono eccezioni a questo modello, ed esistono sia nell'MCU che nel mondo dei processori server / desktop; quando sai di avere praticamente sempre, ad es. dati di rete da elaborare in un'appliance di commutazione, o quando sai che il tuo gioco potrebbe già precalcolare un po 'di mondo di cui potresti aver bisogno o meno in pochi istanti, troverai questi cicli di rotazione. In alcuni driver hardware, troverai "spin lock", il che significa che la CPU interroga continuamente un valore fino a quando non è cambiato (ad esempio, l'hardware ha terminato la configurazione e può essere utilizzato ora), ma generalmente è solo una soluzione di emergenza, e dovrai spiegare perché lo stai facendo quando cerchi di inserire tale codice in Linux, per esempio.

Ho ragione a pensare che l'ATmega funziona effettivamente al 100% e che, essendo così a bassa potenza, non causa problemi di calore evidenti?

Sì. L'ATMega non è, per gli standard moderni, a bassa potenza, ma è abbastanza a bassa potenza perché il calore non diventi un problema.

Ho ragione nel pensare che ATmega funziona effettivamente al 100% e che poiché è così a bassa potenza non causa alcun calore evidente problemi?

Sì, normalmente funziona sempre al 100%, ma è così a bassa potenza che non si riscalda in modo significativo.

Su un desktop / laptop con una CPU Intel i7 ecc. se ho eseguito un file simile ciclo infinito (con niente da fare, o molto poco da fare) sarebbe bloccato la CPU a ~ 100% e in generale le ventole ecc.

Più veloce è il clock di una CPU, maggiore è la potenza che assorbe, perché ogni volta che un livello logico cambia deve caricare le capacità dei transistor nei gate. Le CPU moderne sono progettate per funzionare il più velocemente possibile, in realtà più velocemente del possibile. Anche dopo aver reso i transistor più piccoli possibile, utilizzando il voltaggio più basso possibile e applicato un enorme dissipatore di calore, non riescono ancora a funzionare abbastanza velocemente da soddisfare il "bisogno di velocità" dell'utente del PC. Quindi fanno affidamento sul fatto che il sistema operativo e i programmi applicativi trascorrono la maggior parte del loro tempo in attesa che succeda qualcosa (input dell'utente, hardware periferico ecc.).

Se provassi a far funzionare tutti i core in un i7 continuamente alla massima frequenza, si scioglierebbe. Per evitare che i core inutilizzati vengano spenti, e quando la velocità massima non è richiesta (cioè la maggior parte delle volte) i core attivi funzionano a una frequenza inferiore. Quando è inattivo, il sistema operativo non si limita a eseguire un ciclo occupato eseguendo continuamente le istruzioni, ma mette la CPU in uno stato rallentato o arrestato mentre attende interruzioni, ecc. Varie parti della CPU possono anche essere spente quando non sono in uso.

L'ATmega può anche essere impostato in modalità di risparmio energetico e le singole periferiche possono essere spente quando non sono necessarie. Se l'orologio di sistema viene modificato su una frequenza inferiore come 32,678 kHz e tutte le periferiche non necessarie vengono spente, può funzionare (lentamente) solo con pochi μA, non per ridurre la temperatura, ma per durare più a lungo con una piccola batteria.

È anche possibile "overcloccare" molti chip Atmega.Ho eseguito un ATmega1284p (valutato per 20 MHz max a 5 V) a 30 MHz e ha funzionato bene, ma è diventato abbastanza caldo.

Dipende dal fatto che il tuo sistema ATmega stia funzionando con alimentazione a muro CA o piccole batterie.

Eseguendo la corrente alternata (tramite un alimentatore a muro), l'energia consumata dal 100% della CPU utilizzando lo spin loop è inferiore al rumore di fondo della variazione della bolletta.La dissipazione del calore molto probabilmente è troppo piccola per richiedere un dissipatore di calore o una ventola, a meno che non si trovi in un ambiente super isolato.Potrebbe essere misurabile con un termometro IR.

A corto di batterie piccole, uno spin loop di Arduino farà una differenza significativa nella frequenza con cui devi sostituire o ricaricare quelle batterie.Forse ore contro mesi.Un problema serio se l'accesso al tuo sistema integrato è difficile.Una soluzione comune è quella di utilizzare una sorta di modalità di sospensione temporizzata a basso consumo all'interno del ciclo infinito o una modalità di sospensione più un interrupt di riattivazione da una fonte esterna.

Su un microprocessore contemporaneo, molto probabilmente scriverai un'interfaccia utente grafica che fa il tuo lavoro. La GUI ha i propri loop di eventi in cui vengono elaborate cose come clic del mouse, ridisegni, ecc. La maggior parte delle funzionalità si troverà all'interno di un gestore di eventi a cui è delegato il ciclo di eventi principale.

Quindi, se all'interno di un tale gestore di eventi avvii un ciclo infinito, interromperai la normale elaborazione degli eventi, perché dipende dal tuo ritorno al ciclo degli eventi dopo un periodo di tempo piuttosto breve affinché l'interfaccia utente rimanga reattivo. Almeno la tua applicazione non risponderà se hai un ciclo infinito (i clic del mouse non fanno nulla, la grafica non verrà più aggiornata).

Il multitasking in quanto tale (e quindi gli altri processi) normalmente non ne risentirà, perché comunque il kernel del sistema operativo passerà ad altri processi.

Quindi non è "malvagio" avere un loop infinito su un microprocessore, ma è contro gli standard dell'esperienza utente, almeno per le applicazioni grafiche. Per un'applicazione console, tuttavia, potresti avere un ciclo infinito senza danni, ad esempio se vuoi calcolare pi greco fino a 1 milione di cifre (e infine mettere il risultato sulla console) o qualcosa di simile, perché l'utente è normalmente ( caso peggiore) preparato per applicazioni console che impiegano quasi un'eternità a produrre i loro risultati.