integrato ;)
Commenta l'articolo

Rilevatore elettronico velocità USB
20/08/2007 - Views: 6706
Realizzazione passo passo di un apparato di rilevazione di velocità di oggetti passanti tra due fotocellule e collegamento di questo al pc tramite interfaccia USB. Contiene anche la guida sulla realizzazione dei programmi lato server (PIC18F4550) e lato client (PC) e dell'interfaccia USB.
Leggi tutto:
Commenti:

Commenti

Autore: Reason
(18:04:08 il 30/03/2010)

Ciao suondmao, complimenti per l'ottimo lavoro. Ho letto la tua relazione più e più volte e "credo" di aver compreso tutto, tuttavia connettendo il PIC al PC esso non viene riconosciuto. Sono partito con prove dal tuo firmware per poi provarne molti altri (di cui tutti i precompilati di microchip). Premetto che il PIC per altre funzioni lo programmo perfettamente, ma con l'USB ho Problemi. Le uniche cose (ipotesi) che mi sono venute in mente sono 2: 1) Il PIC è funzionante, ma il modulo USB dello stesso è guasto; 2) La connessione USB è sbagliata (cosa probabilmente dovuta al tipo di connettore che ho utilizzato). Se ho ben capito i Differenziali vanno così: PC D- -> PIC D- PC D+ -> PIC D+ cioè non vanno ad intrecciarsi come si farebbe per un link (credo). Ho pubblicato le mie problematiche come risposta al tuo articolo, relativo a questo progetto, su PC-Tuner. Se potessi illuminare su quale errore commetto te ne sarei grato. Grazie, saluti Reason.
Autore: Suondmao
(02:32:29 il 09/04/2009)

Mi dispiace ma come ti ho detto è passato molto tempo e tra l'altro adesso non lo ho neanche più installato. Sicuramente la libreria c'è comunque! Se proprio non la trovi puoi sempre usare un altro simbolo con la stessa piedinatura
Autore: Roberto_Roma
(21:07:22 il 07/04/2009)

Di nuovo ciao! Tra una scossa e un altra vorrei chiederti dove hai trovato la libreria della famiglia dei pic18f per altium designer. Sul mio altium (winter 09) non sono contemplati. Grazie!
Autore: Suondmao
(00:12:51 il 02/04/2009)

Nessun problema, sarò felice di aiutarti
Autore: Roberto_Roma
(19:55:01 il 01/04/2009)

Grazie!!! Tornerò a scocciarti se avrò qualche rognetta...! Spero di non disturbare troppo...ma purtroppo sono un neofita di queste cose...!
Autore: Suondmao
(17:30:46 il 01/04/2009)

E' passato un pò di tempo da allora, non posso darti la certezza ma quasi sicuramente ho usato Altium Designer. Qualche connettore però è stato ridisegnato successivamente con un programma di grafica per fargli prendere meglio le sembianze reali.
Autore: Roberto_Roma
(16:30:26 il 01/04/2009)

Ciao, il tuo progetto è interessantissimo e sopratutto completo! Dovrei realizzare una cosa simile ma per misurare la velocità dei veicoli veri! Prenderò spunto dal tuo progetto, soprattutto per la programmazione del pic. Una prima domanda che ti pongo è un pò fuori tema. Che programma hai utilizzato per disegnare lo schema elettrico?
Autore: Suondmao
(23:14:09 il 21/05/2008)

Ciao stefano, ti ho spostato qui il commento visto che era relativo essenzialmente a questo articolo.
Cosa intendi tu per class device?
Se intendi solo la visualizzazione dell'icona relativa alla descrizione della periferica installata leggi sempre in questa pagina il mio post delle 15:38:55 il 26/11/2007 dove rispondo ad Antonio su questa questione; se invece intendi la classe del firmware del pic che puoi usare è un'altra cosa:
Questa classe è relativa al tipo di applicazione (ed al grado di difficoltà) che vuoi realizzare: per questo pic la microchip mette a disposizione almeno 4 device class firmware (CDC,HID,MSD e Custom) ugnuna delle quali è più predisposta ad un tipo di utilizzo piuttosto che un'altro.
Ti faccio un breve riassunto se non hai le idee chiare:
Custom Class: Una periferica USB pura e semplice: adatta alla maggior parte delle applicazioni non specifiche (con tutti i pregi/difetti del protocollo USB)
CDC class: Sempre una periferica USB generica ma vista e installata sotto il sistema operativo come una applicazione collegata su una porta COM virtuale: questo ne semplifica la programmazione lato pc ma ne limita la velocità di comunicazione.
MSD class (Mass Storage Device) si spiega da solo: adatto per dispositivi di archiviazione di massa quali memorie esterne usb, ci penserà il firmware stesso a farsi riconoscere dal sistema come un "disco rimovibile".
HID (Human interface device) dispositivi come mouse e tastiere, neanche questi hanno bisogno di essere installati con driver specifici (li ha gia il sistema) e serve appunto per realizzare dispositivi come tastierini esterni.
Una volta scaricato e programmato il pic con questo firmware di base (anche se non aggiungi nulla di tuo) se realizzi correttamente anche il circuito del pic non devi fare nient'altro ed il pc lo riconoscerà e installerà senza problemi se tu fornirai i driver lato pc compresi nel tipo di pacchetto di firmware che hai preso dal sito microchip (sempre che ce ne sia bisogno).
Il link che ti serve è questo: Se ti serve altro fammi sapere, ti ricodo comunque che tutto questo era già scritto nell'articolo in pdf, spero di averti dato una mano
Autore: stefano INFN
(15:15:32 il 21/05/2008)

