Arduino Uno: chi ci gioca?

[andore]

Originalmente inviato da aero330

Il motore a spazzole è una brutta bestia...le commutazioni delle spazzolle sul collettore producono scintille e quindi picchi di tensione (leggi disturbi) che potrebbero dar fastidio a tutto il circuito. Probabilmente la tensione non è ben stabilizzata, io metterei un condensatore elettrolitico da qualche uF sull'alimentazione, ma ElNonino saprebbe indirizzarti meglio.

Per curiosità, questo modulo di alimentazione esterno com'è fatto? riesci a dare più info? tensione in uscita, corrente max fornita....

Il modulo sarebbe questo ed era già compreso nel full kit elegoo

Verifica su Amazon.it
WINGONEER MB102 Tagliere 3.3V/5V modulo di alimentazione 3.3V/5V per Arduino https://www.amazon.it/dp/B01DCZIY2U/..._r5ZhzbEASTM7J

[ElNonino]

Originalmente inviato da andore

Il modulo sarebbe questo ed era già compreso nel full kit elegoo

Verifica su Amazon.it
WINGONEER MB102 Tagliere 3.3V/5V modulo di alimentazione 3.3V/5V per Arduino https://www.amazon.it/dp/B01DCZIY2U/..._r5ZhzbEASTM7J

Quanto assorbe il motorino perchè quel modulo al massimo regge 0,7A e che alimentatore usi per dare la scossa al tutto ?

[aero330]

Originalmente inviato da ElNonino

@andore: per il problema dei disturbi prova a mettere un condensatore in parallelo al motorino, meglio due: un elettrolitico da 22uF..47uF ed un altro ceramico da 10nF, od anche tre, l'elettrolitico e due da 10nF saldati fra i fili di alimentazione del motore e la carcassa dello stesso.

@aero330: per mediare il valore letto dal convertitore AD è meglio usare una media mobile in potenza di 2 lavorando con interi e poi usare lo shift a destra al posto della divisione, solo alla fine fare un unico casting in float che ci sarebbe anche il modo di evitarlo (forse).

Il casting in float, i calcoli in float ed i prinf sono estremamente lenti sui piccoli micro ad 8 bit come quello di arduino 1.

Un altro suggerimento: è buona norma nel assegnare nomi alle variabili usare un prefisso che identifichi il formato della stessa, ad esempio:

- count è meglio chiamarla u8count od u8_count se si usa un intero ad 8 bit senza segno, etc.

Tutti giusto, non fa una piega.
Per quel poco di programmazione che mi hanno fatto vedere durante gli studi il fatto di nominare le variabili u8cnt, u16cnt proprio non l'avevo mai sentita.
In un codice semplice potrebbe anche andare ma in in listato lungo e complesso non potrebbe disorientare??

[andore]

Originalmente inviato da ElNonino

Quanto assorbe il motorino perchè quel modulo al massimo regge 0,7A e che alimentatore usi per dare la scossa al tutto ?

Il motorino non saprei, come faccio a misurare l'assorbimento?

Le specifiche dell'alimentatore (sempre compreso nel full kit) sono queste: INPUT 100/240V AC 50/60Hz OUTPUT 9V DC 1A

Prima o poi mi faccio un alimentatore decente

[aero330]

Originalmente inviato da andore

Il motorino non saprei, come faccio a misurare l'assorbimento?

Le specifiche dell'alimentatore (sempre compreso nel full kit) sono queste: INPUT 100/240V AC 50/60Hz OUTPUT 9V DC 1A

Prima o poi mi faccio un alimentatore decente

Con queste caratteristiche l'alimentatore è in grado di fornire abbastanza corrente al modulo di energia esterno visto che 1A > 0.7A.

A questo punto il motorino potrebbe assorbire più di 0.7A.....fai questa prova: collega in SERIE al motore DC un tester e misura l'assorbimento di corrente...da ON -> OFF potresti leggere un valore alto di corrente per via dello spunto, ma a te serve sapere più che altro quando è a regime (il massimo)

[ElNonino]

Originalmente inviato da aero330

Tutti giusto, non fa una piega.
Per quel poco di programmazione che mi hanno fatto vedere durante gli studi il fatto di nominare le variabili u8cnt, u16cnt proprio non l'avevo mai sentita.
In un codice semplice potrebbe anche andare ma in in listato lungo e complesso non potrebbe disorientare??

Invece è prprio nel listato lungo che serve, perchè così ti ricordi l'ordine di grandezza ed il tipo di variabile, specialmente quando il compilatore da dei warning, ad esempio può capitare di scambiare anche una variabile puntatore con una normale.

Un altro aspetto da considerare per scrivere un buon codice è non infarcire di righe il loop di programma inserendo li il codice stesso, molto meglio creare funzioni e chiamarle dal loop principale, ad esempio nel programmino per dex:

Loop
LeggiADC();
Media(ADC);
DisplayData();
end loop


Questo consente di avere una visone chiara delle funzioni del programma di isolare più facilmente i bugs e di ottimizzare le funzioni chiamate in maniera autonoma.

Se interessa potrei suggerire anche un sistema RTOS molto semplice ma assai efficace per scrivere programmi puliti e veloci.

A chi interessato consiglierei di scaricarsi dalla rete il manuale del "MISRA C" sono le indicazioni per scrivere codice sicuro e testabile alle quali bisognerebbe attenersi se si lavora in automotive, ferroviario, marino etc. non è specialistico ma insegna molto ed è estremamente utile.

