Ich will den source von usb4all compilieren.( das coole ding von www.sprut.de). Leider ist das wohl mit einem mplab vor einiger Zeit compiliert worden und ich finde keinen Hinweis, welche Version es exakt war. Versuche ich es nun mit dem aktuellen Mplab-X, dann bekomme ich bereits in den includes Ärger, da dort der gleiche define einmal als Hex und einmal als Bin definiert wird. Nun habe ich mir eine Version 8.6 geholt, die compiliert auch, doch das Verhalten ist nicht korrekt, denn es werden keine IO-Pins gesetzt, obwohl am USB alles sauber quittiert wird. Hat jemand usb4all auf irgendeiner definierbaren Mplab-Version compilieren können ?
Was für Compiler hast du installiert? Das ist auf jeden Fall ein Projekt der alten IDE und für dem C18 Compiler. Sieht auch nach einer sehr alten Version des USB Frameworks aus.
:
Bearbeitet durch User
Das IDE ist Mplab 8.92 beim compiler habe ich den C18 3.47 (Eval-Version) getestet. Ich musste wenige defines korrigieren, die als binary und dezimal unter gleichem Namen deklariert wurden. Allein das lässt mich vermuten, dass es bei sprut ein älterer/toleranterer Compiler war. Kann man einem binary "ansehen", mit was er compiliert wurde ?
T. X. schrieb: > Ich musste wenige defines korrigieren, die als binary und dezimal unter > gleichem Namen deklariert wurden. Das klingt sehr seltsam; das darf kein Compiler von sich aus schlucken. Magst Du mal ein Beispiel für solche eine Definition (in Form einer Headerdatei, die beides enthält) zeigen?
bitte sehr: das meldet der compiler :\Programme\Microchip\mplabc18\v3.47\h\mwire.h:41:Error [1034] previous definition of macro 'SSPENB' does not agree C:\Programme\Microchip\mplabc18\v3.47\h\spi.h:51:Error [1034] previous definition of macro 'MODE_01' does not agree C:\Programme\Microchip\mplabc18\v3.47\h\spi.h:59:Error [1034] previous definition of macro 'MODE_11' does not agree MPLAB C18 3.47 (evaluation) das wird beanstandet: mwire.h /* SSPxSTAT REGISTER */ #define MODE_01 1 //Setting for SPI bus Mode 0,1 #define MODE_11 3 //Setting for SPI bus Mode 1,1 /* SSPxCON1 REGISTER */ #define SSPENB 0x20 // Enable serial port and configures SCK, SDO, SDI und hier die spi.h #define MODE_01 0b00000001 // Setting for SPI bus Mode 0,1 #define MODE_11 0b00000011 // Setting for SPI bus Mode 1,1 wenn ich statt der Bin-Definition auch obige Dezimalzahl schreibe, gibts keine Beanstandung. Es sind die offiziellen includes vom 3.47 C18 Compiler.
Und Du musst beide Dateien im gleichen Sourcefile einbinden? Daß "spi.h" für die SPI-Schnittstelle da ist, ergibt sich; was ist "mwire.h", wofür ist die da?
T. X. schrieb: > wenn ich statt der Bin-Definition auch obige Dezimalzahl schreibe, gibts > keine Beanstandung. Es sind die offiziellen includes vom 3.47 C18 > Compiler. Mach das einfach! (ich würde bei beiden die Binärschreibweise einsetzen) Die Pfadangaben im usb4all Projektfile (.mcp) deuten auf eine sehr alte C18 Version. Später wurde eine Versionsinfo integriert. (z.B. /opt/microchip/mplabc18/*v3*.*40*) Vieleicht war es bei den frühen Versionen noch kompatibel oder Sprut hat das auch selber abgeändert. Rufus Τ. F. schrieb: > was ist "mwire.h", wofür ist die da? Microwire (EEPROMs)
Volker S. schrieb: > (ich würde bei beiden die Binärschreibweise einsetzen) Damit legt man sich auf einen Compiler fest, der eine nicht im Standard definierte "Binärschreibweise" verwendet. Auch C11 kennt das 0b-Präfix nicht. So etwas sollte man sich --meiner Ansicht nach-- gar nicht erst angewöhnen. Meine eigentliche Frage, ob es wirklich nötig ist, im gleichen Sourcefile sowohl "spi.h" als auch "mwire.h" einzubinden, wurde im übrigen noch nicht beantwortet.
Rufus Τ. F. schrieb: > Meine eigentliche Frage, ob es wirklich nötig ist, im gleichen > Sourcefile sowohl "spi.h" als auch "mwire.h" einzubinden, wurde im > übrigen noch nicht beantwortet. In diesem Projekt http://www.sprut.de/electronic/pic/projekte/usb4all/usb4all.htm gibt es im Prinzip nur ein "user"-sourcefile
Rufus Τ. F. schrieb: > Damit legt man sich auf einen Compiler fest, der eine nicht im Standard > definierte "Binärschreibweise" verwendet. Auch C11 kennt das 0b-Präfix > nicht. Das sind eh Files aus der Bibliothek für die peripheren Module eines nicht Standard konformen, sehr PIC18 spezifischen und nicht mehr supporteten Compilers. Da machen die das eben (immer) ähm oft so. Was solls... ;-)
:
Bearbeitet durch User
T. X. schrieb: > wenn ich statt der Bin-Definition auch obige Dezimalzahl schreibe, gibts > keine Beanstandung. Es sind die offiziellen includes vom 3.47 C18 > Compiler. Funktioniert jetzt eigentlich alles? Ich habe mir das Projekt vor einiger Zeit auch mal kurz angeschaut, mich aber dann dagegen entschieden und mit einer aktuellen Version des Microchip Frameworks etwas eigenes zu bauen. Die "user" Dateien werde ich mir aber nachträglich noch archivieren. Man weiß ja nie ;-)
dass ich in den includes ändern musste, verwunderte mich schon, da ich annehme, dass der sourcecode bei sprut ohne diese "Nachbearbeitung an wundersamer Stelle" funktioniert hat. Er compiliert dann ohne Error, aber: Die Funktion ist nicht ok. Es wird zwar USB Empfang und Reply ausgeführt, aber die IO-Pins funktionieren nicht.
Welche Befehle schickst du genau? Kannst du nicht versuchen das zu debuggen? Einen Breakpoint in die Funktion, welche die Befehle abarbeitet und Schritt für Schritt schauen was passiert. Der PC wird dabei leider die Verbindung abbrechen und du musst die Schnittstelle schließen und dann den PIC resetten. Danach nächster Versuch...
ich nutze des Windows-Testprogram von sprut. Mit der V10-Firmware setze ich bei digital IO den init, dann write ich 0xAA und meine LED leuchten. Tausche ich nun die Firmware durch meine eigene V9, dann leuchtet nichts. Im Code laufe ich an die richtige Stelle, wie mir mein "dataPacket._byte[2]" im USB-Antwortstring verrät.s.u. Das mit dem Breakpoint checke ich nicht. Kann ich das auch nutzen im Live-Device ? Mit einem Simulator weiss ich nicht, wie ich den USB-Input simulieren kann.. void UP_IO(void) { switch (dataPacket._byte[1]) { case 0://aus: alle Pin auf input TRISA |= MaskeA; TRISB |= MaskeB; TRISC |= MaskeC; break; case 1://init: TRIS ganzer ports und pull-up TRISA = dataPacket._byte[2] & MaskeA; TRISB = dataPacket._byte[3] & MaskeB; TRISC = dataPacket._byte[4] & MaskeC; if (dataPacket._byte[5] & 1 == 1) INTCON2bits.NOT_RBPU = 0; //pullup an else INTCON2bits.NOT_RBPU = 1; //pullup aus break; dataPacket._byte[2] = 0x11; //xxx case 2://write: schreiben ganzer ports LATA = (LATA & (~MaskeA)) | (dataPacket._byte[2] & MaskeA); LATB = (LATB & (~MaskeB)) | (dataPacket._byte[3] & MaskeB); LATC = (LATC & (~MaskeC)) | (dataPacket._byte[4] & MaskeC); dataPacket._byte[2] = 0x12; //xxx break;
T. X. schrieb: > Das mit dem Breakpoint checke ich nicht. Kann ich das auch nutzen im > Live-Device ? Live-Device? Das checke ich nicht ;-) Was hast du für ein Programmer/Debugger?
Ich habe die Platine vom usb4all gebaut. Dort kann man per Jumper den bootloader so einstellen, dass er von der Windows-Seite eine neue Firmware laden lässt. Das Board hat den USB-Port und die IO-Pins für die LEDs. Ansonsten habe ich einen China-Programmer, der den PIC standalone schreiben kann.
T. X. schrieb: > Ansonsten habe ich einen China-Programmer, der den PIC standalone > schreiben kann. In China gibt es auch PICkit Klone, aber so einen hast du dann wohl nicht?
Seltsam, wenn man in der Demosoftware den Haken bei CDC blablabla setzt sieht man wohl was da geschickt wird. Für init-IO 50 11 ...: >ASCII_tx: 50 >#50- 11 -00-00-00-00-00-00-00-00-00-00-00-00-00-00- >ASCII_tx: 50 >#50- 02 -55-55-55-55-55-00-00-00-00-00-00-00-00-00- Das sollte doch eine laut Beschreibung eine 01 sein. Kannst ja mal im Sourcecode auf case 0x11 : ändern und schauen, ob sich was tut.
:
Bearbeitet durch User
ich werde mir dann eine china pickit3 besorgen. die cdcblabla-strings sind bei mir gleich zwischen der V10, die funktioniert und meiner selbst compilierten V9.. die leider keine LED schaltet.
T. X. schrieb: > die cdcblabla-strings sind bei mir gleich... wenn die v9 aber was anderes erwartet? Geschickt wird anscheinend 0x50 0x11. Was soll die v9 darauf antworten?
So, habe jetzt ein pickit3 aus dem Land des Lächelns. Irgendwie habe ich Probleme mit dem gleichzeitigen USB-Betrieb des usb4all und dem Pickit. Ich habe einen breakpoint gesetzt, aber ich sehe immer eine asm-Zeile, die ich nicht mit dem Breakpoint korrelieren kann. Wenn ich dann RUN oder ähnliches auswähle, verschwindet der PIC meistens vom USB oder der pickit verliert die Verbindung. Da ich mit dem Pickit teils an den Pins hänge, die von der SW als Ausgang angesteuert werden, frage ich mich, ob das irgendwie abgefangen wird oder ich mir per SW dabei den Debugger abschalte ???
Das, das USB-Device (der PIC) beim Anhalten verschwindet ist normal. Nach jedem Halt muss die Schnittstelle geschlossen, ein Reset ausgeführt werden und die Schnittstelle wieder geöffnet werden. Das Beteriebssystem (Windows) hat gemerkt, dass das USB-Gerät nicht mehr innerhalb vorgeschriebener Zeiten reagiert und gedacht es wurde entfernt. Das PICkit ist davon allerdings normalerweise nicht betroffen. Die PGC/PGD Pins sollten eigentlich während des Debuggens in ihrer normalen Funktion deaktiviert sein. Ich habe aber auch schon gesehen, dass es da Probleme gab. Am besten du verwendest die erst mal einfach nicht. <edit> mit der Zeit wirst du vermutlich heraus bekommen, warum der Debugger an einer bestimmten Stelle im Code (oder auf den ersten Blick auch sonst wo ;-) steht, wenn das Programm stoppt.
:
Bearbeitet durch User
Ich hab's gelöst. Volker SK (vloki) hatte bereits den Tip gegeben, den ich einfach nicht glauben wollte: Das Testprogramm schickt ein 0x11 für init, aber der sourcecode der V9 prüft nur auf 0x1 ab. Gibt man den gleichen Befehl an eine V10, dann funktioniert es.. scheinbar hat die V10 irgendwo eine Bitmaske auf den Befehl, die V9 nicht hat. Das ist doch der Tatbestand der Heimtücke ? In Summe war's ein harter Kampf für ein paar LEDs, aber ich habe jetzt den Code verstanden, das Pickit in Betrieb ... der Lerneffekt war groß ;-) Danke für eure Tips.
T. X. schrieb: > aber ich habe jetzt den Code verstanden, das Pickit in Betrieb ... > der Lerneffekt war groß Ist doch super ;-)
kurze Frage hierzu: hat vielleicht jemand noch eine fertige Platine (unbestückt) übrig? Danke!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.