AiutateCi ad aiutarVi

[Standardoil]

Ovvero se si parte col piede giusto si va come un treno....

Questo thread è dedicato a chi chiede aiuto, esperti o inesperti, giovani o vecchi, tutti abbiamo avuto bisogno di aiuto.

Vorrei solo chiedere, e spero in questo di non essere solo, che ci aiutiate ad aiutarvi ...
... pochi semplici consigli, che più di essere una "imposizione" siano una "indicazione", fidatevi che seguire le buone pratiche si fa prima che a non seguirle (peraltro se le hanno inventate una ragione ci sarà...)

Nessuna di questi consigli è obbligatorio, ma diciamo che "invitano" ad aiutare, oltre che mettere sulla strada giusta per aver meno bisogno di aiuto

Ed ora la parte utile, l'elencazione:

1) indenta bene il codice: ne discutiamo qui:
https://forum.arduino.cc/index.php?topic=617572.msg4185233#msg4185233

2) metti un titolo che descriva il problema
https://forum.arduino.cc/index.php?topic=617572.msg4191852#msg4191852
che stai cercando aiuto per un problema lo sappiamo già, se sei qui sei qui per quello...

3) Spiegalo bene, il tuo problema, perchè noi non lo conosciamo:
https://forum.arduino.cc/index.php?topic=617572.msg4197803#msg4197803

4) Assicurati di avere gli strumenti necessari: ovvero conoscenze, conoscenze e conoscenze (lo ho già detto conoscenze?)
https://forum.arduino.cc/index.php?topic=617572.msg4209434#msg4209434

5a e 5b) prova, prova fino alla nausea (e poi ricomincia)
https://forum.arduino.cc/index.php?topic=617572.msg4210481#msg4210481


6) Non sei mica il primo che ha problemi, cercare non ti farà male, in particolare come Maurotec ha segnalato al post 8
Hai un problema con Arduino? Leggi qui
Grazie a Maurotec,
6b) aggiunta mia:
ci sono alcuni problemi ricorrenti, per questi problemi nel tempo è stata sviluppata una serie di "tecniche" più diciamo "standard", come dire: "ricorrenti anch'esse", provate a dare uno sguardo al post:
 La pappa è fatta
come minimo ci vedete degli esempi, non pretendo che siano "perfetti" ma che siano da ispirazione sì

[Standardoil]

E allora, rotto il ghiaccio, vado io con la prima proposta:
Consiglio zero: posta il codice ben indentato e formattato

da notare che non propongo uno specifico stile di formattazione, quello standard dello IDE va benissimo, o anche uno personale, ma UNO stile ci vuole

c'è una ragione tecnica ottima per indentare il codice:
viene istintivo "seguire" i varii branch del programma, quel'è la parte if, quale la parte else, cosa fa dentro nel for...

^{Personalmente io non aiuterò più chi non lo fa
Ragione: è talmente semplice farlo con la formattazione automatica che se uno non lo fa  è o un completo incapace (inutile aiutarlo, gli serve altro) o un completo maleducato (da ignorare)}

[Standardoil]

Suggerimento due, (che per la verità non era proposto da me)
Mettete dei titoli che siano significativi
Aiuto per un problema NON lo è.... per nulla, tutti quelli che hanno bisogno di aiuto hanno un problema
Aiuto sono senza un problema lo è, in effetti è molto significativo, ma non in una direzione esplicativa
mettiamola in questa maniera: voi siete dei fruttivendoli, in una strada dove "ogni" porta è un negozio di fruttivendolo, rispondete a questa domanda: "perché il cliente deve venire a comperare proprio le MIE mele?"
mettete un titolo che "attiri" l'attenzione di può aiutarvi:
"Devo collegare un GPS e una radio HC12 allo stesso arduino, mi manca una seriale, come posso fare?" è un po' lungo, ma rende subito l'idea
"Non mi vanno i servo quando uso la seriale: è normale?" è ben fatto
ah, per inciso:
Se scrivete non mi vanno i servi io vi ignorerò, la ragione è semplicissima:
il 'C' è un linguaggio piuttosto critico nella forma (maiuscole/minuscole e similia)
se NON riuscite nemmeno a coniugare bene l'Italiano a "maggior" ragione non saprete scrivere in 'C'
il plurale di servomotore (abbreviato servo) fa servomotori (abbreviato ancora servo)
condizione propedeutica per scrivere bene in un qualsiasi linguaggio ('C' compreso) è scrivere bene almeno nella propria lingua madre