Usare buone regole di scrittura è assai utile quando si deve riprendere in mano un programma dopo 10 anni...

[andycar]

Originalmente inviato da ElNonino

Invece è prprio nel listato lungo che serve, perchè così ti ricordi l'ordine di grandezza ed il tipo di variabile, specialmente quando il compilatore da dei warning, ad esempio può capitare di scambiare anche una variabile puntatore con una normale.

Un altro aspetto da considerare per scrivere un buon codice è non infarcire di righe il loop di programma inserendo li il codice stesso, molto meglio creare funzioni e chiamarle dal loop principale, ad esempio nel programmino per dex:

Loop
LeggiADC();
Media(ADC);
DisplayData();
end loop


Questo consente di avere una visone chiara delle funzioni del programma di isolare più facilmente i bugs e di ottimizzare le funzioni chiamate in maniera autonoma.

Se interessa potrei suggerire anche un sistema RTOS molto semplice ma assai efficace per scrivere programmi puliti e veloci.

A chi interessato consiglierei di scaricarsi dalla rete il manuale del "MISRA C" sono le indicazioni per scrivere codice sicuro e testabile alle quali bisognerebbe attenersi se si lavora in automotive, ferroviario, marino etc. non è specialistico ma insegna molto ed è estremamente utile.

Usare buone regole di scrittura è assai utile quando si deve riprendere in mano un programma dopo 10 anni...

Quoto ogni singolo pixel...

[aero330]

Originalmente inviato da ElNonino

Invece è prprio nel listato lungo che serve, perchè così ti ricordi l'ordine di grandezza ed il tipo di variabile, specialmente quando il compilatore da dei warning, ad esempio può capitare di scambiare anche una variabile puntatore con una normale.

Un altro aspetto da considerare per scrivere un buon codice è non infarcire di righe il loop di programma inserendo li il codice stesso, molto meglio creare funzioni e chiamarle dal loop principale, ad esempio nel programmino per dex:

Loop
LeggiADC();
Media(ADC);
DisplayData();
end loop


Questo consente di avere una visone chiara delle funzioni del programma di isolare più facilmente i bugs e di ottimizzare le funzioni chiamate in maniera autonoma.

Se interessa potrei suggerire anche un sistema RTOS molto semplice ma assai efficace per scrivere programmi puliti e veloci.

A chi interessato consiglierei di scaricarsi dalla rete il manuale del "MISRA C" sono le indicazioni per scrivere codice sicuro e testabile alle quali bisognerebbe attenersi se si lavora in automotive, ferroviario, marino etc. non è specialistico ma insegna molto ed è estremamente utile.

Usare buone regole di scrittura è assai utile quando si deve riprendere in mano un programma dopo 10 anni...

Concordo pure io, ma per un principiante alle prime armi con queste cose non è meglio magari lasciare le cose più "semplici"? Del resto parliamo di codici ancora abbstanza "snelli" anche ss quello e dici è giusto e lecito se si vuole ottimizzare al massimo e fare le cose con criterio

[ElNonino]

Originalmente inviato da aero330

Concordo pure io, ma per un principiante alle prime armi con queste cose non è meglio magari lasciare le cose più "semplici"? Del resto parliamo di codici ancora abbstanza "snelli" anche ss quello e dici è giusto e lecito se si vuole ottimizzare al massimo e fare le cose con criterio

mhhhh: "dai ad un uomo un pesce e lo sfami per un giorno, insegnali a pescare e lo sfamerai per la vita"

Aforismi a parte, se si inizia da subito ad essere precisi, metodici ed ordinati nella scrittura del codice quando sorgeranno difficoltà maggiori si avranno i mezzi e le conoscenze per superarle in autonomia; la grammatica e le lingue è bene impararle da piccoli se no poi si fa fatica.

Ad esempio se dal main loop chiamo la funzione CalcAdc ed oggi la funzione è scritta come la tua ma domani decido di implementare la media mobile e un singolo cast, mi basterebbe lavorare sulla funzione e non sul main, cosa assai più facile.

Per esperienza so che le richieste delle funzioni di un programma sono come le ciliege, tutti mangiano la prima ma poi si ingurgitano tutto cesto.... quindi i programmi sono destinati a crescere quasi all'infinito ed a complicarsi in poco tempo, pertanto meglio cominciare bene.

IMHO

[aero330]

Originalmente inviato da ElNonino

mhhhh: "dai ad un uomo un pesce e lo sfami per un giorno, insegnali a pescare e lo sfamerai per la vita"

Aforismi a parte, se si inizia da subito ad essere precisi, metodici ed ordinati nella scrittura del codice quando sorgeranno difficoltà maggiori si avranno i mezzi e le conoscenze per superarle in autonomia; la grammatica e le lingue è bene impararle da piccoli se no poi si fa fatica.

Ad esempio se dal main loop chiamo la funzione CalcAdc ed oggi la funzione è scritta come la tua ma domani decido di implementare la media mobile e un singolo cast, mi basterebbe lavorare sulla funzione e non sul main, cosa assai più facile.

Per esperienza so che le richieste delle funzioni di un programma sono come le ciliege, tutti mangiano la prima ma poi si ingurgitano tutto cesto.... quindi i programmi sono destinati a crescere quasi all'infinito ed a complicarsi in poco tempo, pertanto meglio cominciare bene.

IMHO

È una cosa a cui non avevo pensato....