Newsgroup: it.hobby.elettronica.digitale
Titolo: usare i uC professionalmente

Ciao,
molto probabilmente a breve comincerò a usare i microcontrollori in 
applicazioni industriali e di piccola automazione.
Per non trovarmi impreparato vi chiedo di consigliarmi dei link o libri 
(intendo qualificati, non i soliti divulgativi per l'hobbysta che 
conosciamo) che trattano l'impiego di uC in ambienti industriali dove è 
richiesta la massima affidabilità lavorando in condizioni critiche 
(continuità di funzionamento, esposizione a rumori EM come motori, ecc...).
Mi interessano le linee guida generali per la parte hardware (protezioni 
circuitali, disposizione dei componenti, scelta dei componenti, 
alimentazione, ecc...) e per la parte software (come implementare 
efficacemente le soluzioni ai problemi più comuni, ecc...)
L'ideale sarebbe una trattazione generale a prescindere dalla MCU usata 
e poi un approfondimento sui PIC della Microchip, dal momento che dovrei 
operare con questi.
Sapete darmi delle indicazioni mirate?
Grazie a tutti,
Marco / iw2nzm

 (continuità di funzionamento, esposizione a rumori EM come motori, 
Non so darti una risposta professionale perchè non l'ho mai fatto in
questa maniera.
Però il compianto Rinux lo faceva da 20 anni queste cose e mi ricordo che
quando gli facevo le domande sull'uso sicuro di dispositivi in automazione
e controlli mi diceva sempre: E cosa fai se succede questo? e se si blocca
quello e tu non l'hai previsto? e se non hai implementato quello durante
quell'operazine cosa succede? etc etc...
Quello che ho capito è che bisogna prevedere mooolte cose per operare in
sicurezza e bisogna sapere bene cosa si fà.
Magari se c'era lui ti dava molte dritte, sei arrivato con 15 gg di
ritardo :(
Ti do dei consigli però, cioè te li da Rinux:
Usa sempre il riarmo automatico con disattivazione della potenza se il
micro va in palla.
Fai creare un onda quadra con una porta del µC che controlla la potenza.
SEMPRE! (almeno che non è un giocattolo).
Se non sai cosa è te dimmelo che te lo dico in due parole.
Se puoi usa la soluzione più semplice, in automazione non servono grandi
velocità (spesso) quindi se puoi utilizza due diodi e una resistenza
invece che un IC.
Non pilotare mai direttamente niente se non con transistor, buffer o
quello che sia.
Il datasheet ti dice che si può fare, tu non lo fai!
Se hai un pc che poi gestisce i dati che provengono dalla tua scheda fagli
fare solo quello.
Nel senso che è la scheda che manda dati al pc (magari per visualizzarli o
immagazzinarli) ma non è il pc che comanda i dispositivi... 
I pc si IMPALLANO...
Sulle riviste di elettronica ci sono un sacco di stronzate :) (ma questo
lo sapevamo....)
Ricordati dei tutti SE... che ho scritto sopra.
E tante altre cose che non mi vengono in mente.
PS
io sono un hobbista, Rinux aveva alle spalle 250 progetti e 16 brevetti...
ha utilizzato tutti i µC DSP e PLC in giro oltre ad aver progettato intere
catene industriali. 
Per il resto fai tu.
PS
a lui facevano schifo i PIC, è stato uno dei primi a prendere un sistema
di sviluppo nel '90 ma l'ha abbandonato subito.
Era un cultore degli 8051, che sono molto più performanti e adatti al
controllo a bit.
ciao spero aver fatto cosa gradita.
coals
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 controllo a bit.
concordo e sottoscrivo! non capisco questa maniacale testardagine sui
PIC!
A.

 coals
Grazie!
Marco / iw2nzm

 
ARM ? ATMega ?
li stanno spingendo molto
ma e' un po' come i linguaggi di programmazione ognuno ha i suoi pro e i 
  suoi contro
8051 :  hanno una base d'uso enorme , linguaggi, tool, schede, la 
versione microprocessore e' molto diffusa, molto comodi sono gli 8051 
con flash a bordo riprogrammabili tramite seriale ( RS232 ) il sistema 
di sviluppo e' virtualmente annullato ( prodotti da dallas,philips,atmel 
in varie pezzature )
PIC18xxx : programmati in C diventano come tutti gli altri
ARM : sono a 32 bit molto prestanti ed esistono anche moduli 'piccolini'
ATMega : ? non li conosco abbastanza
dipende molto da quale applicazione e a chi e' destinata ( magari e' lui 
a mettere vincoli )


