ABC - Arduino Basic Connections

niki77:

astrobeed:
... e due resistenze da 560 ohm (sono valori da calcolare in funzione delle resitenze di terminazione e della tensione di linea), solo in un nodo, tipicamente sul master, per il bias.

La storia del bias però non è mai stata approfondita seriamente ... sarebbe molto interessante avere una tua 'spremuta' culturale in materia, magari in un thread più appropriato.

Sto per finire il mio schema, in pratica dialogo tra due micro a distanza mediante due max485 configurati a due fili (A e B). Ho messo su entrambe le coppie A-B (master e slave) una R in parallelo da 100ohm ½watt, l'alimentazione è a 5V, la distanza teorica tra le due schede da pochi cm ad 1km. Se ho ben capito devo aggiungere due R in serie ai poli A e B solo dal lato del max collegato "master", vanno bene i valori 560 ohm?

E anche la 32 è in linea... :smiley:

Scaricabile subito da (set 12): pighixxx.com

@Michele
E' rivolta a me o ad Astro la domanda?

560 ohm sono i valori corretti per terminatori da 120 ohm, ti sconsiglio di scendere sotto questo valore perché se ci pensi bene vuol dire che l'impedenza, resistiva, della linea è solo 60 ohm con tutte le varie considerazioni per la corrente necessaria :slight_smile:

niki77:
La storia del bias però non è mai stata approfondita seriamente ... sarebbe molto interessante avere una tua 'spremuta' culturale in materia, magari in un thread più appropriato.

Per parlare bene della RS485 è meglio aprire un topic dedicato, l'argomento è al tempo stesso semplice e complesso a seconda dell'utilizzo, e dell'ambiente di lavoro, del bus, sopratutto il discorso GND e terra (che sono due cose diverse) è molto importante.

astrobeed:

