Far funzionare autonomamente un Arduino??

Buongiorno a tutti, essendo alle mie prime esperienze con Arduino, non sono ancora molto pratico e mi piacerebbe imparare qualcosa da voi esperti.

Sto progettando un programma con delay molto MOLTO lunghi, (ore ed ore), è una storia lunga...
Dunque mi piacerebbe sapere se esiste un modo per far funzionare non solo da remoto, ma anche autonomamente Arduino senza lasciare acceso il pc... chiedo troppo forse?

Mi piacerebbe ricevere una breve dritta spiegata perchè non me ne intendo molto... grazie mille della pazienza!!!

?? forse non ho capito io, ma ... Arduino si programma da PC ma poi lo puoi staccare dall'USB e Arduino lo alimenti da altra fonte e lui fa girare il programma SENZA pc.

ah ok ottimo grazie,

ma quindi devo caricare lo sketch, staccarlo, alimentarlo e fa tutto da solo? ho capito bene?

Certo…

ok, avrei solo l'ultimissima domanda, (non prendetemi per un babbeo, non ho esperienza mannaggia)

E' possibile far fare a Arduino un loop lungo.? e con lungo intendo VERAMENTE ma veramente lungo??
dovrei usare il delay?
(parlo di giorni, mesi di uno stesso loop ahahah lo so sono pazzo)

comunque sia è possibile?

Un programma Arduino è già un ciclo infinito. Dietro ad uno sketch c'e' un normalissimo programma C:

void main()
{ setup();
  while(1)
  { loop();
  }
}

Quindi hai una setup() chiamata all'inizio 1 volta sola e poi una loop() chiamata in eterno

Usando millis() e non delay() puoi fare dei calcoli sul tempo trascorso, anche molti giorni.
La delay() accetta valori unsigned long ma anche millis() è un unsigned long, quindi al massimo 4294967295, essendo mllesimi, 4294967 secondi, 1193 ore, circa 49.7 giorni

Se devi fare calcoli su tempi lunghi e certi mi pare però meglio usare un orologio RTC

Su tempi superiori alle 24 ore, l'errore di millis() o di delay() è così grande, da rendere obbligatorio l'uso di un RTC esterno per avere una decente precisione. :wink:

Guglielmo

Concordo pienamente con gpb anche perché così nell'RTC è possibile inserire una batteria tampone..

Se proprio non vuoi acquistare un RTC, puoi usare un programma sicuramente più complesso in grado di sollevare un interrupt dal timer1 ad 1 secondo precisissimo, quindi nella ISR andrai a incrementare una variabile che ad ogni ssecondo si incrementa..tieni presente che non appena l'alimentazione di Arduino cessa, si perdono i valori di tutte le variabili. Potresti comunque risolvere con la EEPROM interna.. ecco QUI con tutta la bella spiegazione dietro :smiley:

Gianky00:
Se proprio non vuoi acquistare un RTC, puoi usare un programma sicuramente più complesso in grado di sollevare un interrupt dal timer1 ad 1 secondo precisissimo .....

A si ? ? ? E secondo te millis() come funziona ? E ti pare precisissima ?

Te l'ho già detto una volta, prima di fare certe affermazioni, sarebbe consigliato studiare bene ciò di cui si parla ... altrimenti si rischia di dare indicazioni errate ::slight_smile:

Guglielmo

Millis dipende dal clock che nel caso del Arduino UNO R3 viene generato da un risuonatore ceramico.

La precisione di un risuonatore é intorno al 0,5%. Questo corrisponde a un errore di 432 o ca 7 minuti al giorno.

Per il confronto un quarzo come monta un RTC ha un errore intorno al 100ppm ovvero 8 secondi.

Un DS3231 corregge la dipendenza del quarzo alla temperatura e raggiunge una precisione del 20ppm ovvero ca 2 secondi al giorno di errore.

Ciao Uwe

Ringrazio tutti per le delucidazioni, ho capito che il delay su tempi lunghi non è precisissimo, ma non mi sono spiegato bene:

quello che dura 5 mesi interi è il loop, e mi pare che, per quello che mi avete detto, su questo non ci siano problemi (forse?)

il mio sketch non utilizza singoli delay della durata di MESI o giorni interi, ma al massimo di 11 - 12 ore, forse anche di meno.

dite che è fattibile utilizzare delay (o millis) con questi tempi? (11-12 ore) ? avrò un errore spropositato oppure è una cosa sostenibile? grazie.

Spropositato in base a cosa?

Dipende da cosa vuoi fare
Irrigazione va facilmente fuori. Come precisione, o vuoi irrigare col sole di mezzogiorno?

Se invece cicli una batteria per vedere la durata, l'errore potrebbe essere accettabile

Cosa vuoi fare?

Io propongo un approccio più pratico: inizia a fare lo sketch come hai in mente, se poi trovi che la precisione non sia accettabile, aggiungerai un RTC.

Alessio7894:
quello che dura 5 mesi interi è il loop, e mi pare che, per quello che mi avete detto, su questo non ci siano problemi (forse?)

