Show Posts
Pages: 1 ... 9 10 [11] 12 13 ... 20
151  International / Generale / Re: problema lettura secondi RTC on: December 25, 2012, 11:50:43 am
evidentemente i tempi di risposta sul dallas non sono certi. Io non so la logica in profondità del bus ma spesso nei bus le risposte vengono date a tempi appositamente "random" di modo da gestire eventuali risposte multiple/conflitti tra sensori.
Altra cosa il dallas l'hai attaccato con l'alimentazione parassita? (2 soli fili?): perchè con 2 fili è previsto un ritardo di "carica"... mi pare... devo averlo letto da qualche parte... boo forse mi sono inventato tutto...

andiamo ad una possibile soluzione: io toglierei questo delay: assolutamente.
Poi testerei "alla morte" (più velocemente possibile) l'orologio di modo da avere il più possibile letture al secondo e leggerei il sensore 1-wire (e a questo punto anche l'analogico) solo quando il secondo scatta...
uno "pseudocodice tipo":

void loop:

read dataora;
if second != oldSecond
    lcd.print data ora
    oldsecond = second
     leggo dallas
     leggo analogico.
     lcd.print temperature
     endif
end loop

In questo modo mi aspetto di intercettare il cambio del secondo appena succede ed avere un secondo netto per leggermi il sensore prima che ci sia bisogno di aggiornare di nuovo la data/ora... inoltre metti anche che non ce la facciamo in un secondo spaccato anche se diventa un secondo ed 1 decimo ben difficilmente ci accorgeremo di qualcosa.

L'alternativa è trovare un'altra libreria per il sensore che magari funzioni più velocemente.
Ho il panetto che mi viene su. smiley-grin





 
152  International / Hardware / Re: uso particolare 7805 on: December 25, 2012, 09:43:09 am
grazie per le dritte. Nel link ho notato gnuplot, pare molto bello come programma, potrei provare ad utilizzarlo...
Per fotoaccoppiatore che intendete? Una fotoresistenza con una fonte luminosa?
in ogni caso lo sketch è quasi finito, devo provarlo e per questo mi serve arduino. Per questo devo aspettare di tornare a Milano e devo aspettare che mi arrivi

sono dei componenti... simili ad integrati: di solito hanno 4 o 6 piedini e sono composti da un led ed un fototransistor (o altro tipo di ricevitore tipo triac o mosfet)... si comportano similmente a dei relay ma sono decisamente più veloci ed adatti ad "arduino". Devi calcolare una resistenza per la parte trasmettitore (che è appunto un led ma è incluso nella plastica)
153  International / Generale / Re: [OT] e gli auguri??? on: December 25, 2012, 09:32:12 am
BUON NATALE!!!! E buone feste che questa giornata già ce la siamo mangiata  smiley-grin
154  International / Generale / Re: problema lettura secondi RTC on: December 25, 2012, 09:20:05 am
Scusami se rompo il giorno di natale , anzi ne approfitto per farti gli auguri, ma la modica fatta era soltanto eliminare il DELAY tutto qui, sai dirmi tu che modifica fare? Grazie

Tanti auguri anche a te.
io ho analizzato il codice ed effettivamente imho quello che rende l'aggiornamento ogni 2 secondi è al 99.99% solo il delay: lo togli e dovrebbe aggiornare correttamente.
C'è la remota possibilità che l'interrogazione dei sensori o dell'orologio per qualche motivo impieghi più di un secondo...ma non dovrebbe proprio...mi pare difficile... ma se tu dici che non cambia nulla io devo crederti:
Per ispezionare questa casistica bisogna che ci inventiamo un debug: possiamo usare il Serial.print ma possiamo usare anche il display.
Una possibile soluzione di debug è commentare la parte inerente la lettura dei sensori di temperatura e questo ci permette di capire se è la lettura della data che infastidisce.... commentanto la lettura della temperatura cambia qualcosa?

Un'alternativa "home made" è creare una variabile che viene incrementato ad ogni ciclo di loop e stamparla ad ogni ciclo: questo ci permette di capire quanto dura il ciclo loop (stampa veloce i numeri oppure lentamente) perchè c'è la remota possibilità che il ciclo loop in se duri poco ma che l'orologio per qualche motivo torni valori errati....
una cosa tipo
int cont;
cont ++;
cont = cont % 9;
lcd.print (cont);

155  International / Generale / Re: Temporizzatore con Arduino 1 on: December 23, 2012, 11:03:10 am
Ma utilizzando un display seriale tipo NSM 4000 ed i pulsanti per settare il tempo desiderato le cose potrebbero diventare più semplici ???
Ho visto la vostra discussione e l'accenno a linee occupate per i controlli !
Saluti a tutti .
Moreno