[quote author=Michele Menniti link=topic=146152.msg1202276#msg1202276 date=1366041865]
lato del max collegato "master", vanno bene i valori 560 ohm?

560 ohm sono i valori corretti per terminatori da 120 ohm, ti sconsiglio di scendere sotto questo valore perché se ci pensi bene vuol dire che l'impedenza, resistiva, della linea è solo 60 ohm con tutte le varie considerazioni per la corrente necessaria :slight_smile:
[/quote]
In realtà c'avevo pensato, e la scelta dei 100 ohm era per avere la "classica" impedenza di 50ohm :slight_smile: aumento subito a 120 ed aggiungo le 560 sul master. grazie.

@ pighi: avevo quotato Astro, peraltro aveva aperto lui la questione; invece mi incuriosisce molto lo scheme di simple debounce ; quando ho scritto l'articolo sul Capacimetro ne ho provati e spiegati diversi ma questi non li avevo mai visti, quello a sinistra è quello che ho usato io, ma senza la R in serie sul pulsante, perché a mio modesto parere impedirebbe anche la pressione ripetuta del pulsante, obbligando ad un'attesa forzata, mentre credo che per la pressione singola sia perfetto; invece quello a destra non saprei, io lo vedrei tendenzialmente male, ma bisognerebbe provarlo. Ovviamente parliamo del solo debiunce hw, senza l'ausilio del sw, altrimenti tutto ci sta.... :slight_smile:

Qui ci sta tutto, è solo hardware e soprattutto funziona :grin:
Testato (funziona anche con pressioni multiple, tempo di intervento intorno al 1ms)
Ciao,

Pighixxx

Una domandina.
Il simple debouncer (scheda 32 in alto a dx) lo posso usare anche mettendo il pulsante sul + e togliendo quello sul -?

erpomata:
Una domandina.
Il simple debouncer (scheda 32 in alto a dx) lo posso usare anche mettendo il pulsante sul + e togliendo quello sul -?

no, va invertita completamente la logica.

@ pighi: prima o poi lo proverò ma con i pulsanti che dico io, non con i soliti tastini arduiniani; ne ho alcuni che quasi fanno scintille altro che bounce :D; quelli sono banchi di prova......

:smiley:
Attendo con ansia il tuo responso...

Ho avuto l'autorizzazione per inserire l'ottimo lavoro fatto da Osamu Tamura
Per chi fosse curioso un link: http://www.recursion.jp/avrcdc/cdc-232.html

Poi farò una revisione a tutto e basta, penso che mi fermerò definitivamente. Ho praticamente perso 3 mesi di lavoro :roll_eyes: (anche se sono contento di avere reso un simil servizio)
Ciao,

Alberto

pighixxx:
Ho avuto l'autorizzazione per inserire l'ottimo lavoro fatto da Osamu Tamura
Per chi fosse curioso un link: http://www.recursion.jp/avrcdc/cdc-232.html

Michele , V-USB nuovamente all'orizzonte !!! :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

niki77:
Michele , V-USB nuovamente all'orizzonte !!! :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

Spazzatura :grin:

Facciamo una scheda spazzatura con su v usb, prg ser, prog parallelo

@niki77:
sei di memoria corta :wink:
Il mio lavoro esposto qui

nasce proprio dal link citato.

Ci ho sputato sangue ed alla fine ho smontato tutto. Troppe le volte che l'accrocchio non funziona. Dipende dal cavo, da quanto è lungo, se fa caldo... non è affidabile come soluzione.
Nonostante sia riuscito a farci un video, sia prima che dopo di esso ho avuto problemi di sincronizzazione. "No buono".

leo72:
@niki77:
sei di memoria corta :wink:

Mi sa che tu sei di memoria ancor più corta della mia, io ci ho fatto addirittura una scheda dedicata!!! (con tanto di post in megatopic) XD

Però ho avuto il buon senso di non spacciarla come atta a fare da convertitore usb-seriale!

Ma vedrai che Michele sarà estremamente contento di rivedere quel link... :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

E' vero, hai ragione.
1 a 0 per te :wink:

Ricordo entrambi i lavori.
Fare da convertitoreusb èil problema, perche come programmatori funxionano ad esempio usbasp è fatto con vusb o ricorfo male ?

Confermo, USBasp è basato su V-USB.
Difatti il problema principale è la comunicazione bidirezionale. Anche nel "todo" di USBasp c'è scritto che l'autore vuole dotare l'aggeggio di comunicazione bidirezionale... da 2 anni :stuck_out_tongue_closed_eyes:
Quindi mi sa che la stabilità della cosa non sia facilmente risolvibile. Non puoi rilasciare un prodotto che alle volte fa ed alle volte non fa.

MI avete evocato, eccomi :smiley: sto scoppiando, 7 ore di lezione al giorno ucciderebbero anche A. Stakanov :fearful:
Essendo l'ultimo, in ordine cronologico, ad aver lavorato con l'accrocchio, posso riassumere la situazione:

1 - la V-USB è realizzabile con decorosi risultati, a condizione di ricorrere all'uso di un micro quarzato a 12MHz, che è la frequenza operativa di riferimento per i segnali USB; altre combinazioni 16MHz o, peggio, no quartz, danno risultati stravaganti o non ne danno, comunque sono inaffidabili

2 - Serve un bootloader specifico, comandato tramite un pin del micro, per caricare gli sketc, quindi si perde memoria

3 - Di contro permette il semplice aggiornamento diretto via USB della flash del micro, una alternativa all'ISP

4 - Il problema, ad oggi IRRISOLVIBILE, è la comunicazione bidirezionale col PC, non c'è verso di mandare dati mediante gli stessi segnali al computer; se questa cosa funzionasse allora la tecnica sarebbe rivoluzionaria, visto che non funziona l'unica comodità può essere rappresentata in caso di installazioni off-home, dove ci si può recare con un notebook ed un semplice convertitore usb-seriale.

Insomma, oggi, ma solo grazie a Niki77, che col suo Topic mi aiutò a capire dove sbagliavo nelle centinaia di prove precedenti, e ad Astro, che mi chiarì la questione dei segnali a 12MHz, la V-USB può essere dichiarata una tecnica "economica e praticabile" con i pro e contro di ogni altra tecnica. Così ho detto, la discussione è chiusa e la seduta è tolta.

@ Pighi: per i motivi sopraesposti ti sconsiglio vivamente di replicare il lavoro basato sul tiny45 senza quarzo e sul tiny2313, anche se con quarzo (resta davvero poca flash); l'unico che vale la pena di replicare è quello basato sul mega8 o maggiori.

Quella basata su TinyX5 è una implementazione zoppa, manca la gestione del reset.
Se si vuole usare un Tiny2313 e solo come programmatore consiglio di replicare l'USBtinyISP di Adafruit, che funziona egregiamente (l'ho realizzato anch'io).
Se si vuole "giocare" con l'Avr-Cdc32, come ha detto Michele, usate l'implementazione basata su un Atmega88/168/328 almeno potete replicare anche i segnali DTR e RTS che vi servono per il reset del chip target.

NI,

e ti avevo anche spiegato il perchè.
In realtà ci sono altri modi utilizzati per scambiare dati tra la mcu ed il pc tramite la USB, alcuni semplici ma limitati, altri meno semplici ma che offrono maggiori potenzialità.
I metodi semplici li ho provati personalmente , uno di questi consiste in una modalità pseudo 'modbus' (passatemi il termine) che consente di leggere e scrivere dati nel dispositivo 'on demand'.
L'esempio che avevo provato io praticamente permetteva di leggere e scrivere dei dati sulla eeprom della mcu (nel mio caso un 328 @12mhz).
Gli altri sistemi 'meno semplici' che avrei tanto voluto approfondire , ma non ho avuto tempo, consistevano nella creazione di un driver apposito per il S.O. dove si mappavano le funzionalità del dispositivo vero e proprio, che venivano poi rese disponibili dal S.O. rendendole utilizzabili da C attraverso le API di sistema.

Quello che farebbe più comodo, ma non è possibile è la comunicazione seriale via usb, proprio come si fa con arduino, e questo proprio è decisamente instabile e macchinoso .