ABC - Arduino Basic Connections

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

Ribadisco il concetto, rimane spazzatura, la cacca puoi rimestarla come ti pare però rimane sempre cacca :grin:

Eccomi!
questa mattina ho lavorato :grin:
Secondo me si sta perdendo di vista quello che dovrebbe essere un piacere o un hobby.
A volte la soddisfazione di accendere un solo led per alcuni è paragonabile al lancio della Sojuz per altri.
Lungi da me, non voglio fare moralismo, ma vuoi mettere il piacere di comandare 5 led via USB magari con il programma fatto in Visual Basic?
In questi tempi mi sono trovato ad "aiutare" (e lo metto tra virgolette, non mi ritengo nessuno) parecchia gente che mi ha contattato in privato perchè si vergognava di porre domande a volte bollate banali o con risposte "usa il tasto cerca".
Buon proseguimento

Alberto

Pighi, te l'ho già detto un'altra volta, il problema sta nel fatto che nel 90% dei casi si affida a quelle schede è neofita, se proponi schemi che non funzionano o funzionano male invece di fare un bene fai un doppio male: l'utente non realizza il circuito e si fa convinto di essere negato o deficiente perché lungi da lui mettere in dubbio il tuo lavoro.
Allora io ti ho dato delle indicazioni, altri te ne stanno fornendo ancora, servono per rendere perfetti i tuoi lavori, le indicazioni vengono da conoscenze profonde (v. Astro) o da esperienze dirette serie (Leo, Niki, Test, io, altri...), poi tu fai come vuoi, ci mancherebbe altro, comunque niente ti toglierà il merito di questo lavoro grandioso che hai fatto.

Ciao Michele, forse mi sono espresso male; Per il resto io raccolgo tutti i commenti e suggerimenti e come ho già detto, qua dentro sono l'ultimo arrivato e sono qui per imparare! Una curiosità? Quali sono gli schemi che non funzionano o funzionano male?

pighixxx:
Ciao Michele, forse mi sono espresso male; Per il resto io raccolgo tutti i commenti e suggerimenti e come ho già detto, qua dentro sono l'ultimo arrivato e sono qui per imparare! Una curiosità? Quali sono gli schemi che non funzionano o funzionano male?

Scusate, ma se alcuni schemi sono "critici" ovvero non semplici per un neofita (non credo non funzionino) non può mettere @pighi una annotazione specificando, che sò, "non testato in tutte le situazioni" o qualcosa del genere?

pighixxx:
Lungi da me, non voglio fare moralismo, ma vuoi mettere il piacere di comandare 5 led via USB magari con il programma fatto in Visual Basic?

Assolutamente d'accordo, però come ti fa notare pure Michele tu sei responsabile di quello che metti nelle tue schede, ti consiglio di evitare le cose che danno problemi perché non sono affidabili, ti risparmi un sacco di scocciature :slight_smile:
Mi spiego meglio, la VUSB è un vero proprio accrocchio hardware e software, viola tutte le regole scritte, e pure quelle non scritte, che regolamentano il funzionamento della USB, a cominciare dal layer hardware che richiede un bus differenziale ( e non dei normali GPIO) a 3V per funzionare.
Il fatto che a volte la VUSB funziona, con grossi limiti, è solo perché le porte HOST dei pc solitamente sono molto tolleranti altrimenti non potrebbe mai funzionare la VUSB, però non è possibile sperare nel fatto che il nostro pc sia benevolo per far funzionare un circuito.
Personalmente ti sconsiglio caldamente di includere la VUSB nelle tue schede, se proprio vuoi farlo almeno metti un disclaimer enorme dove avvisi che il funzionamento non è garantito perché il circuito non rispetta le specifiche USB, ovvero "lo realizzate a vostro rischio e pericolo", e tra i pericoli c'è pure quello di danneggiare fisicamente la porta USB del pc.

nid69ita:
che sò, "non testato in tutte le situazioni" o qualcosa del genere?

Io ci metterei non testato da "Testato" :smiley: :grin: :smiley:

Pighi, per quanto mi riguarda il mio riferimento è al mio post sulla questione V-USB, Astrobeed ti ha ampiamente spiegato le motivazioni tecniche, io sono stato più benevolo, limitandomi a consigliarti di NON pubblicare i due schemi che danno CERTAMENTE problemi, come dimostra la sperimentazione di alcuni di noi.
Non sono molto d'accordo, per una questione di rispetto, sul consiglio di Astro

"metti un disclaimer enorme dove avvisi che il funzionamento non è garantito perché il circuito non rispetta le specifiche USB"

, visto che hai chiesto tu il permesso all'autore di pubblicarne gli schemi, ora non puoi scrivegli di sopra che fanno schifo; invece ciò che ti consiglio io è di selezionarne uno, il più affidabile (fermo restando quanto dice Astro in proposito). Inoltre è fondamentale aggiungere delle istruzioni estremamente dettagliate; io, per uno sciocco particolare sfuggitomi, ho perso giorni e giorni dietro a questi schemi.

Perchè non mettere ANCHE un bel avviso nella scheda introduttiva ABC (sarà la prima pagina del "libro"):
Si avvisa che per eventuali danni arrecati al proprio hardware dai circuiti proposti, il curatore delle schede non è responsabile.
???

La "scappatoia" a mio modesto modo di vedere è quella di mettere in basso di OGNUNA delle schede pubblicate un piccolo avviso in cui si dice esplicitamente che i collegamenti proposti possono non essere esenti da bug o riportare dei refusi di stampa per cui viene declinata ogni responsabilità di danni causati dall'uso delle informazioni delle schede stesse.

Badate bene che non è un modo per dire: so che è tutto sbagliato, è un modo invece per mettersi al riparo da eventuali danni.

Una frase simile la metto anche in tutte le mie lib, che cioè io rilascio il software COSI' COM'E' senza nessuna garanzia né responsabilità sul suo funzionamento o sui danni che potrebbero derivarne dall'uso.
Qui in Italia non ci badiamo troppo e se bruciamo un chip per un collegamento sbagliato mandiamo a fanc... l'autore del tutorial e ne cerchiamo un altro ma negli USA ci sono studi legali che campano di cause intentate per le stro....te pi impensante, a cominciare da quelli che scivolano sui pavimenti bagnati a quelli che si graffiano prendendo le bevande da un distributore automatico, figurarsi uno che vede andargli a fuoco la sua attrezzatura perché ha seguito i collegamenti di una scheda fatta male.

leo72:
ma negli USA ci sono studi legali che campano di cause intentate per le stro....te pi impensante, a cominciare da quelli che scivolano sui pavimenti bagnati a quelli che si graffiano prendendo le bevande da un distributore automatico, figurarsi uno che vede andargli a fuoco la sua attrezzatura perché ha seguito i collegamenti di una scheda fatta male.

Verissimo, infatti negli USA non è insolito trovare avvertenze del tipo "non stirare mentre lo indossate", "non inserire animali vivi nella lavatrice mentre è in funzione", etc, proprio perché da loro è possibile fare causa, e vincerla, per cose così ovvie e assurde.
E' sicuramente sempre buona norma inserire il disclaimer per lo scarico delle responsabilità quando si rilasciano lavori open source/hardware, non c'è nulla di male nel farlo e evita di andare incontro a sgraditi problemi.
Per esempio guardate cosa scrive ST, ma anche tutti gli altri grandi produttori, nelle condizioni d'uso dei loro software open source.

 Unless required by applicable law or agreed to in writing, software 
  * distributed under the License is distributed on an "AS IS" BASIS, 
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.

astrobeed:
...
Verissimo, infatti negli USA non è insolito trovare avvertenze del tipo "non stirare mentre lo indossate", "non inserire animali vivi nella lavatrice mentre è in funzione", etc, proprio perché da loro è possibile fare causa, e vincerla, per cose così ovvie e assurde.
E' sicuramente sempre buona norma inserire il disclaimer per lo scarico delle responsabilità quando si rilasciano lavori open source/hardware, non c'è nulla di male nel farlo e evita di andare incontro a sgraditi problemi.
...

Quoto in tutto e per tutto ! Stai pubblicando quelle schede anche in inglese e proprio negli USA ... li, il primo che segue una tua scheda e gli si brucia qualche cosa, ha tutto il diritto di farti una bella causa ... non lo sottovalutare !

Guglielmo