delucagiovanni forum

Ciao a tutti,

Volevo emulare su un ATXmega32A4U una semplice connessione seriale sull'USB col classico programma echo, il pc invia un carattere e gli torna indietro dal micro, il tutto visto dal PC come una porta seriale che in realtà è una USB.

Da quel che ho capito la classe del device da utilizzare in questo caso è il CDC, ho letto l'AVR4907 http://www.atmel.com/Images/doc8447.pdf ed ho dato un'occhio al relativo codice ma sembra forse troppo complesso per quello che vorrei fare, sapete se esiste più "minimale"?

Ciao e grazie a tutti

PS: La dev-board che utilizzo è http://embeddedwirelesssolutions.com/atmel_breakout_boards/ews_atxmega32a4u_breakout_board

flz, vuoi utilizzare gli xmega perchè vuoi la USB.2.0 o c'è possibilità di usare la USB.1.1. anche con i mega standard?
da quello che ho capito vuoi realizzare un usb-rs232 converter
la cosa per me è un pò complessa, mai fatto nulla di simile
ciao

L'XMEGA che utilizzo supporta solamente la Full Speed (12 MBit/s) quindi USB 1.1, la ricerca di un esempio nasce dall'idea di capirlo a fondo per poi estenderlo e realizzare una comunicazione tra MCU e PC per scambiare informazioni

Dai on'occhiata qui http://www.fourwalledcubicle.com/LUFA.php

NO, niente e' facile con l'USB.

Lo sapevo, mannaggia
Bisogna mettersi li e pian pianino capire tutto.

La complessità però non è quella "nativa" dell'USB, sostanzialmente sta nell'utilizzare correttamente la libreria ASF che Atmel fornisce e che si appoggia al supporto HW ma che però trovo personalmente documentata "male" nel senso che è inteso più che altro il codice sorgente come documentazione.. sugli Application Note c'è scritto qualcosina ma non tantissimo *

Libri non ne ho trovati purtroppo. Sinceramente fossi in Atmel assumerei 5-6 persone full-time per scrivere un libro, tenere un blog e scrivere esempi e documentazione su questa benedetta ASF. Darei via anche dev-board e sample a chiunque pubblichi su internet materiale che semplifica l'adozione di ASF (es. a blogger che creano tutorial etc..). Tutte queste non sono pratiche nuove, molti big dell'informatica (sopratutto SW) fanno così da tempo con ritorni per l'ecosistema che si viene a creare che favorisce i loro prodotti rispetto alla concorrenza.

Ciao

