Hallo, Ich hab einen für mich kuriosen Fehler bei meinem PIC. Ich werde nicht gleich CODE snippets hochladen, da der Fehler vlt. bekannt ist. Mein Programm hat einen Interrupt, in diesem werden ankommende Daten aufgenommen und in der mainschleife wieder ausgegeben. Ich lasse mir das ankommen der Daten sowie das ändern der Daten über die LEDs anzeigen und es funktioniert. Aber am Ausgang kommt nix raus. Klingt als hätt ich die Ausgänge falsch konfiguriert. Jetzt lad ich das Programm neu in den Programmspeicher ohne Änderung daran vorzunehmen und noch bevor das Programm im Speicher ist (währrend der Ladebalken sich im MPLAb noch bewegt) , kommen die Daten auf einmal am Ausgang raus. Weißt das auf einen Bug hin oder auf falsch programmiert? wie kann etwas beim neuladen gehen, aber beim ersten mal nicht? Viele Grüße
Die Versionen der IDE und des Compilers wären auch noch interessant und ob du das PICkit gerade als Debugger oder Programmiergerät verwendest.
Ich verwende das Pickkit3 und den bezahlten Compiler für den PIC18LF8722. MCLRE hab ich OFF, habs aber jetzt mit ON probiert und es hat sich nix geändert.
Volker S. schrieb: > Die Versionen der IDE und des Compilers wären auch noch > interessant und > ob du das PICkit gerade als Debugger oder Programmiergerät verwendest.
Patrick S. schrieb: > Ich verwende das Pickkit3 und den bezahlten Compiler für den > PIC18LF8722. > > MCLRE hab ich OFF, habs aber jetzt mit ON probiert und es hat sich nix > geändert. Ok, den bezahlten Comp. ist schon mal gut. Aber das Pickit 3 ist ein Schwachsinn, um ehrlich zu sein. Bei mir haben die Programme meistens nur zufällig programmiert(habe den gratis Comp.) verwendet. Wenn ich das Programm in MikroC hineingespielt habe(mit veränderter Syntax) hat es einwandfrei funktioniert.
Verzweifelt an PIC schrieb im Beitrag #5308848: > Aber das Pickit 3 ist ein > Schwachsinn, um ehrlich zu sein. Bei mir haben die Programme meistens > nur zufällig programmiert(habe den gratis Comp.) verwendet. Da wirst du in den meisten Fällen einfach "zufällig" einen Fehler gemacht haben...
Verzweifelt an PIC schrieb im Beitrag #5308848: > Ok, den bezahlten Comp. ist schon mal gut. Was soll denn daran gut sein. Welcher Compiler genau ist es denn nun? Man kann ja durchaus unterschiedliche kaufen (C18, XC8, MicroE, CCS...)
Patrick S. schrieb: > Pickkit 3 wird als Programmiergerät eingesetzt! Ist denn das Programm schon fertig? Läuft alles? Wenn nicht, dann macht das doch gar keinen Sinn!
Es spielt auch keine Rolle. Da ist nix komplexes dabei und es funktioniert sowohl im Debug modus nicht, als auch wenn ich es nur zum programmieren nehme.
Patrick S. schrieb: > Es spielt auch keine Rolle. Im Debug Modus müsste aber eine Fehlermeldung kommen, wenn das Programm nicht läuft. Wenn nicht passiert, was du erwartest, kannst du einfach auf Pause drücken, und siehst sofort, wo sich das Programm rumtreibt...
Volker S. schrieb: > Verzweifelt an PIC schrieb im Beitrag #5308848: >> Aber das Pickit 3 ist ein >> Schwachsinn, um ehrlich zu sein. Bei mir haben die Programme meistens >> nur zufällig programmiert(habe den gratis Comp.) verwendet. > > Da wirst du in den meisten Fällen einfach "zufällig" einen Fehler > gemacht haben... Hast schon recht. Aber wenn das Programm dann mit dem MikroC Programmiergerät funktioniert hat?
Verzweifelt an PIC schrieb im Beitrag #5308912: > Aber wenn das Programm dann mit dem MikroC > Programmiergerät funktioniert hat? MPLABX hat schon seine Tücken und kann ganz schön auf den Nerv gehen. Nur sitzt der Fehler trotzdem in den meisten Fällen auf dem Stuhl vorm Rechner. (ist zumindest bei mir so ;-)
Volker S. schrieb: > Verzweifelt an PIC schrieb im Beitrag #5308912: >> Aber wenn das Programm dann mit dem MikroC >> Programmiergerät funktioniert hat? > > MPLABX hat schon seine Tücken und kann ganz schön auf den Nerv gehen. > Nur sitzt der Fehler trotzdem in den meisten Fällen auf dem Stuhl vorm > Rechner. (ist zumindest bei mir so ;-) Keine Sorge! Bei mir auch. Ich hab mich jetzt sehr an MikroC angefreundet, kostet zwar 200€, aber ist top. Kann ich dir nur empfehlen, genauso dem TO.
Verzweifelt an PIC schrieb im Beitrag #5308912: > Hast schon recht. Aber wenn das Programm dann mit dem MikroC > Programmiergerät funktioniert hat? Irgend was lauft bei der Bedienung MPLABx&PicKit3 falsch. Ab und an Compiliert MPLABx bei mir nicht mehr das Was aktuell im Editor ist oder schreibt ein altes HexFile. Irgendwas in dieser Richtung Halt, MPLABx neu starten und gut is. Und ja, beim programmieren mit dem PicKit3 rennt das alte Programm zwischendurch kurz 1(2?) wieder los. Kann also daraus an den Pin rütteln. Was mich auch nur zu einem Schluss bringt, der PicKit3 hält denen PIC, nach dem programmieren im Reset fest! Schon mal den PicKit abgezogen?
Verzweifelt an PIC schrieb im Beitrag #5308936: > Ich hab mich jetzt sehr an MikroC > angefreundet, kostet zwar 200€, aber ist top. Kann ich dir nur > empfehlen, genauso dem TO. Ich brauche was, das absolut kostenlos ist und auf Windows, MacOS und Linux läuft, damit unsere Studies das auch problemlos auf ihren privaten Rechnern installieren können.
Teo D. schrieb: > Was mich auch nur zu einem Schluss bringt, der PicKit3 hält denen PIC, > nach dem programmieren im Reset fest! Schon mal den PicKit abgezogen? Kommt drauf an, ob "Hold in Reset" gedrückt ist.
Volker S. schrieb: > Verzweifelt an PIC schrieb im Beitrag #5308936: >> Ich hab mich jetzt sehr an MikroC >> angefreundet, kostet zwar 200€, aber ist top. Kann ich dir nur >> empfehlen, genauso dem TO. > > Ich brauche was, das absolut kostenlos ist und auf Windows, MacOS und > Linux läuft, damit unsere Studies das auch problemlos auf ihren privaten > Rechnern installieren können. Aso ok. Dann ist das wohl besser. Teo D. schrieb: > Was mich auch nur zu einem Schluss bringt, der PicKit3 hält denen PIC, > nach dem programmieren im Reset fest! Schon mal den PicKit abgezogen? Hab alles probiert. Hardware ausgetauscht, sogar das Oszi. Software nochmal deinstalliert und installiert usw. Also den RESET hab ich nicht betätigt. Soviel technisches Verständnis hab ich noch hahaha
Verzweifelt an PIC schrieb im Beitrag #5308949: > Also den RESET hab ich nicht > betätigt. Soviel technisches Verständnis hab ich noch hahaha Ist jetzt nicht so deutlich zu sehen in der IDE. Unsere Studies bringen das durch planloses rumklicken immer wieder hin ;-)
Volker S. schrieb: > Verzweifelt an PIC schrieb im Beitrag #5308949: >> Also den RESET hab ich nicht >> betätigt. Soviel technisches Verständnis hab ich noch hahaha > > Ist jetzt nicht so deutlich zu sehen in der IDE. > Unsere Studies bringen das durch planloses rumklicken immer wieder hin > ;-) Tja wegen planlosen Rumklicken habe ich schon viel angestellt. Deshalb habe ich die IDE schon öfters aus dem Fenster werfen wollen, obwohl es mein Fehler war
Volker S. schrieb: > Ist jetzt nicht so deutlich zu sehen in der IDE. Ja, da kann man auch in nem Menü ein Häkchen setzen, nicht nur den Button drücken. Ob da ab u. an was durcheinander kommt, nur wo, vor oder hinter dem Monitor?
Volker S. schrieb: > Patrick S. schrieb: >> Es spielt auch keine Rolle. > > Im Debug Modus müsste aber eine Fehlermeldung kommen, wenn das Programm > nicht läuft. Wenn nicht passiert, was du erwartest, kannst du einfach > auf Pause drücken, und siehst sofort, wo sich das Programm rumtreibt... Das spielt in sofern keine Rolle, weil es kein unterschied macht, da im DEBUG Modus genau das gleiche rauskommt. Es läuft und es werden keine Fehler und nichts angezeigt. Das Programm läuft, ich muss für die Asugabe jedoch zwischen drin den Resetbutton drücken bzw. das Programm neuladen. Das weißt darauf hin, dass durch den Reset irgendetwas zurückgesetzt wird. Geupdated hab ich jetzt auch alles, immer noch gleicher Fehler. Leider hab ich nur das Pickkit 3 um herraus zu finden ob es daran liegt.
Patrick S. schrieb: > Das Programm läuft, ich muss für die Asugabe jedoch zwischen drin den > Resetbutton drücken bzw. das Programm neuladen. Das weißt darauf hin, > dass durch den Reset irgendetwas zurückgesetzt wird. Dann würde ich sagen dein Programm hat irgendwo einen Fehler. Vermutlich in Zeile 42 ;-). (soll heißen, ohne einen Code zu sehen, wird dir vermutlich keiner weiter helfen können) Kann auch ein ganz einfaches/abgespecktes Programm sein, welches den Fehler aber immer noch zeigt.
Sorry ich schick mal noch keinen Code, da ich den Fehler weiter einschränken konnte. Ich hab mir jetzt mit dem Oszi jeden Kanal angeschaut. Und RH4 bringt einfach keinen Pegel, bei allen anderen kommt das rinchtige raus. erst wenn ich den Reset Button drücke kommt der richtige Pegel. Nun zum Kuriosum. Ich hab einen anderen Port verwendet und hab den gleichen Effekt an einem anderen Pin. Der Controller muss irgendwie überfordert sein mit der Pinbelegung. Kann mir aber immer noch nicht erklären, wieso es dann nach dem drücken des Resets geht.
Patrick S. schrieb: > Ich hab einen für mich kuriosen Fehler bei meinem PIC. Ohne jetzt weeter gelesen zu haben die PIC Klassiker 1.Read modify write problem 2. Nicht abgeschaltete Funktionen wie analog ports, PWM ...
Das Problem ist glaub ich gelöst. Bei den Ports hatte ich auch alles abgeschalten und doppelt kontrolliert. Keine Ahnung. hab das Entwicklungsboard gewechselt und zack ging alles. War vlt alles nur Karma. Trotzdem kurioses Problem, dass die Pegel ohne einen Reset nicht richtig ankamen!
Nutzen von Erfahrung die andere haben... Ich habe auch mit ähnlichen Fehler gekämpft. D diese Beitrag: Beitrag "Unbenutzte Pins vom Mikroprozessor als Fehlerquelle." Antwort von einem Erfahrenen: > Defaultmäßig waren sie als Eingänge definiert. Die Lösung: Am Anfang > muss man > alle Ports vom Mikroprozessorsystem als Ausgänge definieren und sie auf > 0 setzen. > So schließt man das System gegen Störungen. Und meinen Anfänger Fehler > kann > man auch so verstehen. Man sieht nur die Pins die man braucht... Das ist eine Grundregel, kein Logikeingang darf undefiniert offen bleiben. Insbesondere bei CMOS-Bauteilen. Du kannst * die Pins auf Eingang schalten und auf Masse legen * die Pins auf Eingang schalten und über Pullups/-downs auf High oder Low ziehen. Bei geringen EMV-Anforderungen reichen die internen Pullups, sofern vorhanden * die Pins auf Ausgang schalten Was für Dich besser bzw einfacher ist hängt von Deiner Anwendung ab. Für Profis: * in einem Port einen Pin als Output High und einen als Output Low schalten und dort einen Abblockkondensator dranhängen. Beruhigt die anderen Pins des Portes (bzw des chip-internen power rails). * in einem Port einen Pin als Output High und einen als Output Low schalten und mit VDD bzw Gnd verbinden. Stützt die Versorgung der anderen Pins ordentlich ab. Liefert aber auch Diskussionsbedarf im Review.
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.