ciao ho letto il progetto che hai fatto con il PiC 18f45500, utilizzando l-interfaccia usb con il computer .. avrei una domanda da porti : scaricando dal sito della microchip il firmware posso praticamente scegliere il class device? altra domanda in sostanza io non devo programmare niente per far riconoscre a windows il pic ??? grazie se ti posso lasciare l'email : stefano.scordo@ca.infn.it
Autore: Antonio da Piacenza
(18:22:43 il 10/12/2007)

Eccomi quà. Dopo un attenta ricerca eseguita con molta pazienza sono riuscito a mettere insieme i particolari per ottenere una interfaccia CDC. Il sistema Win98SE deve avvalersi di due file molto importanti: USBSER.SYS e CCPORT.SYS. Grazie a questi due files il sistema riconosce l'interfaccia CDC ed imposta una virtual COM. Questo è quello che effettivamente succede. Naturalmente il file INF è completamente diverso. L'unica cosa che non funziona è che non assegna il numero della COM. Per il resto riconosce l'interfaccia e gli assegna il logo giusto ogni volta che si collega alla porta USB. Cosa che prima non succedeva. Comunque continuerò la mia ricerca per capire xchè non gli assegna il numero!
Autore: Suondmao
(12:40:26 il 06/12/2007)

Bastava guardare la documentazione ufficiale, comunque la sezione che ti interessa è questa:

;------------------------------------------------------------------------------
; Windows 98/Me Sections
;------------------------------------------------------------------------------

Puoi scaricare il driver qui: (ricordati di sostituire i tuoi vid/pid): e assicurati di avere i file wdmstub.sys e mchpusb.sys.
Autore: Antonio da Piacenza
(11:53:54 il 06/12/2007)

Se ha i la possibilità di gurdarci tu ai driver per win98se mi faresti un favore, anche xchè sai di che cosa si tratta. Intanto vado a vedere il programmatore dello spagnolo. Poi ti saprò dire, grazie.
Autore: Suondmao
(13:25:26 il 05/12/2007)

Ho guardato i config bits e non hanno problemi. Se hai win98 quei driver non vanno bene! C'è una particolare variazione per i sistemi antecedenti a NT in quei driver, se non c'è in nessuno che ti ho passato è perche la ho cancellata perchè non serviva, dovrebbe ancora esserci in quelli originali del pacchetto che scarichi dal sito della microchip. Se non li trovi te li recupero io e te li invio. Altra cosa, io ho fatto un programmatore USB con un pic18f2550 per pochi euro, trovi gli schemi in internet si chiama GTP-USB LITE. (Lo trovi su un sito spagnolo).
Autore: Antonio da Piacenza
(08:47:51 il 05/12/2007)

Ero certo che fosse un errore (oppure una svista) te l'ho voluto dire xchè nella email del giorno 5 novembre 2007 mi scrivesti: ti passo il mio vecchi progetto..., quindi di conseguenza presumevo che non avesse alcun tipo di anomalia! Comunque x tranquillizzarti ti garantisco che fin dal primo momento ho SEMPRE verificato i VID & PID sia nel firmware che nel file.inf. Detto questo ti chiedo: hai visionato i miei screen che ti ho inviato ????? Cosa ne dici ????? Potrebbe essere il sistema operativo Win98SE ????? Dirai che nel 2007 utilizzo ancora Win 98SE. E' vero è vecchio, antiquato ma purtroppo i miei programmatori di processori utilizzano sia la porta parallela che quella seriale. E' per questo che voglio approfondire i due sistemi di comunicazione USB e CDC proprio per convertire i miei programmatori da porta tradizionale a porta USB. Ho un piccolo dubbio: nel file.inf la voce Signature="$Windows NT$" non è che mi crea dei problemi visto che il mio OS è Win98SE ???? Tu cosa dici ????
Autore: Suondmao
(21:01:05 il 04/12/2007)

Ovviamente è un errore. E' sempre la prima cosa che bisogna controllare che abbiano la stessa conbinazione VID/PID, se no quando fornisci il driver al sistema operativo per cercare di installare il driver ti verrà detto che il driver non corrisponde alla periferica collegata. Quel progetto lo ho recuperato da un vecchio pc, dove alcune parti le ho riutilizzate per nuovi progetti, mi sarà scappato di mettere una diversa combinazione per un altro dispositivo, e di passarti il driver di questo. Comunque è la prima cosa che ti avevo detto di controllare la congruenza dei codici, se non combaciano te lo avrebbe detto anche il sistema operativo e non avresti installato niente. Si vede che avevi gia atlri driver con quella combinazione installati per un progetto differente, magari per il custom, se è cosi è sicuramente per questo che il dispositivo CDC, interpretato dal os come un dispostivo diverso, non riusciva a comunicare.
Autore: Antonio da Piacenza
(17:41:46 il 04/12/2007)

