Leggere bene tre encoder con Arduino UNO

[hellfire39]

Ricordavo bene.

Io mi riferivo a questo modulo.

cattura.jpg

Non mi è mai capitata una applicazione dove collegare un encoder ad un contatore veloce.

[tecno67]

E' un modulo specifico. Non qualcosa di built-in nella CPU come ho detto io quando parlavo di max 50kHz. Se vedi prevede pure una uscita ed un ingresso. Da usarsi molto probabilmente per fare un reset, una cattura al volo od un azionamento al volo raggiunto un preset inviato dalla CPU. In pratica sei nella mia stessa situazione con l'Arduino. Conti veloce senza perderti impulsi. Ma comunque le azioni che fai dalla CPU non sono in real-time coi valori che leggi. Tranne ovviamente il caso del mero azionamento di una uscita al raggiungimento di un valore precaricato. Senza azione dalla CPU. Una sorta di riflesso condizionato che insegni prima al modulo. Non il risultato di una elaborazione con n casi ed n reazioni consequenziali. La stessa cosa che fai con un comune contatore a preselezione con la differenza che il preset arriva dalla CPU.

[tecno67]

E' un modulo specifico. Non qualcosa di built-in nella CPU come ho detto io quando parlavo di max 50kHz. Se vedi prevede pure una uscita ed un ingresso. Da usarsi molto probabilmente per fare un reset, una cattura al volo od un azionamento al volo raggiunto un preset inviato dalla CPU. In pratica sei nella mia stessa situazione con l'Arduino. Conti veloce senza perderti impulsi. Ma comunque le azioni che fai dalla CPU non sono in real-time coi valori che leggi. Tranne ovviamente il caso del mero azionamento di una uscita al raggiungimento di un valore precaricato. Senza azione dalla CPU. Una sorta di riflesso condizionato che insegni prima al modulo. Non il risultato di una elaborazione con n casi ed n reazioni consequenziali. La stessa cosa che fai con un comune contatore a preselezione con la differenza che il preset arriva dalla CPU.

[hellfire39]

E' esattamente quello che avevo detto di avere. Ne più ne meno.

hanno schede dedicate per la lettura degli encoder differenziali. Un avanzo che dovrei avere nell'armadio (ET200S 1COUNT), se non ricordo male, legge fino a 500 kHz.

Ma comunque le azioni che fai dalla CPU non sono in real-time coi valori che leggi

Che poi qui potremmo aprire tutto un altro dibattito OT su cosa è real-time sul plc.
Sono sicuro che se non ho tanti nodi, l'aggiornamento della periferia del profibus è sicuramente comparabile se non minore del tempo ciclo del PLC. Quindi non mi aspetto un valore tanto più vecchio di quello della CPU
Per non parlare delle CPU ET200S intelligenti che se le possono leggere direttamente.

[tecno67]

Sono sicuro che se non ho tanti nodi, l'aggiornamento della periferia del profibus è sicuramente comparabile se non minore del tempo ciclo del PLC. Quindi non mi aspetto un valore tanto più vecchio di quello della CPU

Tempo di ciclo che è sempre dell'ordine dei millisecondi. Ovvero anche con un PLC che costa qualche centinaio di euro rischio di svolgere un azione magari 100/200 conteggi dopo di quando il mio contatore ha raggiunto un determinato valore (non confondere il valore corrente del contatore con il valore che un pur efficiente Bus di comunicazione ti fa avere nel PLC ad inizio ciclo). Infatti di solito tu con un PLC dai una quota od una velocità ad un azionamento od una scheda di posizionamento, non lo gestisci dalla CPU. Lo fai solo se stai parlando di un applicazione non al limite e vuoi risparmiare l'HW aggiuntivo. Infatti alcuni costruttori, tra cui Siemens ed Omron offrono la possibilità di farlo il posizionamento con la sola CPU... Coi limiti di velocità e di dinamica che possono offrire. Non è che a sto mondo si debba per forza muovere tutto alla velocità della luce.
Avere un conteggio che non si sia perso qualche impulso è sempre necessario. Avere una lettura che sia aggiornata al miliardesimo di secondo ed elaborarla alla stessa velocità, non è detto che sia indispensabile in molte applicazioni reali.
Esempio: Per tagliare da una bobina di tessuto in pezzi da 20mt viaggiando a 40/50mt al minuto con una tolleranza di 5-10cm, non è che serva un controllo in Ethercat. Spesso basta un semplice conteggio con pre-quota e rallentamento negli ultimi 50-100cm ed un buon controllo di tensione sul materiale.