[Standardoil]

Suggerimento tre
Descrivi bene il problema, non chiedere come fare per fare quello che vuoi fare
Non è per mancanza di fiducia, ma spesso le persone si "incastrano" cercando una via per una soluzione che 'credono' sia giusta o ideale
Descrivi bene il problema, che ti possiamo aiutare a trovare la soluzione
Esempio, capitato spesso, leggere un file 'strano' che in realtà potremmo scriverci noialtri 'più comodo'
Quindi descrivi bene il problema, ma descrivilo tutto, che non capiti dopo aver fatto il grosso del lavoro, di scoprire che deve andare in ambiente ostile, oppure che vuoi che vada a batteria, o che verrà montato su una moto.
Ci tengo molto all'ultima riga, perchè spesso mi è capitato di "buttare via tutto il lavoro" perchè chi chiedeva aiuto si era "dimenticato" le cose più importanti, per il futuro: evitiamo

Aggiunta della Befana 2020:
dai una bella lettura a questo articolo
https://it.wikipedia.org/wiki/Problema_XY
e quando lo hai letto tutto ricomincia...
sappi che se mi/ci fai perdere tempo su un'apetto marginale e inutile mentre il tuo problema è da tutt'altra parte ci perdi solo tu, in credibilità e punti: ovvero "dopo" più nessuno ha ancora interesse a perdere tempo con te.
lo so, sembra una cosa da squali, ma il mondo reale non è sempre ideale.......

[AmericanDreamer]

Idea numero 5:
Metti lo schema, mettilo tutto
E prova i componenti, provali tutti
Ne ho viste io di macchine che voi umani...
Macchine utensili che non vanno
E poi è solo la spia di acceso bruciata
E giù colpe al povero manutentore

[Standardoil]

Suggerimento 4
gentilmente offerto da Sua Moderazione Guglielmo (e non è una presa in giro)
Copio e incollo integralmente:

con il copia/incolla si arriva a far lampeggiare un LED e poco altro. Se volete veramente realizzare qualche cosa, dovete trovare il tempo e dedicare tale tempo allo studio

cosa dire? che ha ragione! ecco cosa debbo dire...
la possibilità che un programma "raccattato in rete e copiincollato senza guardare troppo per il sottile" vada bene per le vostre specifiche esigenze è pressocchè nulla
significa che "purtroppo" dovete fare le cose alla vecchia maniera:
-Studiare i principi della programmazione
-Studiare il linguaggio
e questi sono i passi propedeutici, pesantucci, ma almeno si fanno una volta sola
-Capire il problema, che nautrlamente va fatto per ogni problema
-Studiarne una soluzione
- questa riga è volutamente vuota
-Tradurre nel linguaggio la vostra soluzione
- questa riga è volutamente vuota

Le righe vuote:
Le righe vuote sono per un'aggiunta mia, che forse non tutti sarebbero d'accordo, la vendo per quello che è: una opinione personale:
Ri-prendete in mano il problema, riprendete in mano la soluzione, riprendete in mano il programma, e "sfrondate", tagliate tutto quello che potete, cancellate tutto quello che potete, riducete al minimo tutte le variabili, tutti i cicli, tutte i comandi
per ogni variabile domandatevi: Mi serve per cosa? cosa ci scrivo? cosa mi indica? da dove la vado a prendere l'informazione che ci scriverò dentro?
Ricominciate da capo
Per ogni comando che scrivete domandatevi: perchè lo sto facendo? è proprio necessario? a cosa serve fare la cosa che sto facendo? e se non lo faccio?
Ricominciate da capo
state tranquilli che se fate così vedrete che il programma complicato lungo e pieno di comandi, si riduce a vista d'occhio, rimangono solo pochi comandi con poche variabili
Un grande dell'industria moderna, un certo Henry Ford non so se avete presente, diceva: quello che non c'é non si rompe
Io che ho imparato da lui, più modestamente dico: il programma corto ha meno spazio per contenere errori