Ciao, ho visionato attentamente il tuo progetto CDC che mi inviasti il giorno 5 novembre 2007. Nella tua email il punto 4 dice: "Ti passo il mio vecchio progetto CDC sotto emulazione seriale come allegato, parte pc e pic". Ho trovato una incongruenza tra il VID che si trova nel file USBDSC.C e il VID che si trova nel file MCHPCDC.INF DOMANDA! E' normale oppure è un ERRORE ?????
Autore: Antonio da Piacenza
(08:23:17 il 03/12/2007)

Ti ho appena inviato di nuovo il tutto xchè tu possa darci un'occhiata. Comunque è vero, la velocità di trasferimento è aumentata notevolmente e ti garantisco che è la modalità BULK di altro non so dirti. Ho recuperato una documentazione in italiano sulla gestione della USB con il PIC18F2550, la stamperò e la leggerò sicuramente per capire bene la cosa. Per quanto riguarda la modalità CDC, ti ho inviato di nuovo le immagini del mio screen in modo che tu possa renderti conto della situazione. Sappiami dire che noti qualche cosa che va! Grazie, ciao.
Autore: Suondmao
(17:47:43 il 01/12/2007)

Leggiti il file /system/usb/usbdefs/usbdefs_std_dsc.h, ci sono un po di specifiche sul trasferimento che puoi usare, tipo il trasferimento asincrono/sincrono e altro. E leggiti i commenti del file usbdsc.c del progetto, dove dice:
  1. // The next parameter identifies the type of the endpoint. Available
  2. // options are _BULK, _INT, _ISO, and _CTRL. When _ISO option is used,
  3. // addition options can be ORed to _ISO. Example:
  4. // _ISO|_AD|_FE
  5. // This describes the endpoint as an isochronous pipe with adaptive
  6. // and feedback attributes. See usbdefs_std_dsc.h and the USB
  7. // specification for details.
Autore: Suondmao
(17:38:29 il 01/12/2007)

Non mi è arrivato ancora niente. Comunque a rigor di logica è difficile che tu possa aver aumentato la velocità passando da un trasferimento di tipo interrupt a bulk, visto che il bulk si usa per trasferire grosse quantità di dati ma a periodi sporadici, mentre l'interrupt si usa per trasferimenti continui di piccole quantità di dati. Al massimo potresti aver avuto un miglioramento ustilizzando il trasferimento isocrono, senza controllo sugli errori ma sempre continuo e di quantità di dati normali. Comunque quale è l'errore che dici che si trova nel file USBDRV.H?
Autore: Antonio da Piacenza
(12:04:11 il 30/11/2007)

Ti invio il tutto con la Posta Elettronica, ciao.
Autore: Suondmao
(19:19:09 il 29/11/2007)

La guida in italiano che intendevo è proprio il post di lentz su pctuner, che anche io in prima battuta ho seguito alla lettera prima di realizzare il mio progetto e ti posso assicurare che funziona!
Non homodificato ninente all'interno del USBDRV.H, quale errori dici che ci sta? Comunque l'unica cosa che devi fare, ma la dovresti aver già fatta, è commentare le due righe nel file USBCFG.H:
  1. //#define USE_SELF_POWER_SENSE_IO
  2. //#define USE_USB_BUS_SENSE_IO
Non so davvero cosa dirti, mi fai uno screen della tua device installato sotto gestione periferiche?
Autore: Antonio da Piacenza
(18:16:09 il 29/11/2007)

Eccomi quà! No non ho letto le specifiche dell'altra documentazione in italiano. Però mi piacerebbe. Hai il link???? Per quanto riguarda la velocità, si è vero in questo momento trasferisco 32KB/s pari 250Kbit/s. Posso dire che per i miei lavori "potrebbe essere sufficiente" ma se si potesse aumentare sarebbe meglio. Non ho indagato come si può fare, comunque... Il pomeriggio l'ho dedicato interamente alle prove della modalità CDC. UN FALLIMENTO TOTALE! E che non mi venga a dire il Sig. LENTZ che funziona senza alcun problema! Non è vero! Detto questo ho scoperto che c'è un' errore di codice nel file USBDRV.H rilasciato da Microchip. Un errore gigantesco. Sistemato l'errore, il progetto CDC rilasciato da Microchip NON FUNZIONA! A questo punto sono entrato nei meandri di Windows per andare ad eliminare tutti i files INF registrati nelle settimane passate, ho ripulito il file contenente il database di tutti i drivers del mio computer eliminando tutti quelli che facevano capo ai progetti USB, CDC, HID, MSD. In poche parole sono RIPARTITO da zero! Adesso voglio proprio vedere cosa dice LENTZ. Ho fatto tutto quello che a scritto sul sito (poteva dedicare qualche minuto in più e scrivere i particolari tecnici più comprensibili) comunque anche qui mi sono armato di santa pazienza per interpretare correttamente il suo italiano e il suo concetto di USB/CDC. Ho scaricato tutto quello che c'era da scricare ho installato tutto quello che c'era da installare (che poi tutto sommato era poca roba) risultato... NON FUNZIONA. Il sistema si comporta esattamente come ieri, come una settimana fa come un mese fa. NON VA! Ora, mi piacerebbe che ci fosse una persona che mi dimostrasse il contrario. Io ci ho speso anche troppo tempo! Credo che rinuncerò al CDC. Conosci qualche persona ITALIANA che mi potrebbe dimostrare il buon funzionamento CDC?????? Adesso sono stanco ed è tardi, ho voglia di una pizza (trovo più soddisfazione). Ciao.
Autore: Suondmao
(14:28:35 il 29/11/2007)

