Hi allerseits Ich weis ja das man hier hauptsächlich mit AVRs arbeitet aber weis vieleicht jemand von euch einen Link für Pic Programmer und development boards?? Ach ja, da ich nur ein Schüler bin und noch kein eigenes Einkommen habe würde mir eine Anleitung für einen Programmer zum selber bauen sehr helfen Ich dachte mal das ich die PICs 16F84 16F877 18LF1220 16F77 12F675 programmieren will können. Es können auch verscheidene Programmer sein (einen Universlaprog ist entweder zu teuer fü mich oder zu kompliziert zum Aufbauen Danke Markus ;)
Schau mal nach sprut.de Da findest du alles über PIC-Controller. Ich war jetzt mal auf einer bulgarischen Seite oder so, die bieten ein Board für den PIC 16F84 an. Das hat so alles, was man will, kosten aber auch 60-70 Dollar. Aber bei dem starken Euro... Vielleicht baust du dir das aber besser selber. Musst dir natürlich im klaren sein, was das Board alles können soll. vielleicht machst du mal eine liste mit funktionen, dann kann man sehen, was man machen kann.
Gerade als Schüler würde ich ja Mikrokontroller vorziehen, die erst gar keinen Programmer benötigen (spart ne Menge Mäuse). Da kenne ich 8051-er (z.B. T89C51RB2, AT89S8252) und AVR. Ich wollte auch mal was mit einem PICs machen (SX18), aber die wollten doch glatt 800,-DM für einen simplen Programmierstecker. Später hab ich dann gemerkt, daß sie mir damit einen großen Gefallen getan haben, d.h. ich bin gar nicht erst in die Versuchung geraten, mich mit einem PIC rumquälen zu müssen. Die 75MIPS braucht man ja eh fast nie, bzw. dafür gibt ja die viel besseren 8051-er von Cygnal. Peter
@ Peter: warum sagen denn immer alle, wie schlecht die PICs sind. Alle machen AVR und 8051. nur hat irgendwie keiner Argumente, was z.B. am AVR so viel besser sein sollte. Ich selbst bin durchaus bereit, noch umzusteigen. Wenn ich nur wüsste warum...
Einen 8051 Programmiergerät und einen ISP programmer für AVRs mit development board habe ich schon nur hätte ich halt gerne um allse komplett zu machen eine selbstbaumöglichkeit für einen Programmer für PICs kennt jemand von euch Parsic??? Das ist ein super Grafikcompiler den ich gerne verwende JAJA ich weis assembler is besser, schneller und kürzer Ich kann ja auch assembler aber es ist doch um einiges komfortabler damit zu arbeiten (ausser bei bitmanipulation) Der funktioniert aber leider nur mit PICs
Der SX18 ist kein echter PIC. Der ist zwar voll Sourcekompatibel, gleicher Befehlssatz usw. und sogar deutlich schneller. Dafür ist er auch teurer und die ganze Entwicklungsumgebung ebenso (da haben sich ein paar ehemalige Microchip-Entwickler selbständig gemacht und diese SX-Serie herausgebracht. Mittelerweile dürfen sie aber nicht mehr mit PIC-kompatibilität werben, obwohl es so ist). Mir persönlich sind die PICs in vielen Anwendungen lieber als die AVRs. Hängt halt immer von der Anwendung ab!
Also ich bin mit allen drein aufgewachsen und ich sage euch das ich die 8051 absolut nicht mag (Bei meiner Diplomarbeit wollte der Hund absolut nicht schwingen egal was ich auch versuchte) AVRs sind zwar super Geräte habe aber leider noch keinen C-Compiler (Grafik so wie easycpp/easycase) gefunden der mir gefällt und für die PICs habe ich Parsic aber wieder keinen guten programmer, development board
Hi allerseits würde mich auch interesieren wo man so was herbekommt Parsic kenn ich auch (hatten wir in der Schule) lg tom
@Wolfram, ich kann jetzt nicht sagen, ob es auch besser geht, aber wenn ich so die typischen PIC-Programme sehe, kriege ich das kalten Grausen vor lauter GOTOs. Es scheint, daß man mit einem verdammt kleinen Stack eben nicht strukturiert programmieren kann. Und dieses ständige darauf achten müssen, in welcher RAM-Bank und in welcher Code-Page man gerade ist. Der PIC ist die erste Maschine, die ich kenne, wo der Code nicht verschiebbar ist. Gerade für Anfänger ist ein linearer Adreßraum für Daten bzw. Kode extrem fehlervermeidend. Und dann schätze ich es sehr, wenn ich für jeden Interrupt auch eigene Flags zum Pollen, bzw. eigene Vektoren habe. Ich mag die 8051 lieber als die AVR, da ich bis zu 4 verschiedene Interruptprioritäten habe und die Interruptbits ganz normale Bits sind, d.h. ich kann sie löschen und setzen ganz nach Belieben. Ansonsten sind die AVRs auch nicht schlecht. Ein bischen mehr Flash sollten die kleinen haben (4kB der Tiny13, 8kB der Tiny2313), da ich da regelmäßig am Anschlag bin. Peter
Angehängte Dateien:
-
Parsic.JPG
190 KB
Hier könnt ihr mal sehen wie einfach es sein kann einen Pic zu programmieren Schaut euch das foto an!! lg markus
@Markus, Parsic kenne ich nicht. Ich kann mir auch unter einem Grafikcompiler absolut nichts vorstellen. Ist das vielleicht so ähnlich, wie die Schaltplaneingabe bei CPLDs ? Schaltplaneingabe bei CPLDs ist ja nur was für ganz kleine Projekte, sonst wird es sehr schnell aufwendig und unübersichtlich. Nur in Hochsprachen kann man größere CPLDs effizient programmieren. Den 8051 programmiere ich ausschließlich in C, den AVR programmiere ich in Assembler. Irgendwie bin ich zu doof, mit dem GCC richtig klarzukommen. Der Keil C51 arbeitet auch prima mit Assembler zusammen, d.h. ich kann für meine Assemblerroutinen bequem Ressourcen (RAM, Registerbänke) belegen und der Linker spielt voll mit. Dem AVR-GCC sind belegte Register aber vollkommen wurst, den interessiert absolut nicht, was ich in den Assemblerroutinen verwende er wills auch haben und dann krachts gewaltig. Peter
in parsic machst du das Programm indem du und gatter, oder, RS flip flops so zusammenschaltest das was sinnvolles rauskommt Est stimmt das man aufwendige Projekte damit vergessen kann, da nehm ich auch liber nen avr oder gleich nen 8051 aber wie gesagt für kleine Projekte gibt es für mich nichts komfortableres als parsic mir fehlt nur der programmer um die chips auch bespielen zu können HELP lg markus
@Markus, kannst Du auch bitte erläutern, was dieses Programm macht ? Es sieht so aus, als ob man mit vordefinierten Funktionsblöcken arbeiten muß, die sich schon mal jemand ausgedacht hat. Leider muß ich aber immer etwas völlig neues programmieren, Z.B. ein ganz bestimmen ADC anschließen (gibts ja über tausend verschiedene) und dessen Datenleitungen mit einem DAC und einem LCD zusammen verwenden, dann noch zwei SJA1000 CAN-Controller usw. Peter
Parsic basiert darauf mit vordefinierten Logikblöcken zu arbeiten: und, oder, negation, exklusives oder, zähler, timer, multiplexer,.... alles was es hardwaremäßig gibt Etwas was mir besonders gefällt ist die Ansteuerung des LCD sie funkt über 4 Dat leitungen und ist uuuur easy zu programmieren (klick auf symbol, kursor dorthinstellen wo man ihn haben will, variable) und er schreibt sie schon raus lg markus
weis denn niemand einen halbwegs guten Pic Programmer?? Er muss ja nicht alle Chips können Es können ruig auch verschiedene programmer sein Danke Markus
Hi, Quellen für günstige PIC-Entwicklung/Programmer: http://www.olimex.com/dev/ http://www.dontronics.com/index.html Hab ich beide ausprobiert, Olimex ist unschlagbar günstig, die Schaltpläne haben sie auch im Netz, aber da lohnt der Nachbau kaum. Was ich mit den AVR-Platinchen angestellt hab, findet sich hier: www.ioproz.de mfg Frank Simon
@Markus >>weis denn niemand einen halbwegs guten Pic Programmer?? http://www.ic-prog.com/ Funktioniert gut und schnell - ein Nachteil 5+(aus der RS) vom PC ist am Programmer GND - Es geht zwar nicht kaputt, wenn man das mal vergißt, aber schön ist es nicht. "Parsic" - Das kann man wirklich nicht mehr programmieren nennen. Und eigentlich zeigt es doch nur das man versucht für die PICs eine Designumgebung zu schaffen mit der man eine strukturierte Lösung erhält. Ich möchte wirklich mal sehen wie eine der viele State maschines aussehen würde die ich immer auf den PIC verwendet hatte.... @Peter >>Irgendwie bin ich zu doof, mit dem GCC richtig klarzukommen. Vieleicht liegt es ja auch am gcc, möglicherweise sind es drei Flags zuviel. Es hatte mich schon genervt für jeden Kram in AVR-Freaks nachzufragen und tagelang auf eine Antwort zu warten. Schön das das Teil Freeware ist, aber trotzdem ziehe ich die professionelle Variante vor - auch wenn avricc eine Windowsapplication ist. Aber sehr gelungen, da nicht überladen. @HDW >>warum sagen denn immer alle, wie schlecht die PICs sind Sie sind ja auch gar nicht schlecht, sie sind nur nicht mehr state of the art. Der begrenzte Stack, kein POP/PUSH, das dähmliche RAM Banking und nicht zu vergessen das Banking schon bei der Initialisierung der Register ist wirklich nicht sehr angenehm. Dann noch die Augenwischerrei mit dem XTAL - leider steht ja nur 1/4 für den User zur Verfügung. Letztes Jahr (auch wenn ich mich hier wiederhole ) hab ich den PICs lebewohl gesagt, leider habe ich ziehmlich viele eindesigned und muß diese pflegen und das ist bei dem Code . Mir graust schon vor einer größeren Änderung....Ich glaub dann schmeiß ich die lieber Stück für Stück raus. Devboards habe ich mir selber für die Pic's welche gemacht - wenn Interesse besteht stelle ich die Eagle-daten zur verfügung. Ich fange damit bestimmt nix mehr an. MooseChecker
ein einfach aufzubauender programmer der mit http://www.ic-prog.com/ oder ntpicprog den 16F84(A) brennt: http://www.the-starbearer.de/Praxis/Microkontrollerpraxis/PIC/Pic_minimal.htm Gruss
auf sprut.de findest du einige verschiedene Brenner mit bauanleitungen. Sprut stellt direkt eine sehr tolle Software für seine Brenner zu Verfügung. Die können dann so gut wie alle PIC brennen. PICs kann man fast alle mit dem selben Programmer brennen. Z.b der brenner5 von sprut hat vier verschiedene Fassungen vorgesehen, so dass sehr viele PICs zu brennabr sind.
Für einen Anfänger mit lohnt sich der Nachbau des ICD Modules von Microchip. Der Nachteil liegt darin, dass es nur unter MPLAB 5.x läuft und nur die 16F87x-Serie unterstützt wird. Als Low-Cost Debugger ist das Teil aber recht gut zu gebrauchen. Die Schaltung ist in der Dokumentation von Microchip www.microchip.de mit enthalten. Im Netz habe ich auch schon ein paar abgewandelte Nachbauanleitungen gesehen. Einfach mal die Suchmaschine anschmeißen. MfG Steffen
Hallo Herr Hildebrand, es sagen ja nicht ALLE der PIC sei schlecht! Einer tut das allerdings besonders und ich muß sagen, daß er nicht in der Lage war seine Behauptungen zu belegen! Was interressiert es den Schachspieler wenn sich ein Damespieler über die komplizierten Regeln beschwert? Natürlich ist der PIC nicht besonders benutzerfreundlich aber er bietet dafür den Vorteil ganz besonders robust zu sein. Dies gilt gerade für den Einsatz in induktiven Störfeldern. Sebst Spannungsrückstöße an den Portpins ( welche während der Projekt Entwicklung auftreten können) bringen ihn nicht gleich außer Tritt oder gar um. Die Portierbarkeit von Programmen (für diese Ebene) soll so wichtig sein? In meinem Umfeld wird kein Programm exact 2 mal verwendet. Neuschreiben (mit der alten Version im Hinterkopf und auf der Platte) ist einfacher, sicherer und damit auch vernünftig! Es geht doch nicht um riesige Programme sondern allenfalls um KB. Die "hingeworfenen" Programmschnipsel einiger PIC Gegner sind kein Kriterium, sondern nur das GANZE! Und wenn Sie sich mit solchen Zeitgenossen Abseits des Forums weiter unterhalten ( Zitat " Die Spannungsaufbereitung des ADW ist umständlich", daß es sich um einen Differenzeingang handelte wurde nicht einmal erkannt )merken Sie schnell was Ignoranz bedeuten kann. Lassen Sie sich nur durch Fakten leiten und eigener Erfahrung, das ist der sicherste Weg. Leider werden aber wohl einige PIC Anwender von solch überheblichen Aussagen davon abgehalten ihre Erfahrungen zur Verfügung zu stellen und das ist sehr schade. Ein zufriedener PIC/HC11 Anwender. MfG Manfred Glahe
@Manfred, "...Natürlich ist der PIC nicht besonders benutzerfreundlich..." Herzlichen Glückwunsch zu diesem Eigentor. Also wenn das nicht ein entscheidendes Argument ist. @Alle Der Rest der Polemik bezieht sich auf mehrere ältere Threads, dürfte also kaum für jemanden verständlich sein und deshalb will ich hier auch nicht darauf eingehen. Mein Angebot "mache so etwas bitte per E-Mail aus" gilt weiterhin. Ich bin ja auch nicht grundsätzlich gegen den PIC. Ein Blinklicht kann man bestimmt auch gut mit dem PIC machen. Aber meine Anwendungen sind einfach zu komplex, um da mit einem PIC zurecht zu kommen. Ich arbeite z.B. sehr gern mit Look-Up-Tabellen, Sprungtabellen, indirekter Adressierung usw. Z.B. müssen meine Anwendungen of mit dem PC kommunizieren und da ist ein Kommandointerpreter notwendig. Das ist also eine Tabelle mit den Kommandotexten und eine andere mit den dazugehörenden Sprungmarken. Und dazu braucht man nunmal DB und DW Anweisungen sowie PUSH/POP um an die Adresse zu kommen. Peter
Kurz und knapp: Peter, das geht auch alles mit dem PIC. Der MPLAB-Assembler kennt ebenfalls DB, DW oder DT-Anweisungen. Befehlstabellen und umfangreiche Lockup-Tables sind auch kein Problem. Auch kann man bei entsprechender Programmierung ohne Push und Pop auskommen. Ob das Umständlicher ist oder nicht hängt dann von der genauen Anwendung ab. Jeder Prozessor hat so seine Vor und Nachteile. Darüber zu streiten bringt absolut nichts. MfG Steffen
Hallo
@Manfred,
"...Natürlich ist der PIC nicht besonders
benutzerfreundlich..."
Herzlichen Glückwunsch zu diesem Eigentor.
Also wenn das nicht ein entscheidendes Argument ist.
@Alle
Der Rest der Polemik bezieht sich auf mehrere ältere
Threads, dürfte also
kaum für jemanden verständlich sein und deshalb will
ich hier auch nicht
darauf eingehen.
Mein Angebot "mache so etwas bitte per E-Mail aus"
gilt weiterhin.
wer im Forum so kategorisch etwas abkanzelt der muß auch an gleicher
Stelle dafür geradestehen. Eine weitere private Kommunikation hatte ich
nach der ignoranten (oder unwissenden Kommentierung meines 16 Bit
Systemes) schon abgelehnt. Wer nach Aufforderung eigene Entwicklungen
zum Vergleich vorzulegen sich mit dem Hinweis "Das ist alles Geheim"
rausmogeln will, hat seine Chance vertan!
Das ist kein Eigentor sondern eine bewußte Feststellung eines kritischen
PIC Benutzers. Zur Analyse gehöhrt eben mehr als nur Meckern!
Wer also meint mit einem PIC nur Led's schalten zu können sollte sich
aus dem Thema PIC herraushalten, der versteht nichts davon!!!
MfG Manfred Glahe
Hi, ich habe lange Zeit mit dem PIC in Assembler programmiert. Ein Alptraum, wenn man den steinalten z.B. Z80 noch kennt. Dann habe ich mir einen PIC Compiler geschrieben, ein Horror mit den Pages etc. Dann kam ein Z8, TMS370 und dann der AVR Compiler. Jeder einzelne von denen ist besser als der PIC. Der ist einfach ein Alptraum. Leute, die Vergleiche haben, wissen das in der Regel. rolf
Hallo Rolf, ich vergleiche den PIC mit dem HC11 und das ist sicher ein Unterschied. Der HC11 als CISC ist nämlich wesentlich komfortabler als das was einige Kritiker des PIC anbieten. Habe ich deshalb diese Controller oder dessen Benutzer abqualifiziert? Aber einen Controller mit 52 Pins kann ich nicht in den Wald stellen um Daten zu sammeln. Der PIC16F84 z.B. steuert bei mir Motoren, Generatoren und und andere induktive Verbraucher seit Jahren ohne Probleme. Einige andere vorgeschlagenen Typen tun das eben nicht wie auch hier im Forum zu lesen war. "Ein Alptraum"? Dann hast Du über "lange Zeit" ja den falschen Controller benutzt! Das nenne ich allerdings DUMM! Nach so viel Kritik von einigen wenigen über diesen Controller habe ich mir mal die Mühe gemacht deren Beiträge zu anderen Themen aufmerksam zu lesen. Es wundert mich nicht mehr! MfG Manfred Glahe
Eigentlich bin ich diese Diskussion über pro und kontra PIC echt leid. Hab mir auch ernsthaft überlegt überhaupt dazu etwas zu schreiben, weil wie gesagt - ich bin's leid. Da ich aber an diesem Thread beteiligt bin, werde ich mich noch einmal dazu äußern und mich aus neuern Diskussionen heraushalten. @Manfred Meinst Du nicht das jemanden hier dumm zu nennen etwas zu persöhnlich ist? Manchmal kann man sich das nicht aussuchen welcher mc in der Application steckt. Wieso meinst Du das ein 52pin Controller keine Daten sammeln könnte? Das ist doch Unsinn. Die Controller besitzen zwar meist recht wenig eigenes RAM, doch dafür gibt es ja Lösungen. Und wieso empfindest Du es als eine Abqualifizierung des Benutzers, wenn jemand seine Einstellung zu einem Controller äußert? Es ist doch jedem selbst überlassen was man zu dem Code oder der Architektur empfindet. Das Recht zur Meinungsäußerung hat hier jeder, für Beleidigungen dagegen keiner. Es muß sich doch niemand persönlich angegriffen fühlen, wenn jemand einen Controller als madig hinstellt - er wird schon seine Gründe haben und hoffentlich darlegen. @Rolf & All Ja auch ich habe schon einige Controller und Prozessoren durch, darunter auch der PIC. Auch ich habe viele Jahre mit den kleinen Schweinchen (für alle Korrekteure: ich weiß das PIG richtig ist) gearbeitet und gute Erfahrungen gesammelt was den Controller den Punkten Sicherheit und schneller Realisierbarkeit von Anwendungen betrifft. Aber nicht nur die Controller entwickeln sich weiter, man selber ja auch. Daher kenne ich ebenfalls unterschiedliche Familien. Zur Zeit versuche ich mich gerade an AVR-Assembler, nachdem ich jetzt 3/4 Jahr den AVR nur in ICC und GCC in der Mangel hatte und noch habe. Bei diesen neuerlichen ASM Gehversuchen hatte ich Anfangs erst einmal geflucht über den AVR-Code, nach jahrelangen PIC-ASM auch kein Wunder. Diese Destination Angaben im PIC für W und F sind einfach eine feine Sache und diese hatte ich dann vermißt. Da hat man dann schon das Gefühl man geht beim AVR über Umwege. Nun, war das natürlich nur der erste Gedanke, neues ungewohntes zu Verurteilen liegt dem Menschen ja im Blut. Selbst wenn man beim PIC einen Befehl findet, für den man beim AVR mehr Code benötigt, ist der AVR immer noch mit seinem 1:1 Quarztakt im Vorteil. Letztendlich bietet der AVR durch seine vielen gleichberechtigten Register, der ausgefeilten bankingfreien IO, bankingfreies RAM, dem zugänglichen Stack und der Exceptionvektortabelle dem Benutzer eine deutlich bequemere und leistungsfähigere Systemumgebung. Und zudem sind die AVRs auch noch günstiger als die PICs. Doch wie schon erwähnt , es bleibt ja jedem selbst überlassen welchen Controller er einsetzt. Es ist dennoch wichtig sich darüber zu äußern und seine Erfahrungen mitzuteilen. Schließlich sollen all diese Postings ja denen helfen, die sich noch nicht entschieden haben oder die Zeit und Geld für langwierige Erfahrungen nicht investieren wollen oder können. MooseC
@ MooseC die einzige wirkliche Schwäche des PIC ist das nervende zeitraubende Bankselekt. die INT on Portchange für 4x4 Tastaturen ist dafür sehr gut gelöst und seine Schnelligkeit mit bcf/bcs ist hervorragend. Wenn ich "Alpträüme" davon hätte würde ich das sofort lassen und mir etwas besseres suchen. Zwänge gibt es überall! Allerdings gebe ich zu das mich gerade die Art und Weise wie einzelne diesen Controller abqualifiziert haben (" wenn man nur eine Led schalten möchte") etws überreagieren läß. Rolf hats nun leider getroffen weil ich den Eindruck hatte das er diese Sichtweise vertritt. Die Verknüpfung von Werkzeug und Benutzer ist gewollt, wenn auch nicht immer explizit erwähnt. Sollte ich mich da getäuscht haben bin ich auch bereit das zu korrigieren. Gemeint war: 52pin plcc ist zu teuer, zu groß und zu empfindlich. Es sollte nicht übersehen werden, daß es hier in der Regel um Programme im KB Bereich geht. Da gibt es viele gute Controller aber doch sicher keinen der Alpträume verursachen würde oder nur Led's schalten kann. MfG Manfred Glahe
@Moosec, Voll meine Meinung. Dem ist nichts mehr hinzuzufügen (hoffentlich). Peter
Hi, ich wollte keinesfalls irgendwelche User von irgendwelchen Controllern abqualifizieren. Mein Horror gilt nur dem PIC. Sicher, ich habe jahrelang u.a. auch den PIC verwendet, da es viele Jahre praktisch keine Alternative gab. Und alles ist zum laufen gekommen.Also der PIC hat auch seine Berechtigung. Aber jetzt Newbies auf den PIC zu heben, finde ich nicht gerade toll. Gerade für einen Anfänger hat die PIC Architektur extrem viele Fallgruben, die einen Unerfahrenen zur Verzweiflung bringen können. Das soll aber nicht heissen, dass alle anderen Typen problemlos sind. Meine Meinung aus 30 Jahren embedded Programmieren :-) rolf
Hallo Rolf, tut mir leid wenn ich das vorher mißverstanden habe. Deinen neuen Beitrag kann ich auf jeden Fall unterstreichen. Zur Analyse gehören doch auch die positiven Eigenschaften des PIC und die muß man dann auch fairer Weise nennen. Möglicherweise hast Du dieses Thema nicht durchgängig verfolgt sonst würdest Du meine Sichtweise wohl auch eher verstehen können. Natürlich ist der PIC auch weiterhin für Anfänger geeignet weil er extrem hart im Nehmen ist. Anfängerfehler wie Kurzschlüsse oder kurze Überspannung (alles in Grenzen natürlich) bringen ihn nicht gleich um und das gleicht meines Erachtens die Programmier Probleme mehr als aus. Einer der vielen PIC's ist, soweit mir bekannt, der einzige "kleine" im Moment, welcher einen DSP Kern integriert hat. Dieser Umstand ist für ADW Applikationen von großem Vorteil. MfG Manfred Glahe
DSP56800 Familie von Motorola hat wie die dsPIC30F family 16bit/ Flash uC und DSP etc. und ist bereits verfügbar "dsPIC30F laut Microchip late 2003" . Womit ich nichts gegen Microchip sagen will (das Thema sollte eigentlich durch sein), aber wenn du HC11 schätzt ist es ja vieleicht auch für dich interessant. Gruß Bernhard
@all Also irgendwie verläuft die Disskussion genauso, wie ich es auch von einem anderem Gebiet her kenne: Programmiersprachen! "C kann dieses", "C++ kann das", "Visulal Basic kann beides nicht (aber anderes am besten)", "FORTRAN ist doch antik", "mit Lisp ist das doch viel eleganter zu machen" u.s.w. Meine Antwort ist dann immer: Wie gut eine Programmiersprache (oder hier: ein Mikrocontroller) ist, hängt zu 80% vom Entwickler ab. Ich behaupte mal: Wenn ich über Jahre hinweg intensiv mit PIC's arbeite (aus welchem Grund auch immer), zaubere ich die Lösung für jede (lösbare) Aufgabe in unvergleichbar kürzerer Zeit aus dem Hut, als ein mittelmässiger Programmierer, der einen "viel besseren" up-to-date-Controller, wie es der AVR vielleicht ist, verwendet. @MooseChecker >"Mir graust schon vor einer größeren Änderung....Ich glaub dann schmeiß ich die lieber Stück für Stück raus." Wie gut Dein Code wartbar ist, hängt doch wohl mehr von Dir/Deinen programmierfähigkeiten und weniger vom Controller ab. MfG Andreas Jäger
@Bernhard "(das Thema sollte eigentlich durch sein)", warum? Erstens ist niemand gezwungen sich daran zu beteiligen und zweitens hat mir Dein Beitrag doch gezeigt daß es auch bei Motorola soetwas gibt. Wer sucht schon andauernd gezielt nach solchen Neuerungen? Der Beitrag von Herrn Jäger trifft genau den Punkt! Den hätte ich doch sonst nie zu sehen bekommen. Ich habe jahrelang nur mit dem HC11E2 gearbeitet und der ist vom Befehlssatz her hervorragend. Und wie Herr Jäger schon feststellte, der hat dann alles gemacht, auch wenn er überdimensioniert war (es ging so am schnellsten und sichersten). Wenn Motorola soetwas wie den PIC 16F84 (oder besser einen mit RS232) angeboten hätte währe ich bei der µP Familie geblieben (wohl auch aus Bequemlichkeit). Ich denke die Akzeptanz hägt stark davon ab, ob man von der Hardware- oder von der Softwar- Seite auf den PIC zugeht. Für mich als Hardware Mensch ist der PIC eine gute Erweiterung zum HC11. MfG Manfred Glahe
>>Wie gut eine Programmiersprache (oder hier: ein Mikrocontroller) ist, hängt zu 80% vom Entwickler ab. Natürlich, früher hat man auch mal Lochkarten oder Hexeingabefelder benutzt, um Rechner zu programmieren. Doch muß ich mir unnötige Arbeit antun? Dafür gibt es doch unterschiedlich gute Tools und Controller. >>Wenn ich über Jahre hinweg intensiv mit PIC's arbeite (aus welchem Grund auch immer), zaubere ich die Lösung für jede (lösbare) Aufgabe in unvergleichbar kürzerer Zeit aus dem Hut, als ein mittelmässiger Programmierer, der einen "viel besseren" up-to-date-Controller, wie es der AVR vielleicht ist, verwendet. Ja, dem stimme ich zu, wenn auch die Klassifizierung mittelmäßig nicht angebracht ist, da wie ich meine es so etwas nicht gibt. Jeder ist auf seinem Gebiet mit Sicherheit ein Profi und in anderen nicht ausreichend kompetent. Das hängt eben viel von dem Umfeld seiner Arbeit und dem eigenen Betreben eines jeden einzelnen ab. Deswegen ist man aber nicht mittelmäßig. Fühlst Du Dich als etwas besseres als der ein oder andere hier im Forum? >>"Mir graust schon vor einer größeren Änderung....Ich glaub dann schmeiß ich die lieber Stück für Stück raus." Nur wegen meinen Belangen, kann ich die PICs gar nicht ausdesignen. Das hätte jede Menge Hardwareänderungen und einen riesigen Berg Papierkram mit den QS unserer Kunden zur Folge. Aber grausen tuts mich trotzdem. Solch einen Fall habe ich erst hinter mir, was für der Anlaß war die Controller nun nach ihrer hochprachenfähigkeit auszuwählen. (Und Ihr könnt mich steinigen, mit C auf dem PIC fange ich gar nicht erst an und das ist auch allein meine Sache) >>Wie gut Dein Code wartbar ist, hängt doch wohl mehr von Dir/Deinen programmierfähigkeiten und weniger vom Controller ab. Dem stimme ich bedingt zu. Fällt aber als Wiederholung auf Punkt zwei. >>währe ich bei der µP Familie geblieben (wohl auch aus Bequemlichkeit). Genau aus Bequemlichkeit bleibe ich nicht bei einer Familie, wenn mir was nicht paßt, ändere ich das ab, sofern mir nicht die Hände gebunden sind. >>Ich denke die Akzeptanz hägt stark davon ab, ob man von der Hardware- oder von der Softwar- Seite auf den PIC zugeht. Ich kam hardwareseitig auf den PIC zu und er war für mir kein Ersatz für einen anderen Controller, sondern für Hardware. Mittlerweile hat sich das aber verschoben, womit sich auch meine Sichtweise dieser Dinge geändert hat. Das immerwährende Lernen ist eben eine Grundvoraussetzung in diesem Bereich. MooseC
Ich lerne auch dazu wenn ich diese Beiträge aufmerksam lese und akzeptiere selbstverständlich andere Standpunkte. Heute gibt es fast für jedes spezielle Problem den passenden Controller. Das heißt doch aber auch nur wieder, daß auch die Profientwickler in den Labors nicht die "eierlegende Woll- Milchsau" anstreben (oder können)! "Bequemer" heißt für mich nicht gleich faul sondern schneller, sicherer und stressfreier. Ich laufe nicht jeder Neuerung hinterher nur weil sie da ist! Sie muß mir entscheidende Vorteile bringen. In meinem Umfeld haben die Kollegen immer 2-3 Versionen Vorsprung im ECAD System. Im Projektvegleich sieht es eher andersherum aus. Warum ist das so? Da die Kollegen nicht dümmer sind als ich, liegt es nach meiner Meinung daran, daß sie zuviel Zeit in immer längere EINARBEITUNG und Änderungen stecken müssen. Allerdings "Graust" mir auch vor großen Änderungen in der Software (ich kann nur Assembler und TP), da schreibe ich lieber neu. Durch Verwendung von 12 Bit ADW Sytemen kann ich fast alle Probleme (in der biologischen Anwendung) damit erschlagen und bei den Subrutinen die ins Hauptprogramm eingebunden sind ändert sich doch eh nichts mehr. Die Arbeit beschränkt sich daher doch nur auf den Ablauf der Hauptschleife (mit Ausnahmen natürlich). PS: Um Mißvertständnissen vorzubeugen, der PIC ist für mich kein ERSATZ (weder für Hardware noch für den HC11) sondern eine ERWEITERUNG. MfG Manfred Glahe
@MooseChecker Selbstverständlich sehe ich mich nicht als irgend etwas Besseres, als andere hier im Forum. Ebensowenig halte ich Dich für mittelmäßig (wie sollte ich, wir kennen uns doch garnicht). Das war eher allgemein gemeint. Meistens soll eine Aufgabe doch schnell gelöst sein (Zeit ist Geld) und zuverlässig funktionieren. Je besser ich die einzusetzende Hardware und die Entwicklungsumgebung(!) kenne, desto besser kann ich diese Forderung erfüllen. Dabei ist es egal, wie alt der Controller oder die IDE ist. Erst wenn ich keinen Lösungsansatz finde, sehe ich mich nach Alternativen um. Und zum Thema "Nicht mehr state-of-the-art": In der Raumfahrt z. B. werden Prozessoren eingesetzt, die 3 oder mehr Generationen alt sind. Da dauert es bis zu 4 Jahre, ehe ein Prozessor getestet (und damit bekannt) ist und führ den jeweiligen Einsatzzweck als geeignet bewertet wird. Allerdings fragt Markus im Ursprungs-Posting explizit nach einem Dev-Board für PIC's. Da erübrigt sich alles weitere... @Markus Bist Du nun eigentlich Schüler "...da ich nur ein Schüler bin und noch kein eigenes Einkommen habe..." oder nicht "...Bei meiner Diplomarbeit wollte der Hund absolut nicht schwingen egal was ich auch versuchte". MfG Andreas Jäger
Hi allerseits!! Zuerst einmal danke an alle die mir links zu development boards geschickt haben So und jetzt möchte ich auch mal sagen warum ich PIC`s verwende: Ich habe die 3 großen Haupttypen (würd ich mal sagen) 8051 AVR und PIC probiert. Der 8051 war echt super um mal in di mc welt einzusteigen. danach entdeckte ich den pic mit parsic jaja das hat nix mit programmieren zu tun aber man kann echt schöne dinge damit machen und zum schluss fand ich die avr da ich nur ein schüler bin musste ich mich entscheiden zwischen 2 Programmern Sie sollten möglichst viele Varianten programmieren können und wenn möglich ISP fähig sein AVR war klar das baue ich mir mal So und bei nr 2 entschied ich mich für den PIC Erstens wegen Parsic und zweitens: die Firma Microchip ist sehr spendabel in Hinsicht von Samples im gegensatz zu den avr`s (Jaja oich nutz das service eh nicht aus sondern brauch im jahr ca 6 Pics, das verschmerzen die locker, doch es soll gesagt sein!!!!! WAHLLOSES UND SINNLOSES BESTELLEN GEFÄHRDET DIESES SERVICE ALSO SEIT FAIR!!!!!)
Also das einfachste Programmiergerär für den Pic16f84 istwohl wirklich dieses Hier: http://www.ek-p.de/electronics/mppp30/index.htm MFG Nik
"...die Firma Microchip ist sehr spendabel in Hinsicht von Samples im gegensatz zu den avr`s..." Endlich mal ein nachzuvollziehendes Argument für den PIC :-) Das es mit den AVRs nicht so einfach ist, kann ich bestätigen. Die wollen immer gleich wissen, wann man die großen Stückzahlen ordert. Da unsere Firma aber nur die Entwicklung macht, kann ich das immer schlecht sagen. Und für Geld muß man mindestens eine komplette Stange abnehmen. Bei Maxim (Dallas) sieht das wohl wieder besser aus. Jedenfalls sieht man hier im Forum ne Menge Schaltungen mit Maximbauteilen, die es aber oftmals nirgends im Laden gibt. Meine DS1994-Samples habe ich auch ohne Probleme und nerviges Nachfragen bekommen. Maxim hat sogar einige 8051-er mit ISP. Peter
Hi! Ich fange gerade mit PICs an und habe mir erst mal nur die Demoversion zu Parsic runtergeladen. Als ich dann die Beispielprogramme auf meinen PIC schreiben und ausführen wollte, ist mir aufgefallen, dass mein PIC (12F675) gar nicht in der Liste steht. Ist der nicht mit Parsic kompatibel, hab ich ne zu alte Version von Parsic oder gibt es ne Möglichkeit den doch einzustellen? Vielen Dank im Voraus! Patrick
http://people.freenet.de/helmutholm/ experimentierboard mit pic 16f877/874 einseitig, leicht selber zu ätzen programmier einrichtung an board. schau schau
"Ist der nicht mit Parsic kompatibel" Im Unterschied zu PCs oder 8051-ern sind die PIC-Familien untereinander weder Binär- noch Source-kompatibel. Grob gesagt gibt es die PIC12.., 14.., 16.., 18.., die alle untereinander verschieden sind. D.h. um Code von einer auf die andere Familie zu übernehmen sind oft größere Änderungen notwendig. Bei Hochsprachen kommt noch hinzu, daß die erst bei den 16- und 18-ern genügend Ressourcen vorfinden, um einigermaßen effizienten Code zu erzeugen. Peter
@Peter "Im Unterschied zu PCs oder 8051-ern sind die PIC-Familien untereinander weder Binär- noch Source-kompatibel." Mal wieder ein irgendwo aufgelesenes Vorurteil? Der ASM-Code ist aufwärtskompatibel! Programme der 12-Bit Familien laufen auch auf den 14-Bit und 16-Bit Familien. Alles andere ist Quark! Angepasst werden müssen die Programme natürlich auf die unterschiedlichen Resourcen der einzelnen PIC´s, was bei den 8051-ern wohl nicht anders sein wird. Übrigens sagt die erste Zahl (12CXXX, 16CXXX etc.) nichts darüber aus zu welcher Familie der PIC gehört. Womit die letzte Aussage "Bei Hochsprachen kommt noch hinzu, daß die erst bei den 16- und 18-ern genügend Ressourcen vorfinden, um einigermaßen effizienten Code zu erzeugen." auch wieder Müll ist. Steffen
@Steffen, Ist mir schon öfter aufgefallen, daß PIC-Benutzer immer gleich sehr aggressiv reagieren, wenn man PICs mit anderen Architekturen vergleicht. > was bei den 8051-ern wohl nicht anders sein wird. Nein, 8051-Programme sind uneingeschränkt Binär- uns Sourcekompatibel. Klar ist natürlich, daß ein Programm, welches Timer T1 benutzt, nicht auf einem 8051 laufen kann, der keinen T1 hat. Die einzige Einschränkung ist, daß bei den High-Speed Derivaten die Delay-Schleifen schneller als geplant laufen, das ist alles. > Programme der 12-Bit Familien laufen auch auf den 14-Bit und 16-Bit > Familien. Alles andere ist Quark! Das habe ich mir auch nicht aus den Fingern gesogen, sondern daraus geschlußfolgert, daß oft Anfragen kommen, warum Programme auf fast gleichen PICs bloß eben mit mehr Speicher plötzlich nicht mehr laufen. > Womit die letzte Aussage "Bei Hochsprachen kommt noch hinzu, daß > die erst bei den 16- und 18-ern genügend Ressourcen vorfinden, um > einigermaßen effizienten Code zu erzeugen." auch wieder Müll ist." Aber ich kann mir beim besten Willen nicht vorstellen, wie man z.B. beim PIC12C509 mit nur 2 Stackebenen sinnvoll einen C-Compiler bauen will, der lebt ja von Unterfunktionsaufrufen. Und daß Parsic nicht den PIC12F675 kann, bestätigt das doch. Nichts für ungut, aber wer die Aussagen anderer pauschal und ohne Begründung als Müll bezeichnet, hat nie recht. Peter
Hi! Danke für die schnelle Hilfe! Konnte leider nicht früher antworten, weil ich übers Wochenende nicht da war. Ich sehe nun ein, dass ich meinen PIC nicht mit Parsic programmieren kann. Naja, ich kann ja aufs gute, alte Assembler zurückgreifen. Nur Parsic erschein mir so praktisch, da ich dort meine Schaltpläne direkt sehen und gegebenenfalls korrigieren kann (ähnlich wie bei Locad). Bis dann! Und noch viel Erfolg bei der Arbeit mit PICs! Patrick
@Peter Was soll ich dir denn begründen? Du bist hier der jenige, der Vorurteile ohne Begründungen anbringt. Schau mal ins Datenblatt des 12F675. Er gehört zur Mid-Range Familie (14-Bit Core). Das Parsic ihn nicht unterstützt liegt wohl eher daran, dass er recht neu ist. Bestätigen tut dieser Umstand absolut nichts. "Klar ist natürlich, daß ein Programm, welches Timer T1 benutzt, nicht auf einem 8051 laufen kann, der keinen T1 hat." genau das ist auch das Problem bei den PIC´s. Bei PIC´s mit integriertem AD-Wandler oder Comperator werden die I/O´s alternativ genutzt. Wird der PIC nicht richtig initialisiert, dann laufen die Programme freilich nicht. Der Befehlssatz der 12-Bit und 14-Bit PIC´s ist identisch. Nach oben sind daher alle Sourchen kompatibel. Ein Programm für einen 16C54 läuft auch auf einem 16F876 und auch auf einem 18Fxxx. Wer etwas anderes behauptet, der hat sich noch nie damit beschäftigt und sollt lieber sinnvolle Kommentare auf dem Gebiet abgeben, wo er Ahnung hat. Die 16-Bit Familie hatt einen erweiterten Befehlssatz aber wie gesagt die Quellcodes der anderen Familien laufen uneingeschränkt ohne größere Änderungen. Steffen PS: Nimm es mir nicht übel aber fast das selbe hatte ich dir schon einmal versucht klarzumachen.
@Patrick hast du denn mal versucht das parsic-programm auf einen ähnlichen prozessor bei parsic einzustellen. vielleicht geht es ja... sonst leg es mal in den anhang. mfg
@Steffen, ja, wenn Du mich immer absichtlich mißverstehen willst, kann ich Dich natürlich nicht daran hindern. Meine Ausführungen sollten doch nur erläutern, daß die PICs nicht Binärkompatibel bzw. nur aufwärts Sourcekompatibel sind und dadurch ein Hochsprachencompiler verschiedenen Code erzeugen müßte. D.h. es ist völlig normal, wenn ein Compiler eben nur bestimmte PICs unterstützt und dabei vorzugsweise die mit dem größeren Befehlsumfang. Ob dabei nun PIC12 und PIC18 als unterschiedliche Familien bezeichnet werden oder nicht, ändert nichts daran, ist also nebensächlich. Und daß eben dazu im Gegensatz ein C-Compiler z.B. für den 8051 jedes Derivat unterstützt, egal ob P78C570 oder C8051F000 oder irgendeinen, den es noch garnicht gibt. Ich benutzte z.B. den Keil C-Compiler von 1995 und programmiere damit den T89C51CC01 von 2002. Also nochmal die Quintessenz ganz langsam zum Mitlesen: irgendein PIC Compiler: unterstützt nicht jeden PIC irgendein 8051 Compiler: unterstützt jeden 8051 Da wirst Du mir doch zustimmen können ? Peter
Soweit ist das fast aber eben nicht ganz richtig. Der Code von einem Compiler für die 12-Bit Versionen läuft auch auf den 14- und 16 bit PIC´s. Anders herum funktioniert das natürlich nicht, weil der Prozessorkern eben nicht identisch ist. Beim 8051 habe ich das Problem nicht, da der Prozessorkern bei allen Derivaten der gleiche ist. Die 12-Bit Varianten, das sind die auf die die ganzen Vorurteile zutreffen. Allerdings werden die kaum noch verwendet. Zwischen den 14-Bit und 16-Bit PIC´s liegen absolute Welten. So gut wie alle kleineren bis mittleren Anwendungen kann ich mit den 14-Bit Derivaten abdecken. Reicht die Leistung/Speicher etc. nicht mehr aus, dann sollte man für kompliziertere Sachen die 16-Bit Familie verwenden. Der Name PIC heißt noch lange nicht, dass der Kern identisch ist wie beim 8051. Es ist richtig, dass teilweise auch nicht alle PIC´s einer Serie von einem Compiler unterstützt werden (siehe 12F675 + Parsic), das liegt aber eher daran, dass der Entwickler des Compilers nicht alle integriert hat und nicht an der unterschiedlichen Struktur. Mal von der richtigen Implementation der integrierten Peripherie abgesehen müsste dein letzter Satz unfähr so lauten: Von einem Compiler für die 12-Bit-Familie erzeugter Code läuft auf allen PIC´s. Ein PIC-Compiler für die 14-Bit Familie kann Code für alle 14-Bit und 16-Bit PIC´s erzeugen. Ein Compiler für die 16-Bit Familien kann nur Code für die 16-Bit PIC´s erzeugen. Abwärtskompatibilität ist nicht notwendig. Das gleiche wäre, wenn jemand verlangen würde, dass seine für Windows 2000 erstellten Programme auch unter Win3.1 laufen sollten. So, ich denke mal gut damit.
@stromi: Danke für den Tip! Ich werds mal versuchen, aber welchen soll ich mal einstellen? Also ein Flash müsste es denke ich schon sein.
@patrick bei so etwas nehme ich den conrad und schaue mir die controllerbeschreibungen auf der entsprechenden seite an. ist da gut aufgelistet. (ich muss in meinem alter aber mit super brillen atbeiten, weil das so klein gedruckt ist :-) ) in der liste einfach den 675 aussuchen, dessen beschreibung muß auf einen typ passen, den parsic unterstützt. den bei parsic einstellen und programmieren. du wirst sehen das klappt. ich habe mit parsic schon einiges gemacht. was ich mir da noch wüsche, ist ein I2C-Baustein und wenns schön sein soll, noch eine 1wire-Baustein, dann vermisse ich erst einmal nichts. wenn man den autor doch dazu bewegen könnte... ist lange nichts passiert da, außer Fremdsprachenunterstützung. man sollte sich mal einig sein und den autor anmailen. wenn es mehr sind die da mitmachen, wird er vielleicht wieder rege :-) sicherlich würde ein hinweis auf den Pic-typ 675 auch anregend sein. mfg und melde dich mal ob's geklappt hat.
Hallo Markus, Wenn du einen Programmer für Pic's benötigst findest du die Beschreibung mit einer Bauteilliste unter www.ic-prog.com und www.sparkfun.com. Wenn du "In-Circuit" programmieren möchtest benutze Sparkfun, wenn nicht ic-Prog. Der ic-Prog Programmer läßt sich aber leicht auf eine "In Circuit" Programmierung umbauen. Sparkfun habe ich selber gebaut, funktioniert... Das Programm das dein HEX-File auf die Zielharware lädt findest du unter www.ic-prog.com. Ich habe den Controller PIC16F877 benutzt. Grüße aus Etschberg Sascha
Hi, könnts ihr mir INFOS über den PIC12C508 geben.(ich weiß das er ein 8-pin µC ist). Ich brauch den für meine Senderschaltung. Habts ihr vielleicht auch das Bauteil in Eagle oder PSpice, das ihr mir schicken könnts! Ich bitte um Hilfe! lg. alwin
Hallo, Infos (Datenblätter o. ä.) gibts auf der Website des Herstellers: www.microchip.com Der 12C508 ist allerdings schon ein älterer Typ ohne Flashspeicher. Zum Neuprogrammieren muß er erst mit UV Licht gelöscht werden. Typen mit einem normalen DIL Gehäuse sind OTP. Für Neuentwicklungen ist der 12F629 besser - er hat Flashspeicher. Gruß Markus
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.