A me, invece, interessa molto lo stesso discorso ma fatto
sul software. E' facile scrivere firmware per microcontrollori
che hanno bachi nascosti che si riveleranno solo in casi
particolari direttamente sul prodotto in funzione nel suo
ambiente.
So che esistono delle raccomandazioni nella scrittura dei
programmi C, per esempio in campo automotive (non ricordo
come si chiamano).
Poi so che esistono delle raccomandazioni (se non sbaglio
si chiamano software in classe A o qualcosa del genere) per
la stesura di software per apparecchiature pericolose
(impianti di gas, caldaie... insomma, cose che possono
esplodere). Poiché oggi è fatto tutto via software, è
necessario che per un baco non succedano cose pericolose
per l'utente. Ma come valutare la bontà di un software?
Quali sono le linee guida da seguire? Qualcuno ne sa qualcosa?

 senz'altro un tipo in gamba e molto disponibile.
Disponibilissimo, solo che delle volte quando sentiva troppe castronerie
si rifiutava di rispondere.
Un grande amico, sono felice di divulgare cose sue.
ciao 


 più corrente perchè il C si scarica e blocca tutto.
Sinceramente non l'ho capito. Quando parli di potenza, intendi la linea
di alimentazione al circuito? E perchè parli di relè master? Ce n'è anche
uno slave?
Avevo visto qualcosa del genere con degli integrati che controllano proprio
la presenza di un'onda quadra in uscita da un uC. Se vedono che quest'onda
quadra non c'è più, molto probabilmente il uC si è impallato e resettano
il uC con l'apposita linea.
Non credo sia molto furbo creare l'onda quadra mediante interrupt. Se fai
così rischi che il software si sia impallato da qualche parte ma l'interrupt
sia ancora attivo e generi continuamente la sua onda quadra.
Penso sia meglio usare un paio di istruzioni in un punto dove il software
deve sempre passare.

 Un grande amico, sono felice di divulgare cose sue.
E io sono felice di poter in qualche modo apprendere attraverso chi lo 
conosceva anche solo una piccola parte delle sue competenze. Grazie!
Ora mi guardo un po' di documentazione, poi ritornerò a rompere le 
scatole sul NG per confrontarmi con voi su quanto avrò visto :)
Thx,
Marco / iw2nzm

 deve sempre passare.
Se il programma è scritto bene si potrebbe sfruttare il punto in cui si 
resetta il WDT: di lì si passa sempre e regolarmente.
Ma credo che il problema sia diverso: si tratta di intercettare un 
errore hardware del micro, ad esempio il blocco del clock o altre cose 
che fermano completamente il flusso del programma.
L'osservazione che fai sembra più plausibile in caso di bug nel 
codice... in quel caso però entra in gioco il WDT con conseguente reset.
Dico bene?
Marco / iw2nzm

 deve sempre passare.
Parole testuali di Rinux:
**********
Io userei un timer o moooolto meglio, il pwm.
Carichi il valore di reload e lui lo fa hardware,
Senno (visto che è un applicativo industriale ) devi usare il watchdog
legato ad un'onda quadra.
**********
Che ti dico?
Probabilmente se c'è qualche malinteso con una sana email si poteva
chiarire, peccato che quel pozzo di esperienza e capacità che era non ci
può più rispondere.
Da retta le cose sono due, o si è spiegato male lui oppure io o ti è
sfuggito qualcosa a te.


 per l'aumento di sicurezza che ne deriva.
Io, non ricordo quando, ho lavorato con una libreria software molto 
carina, in pratica si prendeva un timer HW e ne creava degli altri via 
SW, mi pare ne supportasse 256 o 65K.
In applicazioni comlesse hai sempre bisogno di qualche timer in più, io 
stesso ho fatto una cosa simile, più sbrigativa ma funzionale:
void Timer1_Int(void)
{
//   [ROBA VARIA]
//Software timers:
  if (SwTimerCounter>=200) {		   //Every 200*0.5ms = 100ms
  	SwTimerCounter=0;
 
	SwTimer1 = 1;	  		   //Trig Timer1
	SwTimer2 = 1;	  		   //Trig Timer2
	SwTimer3 = 1;			   //Trig Timer3	
  }
  else
  	SwTimerCounter++;
}
Questo creava 3 timer controllati in polling da alcuni task.
Con qualche riga in più si può anche far eseguire una routine emulando 
così un vero e proprio timer HW con relativo vettore di interrupt.
Quello che invece mi chiedo è se vale la pena di fare tutto questo 
lavoro con l'onda quadra: io non ho mai fatto impianti industriali in 
prima persona ma non ho neanche sentito di queste misure preventive, 
solo Watchdog... insomma, è un Timer a sè stante che non ha nulla a 
vedere con tutto il resto del uC, ho sempre pensato fosse sufficiente.
Mi sbaglio? Chiedo info da chi ha più esperienza.
...:::Zmaster:::...

 coals