Complimenti! Ottimo lavoro! In pratica ora trasmetti a 32 kb/s (cioè a 0.25mbit/s, che equivalgono comunque a solo 1/6 della velocità della connessione USB 1.0 ).
Un utente che ha sviluppato la connessione sotto emulazione seriale, lo avrai letto sicuramente visto che è l'unica guida oltre la mia in italiano, dice di essere riuscito ad avvivare anche a 600kb/s.
Ricordo comunque che la velocità massima raggiungibile da questi tipi di progetto, secondo quanto detto dalla microchip, è la full speed, cioè quella della specifica USB 1.1 di 12mbit/s (cioè 1,5 mb/s) e dovrebbe essere raggiunta utilizzando la connessione "pura", non sotto emulazione. A questo punto mi viene da chiederti se i tuoi conti sulla temporizzazione siano estatti! Ti segno altri 2 link interessanti, il primo sulle spefiche dei vari standard usb e la comunicazione e il secondo il topic di pctuner dove si parla della comunicazione CDC, chissà che con il progetto di lentz non risolvi i tuoi problemi.
Autore: Antonio da Piacenza
(10:13:27 il 29/11/2007)

Sono di nuovo quà xchè ho buone notizie in merito alla velocità di trasferimento dei dati in modalità USB (vedi tuo progetto). Si sono riuscito a trasferire la bellezza di 262144 byte in 8 secondi. FANTASTICO!!!!!!!! FINALMENTE!!!!!!!!!!!!! Ti metto al corrente della modifica: nel file USBDSC.C ho modificato l' Endpoint Descriptors sostituendo il comando _INT con il comando _BULK. La velocità di trasferimento dei dati è decisamente alta e molto interessante. A questo punto rimane solo da sistemare "BENE" la modalità USB/CDC. Mi dai una mano????
Autore: Antonio da Piacenza
(08:52:39 il 29/11/2007)

Mi sembra di capire che i valori di Control Words sono inseriti direttamente nella Form "Configuration Bits" che si trova in Configure/Configuration bits. Cosa ben diversa da come viene gestita dal mio compilatore; tutti i valori di Configurazione vengono inseriti direttamente nel sorgente per mezzo della direttiva __CONFIG(...). A compilazione avvenuta, il file.hex contiene direttamente anche i valori di configurazione, mentre nel MPLAB bisogna fare un'Export. Va be comunque è un editor del quale non ho famigliarità. Ok veniamo al dunque, parliamo di CDC. I valori di configuration bits che hai riportato tu in questa pagina sono leggermente diversi da quelli che ho io. In un primo tempo ho utilizzato gli stessi tuoi e comunque il sistema non assegnava il numero di COM alla mia periferica. Successivamente girando su internet vidi un progetto USB/CDC dove l'autore specificava l'intera Configuration bits. Scaricai tutto e... delusione anche in quell'occasione il sistema non assegnava il numero di COM. L'hardware ti garantisco è corretto: 20MHz di quarzo e PIC18F4550, mentre la Configuration bits differisce in due punti punti (ti invio con e-mail la pagina della Configuration Bits). Prova a darci un' occhiata. Sono Cpu System Clock Postscaler e 96MHz PLL Prescaler. Nel frattempo mi leggo le informazioni al link che mi hai mandato. Grazie.
Autore: Suondmao
(13:05:09 il 28/11/2007)

Come questi progetti non riportano i settaggi dei bits di configurazione?! Li riportano eccome!
Sono gli stessi per entrambi i progetti, e se usi un quarzo da 20mhz non devi neanche toccarli (Se usi il pic18f2550 invece del 4550 allora devi modificarli).
Te li riporto anche qui per completezza:
Comunque a questo punto non so cosa dirti..l'unica è l'errore di cablaggio.Hai provato a impostare te forzatamente una COMx dal pannello di controlla alla tua periferica? C'è il menu a tendina per farlo nelle proprietà del dispositivo.
Per quanto riguarda il trasferimento interrupt non intendo questo:
Il firmware microchip è fatto per gestire l'arrivo dei dati in polling e questo non si può modificare! (a patto che non ti voglia riscrivere tu le funzioni lato pic). Quello che intendo io è modificare il tipo di trasferimento utilizzato, quindi sostanzialmente quello che dobvrebbe accadere lato pc:
Ci sono essenzialmente 3 tipi standard di trasferimento dati usb: bulk, interrupt e isochronous e la prova che ti ho consigliato di fare è quella di provare a impostare il firmware pic perchè lavori in interrupt se già non lo fa (ne accenno brevemente a pagina 19 del mio articolo in pdf, dai un occhio li ma non è tutto).
Comunque leggiti un attimo cosa sono questi tipi di trasferimento:
Autore: Antonio da Piacenza
(08:55:22 il 28/11/2007)

