Newsgroup: it.lavoro.informatica
Titolo: [EMBEDDED] Interessante sull'aumento delle applicazioni dei microcontrollori

http://www.designnews.com/document.asp?doc_id=233904
 
 
Interessante per due aspetti: uno tecnico (fino a qualche anno fa si
prevedeva che i piccoli micro a 8 bit sarebbero scomparsi, invece i
fatti stanno ribaltando tali previsioni) ed uno occupazionale (loro
utilizzo in applicazioni nelle quali l'elettronica non era mai entrata
prima, nell'articolo alcuni esempi)

 prima, nell'articolo alcuni esempi)
 
"an eight-bit MCU with 8K of flash, 1K of RAM, and 128 bytes of EEPROM
for just 25 cents"... beh, di cose ce ne puoi fare parecchie, con
quelle specifiche. Trent'anni fa, anche un home computer ;^).
Non ho pero' ben capito la parte sui LED... che vuol dire che si può
sostituire il "convertitore analogico-digitale" con una MCU in un LED?
Da quando in qua un LED utilizza un convertitore AD? L'unica che ho
immaginato è che nel settore per "LED" non si intenda il singolo diodo
ma uno strumento di misura con display a diodi, è così?
 
bye!


Non sono un grande esperto di illuminotecnica, ma probabilmente fa
riferimento ad applicazioni in cui si acquisisce la luce ambiente e se
ne usano intensità/colore per variare luminosità/colore di led o
gruppi di led; un esempio può essere l'illuminazione degli
scompartimenti dei treni che varia in funzione di quella ambiente
(sole, cielo grigio, gallerie)

 wrote:

Domanda da profano: ma un circuito progettato ad hoc per una certa
applicazione non è sostanzialmente preferibile ad uno con
microcontrollore+sw, per velocità di risposta, consumo, dimensione
complessiva, e non ultima maggiore certezza di risultato (meno bug)?
In effetti credo che spesso ai micro devono essere affiancati circuiti
ausiliari per arrivare allo stesso risultato di un circuito integrato
specifico.

 specifico.
 
Non si riesce certo a fare tutto con le periferiche integrate ma col
passare degli anni le ho viste migliorare fino a diventare in molti
casi competitive ed intercambiabili con circuiteria esterna
 

 (sole, cielo grigio, gallerie)
Ci avevo pensato, ma neanche questa mi torna molto... OK che con un
dispositivo basato su MCU puoi fare una cosa più ganza, ma ho seri
dubbi che la tecnologia attuale per una roba del genere sia mista
analogico/digitale... a meno che per convertitore AD non intendano un
banale comparatore a rampa (disclaimer: mi baso su conoscenze
antiquate e obnubilate, i tempi degli esami di elettronica son
lontani)
bye!

 complessiva, e non ultima maggiore certezza di risultato (meno bug)?
 
sempre da profano, direi che non tutte le cose che citi sono
significative: la velocità di risposta non è una issue (si parla di
applicazioni in strumenti e dispositivi che finora erano
elettromeccanici, quindi comunque caratterizzati da transitori
superiori di un paio di ordini di grandezza), il consumo e la
dimensione sono già ridotti all'osso, e i bug in realtà sono *più*
costosi nelle architetture ad hoc: in quel caso per correggere un
vizio devi riprogettare tutto, nel caso di un microcontrollore ti
basta riflashare la eeprom con il firmware corretto. Se dall'altro
piatto della bilancia metti costi industriali irrisori, possibilità di
accedere a schemi di utilizzo standard e certificati, direi che non
c'e' storia.
 
bye!
 


Se ti incuriosisce il settore "lighting" qui:
http://www.atmel.com/applications/lighting/Default.asp?AppID=2180
trovi una serie di informazioni infinitamente più dettagliate di
quello che posso dirti io, tra cui degli schemi a blocchi piuttosto
ben fatti. La Atmel (e presumo anche altre case che conosco meno) ha
creato una famiglia di microcontrollori con periferiche specifiche per
questo settore, quindi direi che di applicazioni ce ne devono essere a
pacchi.

 c'e' storia.
Mah, anche questo è da verificare. Certo, se pensiamo ad un
microcontroller che ingloba un mucchio di periferiche sono d'accordo
con te: monti praticamente solo quello, lo programmi e fine. Magari
per curare l'acne è sufficiente :-)

 progettazione, tanto poi basta rimemorizzare il firmware....
 
Lui ha parlato di *costo* del bug.
 
Comunque sì, una conseguenza indiretta è che si può essere meno rigorosi nel 
testing quando il bugfixing è poco costoso, ovviamente se il costo di un 
malfunzionamento non è preponderante.
 
Quando produci un ASIC c'è un investimento in maschere e batch produttivo 
molto ingente. Se ti accorgi che il tuo ASIC è bacato prendi maschere e i 
tuoi 10000 ASIC (se va bene) e li butti via.
 
E augurati di non averli già montati....
 
È anche per questo che in molti contesti gli FPGA sono preferiti.
 
Ciao,
 
-- 
  Daniele "Vihai" Orlandi
  Bieco Illuminista #184213


Sì, ma alla fine dipende tutto dalla efficacia e rigorosità delle
procedure di progettazione. Non vedo perchè di base esse debbano
essere più scarse per i circuiti speciali rispetto a quelle per i
circuiti con micro+sw.
A meno che si voglia per l'appunto tagliare su tali procedure, ad es.
nella durata. Puoi produrre direttamente i circuiti, senza sw sopra,
contemporaneamente allo sviluppo del sw. Solo alla fine memorizzi il
firmware definitivo. Sì, questo è possibile.

 circuiti con micro+sw.
 
Perché render rigorosa definizione delle specifiche, progettazione e testing 
costa e se non c'è un valido motivo per spendere soldi non è utile farlo.
 
Non fraintendermi, io sono un forte sostenitore di una buona progettazione e 
una buona realizzazione del software ma c'è anche un fattore economico che 
non si può sottovalutare.


 non si può sottovalutare.
 
Veramente io dicevo esttamente il contrario:
Non vedo perchè di base [le procedure di progettazione] debbano
essere *più scarse per i circuiti speciali* rispetto a quelle per i
circuiti con micro+sw.
Poi chiaramente c'è il fattore economico, verissimo. Anche se talvolta
fa un pò a botte con le buone pratiche ingegneristiche.
 

 ma uno strumento di misura con display a diodi, è così?
 
No, proprio LED per illuminazione.
Per garantire la massima efficienza e durata e ridurre il consumo, i
LED vanno pilotati in una finestra tensione/corrente ben precisa, con
feedback e menate varie.
Aggiungi la necessita' di gestire differenti luminosita' e
aggiustamenti di colore, e una MCU ci va dentro comunque.
Se con la stessa MCU ci fai anche il controllo di corrente e tensione
sul LED, con feedback, risparmi un paio di chip.
 
Non stiamo parlando di LED per indicazione, sono "cosi" che si
ciucciano qualche chilata di A :)
Proprio in questi giorni ho finalmente visto in negozio lampade LED di
seconda generazione (come sviluppo credo si sia gia' alla quarta o
quinta) con LED appunto ad alta efficienza.
Una lampada cosi' ha dentro un bel pacchettino di controllo, altro che
condensatore e raddrizzatore, pero' si inizia a rendere.
Ho preso una 40W nominale (8W di consumo per 520 Lumen). Ora si' che
si inizia a ragionare, altro che le CFL !
Con LED di ultima generazione credo chi si possa arrivare al doppio di
Lumen con la meta' del consumo.
Ma prima che arrivino in commercio ci vorranno almeno un paio d'anni.
 
C'ya
  STeve
 

 microcontrollore+sw, per velocità di risposta, consumo, dimensione
 
Dipende.
In un mercato dove l'evoluzione e' veloce (e illuminotecnica e LED e'
sicuramente uno di questi) se fai il circuito ad hoc e poi cambia
tutto devi buttare via i circuiti fatti.
Con una MCU gli cambi il firmware e gestisci componenti diversi, con
lo stesso circuito.
Quindi puoi farti una milionata di circuiti di controllo, abbassando
il costo di produzione, sicuro che se cambia qualcosa non devi buttare
via tutto.
 
C'ya
  STeve

 prima, nell'articolo alcuni esempi)
 
Aggiungi che ormai tutti i produttori di MCU puntano di brutto sul
risparmio energetico e sensoristica.
C'e' una competizione pazzesca.
 
C'ya
  STeve
 

 circuiti con micro+sw.
 
Dipende cosa intendi con "circuiti speciali".
 
Perché se stai progettando un ASIC allora ti dico io che lo testi molto più 
a fondo di un sistema micro+sw a parità di complessità.
 
Ovvio che un sistema micro+sw può raggiungere una complessità molto 
superiore con kilobit o megabit di stato da esplorare.