>Un altro consiglio spassionato, usa gli 8051!
lo terrò ben presente!
Marco / iw2nzm

 **********
Appunto, la spiegazione di Rinux mi sembra piů simile a quello che propongo
io.
Partiamo dal presupposto che il watchdog serve per evitare blocchi
indesiderati
dell'esecuzione del firmware che risiede nel micro. Ovviamente parlo di
blocchi
software (leggi bachi) poiché i blocchi hw non li possiamo mica aggiustare
via software (Marco, se si blocca per qualche motivo l'oscillatore non ci
possiamo fare nulla, pur facendo tutti i giochini che vuoi con i relč).
In pratica il watchdog č un timer, cioč un registro che si incrementa ogni
x colpi di clock, dove x č normalmente programmabile mediante un prescaler.
Se il timer effettua un overflow (il registro passa dal suo valore massimo a
zero), il micro viene resettato e riparte tutto dall'inizio. Per evitare
questo
si inserisce una istruzione di reset del watchdog (ovviamente del suo
registro)
in un punto (o piů punti) del software in modo che, durante il normale
funzionamento, il registro non vada mai in overflow.
Perché tutto questo? Perché il programma potrebbe impallarsi (baco) e, in
questo
caso, *molto probabilmente* non si passa piů dall'istruzione di reset del
watchdog e, quindi, il registro va abbastanza presto in overflow e il micro
si resetta ricominciando... e sperando di non ritornare nel baco precedente.
In genere, perň, il watchdog č abilitato o resettato modificando il valore
di
qualche bit in qualche registro del uC. Supponete, ora, che il watchdog sia
abilitato e venga resettato normalmente perché il programma funziona
regolarmente.
Ad un certo punto c'č un baco che porta il Program Counter da tutt'altra
parte
e vengono eseguite istruzioni a caso. Nella *maggior parte* dei casi, il
watchdog va in overflow e il micro si resetta. Perň č possibile che, una
delle
istruzioni casuali, vada proprio a disabilitare il watchdog modificando quei
bit di quei registri che servono allo scopo. In questo caso il micro non si
resetta e continua l'esecuzione di istruzioni piů o meno casuali... Il
sistema
č bloccato ed č pericoloso.
E' per questo che spesso il watchdog č esterno... Il timer di questo
integrato
esterno al uC viene resettato quando una sua linea di ingresso, collegata ad
una linea di uscita del uC, va giů. Se questa linea rimane giů o su per
troppo
tempo, l'integrato resetta il uC con l'apposita linea di reset. In questo
modo
č molto piů difficile che il uC in stallo possa sfuggire al controllo del
watchdog esterno. Naturalmente, per abbassare ed alzare il pin, č
sufficiente
un PWM con sufficiente frequenza... ecco che torniamo a quello che diceva
Rinux (watchodg legato ad un'onda quadra).
Se ci pensiamo un attimo, anche qui la probabilitŕ che il watchod esterno
non
si accorga dello stallo del uC non č nulla. Chi ci assicura che, durante lo
stallo, il uC non esegua casualmente delle istruzioni che portano alto o
basso
proprio quel pin collegato al watchdog? Ovviamente, perň, rispeto al
watchdog
esterno, la probabilitŕ che ciň accada č molto piů bassa.
Naturalmente questi sono solo miei pensieri e non ci metterei la mano sul
fuoco.
Perň sarebbe bello continuare la discussione.

 
quello che i progettisti dei watchdog interni tendono a fare e' di 
rendere bassa la probabilita' di un reset casuale del watchdog, si va da 
istruzioni specializzate come nel caso dei PIC18 dove c'e' un solo 
opcode tra tutte le possibili combinazioni ad accessi 'speciali' del 
registro di watchdog con sequenze di piu' di una istruzione.
in questa maniera diventa abbastanza improbabile che il watchdog venga 
resettato per errore in maniera continuativa
bhe se poi ti riempi la memoria 'vuota' proprio di quella istruzione .....
sotto questo punto di vista il watchdog esterno, di quelli semplici, e' 
un po' piu' pericoloso, meglio a quresto punto avere un watchdog su spi 
o i2c in modo che per resettarlo devi proprio farlo apposta!

 
soluzioni a costo 0 per la parte di programmazione ce ne sono
sdcc: compilatore C
il programmatore dei chip con flash ti ho gia' segnalato qualcosa che 
puo' essere programmato a costo circa nullo
il debugger in-system purtroppo e' ancora un sogno a meno di non 
ricorrere a costi spropositati


 debugger in-system.
A titolo informativo vorrei aggiungere che anche per gli AVR ATMega o 
comunque tutti quelli che supportano JTAG è possibile autocostruirsi il 
JTAG-ICE per 10/20€.
...:::Zmaster:::...

 applicazioni industriali e di piccola automazione.
lo farai da dipendente o da libero prof. ?
Saluti,
--
simone.bern
Mr. Heisemberg is not the only one who can affect a measurement by looking at it (Robert A. Pease)
zsimone...@zliberoz.it
 (Rimuovere i caratteri di zorro per rispondere via mail)

 possiamo fare nulla, pur facendo tutti i giochini che vuoi con i relè).