il problema è che non tutti i display seriali prendono i livelli ttl... se non prendono i livelli ttl ti tocca riconvertirli e a quel punto l'affare si complica. Inoltre IMHO a livello di codice questa soluzione è proprio molto molto semplice: con un display ed un menu a questo punto il codice sarebbe sicuramente più complesso anche se ci sono delle librerie per gestire i menu
156  International / Hardware / Re: uso particolare 7805 on: December 21, 2012, 05:25:02 pm
ho avuto di recente a che fare con degli encoder che andavano alimentati minimo a 12 volt. Ho fatto anche io il mio bravo partitore di tensione e ho messo anche uno zener tra piedino e massa giusto per sicurezza. In realtà un piccolo zener è già nell'arduino e serve per scaricare eventuali sovratensioni, statica e cose del genere però è piccolino e tiene finchè può. Mi unisco quindi all'appello di mettere anche lo zener. l'idea del 7805 imho non è neanche male se le frequenze non sono estreme ma diremo che mi pare di tagliare una bistecca con il motosega.
157  International / Software / Re: Calcolare angolo assoluto da velocità angolare on: December 20, 2012, 04:51:45 pm

pero non capisco nel tuo programma che fine ha poi fatto l'arcoseno...


ahhh si aggiungo anche una cosa: forse già la sai ma le operazioni sui double a livello di tempi di calcolo sono veleno... spesso in tal senso si creano degli array di "arcoseni" nel tuo caso già calcolati a partire magari dai gradi che puoi ipotizzare interi e che quindi ti fanno da "indice" dell'array.
Comunque casomai vedrai a tempo debito.
158  International / Software / Re: Calcolare angolo assoluto da velocità angolare on: December 20, 2012, 04:03:31 pm
a me va... non supera mai i limiti impostati...