ma tutto questo è una mia personale opinione

Per il momento fermiamoci alle prime righe:
studiare studiare studiare

sotto qui troverete alcuni link, gentilmente segnalati da Sua Moderazione

risorse on-line
http://cabestano.altervista.org/alterpages/files/TizianaMarsella-ProgrammareArduino.pdf

https://drive.google.com/file/d/0B2OYiD2XGofOVkpodUFNaFNweWM/view

Un buon libro (opinione personale: Molto Buono, vale la spesa)
Il libro di un certo Leonardo Miliani, da inchinarsi

Una collezione di link utili
https://www.amazon.it/Arduino-essenziale-linguaggio-librerie-elettronica/dp/8865374837
E naturalmente il "libro con la 'C' maiuscola": il K&R
che forse per un principiante non serve (balle, serve, ma è presto per prenderlo), lo prenderete al prossimo problema di programmazione

[docdoc]

Suggerimento numero 6: Sperimentare i singoli aspetti prima di metterli insieme in un progetto.

Non incaponitevi nel cercare di far funzionare un progetto che non funziona e che al suo interno ha vari componenti e varie librerie, perché le cause potrebbero essere tante.

Prima cosa, abituatevi a creare un progetto "di laboratorio" (o "lab") con UN solo componente per volta, se possibile usando uno degli esempi della relativa libreria. E se possibile fatelo sempre ogni volta che iniziate a lavorare per la prima volta con un componente/libreria, prima ancora di iniziare il vero progetto finale.

Tutto questo perché i problemi possono essere anche più di uno, ed è necessario imparare a saperli isolare per avvicinarsi sempre più al problema. Esempi:

* Un componente (es. un display LCD) non funziona come ci si aspetta, o almeno non con l'uso che ne state facendo: leggete la relativa documentazione per capire se quello che volete ottenere è previsto;

* Un componente non fa quello che dovrebbe fare ed il problema potrebbe essere software, ossia:

• la libreria che usate non è quella adatta allo specifico componente ma magari ad uno molto simile: verificate nella documentazione della libreria se ci sono indicazioni in tal senso
• la libreria che usate è giusta ma è obsoleta: nel dubbio, aggiornate sempre alle ultime versioni
• non usate bene la libreria: vedere gli esempi a corredo e sperimentare separatamente

* Un componente non fa quello che dovrebbe fare ed il problema potrebbe essere hardware, ad esempio:

• Componente difettoso: se lo è, anche con un "lab" lo potete capire, e farvelo sostituire o acquistarne uno migliore (ad esempio i sensori ad ultrasuoni HC-SR04 sono spesso fallati, mentre con gli SRF05, che costano pochi cent in più, mai avuto problemi)
• è collegato in modo non corretto ad es. occorre un pin PWM e lo avete collegato ad uno non PWM: mantenete gli stessi collegamenti fisici e fate la prova con lo sketch "lab"
• Il componente va in conflitto con un altro componente del progetto o le due librerie in qualche modo non sono compatibili: se isolate il problema con un "lab" separato per ognuno dei componenti, e da soli funzionano bene ma quando li mettete insieme no, significa che qualcosa di hardware o software è in conflitto per cui bisogna capire di cosa si possa trattare (e questo è il caso più difficile da gestire) cercando in rete e nei forum se qualcuno ha avuto lo stesso tipo di problema

[Standardoil]

