next topic »

[Reply #285 on:]

@ 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....

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

Pighixxx

[Reply #286 on:]

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

[Reply #287 on:]

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 ; quelli sono banchi di prova......

[Reply #288 on:]

@ 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 ; quelli sono banchi di prova......

 
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  (anche se sono contento di avere reso un simil servizio)
Ciao,

Alberto

[Reply #289 on:]

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 !!! 

[Reply #290 on:]

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

Spazzatura 

[Reply #291 on:]

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

[Reply #292 on:]

@niki77:
sei di memoria corta  
Il mio lavoro esposto qui
http://arduino.cc/forum/index.php/topic,93547.msg702983.html#msg702983
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".

[Reply #293 on:]

@niki77:
sei di memoria corta  

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)

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... 

[Reply #294 on:]

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

[Reply #295 on:]

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

[Reply #296 on:]

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 
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.

[Reply #297 on:]

MI avete evocato, eccomi sto scoppiando, 7 ore di lezione al giorno ucciderebbero anche A. Stakanov
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.

[Reply #298 on:]

@ 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.

[Reply #299 on:]

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.

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 .