Show Posts
Pages: 1 [2] 3 4 5
16  International / Generale / Re: Scansione battere e levare audio da microfono é possibile ? on: September 02, 2013, 09:28:29 am
Ciao, scusa la mia ignoranza, ma quello che vuoi far fare ad arduino, io, che non sono un musicista, non saprei farlo nemmeno personalmente. Voglio dire che non saprei segnare il "battere" e "levare" di una canzone ascoltandola.

Ti prego di non considerare banale il mio intervento. Intendo dire che, probabilmente, molti di noi non saranno in grado di risponderti semplicemente perchè non sapendo come si fa a riconoscere il "battere" ed il "levare" non sanno cosa deve fare esattamente Arduino e quindi non possono dirti se ha risorse sufficienti per farlo.

Mi farà piacere riflettere con te sulla cosa se ci darai qualche indicazione in più in merito.

Ciao.
17  International / Generale / Re: collegare più atemga in un unica rete (casa domotica) on: September 02, 2013, 09:21:02 am
Non vorrei fare il guastafeste ma, se devo essere sincero, una rete wireless non mi pare affidabile per realizzare un sistema domotico.

"Striscia la notizia" ci ha abituato ai disservizi provocati agli abitanti di una certa zona da trasmettitori troppo potenti che finiscono con il disturbare il comando di cancelli, autovetture etc.

L'impianto elettrico di una casa è un servizio essenziale (a differenza di un cancello elettrico o della chiusura centralizzata dell'auto) ed anche davvero affidabile. Immagino che alcuni componenti della famiglia tollererebbero davvero molto poco eventuali disservizi.

So che spesso non è possibile fare lavori per passare sottotraccia i cavi. Avrei però paura a realizzare un impianto wireless con il rischio di trovarmelo in avaria saltuariamente o definitivamente dopo qualche tempo per cause sopraggiunte successivamente.

Ovviamente è solo la mia opinione...

Ciao.
18  International / Generale / Re: tastierino numerico con meno pin ? on: August 16, 2013, 09:25:17 am
Ciao,

puoi usare due diversi PCF sulla stessa linea ciascuno con il suo indirizzo. Ovviamente dovrai scrivere correttamente lo sketch per utilizzare i due indirizzi diversi.

Ciao.
Vittorio.
19  International / Generale / Re: [OT] Un nuovo progetto della serie "vintage": l'OROLED on: May 03, 2013, 04:11:20 am
si, è vero!!! Davvero disordinata!!!  smiley  smiley  smiley

Scherzi a parte... io invece ti faccio i miei complimenti... io non avrei mai la pazienza di montare una breadboard del genere (e in effetti non ne ho mai usata nemmeno una).

Colgo l'occasione per complimentarmi anche per la passione del vintage. Attendo di vedere l'opera completa.

Ciao.
20  International / Generale / Re: Caratteri sporchi sul display on: March 29, 2013, 07:36:34 am
a me succedeva che perdeva qualche carattere. Mi spiego meglio se faccio clear e poi print "Ciao, mondo" magari vedevo "ao, mondo".

Ho provato a mettere un delay(10) tra la clear e la prima print (soltanto la prima...) e non succede più. In realtà non so se dipende dalla libreria, dal mio display o magari dal mio montaggio.

Ciao.
21  International / Generale / Re: Open Source??......solo nel termine stretto on: March 15, 2013, 01:15:35 am
intervengo solo ora soltanto a causa di impegni di lavoro...

Posso capire il disagio di chi vuole imparare qualcosa ed è costretto a leggere la documentazione in una lingua che non gli è familiare, ma mi pare un po' esagerato "pretendere" uno sforzo maggiore da parte di chi ha già condiviso gratuitamente il proprio lavoro. Questo a prescindere dalle motivazioni che hanno spinto il team ad utilizzare esclusivamente la lingua inglese.

Quote
ma allora lo sforzo di redarre una guida a pagamento per gli utenti lo fa e aggiornare il sito no? A questo punto non fare neanche la guida! perchè sembra ancora di più che chi non sa l'inglese deve letteralmente pagare per conoscere le basi di Arduino.E che dire del sito shop ufficiale ..........Ma guarda! C'è anche in italiano, allora quando si dve far spendere i soldi agli utenti è giusto che capiscano per bene altrimenti non comprano.....è giustificabile?

Questo poi, scusami, ma mi pare proprio il colmo. In passato ho più volte visto la scritta Micro$oft utilizzata dai sostenitori dell'open source per polemizzare contro la maledettissssssima politica di una azienda di scegliere di far pagare il proprio lavoro. Non mi era però ancora capitato di vedere il contrario... Polemizzare contro un team che ha scelto l'open source (anche hardware, non solo software...) perchè profonde qualche energia *anche* nella parte commerciale. Con il prossimo intervento chiederemo al team Arduino di rendersi disponibile non per corsi di formazione personali e gratuiti ma direttamente per progettarci i nostri shields/sketch.

