3 Commenti

1. electropower 13 Giugno 2011

   Non chiamatemi pro-microchip però forse in parte lo sono, fosse soltanto per l’elevata disponibilità di documentazione presente in rete e per il numero non trascurabile di community di progettisti che con questi dispositivi ci progettano e divulgano il loro sapere in merito. La soluzione XLP di Microchip è particolarmente interessante, per dirla breve, secondo quanto riportato qua e là in rete, sembrerebbe che costituisca la soluzione a più basso consumo tra gli IC della sua categoria (microcontrollori progettati da altre case come Atmel, Freescale, ecc…). Personalmente, questa affermazione, la prenderei un pò con le pinze perchè ogni casa di microcontrollori tende a tirare l’acqua al suo mulino e dare un giudizio obiettivo guardando alle carte ufficiali credo che sia eccessivamente azzardato. Fatto sta che in deep sleep (modalità di sonno profondo) il microcontrollore assorbe solo 30nA contro i 34uA/MHz in condizioni operative, ma la riduzione dell’assorbimento è ovviamente dato dallo spegnimento crudo delle varie periferiche che in un certo intervallo temporale no funzionano (non vengo utilizzate nel firmware). La ricerca del low power è un continuo di risultati sempre nuovi per ottimizzare la gestione dei sistemi elettronici integrati. La soluzione microchip è forse, concettualmente, la più semplice ed efficace :”spegni tutto e riaccendi quando sopraggiuge un evento di interrupt tra i possibili abilitati”…Un possibile evento può essere addirittura generato dal RTCC interno che permette di fissare ora, minuto, giorno, anno in cui il micro di deve riaccendere per fare un qualcosa…praticamente sorprendente. Il fatto dello sleep è particolarmente utilizzato da un pò tutte le case produttrici di micro, ma è il deep che fa la differenza. Nella soluzione low power di microchip, anche la memoria dati viene congelata per intero prima di entrare in un sonno profondo per poi ricaricare il mondo una volta sopraggiutno il segnale di risveglio. Il problema principale di questa tecnica (che non è detto che sia un prblema dal punto di vista dell’applicazione finale) è che il risveglio richiede un tempo di latenza che può essere di qualche ms e la tale durata, relativamente lunga se confrontata con il singolo ciclo macchina, è dovuta al fatto che il XLP la tensione di alimentazione non supera i 3.3V e per garantire la stabilità del segnale di clock, la frequenza dello stesso cala al diminuire della tensione. Quindi, in LP posso anche dimenticarmi PLL che moltiplicano la frequenza del quarzo esterno o frequenze di quest’ultimo maggiore di 4 max 8MHz. LA riduzione della velocità del clock e la tecnica di risparmnio energetico, insieme, producono un tempo di risveglio lungo…tutto qua! Ripeto, ai fini dell’applicazione finale questo potrebbe non comportare un problema, anzi tutt’altro. A quanto ho capito, tornando all’IC dell’articolo, memoria programma e memoria dati sono gestiti distintamente e magari anche in contemporanea riuscendo a ridurre di qualche ciclo di clk la durata della singola istruzione (compenso in parte la riduzione della frequenza di CLK).

   Accedi per rispondere
2. Bazinga 13 Giugno 2011

   Ti chiamo pro-microchip e ti spiego perche:

   i valori che tu dichiari di Microchip sono gli stessi anche per Atmel,Freescale,Texas Instruments etc.

   quindi ogni casa ha una propria leadership, dipende quale a te interessa.

   La documentazione ed i siti completi e pieni di application note?
   Hai visto il sito Texas?

   La community in rete con progetti e schemi a migliaia?
   Hai visto AVR e Arduino?

   Vuoi parlare di assorbimenti, il leader è stato per anni l’msp430, e nanowatt, picowatt etc sono solo modi di dire la stessa cosa “il mio micorcontroller assorbe meno del tuo”

   Però magari lo fa in una modalità di funzionamento che non uso per la mia applicazione.

   Accedi per rispondere
3. electropower 14 Giugno 2011

   Guarda Bazinga, accetto volentieri il tuo definirmi pro-microchip, anche perché questa cosa è stata oggetto della mia premessa al commento che ho lasciato in precedenza. Effettivamente, come ho detto e come tu hai avuto modo di sottolineare, non ho provato altre soluzioni di microcontrollori e quindi per quanto riguarda i consumi delle varie architetture non posso certamente fare un’analisi comparativa, fosse solo per il fatto che porre alle medesime condizioni operative due firmware che girano su micro differenti non è assolutamente una cosa da poco. Tempo fa ho letto con grande interesse un articolo di Elettronica Open Source in cui l’autore cercava di avanzare un’analisi comparativa sui consumi di potenza di tre microcontrollori millantati come low power, un microchip, un Atmel e un Motorola. La prova consisteva nell’implementare un contatore che visualizzasse il conteggio su un display a cristalli liquidi e il tutto alimentato da una grossa capacità caricata preventivamente. Non ricordo quale dei tre microcontrollori riuscì a tenere testa sugli altri, ma ricordo che il micro vincitore riusciva ad alimentare display e core ad una tensione addirittura inferiore al minimo di datasheet. Lo stesso Emanuele, mi ricordo, in quella occasione si è sentito la necessità di evidenziare l’impossibilità di garantire per diversi motivi le medesime condizioni operative per i tre microcontrollori. quindi con tutta la buona volontà che ci si può mettere, ricavare dei dati comparativi attendibili sul consumo in potenza con esperimenti home made torna seriamente molto difficile.
   Per quanto riguarda la documentazione disponibile per il singolo micro (o famiglie di micro), ho sempre riconosciuto nella Microchip come la casa produttrice per eccellenza più vicina alle applicazioni general porpuse, tipiche applicazioni che attirano prima delle altre la curiosità degli hobbisti. Per quanto riguarda Arduino, è vero che le community attorno a questo sistema di sviluppo sono ampiamente diffuse un po’ in tutto il mondo, quindi da questo punto di vista batte tutti gli altri sistemi a microcontrollore ma è anche vero che se di Arduino se ne sfrutta l’hardware ma il software è scritto come si deve, allora diventa una evaluation board ospitante un’Atmega, al contrario se ci si attiene alle API fornite con l’IDE (aspetto questo che ha reso e che ancora tutt’oggi rende giustizia a questo toolkit) per semplificare la stesura del codice e renderlo accessibile anche a chi non sa il concetto di tensione e corrente, allora credo di non poterlo inserire tra la schiera dei microcontrollori chiamati al confronto. Io ho iniziato con i micro proprio con arduino per poi spostarmi timidamente verso soluzioni Microchip (ordinando i primi samples gratuiti) però devo ammettere che diverse operazioni svolte su Arduino semplicemente richiamando una funzione di libreria, in realtà si sono rivelate poco efficienti se confrontate con le medesime funzionalità gestite ad esempio via Assembly oppure ancora in C più spicciolo. Le community nascono sulle funzioni di libreria, no sull’uso ottimizzato dell’hardware (e non avrebbe nemmeno tanto senso il contrario).
   Termino dicendo che non posso dire chi è meglio di chi perché è difficile avanzare analisi comparative che rispecchino i medesimi contesti operativi, ne posso dire che è meglio la Microchip sotto alcuni aspetti senza aver perlustrato tutte le soluzioni proposte dal mercato e quindi si, fino a quando mi ostinerò ad utilizzare Microchip e non avrò aperto i miei orizzonti verso altre famiglie di micro, chiamatemi pure pro-microchip!! ;D

   Accedi per rispondere