Il problema non sono i 5 mesi, Arduino può funzionare per tutta la durata della sua vita, molti anni, prima di un guasto.
Il problema è la precisione degli eventi, se non ti interessa che avvengano ad orari precisi, ti basta che avvengono dopo tot ore, metti in conto errori di qualche minuto se usi il clock di Arduino come riferimento, non ti serve un RTC.
Se ti serve una buona precisione sia come intervalli tra gli eventi sia come orario di attuazione allora è indispensabile un RTC.
In tutto questo devi mettere in conto che Arduino è progettato per fare da piattaforma di sviluppo e test sul banco del laboratorio, come tale ha molte carenze sotto il profilo alimentazione e protezione dai disturbi, non so cosa devi fare esattamente però metti in conto dei possibili reset, o crash, di Arduino dovuti a problemi di alimentazione o disturbi.
Ovvero, non è detto Arduino, inteso come scheda commerciale, riesce a funzionare senza mai bloccarsi, o resettarsi, per 5 mesi, dipende da dove e come lo devi usare.

gpb01:
A si ? ? ? E secondo te millis() come funziona ? E ti pare precisissima ?

Te l'ho già detto una volta, prima di fare certe affermazioni, sarebbe consigliato studiare bene ciò di cui si parla ... altrimenti si rischia di dare indicazioni errate ::slight_smile:

Guglielmo

Quello sketch che ho linkato sopra, crea un interrupt ogni secondo. In quell'ISR si incrementa una variabile 'secondi'. millis() dipende molto da quanto carichi il tuo sketch quindi meno loop ti fa al secondo e meno preciso sarà..oltre ovviamente al fatto che già non è preciso di suo.. che poi pure il timer 1
è così..generando un interrupt non interessa quanto carico sia il tuo sketch, ad un secondo incrementa la variabile.

Comparando il timer1 impostato a 1 secondo, con CTC e prescaler, io ho visto che millis() mi perdeva circa 2h ogni 24h rispetto al timer1.. il timer1 ogni 24h ha aggiunto 1 min e 12s rispetto il mio cronometro del cellulare.

Va bene che la misurazione l'ha fatta un essere umano e non una macchina.. però si vede chiaramente come il millis() non sia assolutamente preciso..mentre il timer1 molto più preciso rispetto il millis proprio per l'ISR..di sicuro nemmeno i timer1 va bene per un RTC, chiedo scusa per l'informazione sbagliata che ho detto. Comunque, sapendo l'errore viene poi molto semplice andarlo a correggere via software potendolo utilizzare come RTC. A me personalmente questo errore va più che bene per il mio utilizzo che non è quello da RTC ma di svolgere la mansione di contatore per massimo 10 ore.

Gianky00:
millis() dipende molto da quanto carichi il tuo sketch quindi meno loop ti fa al secondo e meno preciso sarà..

Questo non è assolutamente vero, millis funziona tramite il timer 0 e il relativo interrupt, quindi non ha importanza quanto dura la loop(), l'incremento di millis non è legato a questo.
Semmai il problema sono le eventuali operazioni atomiche, dove gli interrupt vengono sospesi, in questo caso millis può perdere qualche us secondo ogni volta, ma la stessa cosa succederebbe con qualunque temporizzazione legata ai timer e interrupt su match conteggio.

Si vero quello che dici Astro, mi sono espresso male. Quello che intendo è:
quando incrementi una variabile con millis(), aspetti che il tuo sketch arrivi a quella condizione if per resettare millis e incrementare di +1 la variabile (se ad ogni secondo corrispenderà un incremento).
Il problema di millis() è che se il tuo loop dura 0,7 secondi...e quindi il tuo sketch, per arrivare a quell'if impiega 0,7 secondi..significa che la variabile viene incrementata di 1 secondo ogni 1,4 secondi.
E' chiaro si potrebbe utilizzare direttamente il millis() ma non lo vedo tanto comodo lavorare sui millisecondi..

Se in programma la loop dura 0.7 secondi vuol dire è scritto "con i piedi", perdonami l'espressione ma è la verità :slight_smile:

Vabbè, era un esempio...facciamo 0,2 s? Significa che dopo 1.2 secondi la variabile incrementa. NON dopo 1s. Questo perchè non c'è nessuna interrupt che al secondo va ad incrementare, ma aspetta la "lentezza" del loop.
Significa che ad ogni secondo tu vai a perdere 200ms..in linea di massima e senza nessuna correzione sull'errore.

Per quanto ne so io, poi voi siete gli esperti, magari è possibile fare un interrupt pure con millis() questo non lo so :smiley: fatto sta che risulta, almeno per me, scomodo giocherellare sui millisecondi..è un' unità di misura troppo bassa per me...preferisco di gran lunga i secondi...
immagina di impostare un contatore a 17,5 minuti..dovresti scrivere 1'050'000 :o :confused:
meglio scrivere 1050 secondi :stuck_out_tongue:

Gianky00:
Vabbè, era un esempio...facciamo 0,2 s?

Idem come sopra. :slight_smile:
In un codice scritto come si deve la loop dura sempre meno di 1 ms, salvo rarissimi casi dove può durare qualche ms, non mi dire che non è possibile perché nessun mio programma per Arduino ha mai superato queste soglie, di cose molto complesse, anche a livello professionale visto che da un paio di anni mi chiedono di realizzare codice per hardware Arduino like, ne ho realizzate tante. :slight_smile:
Ti faccio un esempio "stupido", Marlin è il firmware usato su quasi tutte le stampanti 3D basate su processori AVR, è disponibile sia come codice C puro da compilarsi con Atmel studio, o tramite make, oppure come sketch per Arduino.
In Marlin la loop dura circa 860 us, con un jitter di circa +/- 90us, misurati personalmente, eppure è un codice molto complesso che fa una miriade di cose, come è possibile questo ?
Semplice, si fa per dire, Marlin lavora event driven, la loop, o la main nel codice C puro, è quasi vuota in quanto tutto è gestito da uno scheduler e gli interrupt.