Mi permetto di sottolineare che "open source" non è mai stato sinonimo di "gratuito" come molti pensano... Io personalmente non ci trovo nulla di strano quando vedo il team Arduino promuovere gli aspetti commerciali del proprio progetto.
22  International / Generale / Re: 4 Arduino Master Slave in RS485 on: March 10, 2013, 04:08:18 am
 smiley smiley smiley volevo solo dire che avevo insistito molto su aspetti che potevano forse sembrare un po' il pelo nell'uovo
23  International / Generale / Re: 4 Arduino Master Slave in RS485 on: March 09, 2013, 05:42:55 am
Io forse posso contribuire un po' di più perchè prossimamente dovrò sviluppare concretamente i concetti discussi sinora (e forse si era notato dal tono del mio confronto con leo72).

Purtroppo però non posso promettere tempi certi perchè dipenderà dall'evoluzione del progetto (probabilmente prima dovrò sviluppare un po' di hardware...).
24  International / Generale / Re: 4 Arduino Master Slave in RS485 on: March 07, 2013, 10:16:14 am
ho trovato questo documento che mi pare molto interessante.

Al secondo punto dell'elenco che c'e' all'inizio di pag. 10, si dice che il Response Time (ossia il tempo che si concede allo slave per rispondere dopo aver elaborato la richiesta), sia tipicamente compreso tra 1 e diversi secondi. E questo sembrerebbe un tempo enorme... ma in realtà non lo è!

Infatti, in sostanza mi pare di capire che la logica sia questa: il timeout è altissimo tanto da poter ragionevolmente supporre che se la risposta non arriva entro questo tempo non arriverà più (slave bloccato, spento, scollegato...).

Questo non rallenta le prestazioni del sistema perchè lo slave risponderà tipicamente in un tempo molto più bassso (pochi ms) mantenendo buone le prestazioni. Quando si verifica il malfunzionamento di uno slave (e si spera che sia un evento molto raro...) il bus rimane "bloccato" per pochi secondi che sono un tempo, tutto sommato, molto basso per identificare ed isolare (il master esclude lo slave dalla lista di quelli da interrogare) un problema.
25  International / Generale / Re: 4 Arduino Master Slave in RS485 on: March 07, 2013, 04:43:29 am
scusami leo72 ma ho ancora qualche dubbio sulla robustezza dell'implementazione.

Quote
Secondo me, se lo slave si aggancia alla trasmissione quando questa è in corso la deve semplicemente ignorare non appena si accorge che il primo byte che riceve non è quello di start. Sempre secondo me, deve scaricare tutti i byte che riceve perché altrimenti non può capire se ad esempio un byte $FF ricevuto a metà di un messaggio fa parte del pacchetto di dati oppure se è il byte di start. Sarà magari cura del master, rispedire il pacchetto se non riceve una risposta dallo slave.

Nell'esempio che facevo prima lo slave si agganciava perdendo i primi tre bytes e riceveva 5, 4, 2, 255, 6, 2, X. Cosa succede se si aggancia perdendo i primi 6 bytes ricevendo quindi 255, 6, 2, X? In questo caso il primo byte che riceve è proprio un 255 (indistinguibile da uno start...) che però non è uno start.

Ma come dicevo, questo problema mi pare risolto dal timeout...

Veniamo invece al tuo terzo punto sul quale ho il dubbio maggiore.

Quote
3) la collisione non c'è se fai come ho detto al punto 1)

Il punto 1 si occupa di come far individuare allo slave l'inizio del pacchetto. La collisione invece può avvenire nel seguente scenario.

  • Il master invia una richiesta ad uno slave ed attende una risposta entro 10ms (è solo un esempio... se è un tempo troppo lungo lo rivediamo successivamente)
  • Lo slave è occupato ed impiega un tempo maggiore per rispondere, per problemi del tutto estranei alla trasmissione dati (nel tuo esempio precedente c'e' un sensore difettoso).
  • Il master, trascorso il timeout, avvia una nuova trasmissione. Magari riprova ad interrogare lo stesso slave, magari passa allo slave successivo, non importa, la questione è che impegna nuovamente il bus
  • Lo slave, che ha ricevuto correttamente la prima richiesta (ma l'ha elaborata in ritardo), risponde mentre il bus è occupato dalla nuova trasmissione del master generando quindi la collisione.

Mi pare che questo scenario non abbia nulla a che vedere con la gestione dello start. Mi sbaglio?
Mi pare tuttavia che vada gestita altrimenti si corre il rischio di compromettere il funzionamento dell'intero bus dato che il master e gli slaves potrebbero entrare un uno stato dal quale non riescono più ad uscire bloccandosi definitivamente.
26  International / Generale / Re: 4 Arduino Master Slave in RS485 on: March 06, 2013, 04:07:12 am
Quote
Se lo slave sta ricevendo un pacchetto, dati non deve interpretare i byte contenuti in esso. Lui deve solo riconoscere:
1) il byte di start, ed iniziare a leggere;