Code:
float mapFloat(float x, float in_min, float in_max, float out_min, float out_max)
{
  return (x - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

void loop() {
  // set the cursor to column 0, line 1
  // (note: line 1 is the second row, since counting begins with 0):
  lcd.setCursor(0, 1);
  // print the number of seconds since reset:
  int i ;
 
  for (i = -8191; i < 8191; i++){
      float angVal = mapFloat(i, -8191,8191, -1, 1);
      lcd.clear();
      lcd.print("i:" );
      lcd.print (i);
      lcd.print ("  ->");
            lcd.print (angVal);
      delay(10);
  }
}


pero non capisco nel tuo programma che fine ha poi fatto l'arcoseno...
159  International / Software / Re: sketch spesso errati... on: December 19, 2012, 03:48:51 pm
In gioventù ho scritto un programma di gestione veterinaria che prevedeva anche la stampa del registro bollato, di cui non sapevo nulla, è ho dovuto acquisire le dovute competenze, ora non ricordo con precisione ma c'è una procedura precisa da seguire nel caso si blocchi la stampante, si inceppi la carta ecc, mi sembra di ricordare che la pagina stampata a metà deve essere annullata e si deve riprendere la stampa dalla pagina di interruzione.

per fortuna molti "formalismi" sono stati parzialmente rimossi dalle contabilità. Io invece dopo gli studi facevo proprio software per applicazioni contabili e vedevo diremo con una certa "invidia" quelli che scrivevano su microcontrollori o su tematiche diverse perchè mi parevano temi più stimolanti... poi lavoro è lavoro e sicuramente anche chi scrive driver per i sensori del cern avrà i suoi momenti di sbattimento ma a me pareva che fare stampe fosse la cosa più pallosa del mondo... in particolare quando mi arrivavano tracciati e moduli fiscali tipo 730-740... una noia mortale di somme ridondanti... vabbè scusa le chiacchere...
Ottimi i consigli che hai dato sulla scrittura del codice: spesso lo spirito ribelle si oppone ma sarebbero da applicare alla lettera ed effettivamente nei software che sopra citavo di contabilità erano un must anche perchè si lavorava in team sotto degli analisti
160  International / Software / Re: sketch spesso errati... on: December 19, 2012, 03:36:23 pm
grazie ragazzi, molto  "agguerriti sul tema", ma la domanda rimane......come imparare in fretta?

scusa tu invece: da un se vogliamo banale problema di compilazione ci siamo ritrovati (e mi assumo una buona fetta della colpa) a parlare di ingegneria del software. In ogni caso non so se esistono vie rapide per imparare... alla fine c'è tanta tanta pratica da fare... è imprescindibile... ma io quello che non ho capito è "cosa" ti interessa e dove eventualmente ti senti lacunoso... in altri termini se ti mancano dei rudimenti di c++ oppure se ti mancano dei rudimenti di programmazione generale, se arduino, se elettronica digitale, se elettronica "analogica". Per esempio dal listato precedente che aveva una libreria mancante io intuisco (correggi se sbaglio) che ti manca un po' di pratica con il c++: arduino non è il miglior strumento per imparare il c... meglio a tal fine un pc ed un  modesto compilatore e mettersi a fare "esercizi".
161  International / Software / Re: sketch spesso errati... on: December 19, 2012, 09:48:56 am

In buona sostanza condivido, tranne per il giudizio; bravo, più bravo ecc. Non ho capito l'ultima parte riguardo al programma di contabilità, mi sembra di capire che chi scrive un programma di contabilità sia meno "bravo" di chi scrive una ISR. Ovviamente non è così, perchè sono lavori complessi entrambe e richiedono competenze diverse.

Riguardo ai commenti sul codice, posso dire evitando di usare la parola "bravo" che se è intesa in modo corretto ci può stare.


no vabbe il bravo più bravo era inteso che hai scritto un codice "più rapido ed efficiente della moltiplicazione semplice" quindi diremo "bravo" per aver "ottimizzato il codice" con una soluzione "non scontata".... che diventa "più bravo" quando commenti quello che hai fatto perchè aggiungi all'ottimizzazione del tuo software la "leggibilità e mantenibilità"
ed il discorso del programma di contabilità era per indicare un programma molto grande ma che di solito non contiene necessità di ottimizzazione spinta del codice... in altre parole se devi fare una IRS devi andare veloce e moltiplicare per 4 è più lento dello shift; se invece devi moltiplicare per 4 un listino prezzi di 1000 record per fare un report è meglio che usi la moltiplicazione e lo shift te lo tieni nel cassetto perchè se no nessuno capisce che cacchio hai fatto ne il perchè.... e quindi nonostante il gesto tecnico non sei stato utile... un po' come essere un bravo attaccante che vuole segnare solo in rovesciata ma che non passa mai la palla




162  International / Software / Re: sketch spesso errati... on: December 19, 2012, 07:34:45 am

"alla lunga"  dopo che si ha un po di pratica , e meglio scriversi le cose di sana pianta.
le cose funzionanti  fatte con la propria testa   sono sempre capite e modificabili/migliorabili   all'istante

la penso così  poi ....  magari mi sbaglio non so.

no non è che sbagli: è normale che un programmatore capisce meglio quello che fa lui che quello che fanno gli altri ma non è un approccio "ingegneristico" al software... è un po' come stuccare un muro o costruire un condominio: se devi stuccare il muro prendi lo stucco e la spatola e fai, se devi fare un palazzo devi fare un progetto ed usare i mattoni, malte premiscelate e ferro prodotti dagli altri e tu "architetto" devi "solo" conoscere cosa puoi fare con questi componenti.... e a tal fine un'altra cosa che spesso il programmatore fa (sbagliando) è quello di spingersi in codici magari molto ottimizzati ma poco chiari invece il ciclo del software è molto lungo e non si ferma alla prima stesura e quindi è prioritario che il programmatore si "abbassi" a scrivere commenti e precisare cosa fa di modo che lui stesso e gli altri possano metterci mano o correggere senza impazzire...
esempio (citando il codice immesso da uwe  smiley-eek)
us <<= 2; ... bel metodo per moltiplicare per 4 in modo molto rapido... ottimo metodo per non far capire a nessuno quello che stai scrivendo... (infatti l'autore consapevole ha accennato un commento).... se stai facendo un driver o una ISR sei bravo, se lo commenti sei ancora più bravo, se stai scrivendo un programma di contabilità (o accendere un led ogni morte di papa) pensi tu di essere bravo ma in realtà stai sbagliando tutto.
IN MIA UMILE OPINIONE SEMPRE COMUNQUE E'...
163  International / Software / Re: sketch spesso errati... on: December 19, 2012, 04:10:55 am

Guarda che il "make or buy" non si applica in questi casi, un conto è comprare un qualcosa che funziona (es. libreria) che richiederebbe mesi di sviluppo perché più conveniente, un conto invece è scaricare dal web a caso del codice che non va che si potrebbe scrivere in poche ore..  smiley

questa è una libreria che nella fattispecie muove un servo... gioca con registri ed interrupt per settare timer eccetera...non è proprio una banalità ed è molto più facile sbagliarla che farla giusta: se c'è già, funziona e fa quello che ci serve non vedo perchè non usarla: qui manca un file alla fine. A me sinceramente gli insegnamenti di ingegneria davano fastidio e li per li ho trovati a volte scontati a volte banali a volte noiosi...del resto da studente... però poi quando l'ho fatto per lavoro ho capito che alcune cose non erano proprio così campate in aria e che alle volte è meglio ad esempio fare un codice chiaro che possa essere corretto piuttosto che risparmiare 1 byte di una variabile e tornando allo sfruttamento del codice fatto da altri in realtà è una prassi che facciamo tutti chi più integralmente chi meno ed obiettivamente più ambizioso è il progetto più devi salire sulle spalle dei giganti che ti hanno preceduto.
forse però sono andato un po' troppo ot con questo argomento...mi scuso: solo un'opinione

164  International / Software / Re: sketch spesso errati... on: December 19, 2012, 02:29:52 am

e poi la strada più giusta   e quella di farsi da soli lo sketch su "misura"

ad ingegneria del software 1 e 2 mi hanno insegnato l'esatto contrario: se si può bisogna sfruttare il già fatto... tutto sommato sbattendosene del come è stato fatto... che dopo la curiosità ti porti al capire come è stato fatto quello è per la ns sete di conoscenza ma non per il fine del progetto.

165  International / Generale / Re: massima lunghezza one wire bus on: December 19, 2012, 02:18:49 am
Cmq dalla note che ho postato (e anche qsecofr) parlano di un centinaio di metri...

ahhh si scusa: che m0na... mi pareva parlassi di altro invece ho postato proprio lo stesso collegamento: chiedo venia smiley-red
Pages: 1 ... 9 10 [11] 12 13 ... 20