Hi, ich bin der David un bin neu hier, Zurzeit bin ich an einem Projekt mit einem PIC18F2580 dran. Leider habe ich ein Problem mit einem Pin. Zuvor habe ich den Vorgänger vom 2580, den 258 verwendet. Da Dieser aber nicht mehr produziert wird, ändere ich das Programm für den neuen µC um. Es ist alles eingerichtet, die Config Bits sind gesetzt und die alte Funktion ist auch gegeben. Nur ein Pin macht Probleme. RB2 sollte als Ausgang gesetzt sein, aber leider tut sich hier nichts. Meiner Meinung nach sind ADCON*, TRISB richtig gesetzt. RB1, RB3, usw- schalten alle, wie sie sollen. Hat von euch jemand schon mal von diesem Problem gehört? Ich habe schon vieles probiert. Den Ausgang mittels LATB, PORTB zu setzen, aber alles ohne Erfolg. #pragma config PBADEN = OFF Die Pins <0:4> habe ich auf digitale I/O gesetzt. PORTBbits.RB2 = 0; als Output, so wie auch RB1 und RB3. Was übersehe ich noch? Das setzen will nicht funktionieren, obwohl ich genau dasselbe mit den anderen Pins mache. Ich denke nicht, dass der Ausgang kaputt ist, da ich den µC schon 2x ausgetauscht habe. Die Last ist ein Transistor, welcher auch an anderen Pins liegt. Ich weiß langsam nicht mehr, was man noch ausprobieren könnte...
David N. schrieb: > PORTBbits.RB2 = 0; als Output, so wie auch RB1 und RB3. Meintest du vielleicht
1 | TRISBbits.RB2 = 0; |
Tris habe ich auch auf 0. Habe falsch geschrieben, sorry. Und ans CAN Modul habe ich auch schon gedacht, aber ich habe im Datenblatt nicht ganz durchgeblickt, wie ich dieses deaktivieren kann. Kannst du mir da bitte weiterhelfen?
David N. schrieb: > Zuvor habe ich den Vorgänger vom 2580, den 258 verwendet Warum jetzt nicht gleich den K80?
Hallo, #pragma config PBADEN = OFF !!!!!!!!! ist ziemlich gemein.... Gruss picfan
Versuch es mal mit CANCON = 0x20; oder CANCONbits.REQOP = 1; Nachtrag: Also das obige ganz zum Anfang und danach dann mit TRISB deine Richtungsregister setzen.
:
Bearbeitet durch User
picfan schrieb: > #pragma config PBADEN = OFF !!!!!!!!! > ist ziemlich gemein.... Betrifft auch nur Eingänge!
:
Bearbeitet durch User
Danke! Ich probiere es morgen mal aus und melde mich dann wieder! Thx :)
David N. schrieb: > PORTBbits.RB2 = 0; als Output, so wie auch RB1 und RB3. Du versuchst nicht zufällig so den Ausgang zu setzen oder ? (LATB verwenden.) Funktioniert denn ein Minimalbeispiel (Deine Config & Initialisierung und dann nur den Pin toggeln)? Kannst du deinen Code hochladen?
Ich habe beides ausprobiert. Mittels PORTB und LATB. Es tut sich bei beiden Varianten komischerweise nichts. Ein Minimalbeispiel habe ich noch nicht ausprobiert, ist aber eine Gute Idee. Leider ist das Projekt etwas vertraulich (Arbeitgeber :/ ) Ich schaue mal, was sich machen lässt, damit ich einen Code hochladen kann. Zum Beispiel, wenn nicht mal das Min.Bsp. funktionieren will. Config Bits vom Pic, CAN Modul ausschalten, Port Richtungen mit TRIS definieren, und dann mit LAT die Pins toggeln. Sollte eigentlich genug sein, oder? Danke für die Hilfe!
Etwas von meinem Projekt(PCFG !!):
#define ADFM 0b10000000 //0-Ergebnis links justieren, 1-0-Ergebnis
links justieren
#define ADCS 0b00000010 //FOSC/32
#define ACQT 0b00001000 //Acquisitions Time
#define ADCON2_InitWert (ADFM + ACQT + ADCS)
#define VCFG 0b00000000 //Vss - Vdd als Referenz
#define PCFG 0b1101 //nur PORTA Kanal 0 und 1 als Analog
Ein, alles andere und auch PORTB als digital
#define ADCON1_InitWert (VCFG + PCFG)
ADCON2 = ADCON2_InitWert;
ADCON1 = ADCON1_InitWert;
ADCON0 = ADCON0_InitWertAN0;
Setz doch in der Software einen Breakpoint direkt vor der Ausgabe über RB2 und schaue Dir dann alle Register an, die diesen Port irgendwie beeinflussen.
Jetzt habe ich den Übeltäter gefunden...
Eine Verständnisfrage habe ich allerdings immer noch, da ich nicht genau
verstehe, wie der Fehler zustande kommt.
Mein Vorgänger hat in der Initialisierung, vor dem Setzen der
Port-Richtungen eine Methode zum Löschen vom RAM aufgerufen.
Wenn ich diese Methode zum Löschen des RAM nicht ausführe, dann
funktioniert alles einwandfrei..
Kann mir wer sagen, was diese Zeilen genau machen? Ich blicke nicht ganz
durch, woher diese Magic numbers kommen bzw. was das welche Auswirkung
hat.
void RamClear(void) //Clear RAM Values
{
// Set FSR to 0 // Zero GPR's for all banks
FSR0 = 0x00;
while( FSR0++ != 0x05ff )
{
INDF0 = 0;
}
FSR0 = 0x0f00;
while( FSR0++ != 0x0f76 )
{
INDF0 = 0;
}
}
Das interessante ist, dass dies der erste Befehl beim Power Up vom Pic ist und erst danach wieder alle Register gesetzt werden. Vielleicht ist es, dass beim 2580 ein kleinerer RAM als beim 258 ist und deshalb irgendwas überschrieben wird, was nicht mit Registern gesetzt werden kann. Ich verstehe es nicht ganz :D Aber normalerweise sollte es eigentlich keinen Unterschied machen. Der RAM ist eh schon leer, sobald der PIC gestartet wird, sodass ich auf diese Methode verzichten kann...
David N. schrieb: > Ich verstehe es nicht ganz :D Schau doch einfach mal ins DataSheet. (Data Memory Organisation) Dann werden dir vielleicht auch die "Magic Numbers" nicht mehr ganz so magisch vorkommen. Der 2580 braucht mehr RAM für die SFRs und hat deshalb weniger für die GPRs übrig. Bei der Verwendung der gleichen/falschen Routine wird also ein Teil der SFRs gelöscht, die ja mit sinnvollen Werten vorbelegt sein sollten. ALLERDINGS sieht die Routine so aus, als wäre sie nicht für einen 18F258 geschrieben worden, sondern z.B. für einen 18F252. Bei dem fängt der Bereich für die SFRs bei 0xF80 an. Davor könnte noch ein kleiner Bereich sein, der zum Debuggen benötigt wird. Darum vielleicht Löschen bis 0xF76. Warum wird eigentlich ein "TEURER" CAN PIC benutzt, wenn CAN anscheinend gar nicht verwendet wird? Und nochmal die Frage: "Warum beim Umstieg nicht gleich ein K Typ?" (wesentlich billiger, mehr Features, mehr Leistung)
:
Bearbeitet durch User
David N. schrieb: > Mein Vorgänger hat in der Initialisierung, vor dem Setzen der > Port-Richtungen eine Methode zum Löschen vom RAM aufgerufen. Was ist der Grund, dem Compiler ins Handwerk zu pfuschen? Der Compiler initialisiert doch automatisch alle benutzten Variablen. Schau mal ins Assemblerlisting. Da sollte bereits eine Routine drin sein, die den RAM lädt. In der Regel wird auch der unbenutzte RAM gelöscht.
Peter D. schrieb: > Der Compiler initialisiert doch automatisch alle benutzten Variablen. Nicht unbedingt. Hier könnte der C18 Compiler benutzt worden sein. Da ist das optional. Kleiner Ausschnitt aus dem User Guide: ######################################################################## Whether the startup code initializes idata sections is determined by which startup code module is linked with the application. The c018i.o and c018i_e.o modules perform the initialization, while the c018.o and c018_e.o modules do not. The default linker scripts provided by MPLAB C18 link with either the c018i.o or c018i_e.o module depending on whether Non-extended mode or Extended mode is being utilized, respectively. The ANSI standard requires that all objects with static storage duration that are not initialized explicitly are set to zero. With both the c018.o/c018_e.o and c018i.o/c018i_e.o startup code modules, this requirement is not met. A third typeof startup module, c018iz.o and c018iz_e.o, is provided to meet this requirement. If this startup code module is linked with the application, then, in addition to initializing idata sections, all objects with static storage duration that are not initialized explicitly are set to zero. ########################################################################
Schau doch einfach mal ins lst-File, ob Du eine entsprechende Struktur
zur Initialisierung findet. Beispiel:
68 ; Clear objects allocated to BANK0 (128
bytes)
69 000702 EE00 F060 lfsr 0,__pbssBANK0
70 000706 0E80 movlw 128
71 000708 clear_0:
72 000708 6AEE clrf postinc0,c
73 00070A 06E8 decf wreg,f,c
74 00070C E1FD bnz clear_0
75
76 ; Clear objects allocated to COMRAM (37
bytes)
77 00070E EE00 F001 lfsr 0,__pbssCOMRAM
78 000712 0E25 movlw 37
79 000714 clear_1:
80 000714 6AEE clrf postinc0,c
81 000716 06E8 decf wreg,f,c
82 000718 E1FD bnz clear_1
Franky77 schrieb: > Schau doch einfach mal ins lst-File... Oder in den User-Guide des uns unbekannten Compilers. (suchen nach "startup code" wäre bei XC8 und C18 ein guter Start)
Vielen Danke für die vielen Antworten! Ich lese mir mal alles durch, was ihr mit vorgeschlagen habt. Danke!!
David N. schrieb: > FSR0 = 0x0f00; > while( FSR0++ != 0x0f76 ) > { > INDF0 = 0; > } Hier wird CANCON (0x0F6F) auf 0 gesetzt und damit Request CAN Normal Mode ausgeführt -> das CAN Modul übernimmt die Kontrolle über RB2
Das wars.... vielen Dank!! Ich lösche jetzt nur noch die GPR bis 0x5FF. Die SRF lasse ich nun in Ruhe. Es ist ja eigentlich auch nicht sinnvoll, diese manuell zu löschen. Diese haben schließlich alle einen definierten Status nach einem Reset.
Witkatz :. schrieb: > Hier wird CANCON (0x0F6F) auf 0 gesetzt und damit Request CAN Normal > Mode ausgeführt -> das CAN Modul übernimmt die Kontrolle über RB2 Das hätte doch eigentlich beim 18F258 auch passieren müssen... David N. schrieb: > Ich lösche jetzt nur noch die GPR bis 0x5FF. Die SRF lasse ich nun in > Ruhe. Es ist ja eigentlich auch nicht sinnvoll... Wie Peter schon angemerkt hat ist das möglicherweise alles gar nicht sinnvoll. Da dein Compiler aber immer noch geheim ist, weiß man da nichts genaues gar nicht ;-)
:
Bearbeitet durch User
Beim 2580 ist ab 0xF00 ein teil der CAN SFR. Wenn diese rückgesetzt werden, dann wird die "normale" Standardeinstellung überschrieben und auch deshalb wahrscheinlich das CAN Modul aktiviert. Ganz genau habe ich mir noch nicht angesehen, welche Register es hier speziell betrifft. Beim 258 sind ab dieser Adresse nur 'unused' Bereiche, was also keine Auswirkung hat. Achja, sorry, total vergessen, auf diese Frag zu antowrten! ich habe den C18 v3.47 Compiler. Der Linker nimmt das c018i.o file, womit alles initialisiert werden sollte. Heißt, du empfiehlst mir, auf das löschen zu verzichten? :) Ich glaube, das werde ich auch so machen.
Das Register CANCON hat sowohl beim 2580 als auch beim 258 die gleiche Adresse (0xF6F). Es müsste also auch beim alten Projekt schon überschrieben worden sein, wenn da ein 18F258 verwendet wurde. David N. schrieb: > Der Linker nimmt das c018i.o file, womit alles initialisiert werden > sollte Damit wird alles initialisiert, was auch im Sourcecode initialisiert wird. Es wird nichts gelöscht! Wozu auch? Fatal wäre natürlich, wenn es im Sourcecode "idata sections" hätte die beim Startup initialisiert und danach durch RamClear() wieder gelöscht werden, weil das ja erst nach dem Startup kommt.
idata sections gibt es keine. Ich belasse es nun so, dass ich einfach nichts mehr lösche. Vielen Dank für eure Hilfe und ich wünsche ein schönes Wochenende!
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.