E' qui che nasce il mio problema, ma senz'altro sono stato poco chiaro. Provo a spiegarmi con un esempio. Il master invia il seguente pacchetto secondo il protocollo che proponevo: 255, 0, 3, 5, 4, 2, 255, 6, 2, X

255 = Start
0 = IDMittente, il master ha ID = 0
3 = IDDestinatario, il master vuole interrogare lo slave con ID = 3
5 = IDComando, il master sta inviando il comando ID=5
4 = LunghezzaPacchetto, di seguito ci sono 4 bytes che, per esempio, rappresentano un long
2
255
6
2
X = Checksum, calcolato per esempio con uno XOR dei 9 bytes (escluso il checksum) che compongono il pacchetto

Ora supponiamo che uno slave si avvii (per esempio venga alimentato...) durante la trasmissione del pacchetto e quindi riceva il seguente frammento: 5, 4, 2, 255, 6, 2, X (ha perso i primi 3 bytes...)

Ignorerà i bytes 5, 4, 2 perchè aspetta un 255 di start, quindi interpreterà bytes seguenti come:

255 = Start
6 = IDMittente
2 = IDDestinatario
X = IDComando

e qui continuerà ad attendere in attesa dei rimanenti bytes del pacchetto che non arriveranno mai. Tuttavia interverrà il timeout ed i bytes verranno scartati con codice di errore = TIMEOUT.

In effetti mi pare che funzioni, volevo soltanto confrontarmi anche con voi sulla correttezza della soluzione, nel caso mi sfugga qualcosa.

Quote
2) il byte contenente il numero di byte ulteriori che deve ricevere, e questo valore non può essere confuso con altri perché è in una posizione ben precisa, e poi i byte di stop e di checksum, che arrivano in determinate posizioni (dipendenti da quanti byte sono stati trasmessi).

Non avevo previsto un byte di stop... ti sembra necessario?

Quote
Quindi è una catena da verifica con timeout in ogni operazione critica, come hai capito anche tu.

Qui non so se basta il timeout, come dicevo nel post precedente, in caso di ritardo nella risposta dello slave, potrebbe verificarsi una collisione perchè il master non ricevendo risposta entro il timeout, pensa che lo slave sia down ed inizia una nuova trasmissione, magari verso un altro slave. Contemporaneamente lo slave precedente trasmette la sua risposta generando la collisione che rileveremo attraverso il controllo del checksum. Dobbiamo però capire come fanno tutti gli oggetti sul bus (il master e gli n slaves) a ritornare in una condizione stabile.
27  International / Generale / Re: 4 Arduino Master Slave in RS485 on: March 05, 2013, 06:26:54 am
Quote
Perché 2 byte di start? Mi sembra inutile. Tanto hai comunque il checksum finale che ti dice se hai intercettato dati spuri sulla linea oppure no.

Avevo pensato a due byte per ridurre la possibilità che la combinazione scelta come start potesse presentarsi all'interno del pacchetto. In effetti, lo start del pacchetto, ci serve per avviare l'automa a stati che deve interpretare il pacchetto. Se il valore di start si presenta all'interno del pacchetto, l'automa comincia ad interpretare i bytes in arrivo attribuendo loro un significato diverso. Pertanto, non capirà che un certo bytes ricevuto è il cheksum del pacchetto. In effetti però mi hai fatto riflettere sul fatto che non scarterà il pacchetto per checksum errato ma piuttosto per timeout.

Non so se sono stato chiaro... ma ti chiedo comunque: che ne pensi?

Quote
Si potrebbero definire 2 o 3 livelli di allarme, ad esempio se il comando inviato è un comando critico, si richiede una risposta entro un certo lasso di tempo, altrimenti il master interpreta la mancanza di risposta come uno stallo o problema del relativo slave.

Qui mi chiedo: è possibile che uno slave risponda tardi?

Mi spiego meglio: il master interroga lo slave ed attende un certo lasso di tempo (come hai suggerito anche tu...). Se lo slave non risponde il master farà qualcosa (i livelli di allarme che proponi...). E' possibile che lo slave risponda ma lo faccia fuori dal tempo normalmente previsto? In questo caso potrebbero verificarsi collisioni sul bus dato che la risposta dello slave potrebbe scontrarsi con un eventuale nuova trasmissione del master.