Il sunto è sempre quello.

-Si possono leggere 9 contatori a 20/30KHz con un Arduino: SI

-Si possono controllare 9 motori in closed-loop con Arduino: NI. Perché non ho abbastanza pin per farlo e se anche li avessi, usando magari un Mega invece di un UNO R3, il loop di controllo sarebbe talmente lento da essere ridicolo a 500Rpm, a 10/15 magari lo si può pure fare.

-Si può provare a leggere più di un Encoder con un Arduino per giocare un po e studiare una metodologia per ottimizzarne la lettura a prescindere dall'HW o dal linguaggio che poi useremmo in un ipotetica applicazione effettiva, magari a solo scopo didattico: SI.... almeno spero!

Se poi tu usi solo encoder line-driver a 20mega-impulsi/giro, sono contento per te.... Non ti divertirai a giocare con Arduino!

[hellfire39]

pur efficiente Bus di comunicazione ti fa avere nel PLC ad inizio ciclo).

Attenzione che le PAW/PEW sono asincrone. Non sono aggiornate ad inizio ciclo con l'immagine di processo, ma in sincrono con il bus.
Ho visto utilizzare questa caratteristica con delle librerie RFID per velocizzare gli handshake.

Comunque: io non ho mai usato encoder che non fossero attaccati ad un motore. Quella scheda, su ET200 era collegata ad un tastatore di cui mi interessava il valore finale. In una seconda release del progetto è stata completamente sostituita con un tastatore assoluto GT2 della keyence.

In generale, se volessi fare qualche controllo più o meno spinto sul plc, penso mi orienterei sulle cpu tecnologiche. Con le quali non ci sono certo problemi di prestazioni (magari di prezzo).

Esempio: Per tagliare da una bobina di tessuto in pezzi da 20mt viaggiando a 40/50mt al minuto con una tolleranza di 5-10cm, non è che serva un controllo in Ethercat. Spesso basta un semplice conteggio con pre-quota e rallentamento negli ultimi 50-100cm ed un buon controllo di tensione sul materiale.

Qui siamo d'accordo. Sono un sostenitore che ogni soluzione vada tarata sulle prestazioni richieste (ma non meno eh!).

Si possono leggere 9 contatori a 20/30KHz con un Arduino: SI

SI, se non fai nient'altro.

Si possono controllare 9 motori in closed-loop con Arduino: NI.

Se ci riesci, lo voglio vedere. Certo 10 rpm non vale! Il controllo delle correnti temo sia troppo veloce per convivere con una valanga di interrupt.
Qui torniamo ai PIC, che con le loro CIP offrono molte possibilità HW in più

Se poi tu usi solo encoder line-driver a 20mega-impulsi/giro, sono contento per te.... Non ti divertirai a giocare con Arduino!

No, no. Come dicevo prima, di solito gli encoder non li vedo proprio, se ne stanno belli bellini attaccati al motore e collegati agli azionamenti.
Raramente mi sono capitata applicazioni di misura in cui l'encoder finiva altrove (labview).
Per il resto, il mio peggior nemico è stato quel tastatore della heidenhain per il quale mi sono intestardito a voler creare un DRO da utilizzare per la regolazione fine dei tool dei robot scara.

[tecno67]

Ok tagliamo corto e pensiamo ai poveri studenti di elettronica ed hobbysti che non hanno la fortuna, solo per ora glielo auguro, di giocare con le apparecchiature un pò più serie con cui giochiamo noi grandi.

In allegato la versione 9 encoder ad 8bit commentata. Se poi non siete esosi e di encoder ve ne bastano 6 o meglio ancora tre non è molto difficile eliminare i settaggi per gli ISR e la parte di codice delle porte non impiegate, far lavorare magari il solo PORTC e lasciare liberi i PORTB e D per comandare magari dei servo o dei motorini DC giocando magari a costruirsi un robottino oppure aggiungere un LCD e farsi il DRO made in ITIS Pinco Pallo invece che made in China. Così fate pure un po di esercizio.
Se avete intenzione di usare quei classici encoder a 58 Impulsi giro per manopole, ricordatevi che sono elettromeccanici, soggetti a rimbalzi dei contatti e quindi se non si prevedono dei filtri RC non funziona nulla. Peggio ancora se la ISR è pure veloce.

Buon divertimento!

