Ciao Zampa di Lepre,

chiedo scusa se sono sembrato rigido sulla mia affermazione...non volevo e non mi riferivo in questo caso alla resistenza ma a circuiti completamente diversi, che seppur sicuramente validi, ci tenevo a precisare che questo circuito era sicuro e testato. Nulla toglie che se vi va potete sperimentare cio che volete e lo condividiamo; Arduino qui è un cantiere aperto e ogni soluzione funzionante è ben accetta.

Ignoravo la presenza delle resistenze di pull-up interne, per cui non capendo il motivo del perché Mauro nei suoi tutorial le mette sempre, gli ho mandato una mail in merito alla vostra osservazione, e mi ha risposto che come riportato sul sito ufficiale di Arduino:

http://arduino.cc/en/Tutorial/AnalogInputPins

Pullup resistors
The analog pins also have pullup resistors, which work identically to pullup resistors on the digital pins. They are enabled by issuing a command such as

digitalWrite(A0, HIGH); // set pullup on analog pin 0

while the pin is an input.

Be aware however that turning on a pullup will affect the values reported by analogRead().

Per cui lui consiglia di utilizzare resistenze di pull-up esterne solo per non avere interferenze, ma nulla vieta di utilizzare quelle interne di pull-up.

Spero di aver chiarito qualche dubbio (o meglio, Mauro), grazie a tutti.


Per rispondere a qualcun'altro che aveva chiesto in precedenza, la differenza tra i pin di I/O analogici e digitali è che quelli analogici sono pensati per leggere valori di potenziometri o comunque dispositivi di questo genere. Per tutti i miei test ho utilizzato i soli pin di I/O digitali.

@Crystal13
beh ! sei disponibile al dialogo, ed allora ...
All' inizio della mia attività di progettista, mi capitò a volte di non dare molta importanza alla descrizione di difetti che il mio cliente mi faceva. Per poi arrivare a constatare personalmente ciò che mi era stato descritto.
Pensavo che il cliente non ne sapesse abbastanza per descrivere minuziosamente un difetto.
Poi imparai che anche una persona digiuna di tecnica, è in grado di osservare e riportare un fatto, anche se non ne conosce il motivo o il funzionamento.
Bella scoperta, vero ?
Nella presente discussione, però, è vero anche il contrario.

Fra tutti gli interventi, ce ne sono di persone che per mestiere applicano elettronica all' automazione o a campi simili.
Zampa di Lepre, max5726 (ma non sei un IC MAXIM !), Despx, BuddaceDCC e, particolarmente, marco_58
e chi lo ha fatto hobbisticamente e con ottimi risultati su plastici complessi :
Tz, Marcello(PT)

Ecco, proprio da quelli che ti ho nominato hai potuto constatare un qualche scetticismo.
E, se chi ci si è misurato, pone obiezioni, a mio avviso varrebbe la pena di approfondire, perchè potrebbero avere motivazioni che ad una prima analisi potrebbero sfuggire.
Mi sento di sintetizzare quei motivi nei due seguenti punti :

PROTEZIONI
Più di uno ha cercato di mettere in guardia dal fatto che, un conto è un funzionamento in laboratorio, ovvero in condizioni ottimali, con fili corti e con un ambiente quasi protetto. Altro conto è il funzionamento sul campo.
In uno degli interventi, marco_58 dava per scontata la presenza di protezioni ed interfacce fra ogni filo che esce dalla scheda ed il pin del processore. Non è una sua "invenzione". In campo industriale questo è un sistema consolidato e dato per scontato.
Un ingresso di un processore, collegato ad un filo di qualche metro, può ricevere spikes anche solo dall' accensione di una luce al neon della stanza. Lo spike è un impulso di pochi microsecondi e di parecchie centinaia di Volt, in grado di rompere il processore o di farlo saltare casualmente in un altro punto del programma.