non è vero.
se si blocca l'oscillatore, si blocca anche l'onda quadra (o PWM che 
sia) e viene disabilitato l'enable alla sezione di potenza. Certo non si 
  risolve il problema ma si evitano situazione pericolose a dir poco. 
IMHO naturalmente.
Marco / iw2nzm

 lo farai da dipendente o da libero prof. ?
al momento come prestazione occasionale (dovrebbe essere questo il 
termine corretto, giusto?)
In parole povere affianco un progettista elettronico che non sa nulla di 
uC e di programmazione. Finora sta facendo tutto in logica cablata (con 
i limiti che ben sappiamo).
La mia domanda iniziale in effetti era rivolta *principalmente* a 
considerazioni di tipo EMI. Ho qualche infarinatura da corsi 
universitari ma al solito, solo qualche formuletta e *zero* applicazioni 
concrete. Perciò il mio desiderio di trovare letteratura specifica.
Ciao!
Marco / iw2nzm

 ricorrere a costi spropositati
da *questo* punto di vista l'ICD2 della Microchip è avanti anni luce 
quindi?
Marco / iw2nzm

 Marco / iw2nzm

 debugger in-system.
Un ICE che funziona sotto bascom è il se 514 che funziona con processori
Atmel 8051 e costa due soldi.
Ho preso il kit diverso tempo fa ma poi tra un impegno e un altro non l'ho
ancora finito di costruire.
vai su 
http://www.mcselec.com/se512-51.htm
Vedi che Bascom è moolto semplice, se usi il C saprai anche il basic e ha
moolte funzioni interessanti già implementate come il controllo di display
grafici, led IR, etc etc.
Vattelo a vedere.
Rino lo usava ormai da qualche anno con grande soddisfazione, quando non
usava l'SDCC, l'ASM o gli altri programmi.
Semmai scrivimi qui...
coals at cirrus dot it
ciao
coals
-- 


applicazioni. 
vabbè anche un pic a 100 Mips (se c'è o ci sarà) c'avra le sue
problematiche no?!
ciao e mi dispiace di aver alzato un vespaio.


 ciao e mi dispiace di aver alzato un vespaio.
Macchè vespaio, figurati. Si fa per chiaccherare...

 concrete. Perciò il mio desiderio di trovare letteratura specifica.
Non riesco a cogliere bene. Tu devi sviluppare solo il firmware o ti devi occupare di EMI ? Perchè quello è un lavoro da
progettisti analogici e 'PCB Engineer', più che da sviluppatori firmware. In ogni caso, ho una certa esperienza di
lunghe e dolorose sessioni in camera anecoica, certificare un apparecchio non è banale... Ho l'impressione che, benchè
indispensabile, non sia sufficiente studiare l'argomento sui libri. Non per scoraggiarti, dico. In ogni caso, ti
consiglio due libri:
La bibbia "High-Speed Digital Design: A Handbook of Black Magic", Haward W. Johnson, Martin Graham. Prentice Hall, 1993.
ISBN 0-13-395724-1
e "Grounding and Shielding Techniques in Instrumentation", Ralph Morrison, 3rd Edition. John Wiley & Sons, 1986. ISBN
0-471-83805-5
Saluti


 0-471-83805-5
Grazie per le informazioni
Marco / iw2nzm

 ha scritto nel messaggio
news:deuota$8hu$1...@news.newsland.it...


 Noise in ADC Circuits.
Molto interessanti!
Ne sto scaricando diversi, grazie della dritta!!
Marco / iw2nzm

 "MPLAB + ICD2 + compilatore C di terze parti".
non me lo potevi dire prima??!! :)
ormai...
ciao e grazie delle info.


 ha scritto nel messaggio
