Hallo liebe Leute, ich beabsichtige, einen PIC18F4455 an den USB-Bus anzuschließen um damit ein (intelligentes) I/O-Modul aufzubauen. Der Einfachheit halber will ich die RS232-Emulation über USB (CDC-Firmware von Microchip) einsetzen. Programmieren werde ich wohl in C mit dem C18 (notgedrungen). Die Schaltung ist auch schon fertig und aufgebaut, Controller mit einem kleinen Test-Programm und CDC-Firmware programmiert und am USB angeschlossen. Soweit, so gut... Aber, es läuft nicht. Um den Fehler zu finden benötige ich Eure Hilfe, denn die CDC-Firmware ist nicht so ausführlich dokumentiert. Wer also damit schon Erfahrung gesammelt hat, den bitte ich, mir zu schreiben. Es fängt an mit den Pull-Ups: Schaltet die Firmware die internen Pull-Ups des Controllers oder muss der angelötet werden? Wenn ja, dan müsste der an D+ für Full-Speed, oder? Taktgenerator: benötigt die Firmware eine spezifische Takt-Quelle und Frequenz? Der 18F4xxx hat glaube ich ca. 2.000.000 Möglichkeiten ;-) Im Moment sieht meine Schaltung so aus: keine Pull-Ups (mit Pull-Up brachte keine Verbesserung) Takt: Quartz mit 24Mhz an OSC1,OSC2, also 24MHz für CPU, Takt für USB (Full-Speed) über PLL: 24/6 = 4 -PLL-> 96 / 2 = 48 -> USB Vbus speist meine Schaltung mit 5V. Für jede Hilfe bin ich sehr dankbar. Gruß Christian
Ich würde sagen, dass ist so in Ordnung. Keine Pullups und Takt stimmt
auch.
>Aber, es läuft nicht.
Kannst du das etwas präzisieren?
Hallo Jupp, also, mit anderen Worten, es tut sich gar nichts auf dem USB-Bus, aber der Controller scheint zu laufen, ein Test-Output an LEDs geht. Ich habe leider auch keine ICD oder ähnliches. Ich kann also immer nur Programmieren, Einstecken und gucken. Programm sieht so aus, nur Test: CDC vorausgesetzt void UserInit(void) { TRISA = 0x0F8; TRISB = 0; TRISD = 0x0FF; //PORTAbits.RA1 PORTAbits.RA0 = 1; PORTAbits.RA1 = 0; PORTAbits.RA2 = 0; } void ProcessIO(void) { if (mUSBUSARTIsTxTrfReady()) { putrsUSBUSART("Hello PC"); PORTAbits.RA1 = 1; PORTAbits.RA2 = 0; } else { PORTAbits.RA1 = 0; PORTAbits.RA2 = 1; } } Gruß Christian
Hallo, habe das Programm nochmal komplett, mit den ganzen Configuration-Bits hochgeladen. Gruß
Hi Ja die Firmeware benötigt eine besondere Takteinstellung.. einfach im Datenblatt der Firmware nachlesen. Hast du dir auch schon Spruts Seite zu gemüte geführt? http://www.sprut.de/electronic/pic/projekte/usb4all/usb4all.htm http://www.sprut.de/electronic/soft/usboot/usboot.htm http://www.sprut.de/electronic/pic/8bit/18f/programm/usb2550/usb2550.htm mfg Schoasch
Hallo, gut, sprut hat auch seine eigene Sache geschrieben. Microchip lässt sich aber nicht sehr über den CDC aus. Etwas bereitet mir Kopfzerbrechen: Beim Messen an der Schaltung sehe ich keine 3.3V an Vusb, obwohl Configuration-Bit gesetzt und nur ein 220nF zur Stabilisierung gegen Masse daran hängt. Nun könnte man argumentieren, der Controller ist defekt. Dachte ich auch und nahm einen Ersatz vom gleichen Typ, gleiches Programm, gleiche Bits und trotzdem keine Spannung an Vusb. Wie geht das denn? Versorgungsspannung ist hingegen ok, Multimeter auch. Gruß Christian
sollte der Kondensator nicht etwas grösser dimensioniert sein? z.B. 470uF? http://burger-web.com/Projects/PIC18F4550USB/en_PIC18UsbBoard.htm.en
µF auf keine Fall, eher 470nF. Daran sollte es aber nicht liegen. Da fällt mir aber etwas ein, dass ich beim HID-Framework auch machen mußte. Sei doch bitte mal so nett, und lösche (bzw. auskommentieren) in der Datei usbcfg.h die beiden Zeilen #define USE_SELF_POWER_SENSE_IO #define USE_USB_BUS_SENSE_IO und probiere es nochmal aus.
Hallo Jupp, das könnte eine SEHR gute Idee sein. Denn ich habe PortA ohnehin anderweitig genutzt, also gibt es bei mir auch keine Sense-Leitungen. Ich werde das nachher mal ausprobieren, nach dem "Wochen-Einkauf" in der Stadt. Die Configuration-Bits (Quartz, etc...) habe ich übrigens alle nochmal mit dem Beispiel-Projekt von Microchip abgegelichen. Die arbeiten tatsächlich mit 20MHz und nicht mit 24Mhz von aussen, aber das sollte nicht schlimm sein, wenn am USB-Modul der richtige Takt (48MHz) ankommt? Schöne Grüße Christian
>Die arbeiten tatsächlich mit 20MHz und nicht mit 24Mhz von aussen, >aber das sollte nicht schlimm sein, wenn am USB-Modul der richtige >Takt (48MHz) ankommt? Nein, ist definitiv kein Problem. Ich hab z. B. einen 12 MHz Quarz benutzt, man muß halt nur die PLL anpassen, aber das hast du ja gemacht.
Mist, da fällt mir noch was ein :) Kannst du mit einem Oszilloskop schauen, ob dein Quarz wirklich mit 24 MHz schwingt? Denn wenn du ein Obertonquarz erwischt hast, sieht es schlecht aus.
Hallo Leute, erstmal vielen Dank an Jupp: der Beste Tipp! Wahrscheinlich habe ich durch Dich viele Stunden Suche gespart! Es lag tatsächlich an den #defines, dass keine Spannung am Vusb anlag. Nun mit Spannung identifiziert sich der Controller am Bus korrekt und verlangt nach dem Treiber. Mittels der INF von Microchip habe ich dann einen zusätzlichen COM-Port. Allerdings lässt der sich noch nicht öffnen. Definitiv muss die Hardware aber ok sein, weil der Controller sich ja identifiziert und daher die Kommunikation auch läuft. Es ist (mal wieder) die böse Software ;-) Muss man dem CDC Einstellungen für die Schnittstelle mitgeben, wie beim USART, etwa Baud-Rate, Parity, etc?? Gruß Christian
Schön, dass die Hardware jetzt läuft :) Ich hatte mal gelesen, dass das CDC-Framework von Microchip nur mit COM1-COM4 funktioniert.
Hallo, ja, ich hab den COM Port schon auf 2 gelegt, der Computer wollte mir zunächst 12(!) anbieten, obwohl 2 frei war. Habe dann versucht die Verbinung mit Hyperterm aufzunehmen, aber es kam die Fehlermeldung, dass COM2 nicht geöffnet werden kann. Gruß CHristian
Hallo, also es läuft jetzt. Ursache war ein Programmierfehler meinerseits, ich habe nicht abgewartet, dass USB bereit ist: if((usb_device_state < CONFIGURED_STATE)||(UCONbits.SUSPND==1)) return; Allerdings, wer wirbt denn da mit so niedrigem Stromverbrauch?? Microchip?? Mit aktivem USB und im Run-Mode schluck der µC gut und gerne 40mA, bei 4MHz Takt OSC1/OSC2 und PLL aktiv. (mit 24MHz OSC1/OSC2 ungefähr gleich). Schaut man in die Specs, in die Tabelle bei USB, dann steht da 'TBD' 'To Be Determined', tz tz tz. Da wirds für meine restliche Schaltung knapp (viele Optokoppler) und ich muss sehen was ich hier noch sparen kann. Hat jemand ähnliche Erfahrung mit dem PIC18xxxx und hohem Stromverbrauch im Vollbetrieb mit USB? Gruß Christian
Hallo Christian, wie oben geschrieben benutze ich ja das HID-Framework und ich habe gerade mal den Stromverbrauch gemessen. Er beträgt 70mA bei 12 MHz Quarz, der Controller ist ein F4550. Außer einer LED, deren Strom ich schon abgezogen habe, ist nichts weiter angeschlossen. Im Datenblatt ist auch nur der Strom für den EC-Oszillator mit 48 MHz angegeben, welcher bei 50 mA liegen soll. D. h. die PLL braucht 20 mA? Oder habe ich da was übersehen? Oder ist das mal wieder typisch Microchip, unvollständige oder falsche Datenblätter oder gar fehlerhafter Controller? MfG Jupp
Hallo, also ich finde die ganze Clock-Schaltung noch etwas verwirrend. Offensichtlich habe ich wohl den CPU-Kern auch mit 48MHz vom PLL gespeist und habe deswegen auch keinen Unterschied im Stromverbrauch gesehen. Ich hatte 24MHz und 4MHz-Oszillator an OSC1/2 angelötet und verglichen. Ich muss mich damit noch näher befassen. Wie generierts Du den Takt? Ich habe jetzt mal die Bits so gesetzt, dass eigentlich 4MHz zur CPU kommen und 48MHz (durch den PLL) zum USB. Allerdings läuft jetzt das Programm nicht mehr ordentlich. #pragma config CPUDIV = OSC1_PLL2 //Postscaler = 1 #pragma config USBDIV = 2 //from PLL 96Mhz/2 = 48Mhz for USB-Full-Speed #pragma config FOSC = HS //HS: Clock from ext Osc. #pragma config FCMEN = OFF Gruß Christian
Hallo Leute, Jupp, nach einigem Nachlesen des Clock-Kapitels und Ausprobieren kann man also folgendes sagen: Was ich vorhatte geht nicht. Entweder PLL oder direkt Oszillator! Wenn man also den PLL aktiv schaltet um den USB-Takt zu generieren, dann kann man für die CPU (speziell Primary Clock) nur noch PLL/2 bis PLL/6 auswählen, aber nicht den außen anliegenden Oszillator - deswegen lief mein Programm auch nicht mehr. Ich hab das wohl zunächst falsch verstanden. Momentan sieht meine Schaltung so aus, dass ich außen einen 4MHz Oszillator habe und den PLL einschalte, der USB bekommt 48MHz(PLL/2) und meine CPU 16MHz (PLL/6) um etwas Strom zu sparen. Der Stromverbrauch liegt damit etwa knapp unter 30mA, damit kann ich schon wieder besser leben. Wenn man nun für die CPU den internen Oszillator mit geringer Taktfrequenz einsetzt (Internal Oscilator) kann man sicher noch ein wenig Strom sparen. Soweit bin ich aber noch nicht vorgedrungen. Nachdem ich nun weiß, dass es so theoretisch geht, werde ich nun noch einiges damit zu tun haben, eine Firmware für mein Projekt zu schreiben und den Stromverbrauch der restlichen Schaltung noch ein bisschen einzudämmen. Wenn jemand zum Thema "USB mit PIC" noch Anmerkungen, Tipps hat, freue ich mich darauf. Schönen Gruß Christian
> ... den Stromverbrauch der restlichen Schaltung noch ein bisschen > einzudämmen. Da Du weiter oben "viele Optokoppler" erwähnt hattest, schau mal nach den ADuM Bausteinen von Analog Devices. Das sind Koppler auf magnetischer Basis die mit relativ wenig Strom auskommen. Ausserdem lassen sich sowohl Eingangs- wie auch Ausgangsseite wahlweise mit 5V oder 3,3V betreiben. http://www.analog.com/UploadedFiles/Data_Sheets/ADUM1200_1201.pdf Im SO16wide Gehäuse gibt es die Teile auch als 3 und 4-Kanal Version. Der Typ mit integrierter Stromversorgung hat allerdings einen ziemlich schlechten Wirkungsgrad, ist m.E. derzeit nicht geeignet um Strom zu sparen. Bezugsquelle für Privatkunden in Deutschland ist mir nicht bekannt.
Hallo Dieter, guter Tipp, ich wusste bisher gar nicht, dass es sowas gibt. Ich hatte bisher auf Darlington-Typen 4N32 (bzw. 4N33) gesetzt, da die eine relativ hohe Übertragung (ca 500%) haben. Ich werd mir das bei Analog mal ansehen. Danke und Gruß Christian
Hallo, um die Vorgänge auf dem USB Bus weiter beobachten zu können, ist das Programm Snoopy 0.22 sehr hilfreich. Bin mir aber nicht sicher, ob das Programm auch in Verbindung mit dem emulierten COM Port läuft, weiß ich nicht. Gruß Stampede
> Bin mir aber nicht sicher, ob das Programm auch in Verbindung mit > dem emulierten COM Port läuft, weiß ich nicht. Tut es.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.