Hallo Zusammen, ich habe mir ein Tesboard mit einem PIC18F4550 zusammengebastelt, das mit 20Mhz betrieben wird. An LATDbits.LATD0 habe ich eine LED, die ich nun zum blinken bringen möchte. ********************************************************** #include <p18cxxx.h> #include "delays.h" #pragma config FOSC = HS //CPU=20 MHz #pragma config PWRT = ON #pragma config BOR = OFF #pragma config WDT = OFF //Watchdog Timer #pragma config LVP = OFF //Low Voltage ICSP #define LED LATDbits.LATD0 void main(void) { ADCON1 = 0x0F; LATD = 0x00; TRISD = 0xFE; while(1) { LED = 0; Delay10KTCYx(250); LED = 1; Delay10KTCYx(250); } ********************************************************** Das ganze habe ich mit MPLab IDE v8.10 und dem C18 Compiler geschrieben. Nur passiert da leider nichts. Der Oszillator funktioniert prima, das habe ich schon am Oszilloskop getestet. Wenn ich in der While-Schleife erst LED = 1 und dann LED = 0 schreibe, bleibt die LED konstant an. Hat hier jemand eine Idee was ich falsch mache?
Zum einen fehlt da eine "}" was aber wohl eher beim Kopieren passiert ist... Kann es sein das der Compiler ungünstige Optimierungsversuche unternimmt und dabei deinen Code löscht? (Vielleicht mal die Code-Optimierung ausschalten). Schöne Grüße, Alex
Binde mal statt der p18cxxx die p18f4550.h ein. Ansonsten hänge deine Schaltung mal an. Es kann auch sein, dass der Oszillator nur schwingt, wenn du das Oszi ranhälst. Resettet der Controller evt. selbständig? Wie groß ist denn der Pullup an MCLR?
Angehängte Dateien:
-
USB-Test.jpg
79 KB
Danke für die Antworten.
Die fehlende Klammer war ein copy paste Fehler. Ich habe die
Code-Optimierung ausgeschaltet, das Problem besteht weitehin.
Auch habe ich es mit der p18f4550.h probiert, leider ohne Erfolg. Den
Schaltplan habe ich angehängt.
Ich denke nicht das der Kontroller automatisch resettet, da die Led ja
konstant an ist wenn ich in der while-Schleife so definiere:
while(1)
{
LED = 1;
Delay10KTCYx(250);
LED = 0;
Delay10KTCYx(250);
}
Wie bekomme ich den raaus ob mein Oszillator nur schwingt wenn das Oszi
dran ist?
Der Pull-Up an MCLR ist 4k7 gross. Das ganze Board habe ich an dem CUI
angelehnt.
http://www.create.ucsb.edu/~dano/CUI/
Ich vermute mal die Funktion Delay10KTCYx(250); dauert entweder viel zu lange (falls der OSC z.B. nur mit 32 kHz laufen sollte), oder dann ist dort sogar eine Endlosschleife drin. Probier doch mal Delay10KTCYx(1); Gruss Roman
Ja, MPLAB SIM macht keine Anstände, und die Delay Funktion habe ich auch schon mit anderen werten probiert. Ich habe auch schon eine eigene Delay-Funktion probiert, mit for-Schleifen. Leider alles ohne Erfolg.
Bist du dir sicher, dass mit "#pragma config FOSC = HS" alle 4 FOSC Bits auf den HS Mode umgeschaltet werden? Standard ist nach Reset der interne Oszillator mit 32kHz. Nicht das die CPU nach damit läuft. Leider habe ich von C keine Ahnung, deshalb frage ich noch mal nach. Sven
Sven Stefan wrote: > Bist du dir sicher, dass mit "#pragma config FOSC = HS" alle 4 FOSC Bits > auf den HS Mode umgeschaltet werden? Standard ist nach Reset der interne > Oszillator mit 32kHz. Nicht das die CPU nach damit läuft. Leider habe > ich von C keine Ahnung, deshalb frage ich noch mal nach. > > Sven :) Nein bin ich nicht. Für mich is das hier auch Neuland (deswegen auch die vermeindlich einfache Aufgabe die ich mir gestellt hatte). Aber alle Beispiele die ich gefunden habe definieren den FOSC so. Ich habs auch mit #pragma config FOSC = HSPLL_HS probiert. Das hilft aber auch nicht. Interessant ist, das wenn ich die Delay Funktionen ausklammer, die LED auch konstant an ist, aber dunkler. Daher denke ich das der Fehler wirklich mit der delay Funktion zu tin hat. Ich hatte auch schon eine eigene benutzt [c] void delay(void) { int i; for (i = 0; i < 2500; i++); } [\c] aber die macht auch keinen Unterschied.
Das würde ich noch mal mit einer kleineren For Schleife Testen. So bis 250. Wenn der PIC wirklich noch mit 32kHz läuft, dann macht er nur 8000 Befehle pro Sekunde. Das könnten bei einer For Schleife bis 2500 (sind ja 16 Bit) schon mal über 10000 Befehle werden. Allerdings hätte die LED dann trotzdem alle 2-3 Sekunden mal blinken müssen. Eigenartig. Das ist halt der Grund, warum ich lieber Assembler mache... Sven Was passiert eigentlich wenn du bei "#pragma config FOSC = HS" aus dem FOSC ein OSC machst? Bei sprut steht da immer nur OSC=HS.
also soo langsam sind die pics auch nicht, die 2500 siehst du nicht blinken :) änder das in 65000, und das 4 mal hintereinander, dann musst du nicht so schnell schaun.
Doch, sind sie. Die 18F werden, sofern die Konfigbits das nicht ändern standardmäßig mit dem internen Oszillator mit 32kHz gestartet. Und irgendwie vermute ich, dass dort das Problem liegt. Das er die Anweisung "#pragma config FOSC = HS" falsch interpretiert und den PIC nicht auf den externen Quarz umschaltet. Ist aber nur eine Vermutung. Sven
Moin noch mal, danke für eure Vorschläge. Blinken geht nicht, weder mit 250 noch 4x65000. Ich denke nicht das dass Problem daran liegt das die LED zu schnell blinkt, denn wenn ich die while-Schleife so schreibe: while(1) { LED = 0; Delay10KTCYx(250); LED = 1; Delay10KTCYx(250); } geht die LED garnicht an. Das Programm kommt also auf dem PIC nicht über die erste Delay hinaus. Ich denke auch das irgend etwas mit dem Oszi nicht klappt. Ich habe da in der Zwischenzeit viele Foren durchsucht, aber nichts gefunden. Bei Sprut steht OSC = HS, da der sich nicht genau auf den 18F4550 bezieht, sodern auch den 18F8720. Der 18F4550 hat mehr konfigurationsmöglichkteinen für den Oszi, wegen dem USB. Ich habe die Config nun wie folgt definiert: #pragma config FOSC=HSPLL_HS #pragma config PLLDIV=5 #pragma config USBDIV=2 #pragma config CPUDIV=OSC1_PLL2 Das habe ich aus verschiedenen Foren und dem Link hier entnommen. http://www.mikroe.com/forum/viewtopic.php?t=10646 Angeblich die richtige Konfiguration für einen 18f4550 mit 20MHz
Weitere erläuterung zur Konfig des Oszi: http://www.wfu.edu/~rollins/18F_hardware.html Ändert aber leider nichts an meinem Problem.
du könntest im MPlab ->menu->configure-> das conf. bits sets in code häkchen entfernen, die fuses händisch setzten, und somit eine fehlerquelle ausschließen. @sven, mein post war nicht auf deins bezogen, hatte es noch nicht gelesen. natürlich hast du recht dass dort der fehler sein kann.
Was mir sonst noch einfällt: Hast du schon mal mit 22pF oder 27pF Kondensatoren probiert? Das wird es aber auch nicht sein. Denn wenn der Quarz nicht schwingt, würde auch die LED nicht angehen. So langsam gehen mir die Ideen aus.....
Ich habe die config auch schon im MPLAB gesett. Problem da ist dass dort viel mehr zu konfigurieren ist als ich brauche. Alles was ich nicht kannte habe ich dann auf default gelassen. Hat aber auch nicht geholfen. Da ich auch absolut keine Idee mehr habe werde ich mal 22pF einseten :)
Ne...wie vermutet machen die 22pF auch keinen Unterschied. Eigentlich hatte ich mir das gane nicht so schwer vorgestellt. Der Schaltplan ist doch ok, oder?
ich hab das mal intressehalber nachgebastelt, und dein listing ganz oben (mit include <p18f4550.h>), blinkt auf anhieb, auch wenn ich die fuses aus dem source setzen lasse. MPlab 8.01 c18 3.21 linker script 18f4550i.lkr sorry.
Hi, und welche fuses hast du im source gesetzt? Die hier #pragma config FOSC=HSPLL_HS #pragma config PLLDIV=5 #pragma config USBDIV=2 #pragma config CPUDIV=OSC1_PLL2 #pragma config PWRT = ON #pragma config BOR = OFF #pragma config WDT = OFF //Watchdog Timer #pragma config LVP = OFF //Low Voltage ICSP oder die #pragma config FOSC = HS //CPU=20 MHz #pragma config PWRT = ON #pragma config BOR = OFF #pragma config WDT = OFF //Watchdog Timer #pragma config LVP = OFF //Low Voltage ICSP Macht mich ja eigentlich glücklich dass es bei dir funktioniert :) Dann habe ich ja wenigstens einen Ansatz ... nochmal bauen!
CPUDIV = CPU System Clock Postscaler:
mögliche werte laut P18F4550.INC file
CPUDIV = OSC1_PLL2 [OSC1/OSC2 Src: /1][96 MHz PLL Src: /2]
CPUDIV = OSC2_PLL3 [OSC1/OSC2 Src: /2][96 MHz PLL Src: /3]
CPUDIV = OSC3_PLL4 [OSC1/OSC2 Src: /3][96 MHz PLL Src: /4]
CPUDIV = OSC4_PLL6 [OSC1/OSC2 Src: /4][96 MHz PLL Src: /6]
wobei dein osc1_pll2 bei mir nicht funktionert, die anderen
drei optionen schon. vermutlich ausserhalb der spezifikation.
die erlaubten werte findest du im pic datenblatt.
das zweite set ist ok, verzichtet aber auf die usb konfiguration.
>Eigentlich hatte ich mir das ganze nicht so schwer vorgestellt.
du hast dir auch nicht unbedingt den einsteigerfreundlichsten
kontroller ausgesucht, dafür bietet er aber möglichkeiten :)
Danke für die Hilfe (an alle). Ich werde berichten wies mit dem 2ten Versuch gelaufen ist.
So...hab mir ein neues Board gebaut, und nun klappts sofort. Bin zwar ein wenig neugirig wieso es beim alten Board nicht geklappt hat, aber ich denke das hebe ich mir für einen kalten Dezemberabend auf. Das ein PIC selber kaputt ist kommt bestimmt sehr selten vor, oder? Vielen Dank noch einmal!
Das hab ich hier schon öfter gelesen, dass User mit µC herumexperimentieren und ein vermeintlich einfaches Problem einfach nicht zu funktionieren scheint. Nach Austausch des Controllers ging es dann. Ob nun der PIC gleich defekt war oder man beim experimentieren das Teil einfach kurzzeitig überfordert hat, so dass er fehlerhaft reagiert ist meist nicht mehr nachzuvollziehen. Ich hatte bisher noch keine defekten PICs. Sven
ich hatte das problem auch mit diesem Sprut beispiel bei mir hatts geholfen wenn ich #pragma config FOSC = HS //CPU=20 MHz setzte und beim Oszillator die Kondis (glaube es waren 33pF oder so was) weggellassen habe (keine ahnung warum war aber so) Lukas
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.