Suggerimento 5a e 5b
che sarebbe un suggerimento doppio in quanto fusione di due differenti,
di AmericanDreamer (che non so ancora se è americano il sogno o il sognatore....)
Metti lo schema, mettilo tutto prova i componenti, provali tutti
Ovvero: evitiamo di "scoprire" dopo 18 pagine di post che il programma andava, era solo bruciato il diodo LED ( e potrei citare un caso anche più drastico che dopo molte pagine si scopre che non si sapeva bene cosa si aveva in mano...  accaduto pochi mesi fa, forse il sognatore americano ricorda, c'era anche lui, anzi eravamo tutti alla stazione sì, ma dormivamo tutti - Ivano Fossati)
anch'io, come AmericanDreamer, ho un passato tecnico, per l'esattezza tecnico d'assistenza esterna
non avete idea delle volte che mancava la corrente ma "La vostra macchina di M... non va di nuovo"
e andare fino in Brasile per scoprire che non avevano collegato un paio di fili scoccia alla grande (cioè, non a me che ci ho guadagnato le ferie, ma alla ditta molto)
provate ogni singola cosa, e poi ri-provatela
a mano
e poi, come suggerisce docdoc nel suggerimento 6 (rinumerato 5B, è il fratello maggiore del 5a)
prova i singoli pezzi del programma, provali tutti
prova accendere un LED, a tempo, poi fallo accendere a comando, poi metti un automatismo, poi attaccalo a internet
prova la comunicazione col pc, poi prova i comandi, poi prova da internet
prova attaccandoti ad internet ad un server "conosciuto", poi con quello che ti serve, che se parti con uno che non sai se "lui" va, poi non sai se "tu" arrivi
Se volete leggere gli originali, sono i post 4 e 6

[Maurotec]

Ricordo che tempo addietro io e nid facemmo questo:https://forum.arduino.cc/index.php?topic=170968.0

Ciao.

[Silente]

Ho i consigli numero N e numero ++N
Consiglio --N (N è già salito di 1, quindi lo abbasso fate un debug come si deve! La cosa vale soprattutto per i codici semplici, nei quali non si pensa mai di fare debug. Un corretto uso della seriale (per questo tipo di uso basta saper usare la Serial.print, quindi neanche problemi di protocolli ecc) permette di identificare, credo, il 50% dei problemi, ed è facilmente eli minabile in sede successiva (e si usa una #define basta cambiare quella riga, altrimenti si apre il programma in un gestore di testi e vai di cerca e sostituisci
Consiglio ++N, Commentare, ma in modo utile. Ogni codice è comprensibile al suo autore (possibilmente voi), ma lo potrebbe non essere al suo lettore (ovvero noi). In aiuto al lettore vengono i commenti, se son ben fatti. Ora, "ben fatti" cosa vuol dire? È inutile, inutile, inutile, e ancora una volta inutile commentare ogni funzione scrivendo quello che fa, che delay (1000) fa aspettare 1 secondo lo si capisce, basta sapere un po di inglese e avere un minimo di inventiva, se proprio, per capire che sono millisecondi. Quello che può non capirsi è cosa l'autore vuole che un certo pezzo di codice faccia. Quindi commenti come

Code: [Select]


delay (500);//Aspetto mezzo secondo
digitalWrite (2, HIGH);//Accendo il pin 2
byte stato=digitalRead (4);//Creo una variabile "stato" e le assegno il valore letto sul pin 4

non aggiungono informazione, e sono solo uno spreco di tempo e di spazio.
Commenti, invece, come
 //Qui faccio lampeggiare il led una volta al secondo //In questa funzione setto i pin come le variabili apposite indicano
possono essere utili al lettore per capire cosa l'autore crede che una data parte di listato faccia, e di conseguenza aiuterà a trovare la falla che impedisce il funzionamento voluto.
Io ho l'abitudine anche di scrivere all'inizio dei miei programmi cosa voglio ottenere alla fine dal codice, ma non è necessario

[maubarzi]

Descrivi dettagliatamente il sintomo del problema e verifica che il problema sia proprio quello che ti sembra!
Si evita di lavorare al problema sbagliato.

Capita spesso che si chieda consiglio su un problema ma poi il problema sia tutt'altro.
Ad es. Arduino si pianta, dopo un po' non attiva più i dispositivi...
Iniziano le discussioni su Watchdog, Filtri per i disturbi elettrici, cavetti difettosi e alla fine si scopre che il programma non entra più sulle parti di codice che attivano i dispositivi perchè non ci sono i valori attesi nelle variabili testate.
Quindi, se pare che Arduino si pianti, verificate prima che sia effettivamente vero che si è piantato!
Qui basta far blinkare di continuo il led della scheda nel loop principale. Se si ferma si è piantato, se non si ferma il problema è sul codice.
Altre volte si debugga Arduino quando invece il problema è in un componente esterno che non risponde, ad es. un web server. Verificate prima che questo server funzioni veramente.

[docdoc]

PROPOSTA:
una volta raccolto un certo numero di consigli e riunito in un unico testo, perché non pensare di aggiungerlo anche (ossia resta comunque qui la versione "dinamica") al documento Arduino BC su cui si sta lavorando?

[Standardoil]

Pienamente d'accordo
Come hai fatto notare una certa persona potrebbe rivendicare dei diritti su una vecchia opera
Sarebbe interessante mettere in chiaro che la nostra è completamente nuova, per contenuti e impaginazione
E anche sarebbe utile che la moderazione togliesse, se già non è così, l'accesso a quella persona, che così non possa cancellare le sue promesse.
In caso di contestazione poter dimostrare chi ha affermato cosa in tempi non sospetti verrebbe molto utile

[C1P8]

provate a dare uno sguardo al post:
 La pappa è fatta
come minimo ci vedete degli esempi

Ma posso copiare giù senza pietà?

Che me ne faccio la mia base ?

[Ducembarr]

E poi, dato che lo abbiamo studiato, mio fratello ed io, un consiglio aggiuntivo:

usate un formatter.conf personalizzato, per l'indentazione del codice

abbiamo scopiazzato in giro e abbiamo pensato che questo sia un buon compromesso tra tutte le esigenze

Code: [Select]


# Questo file di configurazione contiene una selezione di opzioni per il tool di formattazione "Artistic Style"
# http://astyle.sourceforge.net/astyle.html
#
# Se volete cambiare qualcosa non cambiate direttamente questo file
# Piuttosto copiatelo nella cartella dove c'è il file "preferences.txt" e modificate tale copia. In questa maniera non perderete le vostre impostazioni personalizzate se fate un aggiornamento di IDE
# Se non sapete dove sia il file "preferences.txt", aprite l'IDE, e guardate dal menu File -> Preferences, troverete il link alla cartella
# Versione personalizzata 1.8.10
# Dinamico Duo 18/02/2020


# linguaggio C anche se l'estensione non è standard
mode=c

# indentazione 3 spazi
indent=spaces=3

# indentare anche le macro
indent-preprocessor

# indentare classi, switch (e casi), i commenti cominciano in colonna 1
indent-classes
indent-switches
indent-cases
indent-col1-comments

# Uno spazio intorno agli operatori
pad-oper

# Uno spazio dopo if/for/while
pad-header

# mantiene eventuali statement su singola linea
keep-one-line-statements


# via gli spazi prima dei commenti
remove-comment-prefix

# Stile di formattazione
--style=allman

# eliminare spazi tra le parentesi
-U

# asterisco del puntatore separato da variabile e tipo
-k2

# ampersand di riferimento separato da variabile e tipo
-W2

# separare i blocchi if/else/switch dal resto del sorgente
-f

# cancellare linee vuote in eccesso
-xe

# aggiungere parentesi graffe intorno a branch di singola riga
-j

# spezzare le righe di operatori booleani troppo lunghe
-xL



prima che tu (standardoil) ce lo dica: sì ci siamo ispirati pesantemente a te (e al barr group)
se ti offendi veniamo fino a Varese a farci pagare una birra alla Poretti, abiti li no?


quindi il nostro consiglio è:
tenete in ordine le vostre idee e le vostre righe di codice: formattate, formattate sempre, anche di fronte all'evidenza

che se non lo fate vi si "intrecciano tutti i diti" come diceva Fracchia
tradotto in italiano: si confonde la "visione generale del programma"

Grazie per aver riaperto la discussione, aspettavamo solo di agganciarci


abbiamo allegato il nostro formatter.conf, solo abbiamo dovuto aggiungerci l'estensione.txt altrimenti non passava
se lo scaricate togliete l'estensione aggiunta