Se poi riuscite a farci un closed loop a 2 o tre assi senza nessuna pretesa commerciale (basta che gira), mostratela ai vostri prof. magari saranno un po più benevoli, premieranno l'iniziativa e ci rimediate pure quanche credito. 9 assi onestamente sarebbe davvero chiedere troppo. Se riuscite a fare un loop molto veloce magari potrete pure usare l'artificio di gestire i counter a 32bit all'inizio del ciclo sommandoci ogni volta il delta tra lettura ad 8 bit attuale e la precedente (ricordatevi il cast delle variabili). Sarà difficile, visto quello che abbiamo discusso, ma provate. Se non ci riuscite la versione 3 encoder a 32bit ve l'ho postata. Provate pure magari a modificare l'ASM per leggere dei segnali di tipo impulso/direzione invece che segnali in quadratura in modo x 4. Non è difficile.

nove_encoder_HFx4_v1_8bit.rar

[hellfire39]

Ok.

se vedo uno studente che riesce ad implementare correttamente un controllo closed-loop su tre motori (ma su che motori? stepper? brushless?) fatto bene, con Arduino, gli offrirei volentieri una birra e tutta la mia stima.
Intendo un vero controllo di posizione, con loop di corrente, velocità e posizione. Ma fatto bene, che giri almeno fino a 1000 rpm.
Perché, se uno studente mi portasse una cosa inutile, non lo considerei un fatto positivo.


Per la cronaca, dentro i miei driver open-loop DQ542MA, c'è un Freescale MC56F8013. Un micro a 16 bit con DSP e hardware dedicato per il controllo motori, tra cui PWM avanzati (alta frequenza, possibilità di accoppiarli, dead-and per prevenire i corti, ecc).
Per pilotare uno stepper ad anello aperto.
Sarei sinceramente sorpreso di vedere un AtMega328P fare lo stesso lavoro.


Ho la sensazione che, in tutto il thread, quando abbiamo parlato di controllo ad anello chiuso non intendevamo la stessa cosa.

[tecno67]

Non è nulla che userei nella realtà pratica è sempre e solo per divertirsi un po. Serve a capire ed a far capire meglio alcuni concetti. Fornire un esempio di realizzazione a chi si appassiona all'argomento. Chi per formazione, esperienza o semplice disinteresse non apprezza, può semplicemente passare oltre.

I motori però li muove e funziona. (Non vuol dire che dovete usarlo. Vi dico che non è solo una trattazione teorica astratta, che lascio fare a chi ha basi culturali migliori delle mie, è qualcosa di pratico e reale, interessante e divertente... con tutti i suoi limiti)

controllo_2x_DC_CL.rar

Ora non ho telefono con me. Appena possibile posto una foto del tutto.

[hellfire39]

L'ho detto che non ci capiamo!

Tu parli di motori in corrente continua.
Io parlo di controllo di stepper o brushless, per i quali devi controllare le correnti in modo molto veloce.
Tant'è vero che i micro normalmente utilizzati hanno pwm appositi per controllare i ponti.

La differenza tra le prestazioni richieste è tanta!

Per i motori in CC ci sono tanti esempi, vedi i vari pendoli inversi. E dubito che in quel caso ci sia bisogno di scomodare l'assembler.

[tecno67]

L'ho detto che non ci capiamo!

Tu parli di motori in corrente continua.
Io parlo di controllo di stepper o brushless, per i quali devi controllare le correnti in modo molto veloce.

// Una gestione closed-loop su passo-passo sarebbe stata ovviamente più complicata, dovendo gestire due uscite per motore. Avrebbe richiesto pure
// due MDD10 ed il loop di controllo correnti con sensori esterni sarebbe stato obbligatorio dato che la limitazione offerta dagli MD
// non è regolabile esternamente. Oltre a modularla, si sarebbe pure dovuto calcolare la fase con cui applicare le correnti per evitare lo stallo dei motori.
// Decisamente più complesso! In un DC questa cosa è intrinseca nel motore.

Non mi sembra di aver detto il contrario in quello che ho scritto nelle righe di commento in testa al programma.

per comandare magari dei servo o dei motorini DC giocando magari a costruirsi un robottino

Io ho parlato di Closed-loop, letteralmente significa anello chiuso ed identifica una modalità di controllo, non gli oggetti su cui si attua questa modalità e se vuoi ho apertamente specificato che il candidato di preferenza erano i DC (Servo possono essere anche quelli da modellismo non necessariamente un Brushless). Che si dovesse fare su dei passo-passo o brushless lo hai aggiunto tu.
Non puoi modificare i termini di ciò che io propongo per poi attaccare la validità di ciò che ho proposto, per il semplice fatto che a quel punto non stiamo più parlando della cosa che ho proposto io.

