ATTiny 45 board usb

Cioe tu hai programmato via ide arduino ma usando un bootloader alternstivo. Immagino ptecedentemente caricato via ISP.
Dacci i riferimenti che si provs. Prima o poi sto cadavere devo farlo passate anche io. Sarebbe bello smentire i capi del forum ma sino conscio della velleita' dell'operazione

Testato:
Cioe tu hai programmato via ide arduino ma usando un bootloader alternstivo. Immagino ptecedentemente caricato via ISP.
Dacci i riferimenti che si provs. Prima o poi sto cadavere devo farlo passate anche io. Sarebbe bello smentire i capi del forum ma sino conscio della velleita' dell'operazione

Intanto chiariamo che noi abbiamo sempre cercato di creare un chip che facesse le veci (e non le feci, come poi è successo :grin:) del converitore USB-seriale, quindi un chip che contenesse un firmware in grado di interfacciare l'USB con il micro da programmare; qui si parla di un'operazione diversa; io mi fido di Niki77 perché è uno che parla poco e le cose le fa, ne ho prove personali, anche se gli sono a debito di un test (con l'occasione mi scuso), ma il tempo non basta mai; se dice che è riuscito a programmare via seriale un 328P vuol dire che ha trovato il modo; poi bisogna vedere se la tecnica è affidabile e replicabile, e capire se vale la pena metterla in atto. Avere comunque uno stand-alone (quindi del bl non ce ne frega nulla) programmabile direttamente da un portatile, via IDE, potrebbe avere indubbi vantaggi. L'importante (chiudo come ho iniziato) è chiarire che non è ciò che abbiamo cercato di fare noi.

ma quando dici programmabile via ide, e poi dici non ce ne frega del bootloader, intendi quindi farlo via ISP ?

alla fine diventa secondario anche il tipo di programmazione, cioe' l'importante e' che funzioni il circuito, cioe' un micro connesso via v-usb e che attraverso essa trasmetta e riceva dati seriali. Ch poi questo progetto debba essere aggiornato solo con ISP e' il minore dei mali, anzi in genere in fase finale e' proprio questo che si fa, cioe' niente bootloader sul micro finale del progetto.

Testato:
ma quando dici programmabile via ide, e poi dici non ce ne frega del bootloader, intendi quindi farlo via ISP ?

alla fine diventa secondario anche il tipo di programmazione, cioe' l'importante e' che funzioni il circuito, cioe' un micro connesso via v-usb e che attraverso essa trasmetta e riceva dati seriali. Ch poi questo progetto debba essere aggiornato solo con ISP e' il minore dei mali, anzi in genere in fase finale e' proprio questo che si fa, cioe' niente bootloader sul micro finale del progetto.

stiamo parlando di operazioni seriali, non di ISP; sull'ISP ci siamo già, ormai c'abbiamo fatto tutto; comunque finché nik77 non fornisce chiarimenti parliamo sul nulla, io non ho capito molto di ciò che ha scritto, nel senso che non ricavo info sufficienti a capire come ha ottenuto il suo risultato.

Testato:
ma quando dici programmabile via ide, e poi dici non ce ne frega del bootloader, intendi quindi farlo via ISP ?

alla fine diventa secondario anche il tipo di programmazione, cioe' l'importante e' che funzioni il circuito, cioe' un micro connesso via v-usb e che attraverso essa trasmetta e riceva dati seriali. Ch poi questo progetto debba essere aggiornato solo con ISP e' il minore dei mali, anzi in genere in fase finale e' proprio questo che si fa, cioe' niente bootloader sul micro finale del progetto.

Il chip si può autoprogrammare tramite la usb stessa senza ftdi o altre amenità varie.
Appena ho un minuto vi faccio un video così forse si capisce meglio.

Volete il video? Andate a ricercarvelo nei vecchi post oppure sul mio canale youtube (utente leomil72).
Vedrete che attacco, invio, programmo ed il chip esegue. Bello vero?? Peccato che prima di ciò avessi smanettato per almeno 20 minuti infilando e sfilando i componenti, pensando ad un falso contato.

Pensavo che riportare tutto su 1000fori aiutasse, invece peggio! Volete ridere??? Anche la lunghezza del cavo USB influisce sul riconoscimento della schedina!!!
Ecco cosa succede collegando il prototipo con un cavetto corto (diciamo sui 90cm):

[ 1663.103223] usb 5-2: new low-speed USB device number 2 using uhci_hcd
[ 1663.255904] usb 5-2: config 1 interface 1 altsetting 0 endpoint 0x1 is Bulk; changing to Interrupt
[ 1663.255910] usb 5-2: config 1 interface 1 altsetting 0 endpoint 0x81 is Bulk; changing to Interrupt
[ 1663.326832] cdc_acm 5-2:1.0: ttyACM0: USB ACM device
[ 1663.333077] usbcore: registered new interface driver cdc_acm
[ 1663.333083] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Riconosciuto e montato. Appena però vado a programmarlo esce il solito "Programmer is not responding".

OK, cambio di cavetto. Stavolta uno lunghetto, circa 1,5 metri. Ecco il responso:

[ 1886.569867] usb 5-2: new low-speed USB device number 3 using uhci_hcd
[ 1886.708228] usb 5-2: device descriptor read/all, error -71
[ 1886.816526] usb 5-2: new low-speed USB device number 4 using uhci_hcd
[ 1886.958230] usb 5-2: device descriptor read/all, error -71
[ 1887.066527] usb 5-2: new low-speed USB device number 5 using uhci_hcd
[ 1887.095239] usb 5-2: device descriptor read/8, error -71
[ 1887.221258] usb 5-2: device descriptor read/8, error -71
[ 1887.429858] usb 5-2: new low-speed USB device number 6 using uhci_hcd
[ 1887.458246] usb 5-2: device descriptor read/8, error -71
[ 1887.584245] usb 5-2: device descriptor read/8, error -71
[ 1887.686525] hub 5-0:1.0: unable to enumerate USB device on port 2

NON riconosciuto!!! Quindi le variabili in gioco sono troppe!

PS:
la programmazione di un Atmega con un bootloader non Arduino non è una novità. Già un anno fa vi parlavo del progetto Uzebox, una simil console ad 8 bit basata su un Atmega644 che conteneva un bootloader grossotto (4 kB mi pare) con il quale l'utente poteva scegliere a video il firmware del giochino che voleva da un elenco presente una SD installata sulla scheda e poi, dopo la relativa flashatura, avviarlo e giocarci. Insomma, niente di straordinario. Lo straordinario è vedere 'sto cavolo di V-Usb funzionare.

Fintanto ci limitiamo alla comunicazione seriale, il V-Usb funziona. Il problema è poi replicare i giusti segnali al micro a valle per avviare la programmazione. Difatti chip con firmware appositamente dedicati per funzionare come programmatori funzionano, vedi USBtinyISP o USBasp, che altro non sono se non Attiny2313 (nel 1° caso) e Atmega88 (nel 2° caso): ma quei chip fanno SOLO quello, non vogliono prendersi la briga di emulare completamente una seriale.

Poi spero che qualcuno mi smentisca, per ora non posso che dire che a me non ha funzionato.

Pensavo che riportare tutto su 1000fori aiutasse, invece peggio! Volete ridere??? Anche la lunghezza del cavo USB influisce sul riconoscimento della schedina!!!

io ora ho provato il mio convertitore usb seriale fatto con l'attiny 45 cambiando il cavo da 1 m a 2 m ma non ho avuto problemi , prbabilmente dipende anche dalla qulitàè del cavo o da quanto la v usb a voglia di funzicare :sweat_smile: :sweat_smile:
ora intendo provare la metaboard se và faccio sapere ma ...... :roll_eyes: :roll_eyes:
ciao niko

Mettiamo dei paletti:

Chi ha esperienze in queste metodologie dica la sua:

  • Usare la V-Usb SOLO come convertitore usb-ttl, al fine di comunicare con un secondo micro, ma non per programmarlo.
    (quindi sia il secondo micro che il primo usato per la v-usb sono programmati via ISP)

  • Usare un solo micro, con sopra la V-Usb e lo sketch, SOLO per comunicare via seriale con il pc, SENZA usarlo come programmatore.
    (intendo che il micro viene programmato via ISP tramite altri programmatori, usbasp, arduinoisp, ecc)

  • Usare due micro, uno per v-sub ed uno per lo sketch, programmandoli con arduinoide via seriale
    (un ArduinoUno ma con un 328p al posto dell'8u2)

  • Usare un solo micro, con sopra V-Usb, Bootloader, Sketch, programmabile via Arduino IDE
    (questo e' il piu' difficile che funzioni)

@Testato:
stai confondendo V-Usb e Metaboard.
La V-usb è un firmware per un chip che funziona solo da emulatore di convertitore. La Metaboard si basa su un codice derivato dalla V-Usb che altro non è se non un bootloader con integrate le funzionalità della V-Usb. Hai posto male il quesito.

scusa ma io sono andato sul sito ufficiale v-usb e come esemppi ci sono micro che accendono led ad esempio, ricevendo comandi seriali via usb.

non sono solo convertitori. non trovo scritto da nessuna parte che l'obiettivo e' solo di fare un adattatore usb seriale. Non avrebbe senso, il senso arriva proprio quando, con un solo micro, mi attacco sia alla usb sia faccio girare il mio sketch

Altra cosa. Con la V-Usb non si usa l'ISP. Te l'ha già un paio di volte anche Menniti. :stuck_out_tongue:
Con la V-Usb si programma via seriale, quindi necessariamente il chip a valle del convertitore deve avere il bootloader di Arduino sopra.

Comunque io ho usato avr-cdc, che è un progetto derivato dalla V-Usb.

mi manca qualche elemento perche' non ti seguo.
Se io voglio programmare un 328P con uno sketch che andra' a creare la v-usb (in qunto la v-usb e' un codice), perche' non potrei farlo via ISP ? O carico un blink via ISP o carico V-USB via ISP cosa cambia ?

Questo e' un progetto ufficiale v-usb, credo il primo in assoluto, il concetto che vedo e' proprio quello che sto' esprimendo, un solo micro, programmato via ISP, che si connette ad un pc via USB

Nessuno lo chiama metaboard, e' l'implementazione della v-usb nel suo concetto base secondo me

powerswitch.jpg

Una prova così tanto per provare: avete provato con un cavo molto corto USB per alta velocità con quell' "tondino" per eliminare i disturbi che ora non mi ricordo come si chiama ma che è ad esempio sui cavi di alimentazione dei portatili e vedere se la situazione migliora (lo si può prendere in prestito dall'hard disk usb ad esempio)

