PIC Programmer development board

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.

@ 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

wie sieht das denn bei dem AVR mit den Sprungbefehlen und 
Unterprogrammen aus?

Hier könnt ihr mal sehen wie einfach es sein kann einen Pic zu 
programmieren

Schaut euch das foto an!!

lg markus

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

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

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 AVR’s auch noch 
günstiger als die PIC’s.

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

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 PIC’s gar nicht ausdesignen. Das 
hätte jede Menge Hardwareänderungen und einen riesigen Berg Papierkram 
mit den QS unserer Kunden zur Folge. Aber grausen tut’s 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

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

@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

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

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