Nel tuo caso potresti mitigare l' effetto tenendo la scheda vicina ai pulsanti. Ma il cavo lungo che anderebbe fino al servo, potrebbe creare problemi.
Nell' applicazione più generalizzata, invece, occorrerebbe fare più attenzione, poichè non tutti i casi si prestano ad un cablaggio sicuro per il funzionamento del processore.
Forse è questo che ti viene più obiettato. E che si risolve con una manciata di componenti, ma che richiede un po' di basetta e di stagnatore (non è obbligatorio fare un PCB a piste, la parte difficile, come dici tù, è già fatta).

MULTITASKING
E' una parola che certamente conosci. Per chi non lo sapesse, è una tecnica di programmazione per far eseguire ai processori più compiti contemporaneamente, ed in modo trasparente di ognuno rispetto agli altri.
Il tuo processore può interfacciarsi anche con 12 servo. Bene. Ma per come hai scritto il programma, li gestisce uno alla volta. Fino a chè non ha terminato un' operazione, non "ascolta" altri comandi. Quindi, per esempio, mentre stà abbassando le sbarre, non risponde al comando di girare uno scambio.
Questo porta una certa rigidità. Se poi lo si volesse applicare come periferica di un sistema più complesso, questa rigidità lo impedirebbe.

Lo si risolve con uno stile di programmazione simile a quello che avevo descritto a pagina 5, con routine non monopolizzanti. Sistemi che certamente già conosci, ma che per i principianti non sono precisamente semplici da far funzionare.

SERVO
Per il resto, credo che la tua idea sia valida. Un servo che può essere comandato a posizione, può consentire di tarare il movimento di ogni singolo scambio con precisione. E mi pare una buona cosa.
Come alternativa, senza processore, avevo proposto lo schema di pagina 13, che utilizza dei trimmers per determinare la posizione. Funziona solo coi servo ad ingresso analogico. Per funzionare con gli ingressi PWM avrebbe bisogno di qualche componente in più. In rete si trova uno schema con NE555, ma si può fare anche con amplificatori operazioneli (circuito integrato analogico parimenti molto comune e poco costoso).

parere piccolo, intervento lungo ...


Stefano Minghetti

Chiamarlo parere mi pare riduttivo, è semplicemente ed esattamente come stanno le cose.