Secondo me anche il design della millifori influisce quando si lavora con segnali ad alta velocità e con timing molto precisi, bisognerebbe fare alcune prove magari copiazzando qualche design esistente e funzionante.

Un buon oscilloscopio probabilmente è necessario per capire cosa sta succedendo senza andare alla cieca

Io sinceramente ho ordinato alcuni convertitori USB-UART per alcuni progetti http://www.aliexpress.com/product-gs/492071325-CP2102-Serial-Converter-USB-2-0-To-TTL-UART-6PIN-Module-OT814-wholesalers.html e ho chiuso il discorso, rischiavo un esaurimento a stare dietro a V-USB senza l'adeguata strumentazione per fare debug altrimenti

Ciao

A me sinceramente funziona anche Su una breadboard da 2 euro con cavi volanti...

Testato:
Mettiamo dei paletti:

Si hai ragione mettiamo dei paletti :slight_smile:
Prima di tutto vi consiglio caldamente di scaricarvi l'A.N. AVR309 di Atmel, con il relativo codice, dove spiega come realizzare una comunicazione USB di tipo CDC ACM (seriale virtuale) tramite emulazione software, che come ho già detto altre volte è si possibile, ma ci sono grossi limiti.
Se vi leggete l'AN di Atmel vi appare subito chiaro come stanno realmente le cose, tanto per cominciare il micro viene alimentato a 3.3V e non a 5V, il clock deve essere tassativamente un quarzo da 12 MHz, questo per via delle temporizzazioni imposte dalla USB.
Potete ottenere solo un device che va in Low Speed (1.5 mbps) e che fa solamente ed esclusivamente il convertitore USB seriale, oppure un canale dati HID, con la possibilità di comandare da USB svariati pin per farli commutare di stato, nulla di più ovvero potete scordarvi di farci girare sopra del software utente, tanto meno degli sketch di Arduino, perché tutte le risorse e tutto il tempo cpu sono impegnati per gestire la USB.
Da notare che il software Atmel, sia per ATmega8 che per Attiny 2313, è scritto in Assembler per via della criticità dei vari timing, si può fare anche in C ANSI, ammesso di essere molto esperti, ma non certo con un compilatore limitato come l'avr-gcc che per la cronaca non è il massimo dell'efficienza con gli AVR.
Il software Atmel usa un driver dedicato, c'è solo per Windows, e mette a disposizione un demo in Delphi per testare tutte le funzionalità, se lo provate e realizzate bene il circuito, semplicissimo però deve essere montato a regola d'arte, state pure certi che funziona come atteso.
Rimane valido il limite della lunghezza cavo perché manca il transciever hardware per la USB, due GPIO non sono la stessa cosa anche se riescono ad emularlo in parte, difficilmente riesce a funzionare con un cavo più lungo di 1 metro.