Lo so bene che la gestione dei passo-passo e dei brush-less (Termine usato a sproposito da molti pure questo, anche se ormai entrato nel gergo, dato che qualsiasi cosa senza spazzole è un brushless, quindi per assurdo anche un'asincrono senza driver), ma qui il tema è che stiamo facendo qualche piccolo esperimento, senza nessuna valenza pratica di utilizzo.
Per cui se la cosa ti appassiona, ti interessa, e pensi di poter dare un contributo che vada oltre il classico 'le cose serie non si fanno così', scendi dall'olimpo del motor-control (in cui hai dimostrato di sapere il fatto tuo bisogna dartene atto) e 'giochi' con noi comuni mortali. Se invece ritieni che sia solo tempo perso, lo dici una volta, come è lecito e permesso a tutti e poi smetti di partecipare alla discussione. O hai del tempo da perdere e quindi in fondo sei come me?

Detto con molta franchezza e senza voler offendere nessuno, ti chiedo solo frenare un po questa tua smania di bloccare sul nascere ogni cosa che non sia fatta secondo i dettami della buona tecnica corrente e degli oggetti disponibili sul mercato (che traspare in molte risposte che dai qui sul forum). Le ragioni (anche valide) per cui lo fai le hai già esposte più di una volta, ma sta buono un attimo... Rilassati! Si può anche giocare.

Se io dico che un oggetto in movimento nel vuoto, se non lo tocchi (perdona la semplificazione), continua a muoversi come prima, non serve che mi ricordi che sulla terra nel mondo reale c'è un atmosfera una gravità e quant'altro. Lo sappiamo già. Semplicemente ci serve ipotizzarlo per spiegare un principio. Se io compro un driver già bello e pronto, ho un bel driver per costruire la mia CNC, ma delle tecniche che usa non imparo nulla. Ed è anche inutile che mi compro una Ferrari se voglio solo esercitarmi alla guida. Tiro fuori dal cassetto il mio bell'Arduino che avevo già perché mi piace l'elettronica e provo a far qualcosa.

Vedi hellfire tu hai, e lo hai anche dimostrato delle buone competenze, del resto mi sembra che tu sia un ingegnere ed è bello che tu le voglia mettere a disposizione degli utenti del forum. Si vede dal numero totale dei post che hai inviato. Ma non è bello che ogniqualvolta un utente inizia una discussione, proponendo/chiedendo qualcosa, magari anche senza nessuna pretesa di utilizzo reale, o magari anche dicendo qualche castroneria, tu lo rintuzzi subito. Non siamo ne a scuola, ne in una azienda. Siamo su un forum fatto anche di semplici appassionati (poco o per niente competenti) che vogliono poter fare, magari sbagliando le loro prove ed esperienze. Ad irritare, è capitato anche a me purtroppo, non è ciò che dici, ma il come lo dici e la veemenza con cui lo fai (frase tipica: 'Queste sono cose mi mandano in bestia'). E' evidente, soprattutto al giorno d'oggi le soluzioni commerciali sono la via più economica per molti problemi, ma perché perdere il piacere di provare una volta tanto a far qualcosa da sé?

[hellfire39]

Come vuoi.
Però, se qualcuno pubblica un progetto, mi sento in dovere di evidenziarne gli aspetti critici.

Voglio dire, anch'io passo tanto tempo a fare cose che hanno senso solo per me e che non sarebbero capite da altri.
E' un po' lo spirito hacker (inteso nel senso buono del termine).
Ma se rendo pubblico un progetto, devo aspettarmi delle critiche.

In questo caso avevo anche ignorato il primo post, perché immaginavo che avremmo potuto litigare.
Ma poi, avendo visto anche il secondo post, ho pensato comunque che fosse interessante mettere la cosa nella giusta prospettiva, cioè evidenziarne i limiti di utilizzo.

------------------

P.S. i brushless (senza trattino) sono i brushless. Nessuna persona che ha che fare con i motori quando sente il termine brushless pensa agli asincroni. Brushless è un termine comunemente utilizzato per i motori sincroni (anche se pure i motori ad induzione non hanno spazzole).
In vent'anni che lavoro nessun fornitore di motori ha avuto dubbi su cosa intendessi quando chiedo un motore brushless.

[Aggiungo: è sbagliato invece l'utilizzo del termine servo che implica un uso del motore, non una tecnica costruttiva.]

https://en.wikipedia.org/wiki/Brushless ... tric_motor
https://it.wikipedia.org/wiki/Motore_brushless

[tecno67]

Però, se qualcuno pubblica un progetto, mi sento in dovere di evidenziarne gli aspetti critici

Daccordissimo, ma mi farebbe piacere che venisse evidenziata non tanto la sostenibilità e l'utilità economica, ma piuttosto gli errori e le criticità nell'impianto teorico e metodologico di quello che viene proposto. Oppure vengano spese delle parole di elogio se vi è qualcosa che sia anche solo diverso da quello che fanno i più e che in rete trovi copiato e ricopiato all'infinito purtroppo. Tu invece di solito nelle tue repliche, che spesso sono le prime ad arrivare, non solo con i miei post, evidenzi prevalentemente quello.
Visto che sei del mestiere potresti pure proporre delle alternative, magari anche delle migliorie allo stile di programmazione, ma sempre con l'uso dell'oggetto proposto.

Voglio dire, anch'io passo tanto tempo a fare cose che hanno senso solo per me e che non sarebbero capite da altri.

Qui si evidenziano due cose:

1) La presunzione di supporre che altri non capiscano o possano capire le cose che fai o semplicemente disprezzare/apprezzare quello che fai e magari trarne pure degli spunti. Di quale utilità è?

2) Ammetti implicitamente che il desiderio di provare e sperimentare è dentro di noi. Ed allora perché spesso fustighi questo impulso anche quando è presente in persone con un livello di studio magari più basso del tuo? Che male fanno?