news:EsGQe.36312$HM1.1...@twister1.libero.it...

Prego, figurati.
L'ultima pagina di quello che ti ho indicato (Conclusion: what you should do) l'ho appesa alla parete del lab. di
elettronica, ingrandita... :-)

> (continuità di funzionamento, esposizione a rumori EM come motori, ecc...).
Cerca su internet questi documenti molto interessanti, io non ho i link
che li ho scaricati tempo fa.
Riguardano soprattutto l'emi e emc della piastra.
ciao
coals
Compatibilità elettromagnetica: criteri generali e definizioni 
EMC design guidelines (C&D Technologies)
EMC improvement guidelines (Atmel, fa vedere come posizionare il µC con
grafici)
ee.unipr.it/~frankie/TEACHING/CO_EL_Cap8.pdf
 
(Univ. di Parma, di Franco Giovanni, partizionamento della piastra)
Pcb design guidelines (Infineon, application note DS1, dec 2001)
PCB design guidelines for reduced EMI (Texas Instruments)ualche link ch


 Riguardano soprattutto l'emi e emc della piastra.
thx!
Marco / iw2nzm

 
Mi permetto di dire che è cosi' anche con la famiglia  ST6XXX della SGS;
personalmente ci lavoro da più di otto anni e non mi hanno mai riservato 
sorprese.
Inoltre per imparare ad usarli basta prendere il CD ed il KIT di Nuova 
Elettronica e si spende un quinto del prezzo dello starter kit della SGS.
Per i lavori più complessi poi c'è l'ST7.
Saluti
Max

 Max

 (guardati il SAB-80C517) e tanti altri.
Ti sei dimenticato degli LPC della philips che per "piccola controllistica"
possono andare bene.
La scheda di sviluppo costa 99 euro e con poco di piů riesci a comprare
anche l'ICE (si , quello con il POD da piantare al posto dell'micro) della
KEIL... con annesso compilatore uVision libero fino a 4K.
Ciao
Davide B.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 KEIL... con annesso compilatore uVision libero fino a 4K.
c'hai il link che gli do uno sguardo?
ciao e cmq abbiamo fatto lo stesso ragionamento fatto con Simone, qui non
c'č niente di personale.
Si fa per chiaccherare.
ciao
coals


 c'hai il link che gli do uno sguardo?
Eval board :
http://www.keil.com/mcb900/
Emulatore
http://www.keil.com/epm900/
Ti allego anche questo link
http://photos.groups.yahoo.com/group/lpc2000/lst
C'è la foto (mal fatta) di una scheda di sviluppo che ho fatto per
l'LPC2138... quella con l'LCD grafico, lo zoccolo SD e quello USB. Con il 51
quelle cose non le avrei mai fatte.
http://photos.groups.yahoo.com/group/lpc2000/lst



Non vorrei offendere la sensibilità di qualcuno ma fra tutti i micro che ho
usato gli ST6 sono quelli che mi sono piaciuti di meno e tanto che ho lasciato
subito perdere.
Oltre a quello che hai detto mi sembra di ricordare che non avessero
l'istruzione AND e che per farla bisognava usare De Morgan.
Facendo un paragone con gli Atmel AVR, questi ultini mi sembrano di un altro
pianeta.
E non lo dico solo adesso, ecco un thread simile a questo:
http://shorterlink.com/?BUVBGN
ciao
  Stefano

 automazione non credo si possa chiedere piu di tanto....
No, ho specificato "memoria programma esterna": si intende la memoria dove
risiede il codice del tuo programma.
Il program counter negli ST6 non č accessibile, non c'č verso di far girare
il programma al di fuori dei 4K o 8K interni agli ST6. Se il tuo codice
eccede questa dimensione sei fregato, non hai alternative.
Con l'8051 hai almeno 64K di memoria programma indirizzabile esternamente.
Con i pic 17C44 puoi mantenere il codice dei 16 e indirizzare memoria
esterna.
Quello che tu dici č collegare una SRAM per metterci dei dati usando le
porte I/O, ma questa č un'altra cosa.
Ciao, Riccardo.

 
Hai ragione, avevo letto male......   :))