Aggiungo:
http://vusb.wikidot.com/troubleshooting

Bah, qui c'è gente che è certa del non funzinamento per le proprie notevoli conoscenze teoriche (Astro), gente che è certa del non funzionamento per le proprie esperienze pratiche (Leo ed io), gente che ragionevolmente rinuncia fidandosi di tanta dir male (flz), gente che nutre speranza di riuscire dove altri hanno clamorosamente fallito (Testato), gente che dice di aver fatto funzionare tutto con vai di varia misura ma non mostra nulla di concreto, infine gente che dice di far funzionare tutto, ad ogni intervento rilascia una goccia di saggezza, l'ultima quella che ci vogliono due euro, ma che ancora non ha mostrato un briciolo di schema applicativo né fornito info tali da far capire agli altri cosa ha fatto (Niki77): VIVA L'ITALIA.

L'unico fattore comune è che sembra che questo tipo di comunicazione funzioni colo a quelli il cui NICK comincia con NIK: quindi a tutti gli altri: rinunciate, siete fottuti per nascita! :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :smiley-yell

grazie astro dell'approfondimento.

solo un appunto: ArduinoUNO usa il codice V-USB ? l'8u2, ed il 16u2 usati ufficialmente usano un quarzo 16MHz, e' la dimostrazione che i 12MHz non sono obbligatori. a questo punto teoricamente non vedo problemi a prendere i sorgenti dell'8u2 e modificarli al fine di fare accendere un led su una sua uscita oltre a fare da convertitore (di certo non sarei io a poterlo fare) :slight_smile:

p.s. spettate non e' che l'8u2 ha una usb hardware ? :stuck_out_tongue_closed_eyes:

Microcontroller with USB Controller

:stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:
:zipper_mouth_face: :zipper_mouth_face: :zipper_mouth_face:

Mi e' venuta un'idea che cambiera' il corso delle cose, se devo usare la usb uso un micro con usb integrata
(forse l'avevo gia' letta...., ma come insegna la mela morsa l'importante e' brevettarle le cose, non inventarle)
]:slight_smile: ]:slight_smile: ]:slight_smile:

Testato:
l'8u2, ed il 16u2 usati ufficialmente usano un quarzo 16MHz, e' la dimostrazione che i 12MHz non sono obbligatori.

Invece i 12 MHz sono obbligatori eccome, è puramente una questione di timing, al limite è possibile usare i 6 MHz per la low speed, però poi non ce la fai a gestire tutto quanto col micro perché diventa troppo lento.
Una delle cavolate della Vusb è proprio quella di voler gestire anche clock diversi da 12 MHz, è un errore molto grave.
Secondo te, se Atmel ha deciso di utilizzare un quarzo da 12 MHz, alimentazione a 3.3V e software in assembler c'è un motivo reale oppure è solo perché gli passava per la testa di fare così in quel momento, oppure è la soluzione giusta per far funzionare una emulazione software, per quanto con dei limiti, di una porta USB ?

Edit: sto parlando di emulazione software della USB, nei micro con USB Hardware, come l'8u2, il discorso è diverso.

ok,
ma tecnicamente quindi, l'8u2 che ha il controller integrato, perche' viene usato con quarzo da 16 ?
avra' un prescaler che poi li porta a 12 ? ma perche' non usare direttamente 12 MHz come quarzo ?