https://it.wikipedia.org/wiki/Servomotore

magari dei servo o dei motorini DC

Qui c'è un'altra cosa che non va. Come vedi dal link allegato, si può parlare di servo anche con un oggetto che non sia elettrico.
Ma a parte quello, se io scrivo 'Servo' perché tu mi metti in bocca 'Brushless'?

Termine usato a sproposito da molti pure questo, anche se ormai entrato nel gergo

Se l'ho già detto io che è un termine improprio, ma ormai entrato nell'uso comune, perché ci fai polemica sopra (pure sui trattini)?

In definitiva ti dico e ti domando:

Abbiamo cominciato male il nostro rapporto, anche per colpa mia magari che sono stato brusco già dopo la tua prima Reply nel post precedente. Ti ho spiegato cosa mi ha indispettito (Al riguardo ricordati la parabola del figliol prodigo nel vangelo). Ora ti sto offrendo la mano.... non puoi semplicemente dire anche tu: 'Siamo partiti male', hai fatto una cosa carina. Scordiamoci il passato, così poi magari ci mettiamo a discutere e magari pure a collaborare sul closed-loop (che piace ad entrambi), come domenica scorsa quando alla fine hai testato il mio sketch e Vi hai trovato pure delle caratteristiche anche superiori (seppur di poco) a quanto fatto da una persona probabilmente più abile del sottoscritto con Arduino?

[hellfire39]

Daccordissimo, ma mi farebbe piacere che venisse evidenziata non tanto la sostenibilità e l'utilità economica, ma piuttosto gli errori e le criticità nell'impianto teorico e metodologico di quello che viene proposto. Oppure vengano spese delle parole di elogio se vi è qualcosa che sia anche solo diverso da quello che fanno i più e che in rete trovi copiato e ricopiato all'infinito purtroppo

Mi dispiace, ma se non riesco a capire il senso di fare qualcosa, non riesco ad apprezzarlo appieno. Sono "tarato" sulla lunghezza d'onda del lavoro, per cui, cerco lo strumento adeguato per il lavoro che devo svolgere. Quindi se ho uno strumento che fa (molto) meglio un certo lavoro non riesco a pensare di utilizzarne uno che lo fa peggio.
Con la mia ottica, è come se qualcuno mi avesse detto: "guarda come ho arato 10 ettari di terreno con questa zappa!, dimmi che sono stato bravo". La prima cosa che mi viene in mente è: "ma perché non hai usato il trattore!" E' più forte di me: notare l'irrazionalità di una cosa.

spesso sono le prime ad arrivare

In alcuni casi, le sole. Riconosco che gli argomenti sono abbastanza spinti e ben fuori dalla portata dell'utente medio che installa grbl alla cieca.
Questa volta mi ero pure morso la lingua e mi ero imposto di non rispondere al primo post.