Provo a rispondermi da solo.

Uno slave non è un PC che fa mille cose contemporaneamente. Quindi dovrebbe essere possibile tarare i tempi in modo che lo slave risponda sempre in tempi certi, al limite impostando il timeout del master con una certa "abbondanza", confidando sul fatto che tale timeout sarà utilizzato completamente solo molto raramente (in pratica la risposta dello slave arriverà sempre molto prima). Vi pare accettabile?
28  International / Generale / Re: 4 Arduino Master Slave in RS485 on: March 04, 2013, 05:42:00 am
Quote
Hai deciso quali saranno i comandi da trasmettere? Partiamo da lì.
Hai fatto un elenco? Pubblicalo e guardiamolo.

scusami leo, non sarebbe più opportuno cominciare con il definire il formato del pacchetto dati? Immagino infatti che i comandi possono anche essere aggiunti uno alla volta man mano che, durante lo sviluppo del software, si presenta la necessità di averne uno nuovo.

Tanto per essere concreti nella mia proposta sul modo di procedere, provo anche ad ipotizzare un primo formato (rivedendo e modificando quello già descritto qualche post fa...). Naturalmente se pensate sia più opportuno procedere diversamente facciamolo pure.

byte Start1;
byte Start2;
byte IDMittente;
byte IDDestinatario;
byte IDComando;
byte LunghezzaPacchetto;
... qui un numero di bytes pari a LunghezzaPacchetto
byte Checksum;

Start1 e Start2 devono avere un valore fisso, per esempio, 0xFFFF. Non so se conviene scegliere valori particolari, eviterei, per esempio, il doppio zero perchè mi sembra probabile che possa presentarsi all'interno dei dati.

Con un tale formato immagino che gli slaves restino in ascolto sulla seriale in attesa della coppia Start1/Start2. Quando la ricevono, si mettono in attesa dei quattro bytes che identificano il mittente, il destinatario, il comando e la lunghezza del pacchetto dati. Poi attendono tanti bytes quanti sono indicati nel campo LunghezzaPacchetto. Quindi attendono il Checksum e lo confrontano con quello che hanno calcolato sui dati ricevuti.

A questo punto scartano i dati ricevuti nei casi seguenti:

- l'ID destinatario non coincide con il loro (il pacchetto è destinato ad un altro slave... attenzione, non possiamo scartare subito il pacchetto perchè altrimenti rimarrebbero bytes non letti nel buffer di ricezione della seriale)
- il checksum non corrisponde (il pacchetto è corrotto...)
- durante la ricezione dei bytes attesi capita un timeout (in questo caso possono essersi persi alcuni bytes oppure la sequenza Start1/Start2 non identificava l'inizio di un pacchetto ma si è presentata all'interno dei dati e lo slave si è messo in ascolto a trasmissione iniziata. Caso estremo e forse improbabile ma da considerare per la robustezza del protocollo).

Come dicevo all'inizio del post, una volta identificato il formato, aggiungere nuovi comandi significa soltanto definire un nuovo IDComando (probabilmente l'ultimo usato + 1) ed il relativo pacchetto dati di cui avrà bisogno. Il fatto di aver definito un protocollo con pacchetto dati di lunghezza variabile ci consentirà di gestire comandi che non necessitano di parametri (LunghezzaPacchetto = 0) oppure di un numero arbitrario di bytes (LunghezzaPacchetto = n). L'interpretazione di ciascun comando poi si occuperà di capire il significato dei bytes di dati. La definizione degli IDComando avverrà nel codice del master che deve conoscerli tutti; gli slaves possono conoscere soltanto quelli che gli servono (magari ci sono slaves diversi che fanno uso di comandi diversi...) e scartano pacchetti che contengono comandi che non conoscono.

Aggiungo infine che dovremmo anche definire il comportamento del master e degli slaves in relazione ai timeout per gestire situazioni in cui uno slave interrogato non risponde. Ma questo magari è un aspetto successivo.
29  International / Generale / Re: programmare arduino da remoto on: March 03, 2013, 02:34:16 pm
Quote
Perché mi pare che in remoto ci sia solo l'Arduino.

questo mi sembrerebbe strano... se così fosse dove gira PHP? Aggiungo che volendo, si potrebbe anche inviare solo lo sketch, magari attraverso un normale tag TEXTAREA dell'HTML. Il PHP può salvare il testo in un file, lanciare prima la compilazione e poi l'avrdude per fare l'upload. Questo vorrebbe dire che il server PHP ha una USB collegata all'arduino da flashare.
30  International / Hardware / Re: Sapere se su un filo passa corrente arduino on: March 03, 2013, 04:04:00 am
prova a vedere qui... sono bravini...  smiley
Pages: 1 [2] 3 4 5