*In genere c'è poco più del nome della funzione ma non molto altro, esempio udc_attach() abilita le pull-up oltre ad autorizzare l'enumerazione ma non è chiaro se collegare prima della chiamata il cavo USB (ad esempio se il tutto è alimentato dall'USB stessa) può comportare danni.. c'è proprio poco più di una riga nella documentazione.. non c'è scritto se può ritornare errori (non tramite il tipo che è void ma tramite altri meccanismi), etc..

Per me USB e ASF sono parolacce che non si devono MAI usare di fronte a bambini.

La libreria LUFA scritta da un giovane Australiano con radici Italiane fu creata per "semplificare" l'implentazione USB

Il suo lavoro e' stato perfino adottato dalla NXP (ex Phillips) per i loro chips e gli ha regalato un impiego ad Atmel in Norvegia.

Comunque spero che fra poco potro completamente cancellare ogni traccia del' ASF perche' dovrebbe essere possibile scaricare ed installare solamante i componenti Studio che uno usa.

Oggi mi sono messo li e ho riletto con calma gli AN, ho visto bene il codice e... ci sono saltato fuori!

In sostanza la maggior parte dei file va ignorata ed è il sorgente della libreria, il problema è che alcuni file vanno però personalizzati

Ho creato una mia "board" in ASF che corrisponde alla mia dev-board (in pratica nel mio caso ho specificato i pin dei led, dei pulsanti e le caratteristiche dell'oscillatore) ed ho sistemato i settings del progetto ed alcuni file per mappare i nuovi led agli stati del programma.

Ho modificato il progetto di esempio "semplificandolo", rimuovendo la parte UART (di default l'esempio fa da bridge UART<->USB), e scrivendo un semplice codice al ricevimento di un dato

Code: Select all

   int value = udi_cdc_getc();   // Leggi il dato
   udi_cdc_putc(value);           //  Scrivi il dato letto


Che fa proprio quello che volevo fare. La difficoltà maggiore diciamo è stata trovare i file da modificare.
Pian pianino mi sa che mi sto ricredendo su ASF..

usb? mamma mia!
io vado con gli FTDI, specie se devo comunicare in rs232->usb
mi piacerebbe usare l'usb dei micro-avr-U ma per ora mi sembra un limite irragiungibile.

Ciao ulisse21,

Più che agli ATMega-U io sono passato agli ATXMega, i vantaggi sono molteplici.
Ti faccio un esempio: l'ATxmega32A4U vs dell'ATmega32U4

ATxmega32A4U: http://www.atmel.com/devices/atxmega32a4u.aspx?tab=parameters
ATmega32U4 : http://www.atmel.com/devices/atmega32u4.aspx?tab=parameters

Te ne riporto alcuni:
- Costa circa la metà
- Frequenza doppia (32 MHz) a partire da 2.7v
- Maggiori periferiche (pin di IO, interrupt, SPI, UART, DMA, etc..)
- ADC 133 volte più veloce
- DAC 12 bit
- Non si brickano con FUSE sbagliati (non ci sono) e quindi non richiedono modalità parallele o strambe che quasi sempre vogliono dire dissaldare il chip o buttare la scheda

La scelta è presto fatta secondo me..

Certo, tutte queste funzionalità in qualche modo bisogna programmarle. Qui entra in gioco ASF che si occupa dei dettagli di basso livello.

Anch'io pensavo: USB mamma mia il protocol manual è 1k pagine scritte in cinese.. invece alla fine fa tutto la libreria e una volta capito come impostare il tutto la si può usare praticamente anche come una UART. Guarda quando dico mi sono messo con calma vuol dire che oggi mi sono preso un paio d'ore per fare tutto.

Per progetti "importanti" e dove massimizzare i costi è importante gli XMega possono sostituire più IC (DAC, ADC, USB) ad un prezzo di quasi un ATMega328P con un ottimo risparmio e semplificazione della scheda.

Il problema a livello di esempi e supporti della community è che sono utilizzati ancora da pochi perché le prime versioni era buggate. Ci sono ancora problemi di approvvigionamento (non tutti i modelli sono disponibili) ma basta andare su un modello con buona disponibilità ed il problema è risolto

Ciao

Io sto usando l'Xmega32E5 (senza USB per fortuna ...) in un prodotto che sto sviluppando perche' mi servono 12bit ADC e DAC, il tutto in assembly (e' grammaticamente giusto cosi? ). E' si avro' il problemino di comprarli per qualche paio di mesetti ancora ma penzo che tutto andra bene.

Comunque mi diverto vedendo parole Inglesi Italianizzate (brickano , buggate etc.) pensavo che solo noi Italiani all'estero usassimo queste cose come friggia, iarda, fenza, carru, painta etc...

friggia, iarda, fenza, carru, painta etc...

Sono ancora in italia ma non ne conosco neanche una..

La traduzione letterale sarebbe di brickare sarebbe "murettizzare", far diventare come un mattoncino l'HW

Dizionario Italo-Australiano-Siculo

Frigorifero=Fridge=Frigia
Cortile o giardino=Yard=Iarda
Steccato o recinto=Fence=Fenza
Automobile=Car=Carru
Vernice=Paint=Painta

Con ASF il piccolo progetto di "ECHO" tramite USB occupa purtroppo:

Program Memory Usage : 7784 bytes 21,1 % Full
Data Memory Usage : 1854 bytes 45,3 % Full

Diciamo "abbastanza" visto che non fa granché.. sopratutto occupa metà della SRAM (4k totali)
Progetti come XScopes utilizzano "Minimal USB Stack for ATxmega32a4u and related" https://github.com/nonolith/USB-XMEGA basato su LUFA, finché non sono alle strette con la memoria però continuo con ASF

Ciao

Cosa usi al lato PC per imbastire e gestire stream usb ?

Lato PC c'è una semplice connessione seriale virtuale COM (ricordo che utilizzo USB classe CDC), e viene vista proprio come una seriale. Per le mie prove ho utilizzato il semplice putty ma qualsiasi altro terminale o programma che utilizza la seriale va bene. A livello di driver non c'è da fare molto, è il driver usbser.sys che è presente nel sistema operativo che si occupa di tutto, c'è solo da personalizzare il file .inf.

Ciao

Sul mac e su linux e' un pelo diverso rispetto a Windows per quanto riguarda i driver ma per quanto riguarda il mondo usb il discorso non cambia con la classe CDC: sopratutto i servizi uart sono serviti dal kernel e con Api ben definite.

Pero' se al lato firmware e' un servizio uart allora mi chiedo che senso abbia sprecare un sacco di risorse per una classe che e' servita tanto meglio dai chip FTDI; un conto e' se tu come me avessi da veicolare stream real time CAN su usb (facendo abuso di bulk), in quel caso andresti a lavorare su qualcosa "custom", sia al lato firmware che al lato App, un conto e' aprirti una virtualCom (ttyUSB nel mondo *nix), voglio dire fosse un problema di banda ? I chip FTDI tirano fino a 1 Mbyte/sec, che e' quanto faresti con l'approccio seguito, si, pero' succhiando oltre 2Kbyte di ram per tener su lo stack usb, e quindi boh.

Sostanzialmente per il momento è per non comprare chip aggiuntivi ed avere PCB più compatti. Per device very low cost è una grande differenza.

Su MAC/Linux diciamo che non mi interessa come funziona la storia, il mio target è Win only.

Il discorso RAM è per il momento uno scotto da pagare utilizzando la ASF ma per il momento mi basta sapere che eventualmente ci sono alternative già pronte molto più leggere nel caso servissero.

Ciao