1) La presunzione di supporre che altri non capiscano o possano capire le cose che fai o semplicemente disprezzare/apprezzare quello che fai e magari trarne pure degli spunti. Di quale utilità è?

Si, ho la presuzione di capire se quello che sto facendo è una grossa sega mentale! Ma se penso che la cosa possa interessare (e se ho la costanza di completare quello che sto facendo, lo condivido volentieri.

Ammetti implicitamente che il desiderio di provare e sperimentare è dentro di noi.

Certo che lo ammetto. Ma se non capisco l'utilità dell'esperimento, non la capisco.
Ribadisco il concetto: sei stato bravo a scrivere quel pezzo di codice, ma lo reputo inutile per due ragioni:
- l'assembler è incomprensibile (una delle regole dello sviluppo sw è: pensa a chi verrà dopo di te!)
- l'incremento di prestazioni è irrilevante nell'uso pratico

L'unica volta che ho usato l'assembler con un pic (a quel tempo non avevo ancora compilatori), per fare le luci del presepio, pensa te, ho imprecato in aramaico antico.

Ed allora perché spesso fustighi questo impulso anche quando è presente in persone con un livello di studio magari più basso del tuo?

Quello che fustigo è l'incompetenza. Il voler fare cose che si ignorano completamente, senza studiare. E, credimi, si capisce se uno è completamente a digiuno di un argomento oppure no.

Sui brushless, ho solo risposto ad una tua affermazione, che mi sembrava polemica. Polemicamente.
Un po' come ho percepito in tono polemico l'affermazione sui servo.
Di solito, in questo forum, chi parla di servo si riferisce ad azionamenti brushless ad anello chiuso. E volevo solamente far notare che servo indica una funzione, come dice il termine stesso.

Ma a parte quello, se io scrivo 'Servo' perché tu mi metti in bocca 'Brushless'?

Mi è sfuggito il momento in cui avrei fatto confusione.



Se reputo un progetto interessante, sarò felice di dare il mio contributo.

[tecno67]

Riconosco che gli argomenti sono abbastanza spinti e ben fuori dalla portata dell'utente medio che installa grbl alla cieca.
Questa volta mi ero pure morso la lingua e mi ero imposto di non rispondere al primo post.

E' una tua opinione. Lo stesso post pubblicato sul forum italiano di arduino, è stato visualizzato 141 volte e scaricato da 12 utenti,quello da tre encoder e 4 volte quello da 9 encoder. Uno di questi è addirittura un Faraday member (in totale ce ne sono 17 su più di 60000 iscritti). Uno sketch molto rudimentale in cui controllo due DC in closed loop (pubblicato ieri mattina) ha già visto 19 visualizzazioni.
Come vedi c'è anche chi non la pensa come te. Capisco invece che su un forum di CNC l'interesse sia minore.

mi ero imposto di non rispondere al primo post

Visto che proprio non riusciamo ad entrare in sintonia, posso chiederti di morderla più forte la lingua la prossima volta?

Si, ho la presunzione di capire se quello che sto facendo è una grossa sega mentale!

Guarda che io dicevo che la presunzione era nel decidere che altri non potessero capire quello che tu fai (il che, a casa mia, equivale a ritenerli degli stupidi. - L'hai mai pensato?). La tua capacità di capire te stesso e quello che fai, può anche creare problemi ad altri, ma non era il problema in discussione.

L'unica volta che ho usato l'assembler con un pic (a quel tempo non avevo ancora compilatori), per fare le luci del presepio, pensa te, ho imprecato in aramaico antico.

Io invece no. Perché dato che ancora da studente avevo programmato (sempre per diletto) con l'assembler Z80, questa esperienza a più di 30 anni di distanza mi ha aiutato a faticare meno. Piuttosto devo dire che il set di istruzioni dello Z80 era più ricco, ma questo è normale dato che l'ATmega 328P è un RISC.

Sui brushless, ho solo risposto ad una tua affermazione, che mi sembrava polemica. Polemicamente.

Guarda che la polemica qui non era sul tipo di motore, ma sulla pessima abitudine di cambiare le parole altrui quel tanto che basta da potersi creare gli argomenti per poi giustificare le critiche fatte.

Se reputo un progetto interessante, sarò felice di dare il mio contributo.

Tempo scaduto! Vista l'accoglienza ricevuta, non so se in futuro condividerò altro. Peccato!