P.S.
Però, il multitasking del multitasking è divertente, ho fatto impazzire più di qualcuno, perchè difficilmente si osa farlo (preferiscono venderti un'apparecchiatura di taglia e prestazioni superiori), ma se il microprocessore può fare fino a 8 livelli, pretendo che li faccia. Così come pretendo che mi faccia 8 livelli di parentesi in 8 gruppi di parentesi nella stessa espressione. Nel '90 io ed un mio cliente ci siamo "divertiti" a fare macro a iosa di questi tipi in un impianto.
Dico divertiti, perchè fare una programmazione tradizionale eccedeva i limiti dela CPU basata su processore serie X86 sotto tutti gli aspetti, usando: multitasking, parentesi e indicizzazioni a gò gò, ci ha permesso di aumentare di 8 volte le possibilità di gestione, riducendo di 10 volte i tempi di elaborazione, anche se si parla sempre di ms. Chi conosce la famiglia degli X86 sa cosa intendo.

bellissima, la rivendo.....



Anche per me hai spiegato bene lo stato delle cose!
Si possono usare / inventare decine e decine di soluzioni ai problemi tecnici, che spesso appaiono in fase post progetto (come ad es la sensibilità ai disturbi esterni): 2 sole cose rimarranno sempre le stesse! La legge di Ohm ed il teorema di Kirckhoff........

ciao

Max

Stefano, mi dispiace se mi sono fatto fraintendere. Ribadisco che sono un'umile cacchetta che tenta di imparare qualcosa, e ribadisco che non intendevo imporre che il circuito è quello e basta, semplicemente ho detto che funziona, ma ho letto attentamente cio che hai scritto e sono problemi che effettivamente ho sottovalutato.

Cerco di rispondere. Sul discorso protezioni sono d'accordo con te. Considerando che ai pin di arduino ci possono essere collegati (nel nostro caso) al più 5V, esiste comunque questo rischio? Ho cercato un po' in rete e il problema può essere ovviato inserendo magari tra pin e alimentazione una resistenza, uno zener a massa e un fusibile.
http://arduino.cc/forum/index.php?topic=116696.0

Per quanto riguarda il multitasking se ne è già parlato qualche pagina addietro, pero ti chiederei in qual caso sia necessario aspettare tra un'operazione e l'altra. Stiamo parlando infatti di operazioni che impiegano 2 secondi per muovere uno scambio (al vero gli scambi si muovono tutti contemporaneamente o in sequenza?) se lo si vuole fare in modo realistico oppure pochi millisecondi se non lo si vuole fare in modo realistico. Se tu fai uno sketch in cui tra un pezzo di codice e un altro passano 2 secondi, vuoi che te ne accorga? Non penso che muovi una serie di scambi a 5cm dall'arrivo del treno...penso che il movimento lo azioni molto prima (come è al vero).
Posso darti ragione sul PL, che nel mio caso impiega 8 secondi. Ma credo che alla fine non sia un problema cosi insormontabile.
Domanda: le funzioni dei decoder DCC vengono eseguite in parallelo o sequenzialmente?

Osservazione NE555: come dicevo ci ho già provato, prendendo schemi in rete. Ti posso assicurare che tra una scheda centralizzata come arduino e piu schede realizzate singolarmente, preferisco di gran lunga la centralizzata sia per facilità d'installazione (lo installi una volta e basta) sia perche non devi stare a costruire nulla.

Allora, al vero gli scambi si muovono sempre sequenzialmente, il primo, verificata l'avvenuta manovra con i feed back, comanda il secondo, e via di seguito. Parlando di ACEI è come se ci fosse un registro FIFO: primo ad entrare, primo ad uscire, questo per dire che l'itinerario si distrugge nello stesso ordine con il quale è stato creato.

Fermarsi 2 secondi su un'unica macro, spesso è deleterio, e ben poco funzionale, occore usare altre tecniche di programmazione, tra le quali c'è anche il multitasking, compatibilmente con le possibilità del processore.

I microprocessori, tutti, leggono ed eseguono sempre un operazione per volta, quindi sono sequenziali, quanto e come viene comandato dipende dai bit: 4, 8, 16, 32, ad esempio nel 16 posso leggere o scrivere 16 ingressi o 16 uscite digitali, ovvero convertire un I/O analogico in un numero e vv.. Poi ci sono i processori che lavorano a singola o doppia lunghezza, quindi è possibile raddopiare le capacità di elaborazione.
Il multitasking è in funzione dell'architettura di contorno al microprocessore, a prescindere se è un unico cip piuttosto che 2 o più.
Infine, salvo rari casi una macro, può essere lunga quanto vuoi ed elaborare diverse funzioni contemporaneamente, va da se che gli esempi che trovi in giro, anche nei manuali, sono sempre per il singolo problema. Ovviamente risolvere un problema alla volta è più semplice, ma è altrettanto semplice risolvere 1000 problemi contemporaneamente, basta vedere i singoli problemi in altro modo.

Un decoder è di fatto un microprocessore, con incorporate le sezioni di I/O.

Se si vuole che un programma evolvi rapidamente bisogna evitare il più possibile: IF, Then, Else, Wile, Do, Jump, Goto, e istruzioni simili, imparando ad utilizzare al meglio le parentesi.

E questo permette l'utilizzo di cavi di collegamento di dimensioni non eccessive: se tutti gli scambi venissero comandati in contemporanea, l'assorbimento istantaneo di corrente sarebbe tante volte maggiore quanti sono gli scambi azionati, il che implicherebbe cavi di sezione assai maggiore a monte del quadro distribuzione (questo vale anche in piccolo x dimensionare cavi adeguati per gli scambi sui plastici, problema secondario date le correnti in gioco....)


oppure utilizzare microprocessori dove certe funzioni sono realizzate in hardware (ad es. i PWM interni....)

ciao

Max(im)

NO!!!!! I deviatoi comandati da un itinerario si comandano tutti insieme!!!! Si muovono uno dopo l'altro SOLO i deviatoi formanti comunicazione.

Negli impianti più grandi (dove ci sono più di 8-9 deviatoi da comandare) si utilizzano partitori di comando, ma sempre in blocci da 8-9 deviatoi.

ciao

Come nel mio impianto in cui tutti i deviatoi di un itinerario partono contemporaneamente ma nelle comunicazioni prima parte l' "a" e quando va in controllo parte il "b"...

Nel precedente post mi sono dimenticato un concetto fondamentale.
Quando si parla di automazione o/e comando a distanza, a prescindere dal come ciò si costruisce: meccanico, idraulico, elettromeccanico, o elettronico, bisogan tenere ben distinte le azioni dai comandi e dai controlli.

Le azioni possono avvenire sia in milli secondi che in mesi: dall'accensione di un led di segnalazione all'essicazione di legname, passando da processi di stampaggio, piuttosto che di impastaggio, piuttosto che cottura o di inscatolamento.
I comandi ed i controlli invece debbono avvenire nel minor tempo possibile ed essere ripetuti all'infinito, ovvero fino a quando non sono più necessari, la differenza tra milli secondi e l'eternità è proprio questa.
Per essere sicuri che un processo, cioè una o l'insieme di più azioni avvenga con sicurezza nei modi che desideriamo, ogni organo che esegue azioni fisiche deve essere comandato e controllato in continuo, sulle modalità sorvoliamo un attimo, altrimenti scrivamo 1000 Treccani.
Tornando ai sistemi elettrici abbiano quattro possibilità:
- elettromeccanico in corrente alternata, considerato in tempo reale, i ritardi di risposta sono dovuti sia alla frequenza della corrente sia ai tempi propri delle apparecchiature, a 50 Hz si considerano mediamente normali, ovvero tempo reale, tempi entro i 30 ms
- elettromeccanico in corrente continua, considerato sempre in tempo reale, i ritardi di risposta sono dovuti solo ai tempi propri delle apparecchiature, quindi tempi entro i 20 ms
- elettronicostotalmente statico in corrente continua, considerato ancora in tempo reale, i ritardi di risposta sono dovuti solo ai tempi propri delle apparecchiature, quindi tempi entro i 5 ms
- elettronica a microprocessore, non si pò più consideralo tempo il reale, perchè impossibile da realizzare, però se si riesce a rimanere nei tempi di cui sopra, all'atto pratico si considera sempre tempo reale.

Con l'impiego dei microprocessori i tempi di ritardo sono dovuti a quattro situiazioni ben distinte, che non ci sono negli altri casi:
1- ritardi nell'acquisizione dei comandi dall'esterno e degli stati, cioè il cambio di stato dei suoi ingressi es. ON-OFF di: un pulsante, un microinterruttore, una fotocellula, sun segnale da comunicazione seriale, ecc.
2- tempi di elaborazione da parte del microprocessore, dovuti sia al come è costruito, sia al programma che deve elaborare, fermo restando che esegue sempre un'istruzione alla volta
3- titardo nel dare i comando, cioè il cambio di stato delle sue uscite
4- tempi di esecuzione del comando da parte dell'interfaccia di potenza, cioè transistor di uscita piuttosto che relè.

I tempi di ritardo introdotti dalle apparecchiature comaandate e controllate sono sempre uguali in tutti casi, un motore si avvierà sempre nello stesso tempo, una lampada diventa luminosa sempre nello stesso tempo. Relè o contatori di potenza, piuttosto che inverter o decoder reagiscono sempre allo stesso moda ad ogni solleciatazione specifica.

Da quanto sopra si deduce che le prestazioni dell'unione tra microprocessore e software è fondamentale. Lo stesso evento fisico (es. il movimento di un ago di uno scambio) a parità di microprocessore, può essere comandato e controllato sia congelando il processore in quella gestione, sia fecendogli fare altri milioni operazioni. La differnza dov'è, visto che in fin dei conti l'ago si muoverà sempre in due secondi. La differenza è che se congelo il processore in quello stato, in due secondi conando solo quell'ago, se al processore faccio eseguire sempre tutto il programma ad ogni scansione* in due secondi posso nuovere tutti gli aghi di tutte le ferrovie del mondo (sempre di avere un unico processore di tale potenza).
Quindi il funzionamento del sistema automatico comandato da microprocessore sarà considerati più performante, potente ed affidale in funzione di quante volte al secondo sarà eseguita la scansione.
Oggi si considerano di buon livello tempi di scansione di 5/6 ms per circa 10000 passi di programma, ipotizzando C possiamo dire che il paragone è a circa 15000 righe scritte con l'editor, commenti esclusi.

Per usi specifici esistono apparecchiature dedicate che eseguono circa 2000 passi di programma in 0,1 ms.
Si tenga però presente che nel campo industriale, così come in un SCC, da una certa taglia in su, le apparecchiature sono sempre multi processore: un master che coordina, e tanti altri che eseguono compiti specifici.
Direi proprio che tutto ciò non è proprio il caso di Arduino. Con Arduino bisogna lavorarci di software, ovviamente sempre nei limiti dell'hardware.


* Per scansione si intende la lettura e l'esecuzione di tutto il programma contenuto nella memoria del microprocessore.

Dici che se anche l' operazione occupa 2 secondi, non necessariamente il processore deve andare così lento. Vero. Questo significa che al processore può rimanere tempo per fare altro.
Ed a noi che siamo abituati, verrebbe sicuramente da fargli fare altre cose (interfaccia seriale, comando contemporaneo ...). Però non è mia intenzione spingere Crystal13 ad una applicazione complessa.
Se non ritiene di averne necessità ...
Non dico se si parlasse di ACEI, ma se solo avesse dei circuiti di binario, diventerebbe obbligatorio.

Quindi potrebbe anche rimanere una applicazione sequenziale, che sostituisce un po' di cablaggi e di componenti elettronici. Se si tratta di una stazione non molto grande, il tempo risulta accettabile ed anche l' effetto può venire bello.

Non solo. Si potrebbero aggiungere dei pulsanti che comandino una sequenza di scambi. Ovvero degli instradamenti, che possono anche comprendere il PL.
E si potrebbero pilotare dei leds che riportino la posizione presunta degli enti (Alex Corsico, Tz : voltatevi in là un momento per favore ...).


Tu hai trovato un modo originale per pilotare gli scambi, e lo hai condiviso con noi. Ti ringrazio perchè è una combinazione (scheda commerciale + servo economico) che non conoscevo.
Non vorrei dare l' impressione di volerti frenare.

La protezione :
resistenza e zener vanno bene, ma il fusibile è un po' drastico. Se intervenisse, addio processore. Con quella corrente, infatti, la tensione sullo zener sarebbe facilmente ben superiore ai 7V che il processore potrebbe sopportare.
Meglio fare così :

non è IL sistema, da utilizzare, ma solo uno dei tanti possibili. E non necessariamente il migliore.

Dato che un disturbo è, per sua natura, di durata limitata, non ha energia sufficiente a caricare il condensatore a tensioni che possano mettere in pericolo il processore.
Sono sempre fenomeni che si esauriscono in qualche decina di microsecondi.
Lo zener potrebbe anche essere omesso.
Ho portato il pull up fuori, così ho potuto usare resistenze di valori adeguati alla protezione.
Il circuito di ingresso ha una frequenza massima di circa 1500 Hz, più che sufficienti per l' applicazione cui è destinato.

L' uscita, essendo a bassa impedenza, ha meno necessità.

Se può essere utile ...


Stefano Minghetti

Stefano, anche io vi ringrazio per le vostre segnalazioni.

Quello che mi sento di dire è che nel nostro caso non stiamo usando Arduino per un ambito industriale, per il quale sono d'accordo che non è ovviamente concepito, ma per uno scopo hobbistico; poiché ai pin di I/O non sono collegati mai più di 5V, io credo (smentiscimi nel caso) che non si corra il rischio di avere gli spike.

Relativamente al multitasking, anche in tal caso credo che un'azione sequenziale non sia drammatica per i nostri scopi. Sono altresì d'accordo che il codice dovrebbe essere tuttavia il piu snello possibile. Ma considerate che, ad esempio, per la chiusura di uno scambio stiamo parlando di loop di un paio di secondi, se lo vogliamo realistico, e di millisecondi se lo vogliamo immediato.


Gianfranco

Mi spiegherò meglio con un esempio.
Quando in casa accendi una luce al neon, nella radio si sente gracchiare l' altoparlante. Anche l' immagine del televisore fà alcune righe. A Natale, le vecchie intermittenze causavano simili disturbi.
Quando accendi il trapano o il robot da cucina, idem.
Questo avviene perchè, anche se la tua schedina và a 5V e consuma pochi Watt, il generatore del disturbo funziona a 230V ed assorbe centinaia di Watt. E funge da trasmettitore.
La schedina ha il circuito stampato multistrato, ed in uno degli strati interni c' è un piano di massa che la mette abbastanza al riparo dal ricevere disturbi. Quindi, da sola, è affidabile.
Ma se colleghiamo un filo di qualche metro, allora questo è in grado di agire come antenna ricevente e di captare una parte di disturbo in grado di mettere in difficoltà la scheda.
Filtri e protezioni sono diffusi ovunque, anche se non li vediamo quasi mai.
All' interno delle prese USB, Ethernet, dei telefoni fissi, lungo i cavi di alimentazione o dei video (si vede un ringrosso che contiene una ferrite), etc.
Nessuna applicazione commerciale, anche se destinata ad uso casalingo o a plastici, si può permettere di mettere un pin di uscita direttamente collegato ad un filo.
Anche una locomotiva H0 è in grado di emettere disturbi di intensità sufficiente ad "impallare" un processore che non sia filtrato almeno un minimo.

Però, non voglio adombrare scenari tragici. Quando inizierai ad applicarlo ad un plastico, allora ti converrà fare qualche prova. La prima che farei è la seguente. Comandare due servo, alla massima distanza che il tuo impianto richiede, e controllare che mentre una locomotiva gira i servo non siano perturbati.


Stefano Minghetti

Allora, industriale o hobbistico che sia, noto che mancano diverse basi della programmazione, una qualsiasi, non importa.
Senza entare troppo nei dettagli faccio due banali esempi.

Soluzione 1

If pippo
then
set pollo
else
reset pollo

Soluzione 2

pippo -> pollo
in alternativa
pollo = pippo

Le due soluzioni fanno la stessa cosa, cioè mettono allo stato 1 la variabile pollo quando la variabile pippo è uguale a 1, ovvero a zero, solo che la soluzione 2 impegna il processore per un quarto del tempo ed occupa pure meno di metà memoria.

Una routine puo contenere diversi comandi (tralascio volutamente le dichiarazioni specifiche di: routine, riga, endif, commento, ecc.):

pollo = pippo
andrea = pippo and (mario or giuseppe)
lucio = 12 * marco
Vanni = (franco >= lucio) or (pippo and (luigi <> 23))

If pippo
then set_ton_2 = 23, start ton_2
else reset ton_2

dalia = ton_2
franceso = (gigi == (((vanni + 45) / lucio) or 16#07ff); bruno = vanni and dalia and pippo and (andrea or lisa)

Una qualsi ruotine o macro può gestire decine, se non centinaia, di situazioni diverse (dipende dal processore), quindi al suo interno posso comandare decine o centinaia di utenze.
Ad esempio i 10000 passi citati nel post precedente si riferiscono alla media delle macchine o impianti che faccio abitualmente, in pratica si tratta di gestire circa un migliaio di I/O. Ad esempoi una linea per imbottigliare bibite: partendo dalla lavatrice delle bottiglie vuote, arrivando fin davanti al palettizzatore, cioè la macchina che impila i fardelli o le cassette sulle palette, in mezzo ci sta la sciaquatrice, lo sterilizzatore, la riempitrice, la tappatrice, l'etichettarice, il pastorizzatore, e ancora uno sterilizzatore, il tutto contornato da tappeti e nastri trasportatori. Il tutto è paragonabile, come complessità, ad esempio alle stazioni: centrale di Milano, Termini, Bologna, ecc.. Il programma può girare sia su un solo processore o su più processori che ad ogni scansione eleborano ed eseguono tutto il programma in pochi ms, ad esempio una linea per succhi di frutta riempie tipicamente 125000 boccetti ora, che equivale a circa 35 al secondo (che equivale a circa 28 ms a boccetto, cioè un boccetto transita, ed è lavorato, solo per 28 ms in ogni stazione), per essere sicuri che ogni boccetto sia gestito correttamente bisogna che la sua parte di programma sia elaborara almeno 10 volte dal microprocessore, e siccome solo la riempitrice ha almeno una decina di stazioni che eseguono le varie operazioni riempimento, solo con l'adeguata programmazione è possibile utilizzare i microrocessori.
Potrei anche postarvi qualche esempio di programma, ma solo vedendo il programma è come se dicessi che Peppino tifa per la il San Pollo.

Tralascio i linguagi grafici o a lista d''istruzione, perchè richiedono conoscenze specifiche.

Parlando di programmazione, bisogna anche tener conto che:
- il linguaggio che ha maggiore efficienza (numero di istruzioni/funzione) è l'assembly. Se ci sono di questi problemi è l'unica soluzione, anche se c'è da scervellarsi assai...
- con i linguaggi di alto livello, ogni compilatore interpreta a suo modo una certa funzione: tutte le volte che la si richiama viene tradotta allo stesso modo: ma il risultato di compilatori diversi può non essere lo stesso. La potenzialità del compilatore può essere talvolta limitata per ragioni di licenza (e quindi di costo)
- quando l'utente raggiunge una certa padronanza del linguaggio di programmazione, di trucchi come quelli indicati da Marco ne trova a decine.....
- l'efficienza aumenta se una funzione viene realizzata in hardware dal micro, piuttosto che da software dedicato

per avere un'idea: un qualsiasi micro da 2 € può eseguire oltre 4000000 di istruzioni assembly al secondo, di tempo x controllare il mondo esterno ce n'è abbastanza. Certo, per sistemi complessi come quello dell'esempio di Marco, tutto deve essere dimensionato a modo....



Infatti le prove di compatibilità elettromagnetica, note perchè permettono l'applicazione del marchio CE sulle apparecchiature, sono composte da:
- prove di reiezione disturbi sulla linea d'alimentazione.
- prove di reiezione disturbi radio emanati a distanza nota e di potenza nota
- prove di reiezione disturbi elettromagnetici esterni, emanati a distanza nota e di potenza nota
- misura di perturbazione elettrica sulla linea di alimentazione dovuta all'apparecchiatura in prova



Concordo! anzi, mi permetto di dare qualche semplice suggerimento:
- bypassare la linea d'alimentazione del servo con un condensatore da 100-1000 nF posto nelle immediate vicinanze del servo stesso
- se l'impedenza d'ingresso del segnale del servo fosse alta (io non ne conosco il valore....), per aumentare l'immunità ai disturbi collegherei sull'ingresso del servo una resistenza verso massa ed una vero il + dello stesso valore (ad es. 2,2kOhm): così facendo si 'carica' la linea di segnale sia che questa sia a 0 sia che sia ad 1. Meglio ancora se si utilizza un driver di linea come interfaccia in uscita dal micro (ho fatto funzionare un vecchio 68HC12 senza driver e con le sole resistenze in ambiente industriale d'officina, trasferimento dati a 40 KHz su 4 mt. di cavo.)

saluti

Max