Hallo, ich habe ein Problem mit dem PIC16F628A. Wenn ich ein fertiges Programm aus dem Internet auf dem PIC lade funktioniert das Programm. Wenn ich ein Programm mit MPLAB (mit allen Einstellungen) schreibe und dann drauf lade funktioniert das Programm nicht. Ich bin ratlos, habe verschiedene Sachen ausprobiert. Ich brauche dringend Hilfe, weil ich in der Prüfung bin. Vielleicht hat ja jemand eine Idee, woran das liegen könnte. Ich denke mal es liegt an irgendeiner Einstellung von MPLAB. Benutzte MPLAB 7.40 oder 7.50. Hofffentlich könnt Ihr mir helfen.
Klar kann ich das, auf den Fehler bin ich reingefallen!! Du hast warscheinlich das Konfigurationswort nicht richtig gesetzt!! Es reicht nicht, wenn man es unter MPLAB (Configurtation) setzt. Es muss im Quellcode eingestellt werden. GRUSS Ingo
Hallo zusammen, ich springe mal auf diesen "Zug" mit auf, da mein Problem ähnlich gelagert ist. Seit ein paar Jahren programmiere ich ein bißchen mit 16F628 rum und das klappt ansich sehr gut. Nun wollte ich auf den "A"-Typ umschwenken, da der 16F628 (ohne A) mir zu teuer geworden ist und der 16F628A der Nachfolger ist. Mein Problem ist, das ich den"A" nicht gebrannt bekomme. Meine Tools: - CCS Compiler - MPLAB 7.50 - Brenner5 von Sprut mit Änderungen für den "A" Typ - Software PBrennerNG von Sprut Das Problem scheint in den Konfig- und ID- Einstellungen zu liegen. Diese habe ich über #fuses NOPROTECT, NOLVP, NOBROWNOUT, WDT, PUT, INTRC_IO deklariert. In meine Software habe ich die Header-Datei des 16F628A eingebunden. In dieser sind die Namen für die Konfig-Bits identisch zum 16F628 geblieben. Wenn ich den Brennvorgang starte, wird das Hexfile augenscheinlich gebrannt, am Schluss erscheinen dann einige Fehlermeldungen, die falsche Konfig-und ID- Einstellungen angeben. Für den "A"-Typ scheint es eine neue Nomenklatur für einige Konfig's zu geben, u.a. auch für den interne Oszi, der jetzt INTOSC heißt. Leider bringt mich das nicht weiter, da mein Compiler dieses Wort nicht kennt und mit Fehlermeldung abbricht. Wenn ich die Configbits in MPLAB verstelle und das Programm kompiliere, stehen die Configbits genau so, wie sie stehen sollten. Wer von euch weiß Rat? Ich stehe voll auf dem Schlauch...... Kann es sein, das meine 16F628A Header-Datei nicht korrekt ist?? Gruß Uwe
Ich kenn den CCS nicht. Wenn man die #fuses im CCS weglässt, kann man doch auch die Einstellungen mit MPLAB vornehmen, Ich arbeite mit dem C18 von Microchip (für die PIC18, mit den PIC16 hab ich schon länger nix mehr gemacht). Da funktioniert das auf jeden Fall. Gerhard
Hallo Gerhard, wenn ich die #fuses weglasse, werden die Eionstellungen im MPLAB aber meineswissens nicht mit kompiliert. Dann kann ich die Einstellungen nur im Brennprogramm machen. Wenn ich die Einstellungen dort mache, kann ich den PIC auch brennen und es funktioniert auch meistens (warum es manchmal in die Hose geht, weiß ich nicht). Aber irgendwie scheint die Nomenklatur der #fuses nicht zum Brennen zu passen. MPLAB versteht die Einstellungen anscheinend, da die Config-Bits korrekt eingestellt werden, wenn ich die vorher komplett verstelle. Der Brenner kommt damit einfach nicht klar, außer ich setze die Bits im Brennprogramm selbst... Der "normale" 16F628 funktioniert tadellos. Gruß Uwe
Die Konfig-Eínstellungen in MPLAb müssten schon übernommen werden. Du kannst aber schauen, ob MPLAB deine #fuses-Einstellungen versteht. Die Einstellungen im Quell-code überschreiben die in MPLAB. Das heisst, wenn du aus MPLAB heraus mit CCS übersetzt (zumindest funktioniert das beim C18-Compiler) übernimmt MPLAB diese Einstellung - und in der Konfiguration in MPLAB kannst du anschauen, was CCS produziert hat. Gerhard
Hallo Gerhard, genau so ist es.Ich glaube, wir hatten da etwas aneinander vorbeigeredet. Wenn ich die #fuses aktiv habe, kann ich im MPLAB die Einstellung der Config-Bits überprüfen. Aber in das Hex-File werden die dann nicht geschrieben, zumindest nicht bei mir. Wie dem auch sei, ich glaube das Problem lokalisiert zu haben und jetzt kompiliert der CCS auch korrekt, und das auch reproduzierbar. Beim 628 (ohne A) habe ich einige Cinfigbits einfach weggelassen, die ich nicht brauchte, bzw. weil es auch so funktionierte. Der 628A scheint da schon pingeliger zu sein. Nach dem ich in die #fuses MCLR , NOCPD mit aufgenommen habe, geht es einwandfrei,auch per ICSP in der Schaltung. Ob NOCPD notwendig ist oder nicht, habe ich noch nicht getestet, aber ich bin mir sicher, ss es minimum am MCLR gelegen hat. Dem 628 ohne A war das sch...egal. Da muss man erst mal drauf kommen. Ich hoffe, hiervon können jetzt auch noch andere Leute profitieren. Nochmals Danke für euren Support.So, und jetzt hoffe ich, das Speedy-Virus auch voran kommt und sein Progrämmchen zum Zucken bringt ;-) Gruß Uwe
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.