Si ho già provato a scaricare un progetto CDC vergine originale della Microchip. Ho fatto attenzione anche a VID e PID, ma il risultato è identico. Stesso comportamento. Ho un unico dubbio. Come ti avevo già fatto notare, questi firmware rilasciati dalla Microchip NON riportano i valori della CONTROL WORD. Io ho trovato su internet un progetto CDC dove l'autore "fortunatamente" aveva inserito i valori. Non è detto che questi valori siano compatibili con il mio progetto, pertanto potrebbe essere proprio a causa di uno di questi che non consente al sistema di riconoscere correttamente la periferica. Non sò, tu cosa ne pensi ????? Per quanto riguarda la prova di compilare e debuggare il sorgente DLL questo lo posso fare appena ho un buco a disposizione (poi ti saprò dire), mentre per quanto riguarda la modalità interrupt (anzichè Bulk) credo che tu intenda dire "modificare il firmware in modo che questo generi un'interrupt al ricevimento dei dati". E' così ??????
Autore: Suondmao
(21:04:15 il 27/11/2007)

Si avevo già guardato la procedura ieri sera, per fare un lavoro fatto per bene dovresti debuggare anche questa, quindi ti converrebbe compilare insieme al progetto lato pc anche i sorgenti della dll in modo da avere le funzioni già incluse, evitarti il run-time linking e quindi debuggare direttamente dal compilatore con il sorgente in C della mpusbapi. Comunque a occhio direi che il problema sta qui:
  1. // attempt an asynchronous read operation
  2. bResult = WriteFile(handle,pData,dwLen,&nBytesWritten,&gOverlapped);
  3.  
  4. if(!bResult)
  5. {
  6. // deal with the error code
  7. switch (GetLastError())
  8. {
  9. case ERROR_IO_PENDING:
  10. {
  11. // asynchronous i/o is still in progress
  12. switch(WaitForSingleObject(gOverlapped.hEvent, dwMilliseconds))
  13. {
  14. ...
  15. ...
  16. ...
(La stessa cosa viene fatta nella MPUSBRead() testanto il bResult della ReadFile())
Si tenta una lettura asincrona e se questa fallisce si attende una riposta del dispositivo e si controlla il valore di ritorno della WaitForSingleObject() per vedere se c'è stato timeout o altro. Potresti provare a debuggare e vedere se viene mai eseguito l'if(!bResult). Se questo viene eseguito sempre probabilmente è qui che si perde tempo, se no il problema sta altrove.
(Ovviamente resta sempre valido il consiglio che ti avevo dato di provare a lavorare in modo asincrono.)
Per quanto riguarda il progetto CDC non so cosa dirti, prova mangari a scaricarti un progetto vergine con classe sempre CDC dal sito della microchip e vedere se anche con quello hai gli stessi problemi. Hai cambiato la combinazione VID/PID con la quale avevi installato il mio progetto prima di installare il CDC magari con la stessa combinazione? O magari è un problema hardware di cablaggio..
Autore: Antonio da Piacenza
(16:56:31 il 27/11/2007)

Ho fatto altre prove con la linea USB sui tempi di comunicazione da PC a PIC. Per quanto riguarda il lato PIC, tutte le funzioni chiamate in causa per generare una scrittura verso il PC, sono velocissime. Non c'è elemento che possa costituire un ritardo. Diversamente per quanto riguarda il lato PC torno a ripetere che la procedura MPUSBWrite() genera un piccolo ritardo. Non so da che cosa è causato. Impostando il tempo di time-out a zero, non si ottiene nulla in quanto la procedura MPUSBWrite() non fa in tempo a "comunicare" con il dispositivo esterno e di conseguenza restituisce un valore che è pari ad un errore. E più esattamente ERRORE 0 (zero). Impostare un valore di time-out INFINITE la cosa non cambia, anzi qualora il dispositivo non comunicasse con il PC, quest'ultimo rimarrebbe bloccato. Ti ho inviato il file sorgente MPUSBAPI.cpp da interpretare (se hai voglia) in modo da capire che cosa succede quando viene eseguita la procedura MPUSBWrite(). Ciao.
Autore: Antonio da Piacenza
(08:30:46 il 27/11/2007)

Si, è vero, la procedura MPUSBOpen() impiega parecchio tempo xchè probabilmente deve "connettersi" con il dispositivo esterno. Ma una volta connesso la velocità di MPUSBWrite() dovrebbe essere velocissima proprio xchè la connessione è stata effettuata. Comunque, appena ho un buco fra i miei impegni di lavoro, sicuramente farò la prova da te suggerita, nel frattempo sarebbe interessante recuperare il sorgente della DLL. (dici che è un'utopia?). Per quanto riguarda la USB/CDC il sistema riconosce la presenza del nuovo hardware e una volta installato il file.inf effettivamente aggiunge una icona COM nella parte dedicata alle porte LPT e COM ma con un punto interrogativo al centro dell'icona. Il sistema non assegna nessun numero (COM) all'icona pur evidenziando che la periferica funziona correttamente. In realtà non è così xchè non avendo assegnato nessun numero di COM alla nuova periferica, non c'è la possibilità di aprire la comunicazione. Non riesco a capire! Ti viene in mente qualche cosa ??????????
Autore: Suondmao
(20:54:57 il 26/11/2007)

Leggendo la documentazione della mpusbapi.dll ho trovato due informazioni che forse ti potrebbero essere utili (per quanto riguarda la funzione MPUSBRead() e MPUSBReadInt()):
  1. //dwMilliseconds
  2. // - Specifies the time-out interval, in milliseconds. The function
  3. // returns if the interval elapses, even if the operation is
  4. // incomplete. If dwMilliseconds is zero, the function tests the
  5. // data pipe and returns immediately. If dwMilliseconds is INFINITE,
  6. // the function's time-out interval never elapses.
  7. //
  8. // Note: To use MPUSBReadInt(), the format of pEP has to be
  9. // "\\MCHP_EPz_ASYNC". This option is only available for
  10. // an IN interrupt endpoint. A data pipe opened with the
  11. // "_ASYNC" keyword would buffer the data at the interval
  12. // specified in the endpoint descriptor upto the maximum of
  13. // 100 data sets. Any data received after the driver buffer
  14. // is full will be ignored.
  15. // The user application should call MPUSBReadInt() often
  16. // enough so that the maximum limit of 100 is never reached.
Potresti fare una prova impostanto il parametro di attesa alla MPUSBRead() a 0 invece che a INFINITE come avevo messo io per leggere immediatamente il dato presente sul canale. La seconda prova che puoi fare invece riguarda la fuzione MPUSBReadInt() che a suo tempo non avevo implementato (ma lo puoi fare benissimo anche te) e provare a scambiare i dati in modo asincrono, utilizzando una trasmissione di tipo interrupt invece che bulk.
Autore: Suondmao
(20:40:25 il 26/11/2007)

L'esecuzione della MPUSBOpen() penso sia normale che non sia una scheggia, del resto deve verificare la connessione di un dispostivo e sarà pur stato previsto un timeout per la risposta che occorre aspettare. In ogni caso questa va chiamata una volta sola quindi il problema non sta qui. Se il problema allora sta proprio nella MPUSBWrite() più di tanto non so dirti; alla fine io ho solo importanto delle procedure da un modulo dll già scritto da qualcun altro, il massimo che posso fare è dare un occhio all'interno della mpsubapi.dll e vedere come sono implementate queste funzioni e se si possono ottimizzare (dubito però, visto che sono rilasciate direttamente dal costruttore).
Che problema hai con il progetto CDC? Quando attacchi la tua periferica viene almeno riconosciuto dal sistema il nuovo hardware?
Autore: Antonio da Piacenza
(17:36:30 il 26/11/2007)

uhauuuu! Questo si chiama "fare bene le pagine WEB" adesso si capisce bene. Anche xchè... l'occhio vuole la sua parte. OK veniamo al dunque: Non ho trovato il motivo per il quale sono necessari 8 secondi x inviare 16384 bytes; però in compenso ti posso dire che dopo aver debaggato il programma (parte PC) nella modalità Single Step, si nota molto bene che la procedura MPUSBOpen() impiega una vita mentre la procedura MPUSBWrite() è un pò più veloce della prima, ma comunque lenta lo stesso. Ho provato ancora la comunicazione USB/CDC. MACCHE'! Non ne vuole sapere di farsi conoscere dal sistema che è una COM virtuale! SONO FERMO!
Autore: Antonio da Piacenza
(16:02:05 il 26/11/2007)

Ciao. Ho fatto tutte le prove per ottenere un array con grandezza oltre a 128 char e ci sono riuscito. Ho capito come è la filosofia del compilatore. Ho ridefinito alcune aree RAM creando un file.lkr:

ACCESSBANK NAME=accessram START=0x0 END=0x5F
DATABANK NAME=gpr0 START=0x60 END=0x3FF
DATABANK NAME=usb0 START=0x400 END=0x4FF PROTECTED
DATABANK NAME=gpr1 START=0x500 END=0x57F PROTECTED
DATABANK NAME=gpr2 START=0x580 END=0x7FF
ACCESSBANK NAME=accesssfr START=0xF60 END=0xFFF PROTECTED
SECTION NAME=CONFIG ROM=config STACK SIZE=0x80 RAM=gpr1

gpr0 definisce un'area ram di 0x39F byte liberi teorici (in realtà sono 0x31D) usb0 definisce un'area ram di 0x100 byte occupati dal protocollo USB gpr1 definisce un'area ram di 0x80 byte occupati dallo STACK SIZE gpr2 definisce un'area ram di 0x280 byte liberi teorici (in realtà sono 0x261) per tutte quelle variabili che devono essere dichiarate utilizzando l'area gpr0, è sufficiente fare una dichiarazione normalissima es.:

char Var1, Var2; int Var3; long Var4; ecc.

ad esaurimento dell'area gpr0, per poter sfruttare l'area gpr2 sarà necessario impostare una direttiva di compilazione che specificherà l'indirizzo assoluto di inizio della RAM dove allocare altre variabili es.:

#pragma udata usbgpr2=0x580 //See Linker Script,gpr2:0x580-0x7FF
char Var5, Var6; int Var7; long Var8; float Var9 ecc.

in questo modo si riesce ad utilizzare tutta la RAM rimanente. Ho modificato anche il file.inf inserendo la Class: Class=USB e l'icona della mia periferica da punto interrogativo è diventata icona USB.
Autore: Suondmao
(15:38:55 il 26/11/2007)

Non preoccuparti, ho dato una sistemata al codice pascal perchè venga interpretato correttamente e indentato e colarato.
Per quanto riguarda la visualizzazione della tua periferica in pannello di controllo questo dipende dal driver .inf che usi. Se utilizzi il mio (che è quello della microchip) non viene specificata nessuna classe del driver, e quindi resta sconosciuto (e visualizzato con ?). Le righe che devi modificare per sistemare questa cosa sono nel file mchpusb.inf è la voce:

Class=Unknown

Puoi utilizzare una classe di driver già esistente e quindi vederci associata una icona predefinita dal sistema operativo; puoi ad esempio utilizzare:

Class=USB

Per vederci associata la classica icona con il logo usb. Se invece hai voglia di farti una classe tua, dove specifichi le tue caratteristiche e utilizzi una tua icona ti invito a leggere questi due documenti che ho trovato:
Ti consiglio di scaricarti il primo file .doc e dai un occhio alla sezione "Example inf" in fondo.
Autore: Antonio da Piacenza
(13:45:17 il 26/11/2007)

Ho notato che il fine riga (CR) non viene rispettato, di conseguenza la parte di programma scritta in Pascal non si capisce un gran che'. Hai la possibilita' di incollare delle immagini BitMap all'interno di questi messaggi?????
Ho un'altra domanda per te: come mai nella finestra che visualizza i driver installati, "Pannello di controllo/Sistema/Gestione periferiche", la mia periferica viene visualizzata con un punto interrogativo ?
In riferimento al fatto che il sistema impiega troppo tempo ad inviare 16384 byte di dati ho notato che il rallentamento è provocato dalla parte del computer e più precisamente nel momento in cui viene eseguita l'istruzione

MPUSBOpen: myOutPipe := MPUSBOpen(Selection, vid_pid, out_pipe, MP_WRITE, 0);

il programma esce da questa procedura dopo diverse centinaia di millisecondi.
Ti viene in mente qualche cosa in merito a questo particolare????? Grazie ciao.
Autore: Suondmao
(11:37:57 il 26/11/2007)

Ciao Antonio
Sono contento che ti sia servito il mio progetto! Almeno in parte ho raggiunto lo scopo per cui ho pubblicato il mio lavoro!
Veniamo ai tuoi problemi:
1) Il fatto che il software impieghi lo stesso tempo a inviare 256 pacchetti da 2bytes o 256 pacchetti da 64bytes mi fa pensare a 2 possibili cause:
- o in realtà viene sempre inviata la stessa quantità di byte, ma in un primo caso se ne utilizzano solo 2 e gli altri sono settati a 0 mentre nel secondo se ne utilizzano 62. (inizialmente le varibiali input_buffer e output_buffer nel progetto sono settate entrambe 128bytes e questi vengono sempre inviati, sia che tu ne usi 2 o 64)
- Oppure che intercorra lo stesso dalay di tempo tra una chiamata e l'altra della routine MPUSBWrite(). Se questo è vero occorrerà quindi verificare se il problema sta in questa parte latopc o il ritardo è dovuto alla routine di lettura latopic
Controlla quanti dati spedisci ogni volta che è la cosa più facile da verificare, cosi scartata una ipotesi ci possiamo occupare dell'altra.
2) Fortunatamente questo problema è di facile soluzione. Nel file rm4550.lkr del progetto che compili sono specificate le aree di memoria riservate per ogni zona del codice e dati che verrà compilato con le rispettive dimensioni.
Il problema della limitazione dei 128bytes contigui per un array può essere superato ampliando le dimensioni di queste zone, sta a te ampliare quella rispettiva alla zona dati, o a definirne una nuova all'interno della quale verrà fisicamente allocato il tuo array nel pic. Questa tecnica la trovi spiegata a pagina 70 nella guida al C18 della microchip che trovi all'indirizzo: E' facile ti riporto anche l'esempio che c'è su quella guida:

3. A new region that spans multiple banks must be created in the linker script.
Linker script before modification:
DATABANK NAME=gpr2 START=0x200 END=0x2FF
DATABANK NAME=gpr3 START=0x300 END=0x3FF
Linker script after modification:
DATABANK NAME=big START=0x200 END=0x37F PROTECTED
DATABANK NAME=gpr3 START=0x380 END=0x3FF

Ti ringrazio per postato le tue domande, fammi sapere se risolvi questi problemi
Autore: Antonio da Piacenza
(10:52:10 il 26/11/2007)

Ciao, ho un paio di domande da farti:
PRIMO ARGOMENTO: Dopo aver definito il prototipo per la trasmissione dei dati su USB, ho voluto provare ad inviare dal computer, 2 byte di dati all'interno di un' istruzione "for" di 256 cicli. Incollo la procedura in Pascal che si occupa di questa trasmissione: (anche se è Pascal sono sicuro che sei in grado di interpretarla senza alcun problema)
  1. procedure TFormTerminale.btnWrite255PacketClick(Sender: TObject);
  2. var
  3. SendBuf: TByteBuffer; // array di 64 byte
  4. Selection: DWORD; // double word
  5. SentDataLength: DWORD; // double word
  6. I: Integer;
  7. begin
  8. Selection := 0;
  9. myOutPipe := MPUSBOpen(Selection, vid_pid, out_pipe, MP_WRITE, 0);
  10. if (myOutPipe = INVALID_HANDLE_VALUE) then
  11. begin
  12. ShowMessage('Open out data pipe Fallito');
  13. Exit; // esce dalla procedura
  14. end;
  15.  
  16. SendBuf[0] := WRITE_255; // Comando da inviare al PIC
  17. for I := 0 to 255 do
  18. begin // istruzione for da 256 cicli
  19. SendBuf[1] := I; // Dato da inviare al PIC
  20. if MPUSBWrite(myOutPipe, @SendBuf, 2, @SentDataLength, 1000) <> 0 then
  21. begin
  22. if (SentDataLength <> 2) then
  23. ShowMessage('Comando WRITE_255, Fallito');
  24. end
  25. else
  26. CheckInvalidHandle();
  27. end;
  28. ShowMessage('Comando WRITE_255, completato con successo');
  29. MPUSBClose(myOutPipe);
  30. myOutPipe := INVALID_HANDLE_VALUE;
  31. end;

Ho notato che il computer impiega 8 secondi per inviare 256 pacchetti composti da 2 bytes. Da sapere che impiega lo stesso tempo anche se invio 256 pacchetti da 64 bytes (pari ad un totale di 16384 bytes).
NON TROVI CHE QUESTO SISTEMA IMPIEGHI UN PO' TROPPO TEMPO ?????
Secondo la tua esperienza c'è la possibilità di inviare grandi quantità di dati in un tempo decisamente corto ?????
Questo mi interessa perchè vorrei archiviare grandi quantità di dati all'interno di una SD Memory Card attraverso la porta USB.
SECONDO ARGOMENTO: Nel verificare alcune cose all'interno del sorgente "user.c" per il firmware del PIC, ho notato che non riesco a dichiarare un array più grande di 128 char perchè il compilatore MCC18 mi da

ERRORE: MPLINK 4.00, Linker Copyright (c) 2005 Microchip Technology Inc. Error - section '.udata_user.o' can not fit the section. Section '.udata_user.o' length=0x00000103
Errors : 1 Link step failed.
BUILD FAILED: Fri Sep 07 16:51:12 2007

Siccome non ho molta dimestichezza e tantomeno confidenza con l' MPLAB unito all' MCC18 (visto che preferisco usare il mio PlanetPICC 3.0) chiedo: secondo te come posso ottenere un array di dimensioni più grandi di 128 char visto che il PIC18F4550 è dotato di una RAM da 2048 bytes ????? Grazie.
Autore: Antonio da Piacenza
(09:17:46 il 26/11/2007)

Il progetto che ho scaricato dal tuo sito (interfaccia USB con il PIC18F4550), funziona perfettamente. Sono molto soddisfatto. Questo grazie alla tua documentazione; primo perchè è scritta in italiano e secondo perchè riporta un progetto completo in tutte le sue parti. Naturalmente io non ho sviluppato il "misuratore di velocità", ma mi sono limitato a capire il "concetto di USB" realizzando un prototipo di scheda con a bordo un potenziometro e una bancata di dieci LEDs. Ho modificato il file user.c riscrivendo buona parte del sorgente. La stessa cosa l'ho fatta dal lato PC. Ho realizzato un'applicazione con DELPHI 5.0 Prof. (linguaggio PASCAL) che interfacciandosi con la DLL mi permette di visualizzare il valore del potenziometro e gestire otto LEDs. Grazie alla tua pazienza e costanza (non è un complimento gratuito), posso dire che anch'io oggi sono in grado di gestire un flusso di dati che viaggiano sulla porta USB.

Aggiungi un commento

Nome:
Messaggio:
CAPTCHA image

Script Execution Time: 0.079619 seconds - Visite: 667946
Copyright © 2007-2018 Suondmao v0.1.5-1