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.
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:> 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... ;-)
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.
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.
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.
