Hallo, ich habe einen PIC-Brenner für den USB-Port gebaut, nach einer Vorlage von www.sprut.de Das Problem ist, dass der Brenner mit einem Steuer-PIC arbeitet, der vorher erstmal programmiert werden muss. Kennt jemand eine möglichst einfache Schaltung, mit der man den PIC programmieren kann (über RS232 oder notfalls über einen Parallel-Port)? Sollte wie gesagt möglichst simpel ein, da ich die Schaltung nur ein einziges mal benutzen muss. Der PIC ist ein PIC18F2550 SP. Für Vorschläge wäre ich sehr dankbar! Gruß, Oli
Komische Frage. Die findest du natürlich auch auf Sprut.
du hast wahrscheinlich das gleiche problem wie ich damals ich hatte sogar den brenner5 auf steckbrett nachgebaut und hat nicht geklappt hatte dann das grosse glück das mir einer meiner lehrer den pic gebrannt hat da in meinem bekanntenkeis KEINER aber wirklich KEINER sich mit pic oder gar elektronik beschäftigt. ich kann dir nur anbiehten das ding mit rückumschlag an mich zu schicken und ich brenne ihn dir. --- ja für lau... ...so ein netter kerl bin ich
Ich biete es dir auch an den zu brennen, dann hast du noch einen in Reserve. Wie du siehst lohnen sich PIC's eigentlich nicht. Ein AVR funktioniert sogar mit einer Stromversorgung über einen 47k Vorwiderstand. Zwar nicht richtig aber immerhin.
Hey ein PIC funktioniert sogar über einen 4,7Meg Ohm Vorwiderstand in der Stromversorgung. Zwar nicht richtig aber immerhin.
Danke für die schnellen Antworten. Ich habe gehofft, es gäbe da noch so eine einfache Möglichkeit, so wie den Brenner0 von sprut.de Habe nach einigem herumrennen doch noch jemanden gefunden, der einen PIC-Brenner hat und habe ihn programmieren lassen. Trotzdem danke!
Oli: in der tat stehe ich zZ vor dem gleichen problem, die lösung ist ein recht simpler und erstaunlich vielseitiger JDM2 Brenner... den ich mir die tage bauen will um mir dann ein icd2 zu basteln guckst du hier: http://www.instructables.com/id/EGE5OCBXEQEP286GSC/ und ja. ich finde das auch verdammt doof das man bei microchip so massive steine in den weg gelget bekommt wenn man mal mit dem thema anfangen möchte. grüsse...
ich habe mal so einen pic-brenner gesehen, der mit nur wenigen widerständen gebaut wurde... nur wo, das weiss ich leider nicht mehr, falls du aus der CH bist, kann ich ihn dir auch brennen (mit sofern du die portokosten übernimmst)
ob man damit auch PIC18Fxxx brennen kann, weiss ich nicht: http://www.the-starbearer.de/Praxis/Microkontrollerpraxis/PIC/Pic_minimal.htm
@ Master Snowman: Den Plan hatte ich schonmal irgendwo gesehen, aber damit kann man glaube ich nur 16XXX brennen, habe ich irgendwo gelesen. @ André: Ja, an sowas in der Art hatte ich gedacht. Hab allerdings schon jemand gefunden, der mir den PIC gebrannt hat. Wenn der Bootloader erstmal in den PIC gebrannt ist, dann ist der Brenner echt super. Man kann dann sogar ohne einen weiteren Brenner Firmware-Updates in den Steuer-PIC laden.
Ist mir im Moment garnicht so bewusst gewesen, dass der Brenner 5 nicht den PIC 18F2550 brennen können soll. Gerade noch mal bei sprut nachgeschaut: Mit einigen Änderungen (Vpp muß 12V statt 13V betragen) soll der Brenner 5 wohl den 2550 brennen. Ich hatte mir auch schon überlegt mal den Brenner 8 zu bauen. Na mal sehen, bis jetzt komme ich mit dem 5er ja noch hin. Sven
Wieso besorgst Du Dir nicht einfach einen ICD2 (siehe ebay), Microchip´s kostenloses MPLAB IDE und baust in Deine Schaltung eine RJ-12-Buchse ein? Mit dieser Lösung kannst Du Deine Software prima debuggen und jederzeit ändern, ohne den Controller jemals wieder herausfummeln zu müssen. Mit dem ICD2 hast Du übrigens Zugriff auf überaus viele Controller-Typen (was manchen Atmel-Freak die Tränen in die Augen schießen läßt), die zudem gut zu bekommen sind (auch in dieser Hinsicht sind Atmel-Anhänger nicht gerade verwöhnt).
So genial ist der ICD2 nun auch nicht. Beispielsweise frage ich mich, weshalb das Teil, als Programmer genutzt, drauf besteht, die PGC/PGD-Leitungen aktiv auf Masse zu ziehen. Auch wenn's grad überhaupt nichts zu programmieren gibt. Logischerweise blockiert das permanent diese beiden Pins. Nötig wäre das nicht, der könnte sie genausogut freigeben. Wenn ein anderer Programmer sich diesbezüglich besser verhält, so hätte das durchaus seinen Charme.
> So genial ist der ICD2 nun auch nicht. Beispielsweise frage ich mich, > weshalb das Teil, als Programmer genutzt, drauf besteht, die > PGC/PGD-Leitungen aktiv auf Masse zu ziehen. Auch wenn's grad überhaupt > nichts zu programmieren gibt. Logischerweise blockiert das permanent > diese beiden Pins. Nötig wäre das nicht, der könnte sie genausogut > freigeben. So wirklich verstehe ich Dein Problem nicht. Im Programm-Modus steht der Controller nach dem Programmieren im Reset. Erst mit ziehen des RJ-12-Steckers läuft er los. Damit sind auch die Portleitungen an PGC und PGD wieder voll nutzbar. Im Debug-Modus werden diese Leitungen zur Controller-Steuerung benutzt und sind für das eigene Programm nicht zu verwenden. Oder wie sollte sonst der PC/ICD2 im Betrieb mit dem Controller sprechen? - Also gibt es auch hier kein Problem. Eine Lösung könnten bestenfalls zusätzliche ICD2-Leitungen sein. Dafür gibt es aber (fast immer) größere Controller.
Andreas Kaiser wrote: > So genial ist der ICD2 nun auch nicht. Beispielsweise frage ich mich, > weshalb das Teil, als Programmer genutzt, drauf besteht, die > PGC/PGD-Leitungen aktiv auf Masse zu ziehen. Auch wenn's grad überhaupt > nichts zu programmieren gibt. Logischerweise blockiert das permanent > diese beiden Pins. Nötig wäre das nicht, der könnte sie genausogut > freigeben. > > Wenn ein anderer Programmer sich diesbezüglich besser verhält, so hätte > das durchaus seinen Charme. Naja, so tragisch ist das ja wohl nicht, oder. So ein RJ12 Stecker ist schnell ausgesteckt, wenn die beiden Leitungen wirklich benützt werden. Und nach dem Programmieren wird der Programmer ja nicht mehr an der Schaltung benützt, ausser man will immer wieder eine neue Version runterladen, aber dann ist es sinnvoller, den ICD2 als Debugger zu verwenden. Ohnehin ist es sinnvoll, die beiden Pins nach Möglichkeit nicht zu verwenden, so dass sie für Debug-Zwecke frei bleiben. Das Teil ist also wirklich genial. Vor allem können damit auch alle Fuses zurückgesetzt werden, was z.B. in der AVR-Welt teilweise nur mit bestimmten Programmern gehen soll.
Gast wrote: > Im Programm-Modus steht der Controller nach dem Programmieren im Reset. > Erst mit ziehen des RJ-12-Steckers läuft er los. Damit sind auch die > Portleitungen an PGC und PGD wieder voll nutzbar. Jo. So ist das offenbar gedacht, ist mir auch klar. Und für jene AltPICler, die gewohnt waren, statt des ISPs immer den ganzen Prozessor zu stöpseln, ist das sicher ein gewaltiger Fortschritt. Nur bin ich da etwas AVR-verwöhnt und will nicht dauernd Stecker raus und reinstöpseln. Schon garnicht, wenn's eigentlich nicht nötig ist. Aus dem Reset immerhin entlässt ihn der ICD2 auch selber, und für PGC/PCD hat der ICD2 als Treiber '125 Gates drin, deren Enable er genausogut freigeben könnte. Ich bin aber auch nicht der erste, der deshalb einen ICD2-Klon um eine eigene ISP-Steckerkonvention mit Muxer bereichert hat, der die PGM-Pins des Controllers zwischen Programmer und Anwendung umschaltet. Bin ich mittlerweise anderswo (Mikroelektronika) auch schon begegnet. > Im Debug-Modus werden diese Leitungen zur Controller-Steuerung benutzt > und sind für das eigene Programm nicht zu verwenden. Klar, da geht's nicht anders. Aber ich schrieb ja ausdrücklich vom Programmer Mode. > Eine Lösung könnten bestenfalls zusätzliche ICD2-Leitungen sein. Dafür > gibt es aber (fast immer) größere Controller. Will aber keine grösseren im Endprodukt ;-). Für's Debugging habe ich mit dieser Strategie aber kein Problem.
Severino R. wrote: > runterladen, aber dann ist es sinnvoller, den ICD2 als Debugger zu > verwenden. Wieso? Den Debugger brauche ich meist grad so lang, bis Konsol-Textausgabe funktioniert. Sinnvoller scheint mir eher ein Bootloader. > Ohnehin ist es sinnvoll, die beiden Pins nach Möglichkeit nicht zu > verwenden, so dass sie für Debug-Zwecke frei bleiben. Jo. Mach das mal beim dsPIC30F4012. Da liegt CAN drauf. Und SPI. Und I2C.
> Ich bin aber auch nicht der erste, der deshalb einen ICD2-Klon um eine > eigene ISP-Steckerkonvention mit Muxer bereichert hat, der die PGM-Pins > des Controllers zwischen Programmer und Anwendung umschaltet. Bin ich > mittlerweise anderswo (Mikroelektronika) auch schon begegnet. Der Vorteil der Steckerlösung ist, dass an meiner Zeilhardware nichts hängt, was Probleme bereiten könnte (Störeinkopplungen, Potentialverschleppungen ...). Die Schalter-Lösung erzeugt bei mir ein sehr ungutes Gefühl. Auch erleichtert es bei gleichzeitigem Einsatz mehrere PICs an mehreren ISPs den Überblick.
Gast wrote: > Der Vorteil der Steckerlösung ist, dass an meiner Zeilhardware nichts > hängt, was Probleme bereiten könnte (Störeinkopplungen, > Potentialverschleppungen ...). Die Schalter-Lösung erzeugt bei mir ein > sehr ungutes Gefühl. Ist ja auch keine Dauerlösung, ohne Programmer im ISP-Anschluss wird das durch Jumper im ISP-Stecker erledigt (ebenso bei MikroE), wodurch sich diese Probleme bei vernünftiger Plazierung des Steckers in Grenzen halten. Ist übrigens eine Original-Microchip-Lösung ;-). Naja fast. Deren PIC30 Demoboard macht das ähnlich - nur ist's da der Philosophie "Handbetrieb ist besser" folgend ein manueller Umschalter.
>> Ohnehin ist es sinnvoll, die beiden Pins nach Möglichkeit nicht zu >> verwenden, so dass sie für Debug-Zwecke frei bleiben. > > Jo. Mach das mal beim dsPIC30F4012. Da liegt CAN drauf. Und SPI. Und > I2C. Du kannst bei die beiden ICD-Leitungen an vier (4) verschiedenen Pin-Paaren alternativ konfigurieren, so dass sie wohl doch nicht dort liegen, wo Du die eingentlichen Pin-Funktionen brauchst.
Severino R. wrote: > Du kannst bei die beiden ICD-Leitungen an vier (4) verschiedenen > Pin-Paaren alternativ konfigurieren, so dass sie wohl doch nicht dort > liegen, wo Du die eingentlichen Pin-Funktionen brauchst. Im Debug-Modus ja, im Programmier-Modus m.W. nicht. Bei den PIC24/33 scheint sich das netterweise geändert zu haben, nur gibt's da dummerweise keinen 28pin-Zwerg mit CAN. Kriege ich den Controller denn so dessiert, dass er völlig ohne Zugriff auf die Programmier-Pins nur über die Debug-Pins ansprechbar ist? Ich hatte das auch mal versucht, war aber gescheitert.
Hallo, habe das selbe Problem. Kann nicht mal mit meinem PICSTART Plus diesen 18F2550 brennen. Wollte mir dann auch den Brenner8 nachbauen mit dem selben Ergebnis das ich wieder den Programmierten Pic18F2550 brauche. Also gehts nur mit Brenner5 von sprut der dann erst noch modifiziert werden muß. Kann mir da jemand aushelfen und mir den Pic brennen?
> Kann nicht mal mit meinem PICSTART Plus diesen 18F2550 brennen.
Der PICSTART Plus kann den 18F2550 prommen, allerdings nur, wenn du das
"PUM" Flash Upgrade eingebaut hast oder einen PICSTART Plus hast, der
das bereits werksseitig hat.
Mein PICSTART Plus ist R4, also eine ganz alte Revision...
Ich habe selbst auch einen "Brenner8P" gebaut und den 18F2550 damit
geprommt.
Hi, ich hab mir auch den Brenner 8P von sprut nachgebaut und habe nun das selbe Problem wie der Threat eröffner und zwar das, dass ich den Steuer-PIC für den Brenner erst einmal brennen muss :(. Jetzt wollte ich fragen, ob einer von euch vielleicht so net wäre und mir einen PIC18F2550 SP flashen könnte????
Kein Problem, kostet Dich halt 2 mal Versand (Hin- und Rückweg). Bitte Kontakt per PN, dazu muss man sich aber anmelden.
Hallo liebe mikrocontroller.net-Community, ich habe das gleiche Problem wir der Thread-Starter und würde mich sehr freuen, wenn sich jemand dazu bereit erklären würde, meinen PIC18F2550 zu brennen. Vielen Dank im Voraus, sorry für das pushen des Beitrags und liebe Grüße, Benjamin
Kannst mir deinen Pic schicken, dann mach ich das. Wenn du es eilig hast, hab ich auch noch einen 2550 hier, den ich dir parallel schicken kann. (Also so dass ich nachher deinen behalte und du bekommst meinen, mit deiner Datei programmiert^^) Dazu musst du dich nur anmelden, dann können wir das per PN klären.
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.