Hallo zusammen, ich bin neu hier und beschäftige mich auch erst seit wenigen Wochen mit den PIC's. Angefangen habe ich mit einem 44- Pin Pickit2 Demo Board. (PIC 16F887) Nun habe ich mir eine weitere Schaltung gebaut und benutze jetzt den PIC 16f877A. Weiterhin wollte ich aber mit dem Pickit2 arbeiten, und damit die Programme auf den PIC brennen. Ich habe, wie im Pickit2 user guide angegeben, die 5 Pins korrekt angeschlossen. Den MCLR Pin habe ich mit einem Pull up Widerstand auf +5V gezogen. Das Pickit2 erkennt das Device und kann den Program Speicher auch auslesen. Jedoch funktioniert das Brennen nicht. Ich habe schon sämtliche Problemlösungsansätze ausprobiert, jedoch besteht das Problem immer noch. Habt ihr eine Ahnung was das Problem ist? Brauch ich eventuell einen externen Clock, da ich bei den Configaration Bits keinen internen Clock auswählen kann. Gruß andi
Andreas Ede schrieb: > Brauch ich eventuell einen externen Clock, da ich bei den Configaration > Bits keinen internen Clock auswählen kann. Den brauchst du in jedem Falle. Ältere PICs, und dazu gehört der 16F877A, haben noch keine internen Oscillatoren und demnach kann man diese auch nicht in der Config einstellen. Ich hätte jedoch gedacht, dass das Rauschen an den Pins einen unkontrollierten Ablauf des Programms macht. Gibt er denn beim Programmieren eine Fehlermeldung aus? Wenn nicht, hat es auch geklappt und der Fehler ist entweder im Programm, in der Verschaltung (mindestens der fehlende Quarz) oder der PIC ist kaputt.
Danke für die schnelle Antwort! Ok dann ist das wohl die Lösung des Problems! Werde es am Montag direkt ausprobieren! Doch es kommt eine Fehlermeldung! Ein Ablauf des Programms kann somit noch gar nicht zustande kommen, und ein Rauschen an den Pins ist auch nicht vorhanden; werde jedoch noch 2 Kondensatoren zwischen die Versorgungsspannung schalten; nur zur Sicherheit! Der uC wird über einen DC-DC Wandler versorgt, der eine Ausgangsleistung von 3W bei 5V hat. Wenn ich mir jedoch einen PIC16F887 zulegen brauche ich den externen Takt nicht oder? Gruß andi
>> Brauch ich eventuell einen externen Clock, da ich bei den Configaration >> Bits keinen internen Clock auswählen kann. Nein. >Den brauchst du in jedem Falle. Falsch. PIC16 brauchen keinen externen oder internen Takt beim flashen. Der Takt kommt aus dem Programmer.
Hallo Holger, hättest du dann eventuell eine andere Idee, was der Fehler sein könnte?
Was sind deine Einstellungen beim Config-Word? Hast du vielleicht MCLR auf IO konfiguriert? Dann kann es Probleme dabei geben, den PIC in den Programmier-Modus zu schalten, ist mir schön öfter bei 18-Pinnern passiert. Gruß Jens
>hättest du dann eventuell eine andere Idee, was der Fehler sein könnte? Ist der PIC gebraucht? Wenn im Config Word das LVP Bit nicht auf 1 ist, dann geht nur HV Programming mit 13V auf dem Reset Pin.
MCLR mit pull-up auf 5v ist schlecht, funktioniert nur mit Diode. Ansonsten kommt die 12V dank des pull-up zur VCC und verhindert damit den ICSP entry.
Ja ich hab LVP enabled, und wenn ich den PIC beschreiben will, hab ich an dem MCLR Pin 12 V gemessen. Als Referenz benutze ich das 44 Pin Demo Board mit dem PIC16F887. Die Spannungsverläufe sind identisch wie beim PIC16F877A, wenn ich brennen will. Nur der keine aber feine unterschied ist, dass er beim *877A keine Daten schreiben kann! Also an dem Programmierkit und der Beschaltung kann es eigentlich nicht liegen! Deswegen dachte ich, dass es in die Richtung Oszillator geht. Nur habe ich jetzt oben 2 verschiedene Standpunkte gehört! Was stimmt nun?
Das bedeutet was? Wie soll der MCLR dann beschaltet werden?
>MCLR mit pull-up auf 5v ist schlecht, funktioniert nur mit Diode. >Ansonsten kommt die 12V dank des pull-up Bis jetzt hört es sich nach LVP Programming an;) Da braucht es keine 12V. Vieleicht ist ja auch nur die Codeprotection gesetzt und deshalb funktioniert das flashen angeblich nicht. Kleine Korrektur zu meiner ersten Antwort: Der PIC braucht keinen externen Takt beim flashen. Er braucht aber einen externen Takt um das Programm auszuführen.
Poste mal bitte den Schaltplan zu deiner Schaltung, oder auch ein paar Fotos.
>Ja ich hab LVP enabled, und wenn ich den PIC beschreiben will, hab ich >an dem MCLR Pin 12 V gemessen. Aha, also doch HV Programming. Zieh mal RB3/PGM mit einem 4k7 Widerstand gegen GND.
Angehängte Dateien:
-
beschaltung.gif
130 KB
Ok, dass kann ich auch mal veruchen! Was mich halt stutzig macht, dass es bei dem Demo Board einfach so funktioniert! Da ist weder eine Beschaltung am MCLR , noch der RB3 mit einem Pull down versehen. Hier ist noch die relevante Beschaltung zum flashen! Bilder kann ich leider nicht machen! Ich mache dies im Geschäft und dort ist fotografieren nicht erlaubt!
holger schrieb: >>Ja ich hab LVP enabled, und wenn ich den PIC beschreiben will, hab ich >>an dem MCLR Pin 12 V gemessen. > > Aha, also doch HV Programming. Zieh mal RB3/PGM mit einem > 4k7 Widerstand gegen GND. Ja habe ja nie gesagt dass ich LVP mache ;) Aber wenn ich doch LVP mit den Config bits ausschalte, ist RB3 I/O Pin und somit unrelevant fürs flashen. Deshalb denke ich nicht dass dies etwas ändern würde!
PGM auf GND ziehen, wurde bereits gesagt und ist sehr wichtig. Es gibt ein Bug daß HV nicht funktioniert, wenn LVP eingeschaltet ist und PIN high nicht low ist. Dann könnte es bereits funktionieren. 500 Ohm Widerstand, Microchip schreibt mindestens 1Kohm vor (ein weiterer Bug) ist aber weniger relevant. http://www.best-microcontroller-projects.com/pic-icsp.html Ich würde den 500 Ohm Widerstand durch eine Diode ersetzen.
>Aber wenn ich doch LVP mit den Config bits ausschalte, ist RB3 I/O Pin >und somit unrelevant fürs flashen. Das ist richtig. >>Ja ich hab LVP enabled, Na, was ist das denn? Enabled, deine Aussage. Dann ist RB3 durchaus weiter beteiligt.
oh sorry, ich meite disabled ;) als auf deutsch: als I/O Pin configuriert =)
Chris schrieb: > PGM auf GND ziehen, wurde bereits gesagt und ist sehr wichtig. > Es gibt ein Bug daß HV nicht funktioniert, wenn LVP eingeschaltet ist > und > PIN high nicht low ist. > Dann könnte es bereits funktionieren. > 500 Ohm Widerstand, Microchip schreibt mindestens 1Kohm vor (ein > weiterer Bug) ist aber weniger relevant. > > http://www.best-microcontroller-projects.com/pic-icsp.html > > Ich würde den 500 Ohm Widerstand durch eine Diode ersetzen. Ok, dann werde ich den pulldown einbauen. Werd dies aber erst am Dienstag tun können! Die Beschaltung mit den 500 Ohm habe ich von einem Microchip PDF. Also dies sollte sowohl mit dem Widerstand wie auch mit der Diode funktionieren. Sollte kein Unterschied machen!
Laut Anleitung von Microchip zum Thema Pic16f877a programmieren ist der RB3 Status bei HVP egal: "The Program/Verify mode is entered by holding pins RB6 and RB7 low, while raising MCLR pin from VIL to VIHH (high voltage). In this mode, the state of the RB3 pin does not effect programming." Hier steht jedoch, holding RB6 und RB7 low ... bedeutet dies etwa, dass man die beiden Pins mit einem Pull down Widerstand versehen muss??? Hab ich aber noch nie gesehen ...
>Laut Anleitung von Microchip zum Thema Pic16f877a programmieren ist der >RB3 Status bei HVP egal: Und nach meiner Erfahrung ist er nicht egal wenn das LVP Bit gesetzt ist. Ich hab da damals einige Zeit verbraten um das rauszufinden. Wenn das LVP Bit gesetzt ist muss RB3 an GND für HVP. Wenn das LVP Bit gelöscht ist, ist RB3 frei verwendbar. Das muss bei neueren PICs nicht mehr so sein und wurde wohl bereinigt. Ist ja auch nur ein Tip von mir. Kostet dich nichts. Wenn es nichts bringt lag ich falsch:)
Was mir gerade noch eingefallen ist: Als ich mir die Datenleitung beim Lesen des Datenspeicher über einen Oszi angeschaut habe, war auffällig, dass der Pegel nicht sauber zwischen 0 und +5V durchschaltet, sondern zwischen +1V und +5V. Eventuell bringt die Info noch etwas ?!?! Ein Pull down Widerstand an die Datenleitung ? Denn die MCLR Beschaltung dürfte ich denke soweit passen, da beim Lesen der Chip selbständig die +12V erzeugt die er benötigt. und wenn ich später mal das Programm laufen lasse, müssen am MCLR +5V anliegen, ansonsten REset ich ja den Controller ! Ansonsten würde mir nichts weiter einfallen, als das Problem mit der Datenleitung...
>dass der Pegel nicht sauber zwischen 0 und +5V durchschaltet, sondern >zwischen +1V und +5V. Da würden bei mir alle Alarmglocken läuten. Fehlende Masseverbindung evtl. oder falsch gemessen. Aber fassen wir mal zusammen: >Das Pickit2 erkennt das Device und kann den Program Speicher auch >auslesen. Es erkennt das Device. Konnte also die ID lesen. Dann war der PIC wohl doch schon im Programmiermodus. Das mit dem lesen ignorieren wir hier einfach mal. Da kann sonst was gelesen worden sein. >Jedoch funktioniert das Brennen nicht. Beim brennen benötigt der PIC etwas mehr Strom. Vieleicht liegt da das Problem. Der PIC hat keine vernünftige Spannungsversorgung oder ist falsch angeschlossen. Nur eine Vermutung. AVRs konnte ich auch schon mal ohne Spannungsversorgung programmieren. Da kam der Saft halt aus den Datenleitungen des Programmers. Parasitäre Versorgung. Ich klink mich dann mal aus. Zu viele unbekannte.
C1 ist ja ungewöhnlich hoch. Den 500 Ohm-Widerstand würde ich auf jeden Fall höher wählen. Ein PIC kann bei HVP-Programming immer beschrieben werden, egal wie die Config-Bits für Oszillator oder Code-/Data-Protecting gesetzt sind. PICs können auch komplett durch den Programmer versorgt werden während des Programmierens. Die Programmier-Kabel sollten nicht unsinnig lang sein, weil es schnell zu Störungen kommen kann. Ich habe i.d.R. noch nie Probleme mit LVP-Bits gehabt, weil ich sie auch nie setze. Ich sehe keine 100nF-Abblockkondensatoren am PIC. Beim Schreiben werden hohe Ströme gebraucht.
Andreas Ede schrieb: > Hier steht jedoch, holding RB6 und RB7 low ... Das bedeutet, daß der Programmer, hier PICkit, die Leitungen auf low setzt, während er 12V an MCLR legt. Zum Programmieren ist ein Takt nicht erforderlich. Solange man nur am Programmer/Debugger arbeitet, kann MCLR offen bleiben, der PICkit kümmert sich darum. Für standallone Betrieb 4,5 bis 10k von MCLR nach Vcc, das stört den PICkit nicht. Die Sache mit den Datenleitungen betrifft das Programmieren von Low Voltage Bausteinen bei sehr niedriger Spannung. Das hat nichts mit LVP zu tun. Es geht da um Bausteine, die noch bei 1,8V arbeiten, die PIC16 mit 5V gehören nicht dazu. Und das Problem haben nicht die Bausteine sondern das PICkit 3. IMHO kann der PICkit 2 das sowieso nicht. holger schrieb: > Der PIC hat keine > vernünftige Spannungsversorgung oder ist falsch angeschlossen. Das ist denkbar. Ich verwende den PICkit 3, der kann die Versorgung liefern, wenn man das auch aktiviert (vergesse ich gerne). Da gibts dann aber eine passable Fehlermeldung. MfG Klaus
Andreas Ede schrieb: > Laut Anleitung von Microchip zum Thema Pic16f877a programmieren ist der > RB3 Status bei HVP egal: > > "The Program/Verify mode is entered by holding pins > RB6 and RB7 low, while raising MCLR pin from VIL to > VIHH (high voltage). In this mode, the state of the RB3 > pin does not effect programming." JA, völlig Richtig! Bei Microchip ist -anders als bei Atmel- HVP einfach der "Normalzustand". Und es zudem so das beim HVP zugriff ALLES andere Irrelevant wird. (MCLR als IO geschaltet... LVP Aktiviert... usw. usf. Völlig Irrelevant, man KANN SICH NICHT AUSSPERREN) Das Problem mit dem RB3/PGM ist ein anderes. Wenn LVP aktiviert ist UND der RB3 nicht sicher auf GND Niveau liegt(z.B. weil der offen ist oder der Widerstand zu hhoch ist), dann KANN es während des Betriebes passieren das ein HIGH Zustand auftritt/detektiert wird. In dem Moment wo der Controller bei aktiviertem LVP dann ein HI an seinem LVP feststellt wechselt der SOFORT in den Programmiermodus. In der Folge wird der vernünftige Ablauf des Programms auf jeden Fall unterbrochen und unter ganz ungünstigen Umständen kann sogar der Inhalt des Programmspeichers beschädigt werden. Also zusammenfassend: Wenn LVP aktiviert und der RB3 nicht sicher auf GND: Beim NORMALEN Programmieren ist das völlig belanglos, ABER bei der Programmausführung kann das kritisch werden. > Hier steht jedoch, holding RB6 und RB7 low ... > bedeutet dies etwa, dass man die beiden Pins mit einem Pull down > Widerstand versehen muss??? Hab ich aber noch nie gesehen ... NEIN, Fang jetzt nicht an da wild Pull Up und Pull Downs zu setzen! RB6 und RB7 sind doch die ICSP Pins. Da ist der PICKIT (oder was auch immer) angeschlossen. Das was da beschrieben wird ist der Beginn der Programmierungssequenz und das wird vom Programmer völlig automatisch gemacht. Das einzigste worauf du achten musst ist das an den beiden PINs keine Hardware hängt die die Programmiersignale verfälschen kann (z.B. Kondensatoren usw.) Wenn es sich nicht vermeiden Lässt diese IO mit solchen evtl. störenden Komponennten zu beschalten dann sollte eine Möglichkeit der Unterbrechung vorgesehen werden (Jumper) Ach ja: Auch wenn man HVP nutzt ist eine Diode zwischen !MCLR und VDD NICHT IMMER zwingend notwendig. Schaden tut sich aber in FAST keinem Fall (Bei Betrieb der PICs für Spannungen <3V an deren untersten Spannungsgrenze kann sie u.U. stören.) Ob man die Braucht oder nicht kommt auf die Beschaltung von VDD auf dem kompletten Board, auf die Größe des Pull-Up Widerstandes und auf die Art der Spannugnsstabilisierung an. Aber auch hier gilt: Wenn man sich nicht sicher ist -> Immer die Diode setzen. (Man muss sicher beurteilen können ob das zuviel der Spannung problemlos an dem PullUp Widerstand durch die Beschaltung von Vdd oder den Spannungsregler abfällt oder ob es zu Problemen oder gar Schäden kommen kann. Gruß Carsten
nimm einen anständigen programmer z.b. den von sprut.de und es geht auch dann wenn lvp verfused ist nein meine shift taste klemmt nicht und ich habe auch eine kommataste aber das tippen geht schneller ohne shifft
sprutfan schrieb: > nimm einen anständigen programmer z.b. den von sprut.de und es geht auch > dann wenn lvp verfused ist ? ? ? Was willst du damit ausdrücken? 1. - Einen PIC kann man NICHT verfusen. 2. - Ein gesetztes LVP Bit hat bei der normalen Programmierung (HVP) überhaupt keine Relevanz 3. - Ein Originalprogrammer ist (zumindest bei PIC und AVR) IMMER irgendwelchen Selbstbaugeräten vorzuziehen. Wenn man die Wahl hat, dann sind Originalgeräte die erste Wahl, danach kommen dann die 100% identischen Clones von Originalgeräten, danach Fremdgeräte mit anderem Aufbau/anderer Firmware, die aber softwaremäßig kompatibel sind und direkt aus der Programmierumgebung heraus funktionieren. ERST DANN -als ALLERLETZE OPTION- sollte man überhaupt noch über solche Selbstbaubrenner nachdenken die eine eigene Software benötigen. Die Zeit dieser Geräte ist einfach vorbei. Die haben mal viel Sinn gemacht als Originale Geräte noch viele hundert DM gekostet haben und auch nicht viel mehr konnten las nur den Baustein beschreiben (Debugger/Emulatoren lagen dann gleich bei einigen tausend DM). Heute wo ein Programmiergerät das dazu auch noch Debugfähig ist aber nur noch um die 30 Euro kostet macht das alles kein Sinn mehr. Alleine schon der Aufwand immer zwischen zwei Programmen hin und her schalten zu müssen währe mir das nicht wert. Wenn man dann noch die Beschaffung der Bauteile und den Aufbau verbunden mit evtl. auftretenden Problemen dabei berücksichtigt... Gruß Carsten
Nein, es ist ein Bug vom Chip, http://www.piclist.com/techref/microchip/16F877/hvprog.htm müsste zwar die genauen Bugmeldungen haben, es ist mir aber nicht Wert danach zu suchen. Weiters hat PicKit2 und viele Clones ein Problem mit der Spannungserzeugung, und hat ziemliche Probleme, wenn nicht 5V am USB vorhanden sind usw, bzw nicht die Configurierte Voltanzahl oder die Volts eine sichere Programmierung einfch nicht zulassen.
Nachtrag, durch diese Probleme sind auch Kondensatoren am MCLR Pin problematisch, deshalb auch mein ernst gemeinter Rat, eine Diode einzubauen. Hat auch Implikationen mit dem Program Counter und ist dieser verstellt, kann man den Chip nicht richtig programmieren, da im falschen Modus.
Warum hängt pin2 vom pickit an mclr, sollte doch Vdd sein!
Chris schrieb: > Nein, es ist ein Bug vom Chip, > http://www.piclist.com/techref/microchip/16F877/hvprog.htm > müsste zwar die genauen Bugmeldungen haben, es ist mir aber nicht Wert > danach zu suchen. Ok, erst wollte ich noch schreiben das dies nicht stimmt - und habe das auch noch extra gerade ausprobiert (Mit dem Ergebniss das alles Ordnungsgemäß ist!) Habe dann glücklicherweise doch die Seite erst mal genau gelesen. Ja- das kannte ich noch gar nicht - auch wenn ich viel mit diesem µC zu tun hatte. Liegt wohl einfach an der Zeit, von dem BuG scheinen die frühen A Revisionen betroffen die zu der Zeit wo ich mit dem 877 die ersten größeren Sachen begonnen habe schon wohl lange nicht mehr in den für kommerzielle Produkte relevanten "Distri-Umlauf" waren. (Aber natürlich bis heute immer noch mal auftauchen können weil sie in irgendwelchen Schubläden kleiner Elektronikbasterläden oder als irgendwann nicht mehr verbrauchter und eingelagerter Materialbestand von produzierenden Firmen heute dann doch wieder auf dem "freien" Markt gelangen und so selbst bei größeren Elektronikversendern wieder ins Sortiment rutschen - NAtürlich nur bei solchen Händlern die frei einkaufen wo es gerade am billigsten ist und nicht bei echten Distributoren.) Ich habe ja hier auch noch bestimmt über 30 neue 87x in diversen Bauformen liegen - Obwohl ich schon ende 2007 sowohl Privat wie auch bei der Verwendung in Auftragsentwicklungen auf die 16F88x umgestiegen bin. Also um da auf einen Nenner zu kommen: Es SOLLTE so sein (und ist es auch bei der Absoluten MEhrheit der PICs) das "HVP" völlig unabhängig vom Setting des LVP Bits und der Beschaltung des RB3 ist. Bei einigen frühen Versionen der 16F87x Familie aber ist es aufgrund eines BuGs leider möglich das es doch Probleme gibt. Gruß Carsten
Ich weiss, daß der Bug in Rev A HW releasse 04 noch nicht behoben war.
Ich habe hier mehrere PIC16F87x herumliegen (leider keinen A) und einen brenner8 von sprut.de: bei einigen geht PICKIT3 tatsächlich nicht, der sprut-Brenner aber schon. Die PIC16F87x haben auf der Homepage von Microchip seit längerem keine Errata mehr, offensichtlich werden die nicht mehr gepflegt. Ich empfehle daher auf PIC16F88x oder PIC16F18xx umsteigen.
Also ich hatte bisher mit dem PICKIT 3 keine Probleme mit dem Schreiben. Pullup von MCLR zu 5V und Quarz + 2 Kondensatoren (die bei deinem Schaltplan noch fehlen) bzw auch das meist nicht, da die PICs, die ich nehme auch interne Oscillatoren haben. holger schrieb: > Falsch. PIC16 brauchen keinen externen oder internen Takt beim flashen. > Der Takt kommt aus dem Programmer. Wie du später ja noch schriebst, meinte ich dann das laufen lassen des Programms. Zum Programmieren kommt der Takt ja vom Programmiergerät. Mit dem Rauschen meine ich nicht die Versorgungsleitung sondern die offenen PINs für den Quarz bzw. anderer Taktgeber. Andreas Ede schrieb: > Doch es kommt eine Fehlermeldung! Welche kommt denn? ;) Wie jemand hier schon gesagt hat: Der "Standard" der ICSP-Stecker der Microchip-Programmierer sind: 1-Vpp, 2-Vdd, 3-GND, 4-Data, 5-Clock. In deinem Schaltplan geht Pin 2 aber an MCLR und Pin 1 auf Vdd. Wenn dieses so ist, hast du ggf durch die "Hoch"spannung den PIC geschrottet. Wie sieht denn das Programm inkl der Config aus? usuru schrieb: > Die PIC16F87x haben auf der Homepage von Microchip seit längerem keine > Errata mehr, offensichtlich werden die nicht mehr gepflegt. Ich empfehle > daher auf PIC16F88x oder PIC16F18xx umsteigen. Abgesehen davon, dass es ansich klappen sollte, empfehle ich auch immer neue PICs zu nehmen. Die sind nicht nur schneller, sondern haben mehr RAM/ROM und Peripherie für meist weniger Geld. Ich hab das hier auch mal erwähnt: http://www.mikrocontroller.net/articles/PIC#Alte_und_neue_PICs Ich find, man sollte dort schon ein wenig up-to-date bleiben und solche alten µCs nur nutzen, wenn man muss oder schon Schaltplan und Programm vorhanden sind. Wo man aber auch wieder beim Sprutbrenner wären, der die ganz neuen PICs deutlich später unterstützt als das PICKIT3 (und man braucht keinen nervigen extra 3V3-Adapter-.- ).
> Pullup von MCLR zu 5V und Quarz + 2 Kondensatoren (die bei deinem > Schaltplan noch fehlen) bzw auch das meist nicht, da die PICs, die ich > nehme auch interne Oscillatoren haben. Sowohl der Pullup als auch irgendwelche Quarze oder Kondensatoren (ausser den üblichen 100nf zwischen VDD undf VSS) sind beim Flashen der PICs völlig überflüssig, auch bei den PICs, die keine internen Oszillator haben. MCLR wird direkt mit VPP verbunden und MUSS beim Flashen des PIC mit einem Schalter oder einer schenllen Diode vom Rest der Schaltung getrennt werden. Manchmal ist es auch ganz hilfreich, das Clock-Kabel abzuschirmen!
usuru schrieb: > Sowohl der Pullup als auch irgendwelche Quarze oder Kondensatoren > (ausser den üblichen 100nf zwischen VDD undf VSS) sind beim Flashen der > PICs völlig überflüssig, auch bei den PICs, die keine internen > Oszillator haben. So wie ich es ja auch geschrieben habe. Nur was nützt einen eine Schaltung, wo man den PIC zwar programmieren kann, aber ihn danach wegen mangelnden Quarz und Pullup nicht laufen lassen kann? Das ist die Minimale Beschaltung, damit der PIC zuverlässig läuft.
Das Problem hat sich endlich gelöst: Weder waren nicht belegte Pins verantwortlich, noch eine unzureichende Stromversorgung, noch der Programmer! Was auch ein Märchen ist, dass man die Kabel beim Programmieren so kurz wie möglich halten sollte (<5cm). Zudem können alle Pins, außer RB6 und RB7 einen beliebigen Status haben. MCLR muss rein zum programmieren auch nur direkt an das Pickit angeschlossen werden. Meine Kabellänge von uC zum Pickit 2 beträgt ca. 25cm und es funktioniert einwandfrei. Einzigstes Problem war der nicht vorhandene Takt. Nachdem ich spaßeshalber ein RC Oszillator angeschlossen habe, lief das Brennen einwandfrei! Danke "rbs_phoenix" für den Hinweis ;)
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.