Diskussion:PICmicro/Archiv

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

allgemeine Kritik

Letzter Kommentar: vor 15 Jahren21 Kommentare6 Personen sind an der Diskussion beteiligt

Ansich ein schoener Artikel, aber ein wenig Verbesserungsbedarf sehe ich:

Der Absatz zum Thema Debuggen bei der Auflistung der Typenfamilie ist zum einen dort irgendwie deplaziert, geht er doch viel zu sehr in's Detail. Zum anderen ist er auch in sich etwas komisch. Erst wird erklaert, dass es fur die gesamte F-Typenreihe gilt, und dann doch nur fuer die "grossen". Wieso dann "jeder einzelne Controller" debuggt werden kann und was daran so besonders ist, ist mir nicht klar. Alle Exemplare eines Typen sollten doch identisch sein?!

Die großen können so debugged werden, wie sie sind. Bei den kleineren fehlen die zwei Debug PINs. Es gibt für diese eine spezielle Entwicklungs-Version, die zwei Pins (die zum debuggen) mehr hat. Wenn die Entwicklung abgeschlossen ist, werden in der Massenproduktion die Normaltypen verwendet. Das liegt daran, dass man bei einem kleinen Controller, die herunter bis zu nur sechs PINs haben, nicht davon auch noch zwei für das Debuggen verplempern möchte. Zwei PINs sind ja ohnehin für die Versorgungsspannung, so dass ein solcher 6-pinniger Controller nur noch zwei Portpins (anstatt vier) hätte. Für den Bastler, der keine Massenproduktion betreibt, sind also die größeren Controller empfehlenswert, weil sie debugged werden können, wie sie sind. Der Debugger ist schon auf jedem Chip implementiert. Man kann das Debuggen aber auch abschalten, so dass auch diese beiden PINs auch als Portpins benutzt werden können. Jeder, wie er möchte. ..... Ich gebe Dir recht, dass dieser Artikel überarbeitet werden müsste. Um aber sie wirklichen Verhältnisse richtig darzustellen, müsste man ihn vollkommen neu schreiben. So wirken also manche Darstellungen in der Tat etwas deplaziert. -- 84.132.119.65 17:01, 21. Nov. 2006 (CET)
Für's Neuschreiben reicht mein Wissen nicht aus. Ich kenne nur aus einem einzigen praktischen Projekt den 16F84. --ChrisHuebsch 13:33, 22. Nov. 2006 (CET)
Meines auch nicht, obwohl ich fast 50% meiner Arbeitszeit damit verbringe. Ich habe mich auf sechs Vorzugstypen eingeschossen. Aber ich kann soviel sagen: Es hat heutzutage selbst im Bastelbereich nur noch einen Kultsinn noch in einer nichtrelozierenden Assembler zu schreiben. Wenn Assembler, dann reloziert oder gleich C. Alle Prozessoren unter 18FXXX haben zu viele Haken und Ösen. Sie lohnen sich nur, wenn man noch die letzten Cent sparen will und das ist meist nur in Massenprodukten der Fall. Die ganze geschaffene Bastlerinfrastruktur stützt sich aber noch auf den direkt adressierenden Assembler, wo die Überlegungen und Pflege um die händische Speicherwaltung schlecht geschätzt (eher erheblich mehr) mindestens 50 Prozent der Arbeit kostet. Was da den armen jungen Nachwuchsbastlern da (auch hier im Artikel) beigebracht wird, ist das, was die Proffessionellen jetzt schon nicht mehr und spätestens in 10 Jahren nur noch Nostalgiker tun werden. Daher fand ich es schon wichtig, dass hier im Artikel wenigstens einmal angetippt werden und eine Ahnung vermittelt werden sollte, was der technische Stand ist. Dem jungen Newcomer sollte wenigstens mitgeteilt und vermittelt werden, dass da noch mehr ist. Schon während des C64 und Apple II Zeiten geriet der direkte Assembler beim Desktop Computer ins Hintertreffen und Basic wurde genutzt. Heute würde sich keiner mehr einfallen lassen, ein PC Programm noch in Assembler zu schreiben. Und die Schwelle ist jetzt auch bei den Mikrocontrollern erreicht. So ist der gute alte direkte Assembler stark mit den Prozessoren unter 18Fxxx verwoben. Teilweise werden schon Betriebssysteme geladen. Die Anfänge dabei waren die Bootloader. Da sich die freie Gemeinde bisher schwer tut, sich den neuen Entwicklungen anzuschließen, fällt dies bei den freien Tools - ich betone: leider - noch um einige Stufen schärfer auf. Ich weiß nicht, ob das überhaupt noch leistbar ist. Keine Frage: Natürlich sollen die freien Tools hier erwähnt werden. Ich befürchte aber, dass diese in Zukunft - nochmal: leider - in der Versenkung verschwinden werden. -- 84.132.89.9 17:07, 27. Nov. 2006 (CET)

"Das Befehlsformat lässt sich nach den Argumenten in drei Gruppen einteilen."

Ich zähle vier Gruppen.

Um dies richtig zu differenzieren, müsste man den Artikel neuschreiben. Die 16 Bit ALU Typen, wie PIC24F und die DSPIC (Signalcontroller) fehlt völlig. -- 84.132.119.65 17:01, 21. Nov. 2006 (CET)
Dass man die Befehle in Gruppen einteilen kann, ist zwar schön, aber eigentlich fast egal. Wesentlicher find ich, dass Befehle alle gleich lang sind (sind sie doch hoffentlich auch bei den "Grossen"?) --ChrisHuebsch 13:33, 22. Nov. 2006 (CET)

Im Handbuch zum 16F84A sind nur 4 verschieden Oszillator-Modi angegeben. Die werden mit FOSC1 und FOSC2 eingestellt. Der RC-Oszillator benoetigt zudem extern eien Kondensator und einen Widerstand. Mit diesen wird die Taktrate eingestellt.

Der 16F84(A) war in der Tat DER PIC für den Bastler. IMHO ist er der einzige PIC, den Microchip nur als Remineszens an den Bastler im Programm hat. Denn in Massenprodukten der Industrie wird er schon lange nicht mehr verwendet. Daher wird er nur in sehr kleinen Stückzahlen gefertigt und ist daher mehr als doppelt so teuer, wie ein Chip mit mehr Features. -- 84.132.104.163 23:28, 21. Nov. 2006 (CET)
Das mit dem Preis kann ich nicht nachvollziehen. Es mag gut sein, dass einige Haendler den 16F84 teuer verkaufen. Aber das wohl auch nur, weil man damit dann mehr Gewinn erzielen kann. In der Preisliste, wo ich eben nachgeschaut habe, faellt der 16F84 nicht besonders auf wegen seines Preises. Kann aber gut sein, dass das bei Großkundenpreisen anders ist. --ChrisHuebsch 13:33, 22. Nov. 2006 (CET)
Wie gehabt: Großkunden für den 16F84(A) gibt es nicht mehr, ansonsten Preise im Microchip Online Shop ab 1 Stück für die Mainstream Bauteile -- 84.132.89.9 17:08, 27. Nov. 2006 (CET)

. Mit gpsim und gpsam stehen zudem auch zwei unter GPL stehende Tools fuer die PIC-Progeammentwicklung bereit.

GPL in allen Ehren. Aber was Microchip in den letzten Jahren für neue Features in die kostenlose Entwicklungsumgebung MPLAB eingebaut hat, da kann kein freies Projekt gegen anstinken. Hinzu kommt, dass alle freien Projekte immer nur eine Teilmenge von Prozessoren und eine Teilmenge der Features unterstützt. Und genau das/der gerade benötigte ist dann gerade nicht drin ;o) -- 84.132.104.163 23:34, 21. Nov. 2006 (CET)
Bei der GPL geht es nicht um den Preis. Bei der GPL geht es darum, dass die jeweilige Software auch dann weiterverwendbar ist, wenn der Hersteller das Interesse daran verloren hat. Wenn Microchip heute entscheidet, den 16F84 im Compiler nicht laenger zu unterstuetzen, dann wird der Support hierfuer aus der IDE genommen. 08/15 Kunde muss dann eben einen neuren Pic kaufen. Alle bestehenden Projekte koennen dann die (immer merh veraltende) vorgestrige IDE verwenden. Ob man die noch ewig downloaden kann, ist sicher ungewiss. Irgendwann hat man dann einen Chip, einen Programmierer und kein Programm mehr, mit dem man beides verwenden kann. Weit hergeholt? Nun NVidia und AMD/ATI unterstützen in ihren Treibern aeltere Chips schon nicht mehr. Die freien Treiber gehen noch immer.
Microchip wird die Unterstützung nach Einschätzung der meisten Kunden nur für solche Bausteine aufgeben, die sie nicht mehr vertreiben. Und in der Modelltreue sind sie zumindest bisher trotz ihrer Vielfalt ungeschlagen. Leider macht diese Modellvielfalt gerade die Übersicht und das Schreiben dieses Artikels ungemein schwer. Nicht umsonst kostet das einzige Buch, das die PIC18FXXX einigermaßen umfassend beschreibt, fast 100 Euro. Meiner Meinung nach ist es auch das einzige Buch, dessen Kenntnis zum Schreiben des PIC18XXX Ausschnittes des Artikels befähigt. -- 84.132.89.9 17:10, 27. Nov. 2006 (CET)
Die Features der alten PICs sind uebrigens meist gut unterstuetzt. Nur weil die neusten Top-Modelle nicht unterstuetzt werden, heisst das doch noch lange nicht, dass man die beiden Tools nicht nutzen kann. Sie sogar zu verschweigen und nur die kommerziellen Tools zu nennen, wiederspricht in meinen Augen der Neutralität der Wikipedia. --ChrisHuebsch 13:33, 22. Nov. 2006 (CET)

Die Ueberschrift "kostenloser C-Compiler" ist ein wenig irreführend. Ein Compiler hat keinen Quellcode-Editor. Vielleicht ist es ja eine kostenlose IDE, die einen C-Compiler eingebaut hat?

Der war gut :o) Natürlich läßt sich der Microchip Compiler auch ohne Oberfläche benutzen. In den Anfangszeiten war dies sogar die einzige Möglichkeit. Die Einbindung in die Oberfläche MPLAB kam erst später. Ein Gebrauch ohne MPLAB ist aber erheblich umständlicher. Die Menge der mitgebrachten Entwicklerwerkzeuge ist ohne solch eine integrierte Oberfläche nicht mehr zu handhaben. Das sollte sich wirklich niemand mehr antun. Nur ein winziges Beispiel: Man kann ein Programm in C schreiben/korrigieren und mit einem Klick ist es dann compiliert und assembliert und mit geladenem Debugger im Chip drin. -- 84.132.104.163 23:28, 21. Nov. 2006 (CET)
Und? Makefiles existieren. Nur weil jemand seinen Arbeitsablauf nicht ordentlich organisiert bekommt, muss man ja nicht gleich Unsinn schreiben. Ein Compiler ist ein Uebersetzungsprogramm. Kein Editor, kein Linker, kein Debugger und auch kein Loader. Wie schon gesagt. Hier ist eine Enzyklopädie und kein Forum. --ChrisHuebsch 13:33, 22. Nov. 2006 (CET)
Nochmal, Du kannst den Compiler blanko installieren und mit Makefiles benutzen, so wie Du es wünscht. Punkt. .....------..... ZUSÄTZLICH gibt es noch die zweite Installationsmöglichkeit, ihn in eine integrierte Umgebung zu installieren. Dass er durch diese zusätzliche Möglichkeit auf einmal kein Compiler mehr sein soll, ist doch bei den Haaren herbeigezogen. Zudem vereinfacht und beschleunigt eine solche Entwicklungsumgebung den Entwicklungsvorgang und hilft, Fehler zu vermeiden und Komplexitäten zu beherrschen, wie es mit den rudimentäten Möglichkeiten der alten Arbeitsweise kaum mehr möglich wäre. Eine Forderung, der sich heute jede Software stellen muss, um langfristig am Markt zu überleben und die auf diesem Wege erfüllt wird. Zum Beispiel sind die Debugmöglichkeiten der integrierten Softwäre direkt auf dem Zielchip und deren umgebender Elektronik nicht mehr ohne Verzahnung von Compiler, Linker, Editor, Assembler und Loader bereitzustellen, z.B. deshalb, weil der Debugger nicht nur vorwärts, sondern auch rückwärts arbeiten muss. Von den Anforderungen für Simulation und Analyse möchte ich hier gar nicht sprechen. Word hat auch kaum mehr etwas mit dem uralten Volkswriter zu tun, der noch auf eine Diskette passte. Mit "nicht organisieren können", hat das nichts zu tun. Ich empfehle Dir dringend, Dich mit den neuen Möglichkeiten auseinanderzusetzen. Dannach wirst Du sehen, dass "existierende Makefiles" für die heutigen Anforderungen an Embedded Produkte ungefähr soviel wert sind, wie ein Handkeil im mechanischen Uhrenbau. Dass das Ganze im Artikel, nicht einer Enzyklopädie entsprechend dargestellt ist, steht ausser Frage. Dabei unterscheidet er sich aber kaum vom restlichen Artikel. Eigentlich müsste der komplett neugeschrieben werden, was aber, wenn es der Wirklichkeit und einer Enzyklopädie gerecht werden sollte, einen Aufwand von mehrer Tagen bis Wochen kosten dürfte. -- 84.132.89.9 11:08, 27. Nov. 2006 (CET)

Die Links sind irgendwie seltsam formatiert und sollten ansich auch mal ein wenig sortiert/aufgeräumt werden.

So. Genug gemeckert. --ChrisHuebsch 15:01, 7. Okt 2006 (CEST)

Bin gern bereit hier aktiv mitzuarbeiten, leider fehlt mir jedoch oft die Zeit für größere Aktionen. --NobbiP 19:59, 21. Nov. 2006 (CET)

Leider dito. Allein die Diskussion hier zeigt, wie wenig über die Neuentwicklungen der letzten Jahre bekannt ist. Daher ist das Neuschreiben dieses Artikels wäre wohl eine Aufgabe, in die man Wochen verwenden müsste. Man müsste ein halbes Lehrbuch schreiben. -- 84.132.104.163 23:28, 21. Nov. 2006 (CET)
Lehrbücher gibt es nebenan bei der Wikiversity. Hier geht es um langfristiges Wissen. Es muss nicht jedes Detail aufgeschrieben sein. --ChrisHuebsch 13:33, 22. Nov. 2006 (CET)
Lehrbücher nicht nach Wikiversity, sondern bitte nach Wikibooks.
-- MichaelFrey 18:10, 22. Nov. 2006 (CET)
Verfolge die Diskussion hier mit und möchte nochmal mein Angebot der aktiven Mitarbeit geben. Auf Grund meiner beruflichen Tätigkeit im Großhandelsvertrieb dieser Dinger kenn ich mich auch mit den neusten PICs/dsPICs recht gut aus. Vielleicht sollten wir diese Seite wirklich neu angehen, dann aber bitte Stück für Stück bzw. Abschnitt für Abschnitt. Hat einer'ne brauchbare Idee (anderes Lemma?) für eine vernünftige Struktur um das Kuddelmuddel hier aufzulösen? Würde dann gern einzelne Abschnitte oder auch Fotos, z.B. von neuesten PIC24/(dsPIC33 beisteuern können (obwohl die schwarzen Käfer ja äußerlich eh' immer gleich sind...). mfg --NobbiP 17:58, 27. Nov. 2006 (CET) , PS auch wenn meine Diskuseite noch leer ist, anmerkungen gern auch dort. Nobbi
-->Hier geht es um langfristiges Wissen. Es muss nicht jedes Detail aufgeschrieben sein. ... Kommt drauf an, was man unter Detail versteht. Langfristiges Wissen ist einer der Grundsätze in Wikipedia. Die Grundsätze von Wikipedia sind aber keine Dogmen, sondern müssen immer im Lichte der speziell in einem Artikel behandelten Materie gesehen werden. Nun ist es aber gerade in technischen Fachgebieten so, dass das Wissen nur recht kurzlebig ist. Gerade im Bereich der Microcontroller hat sich der Mainstream des Angebots und die Arbeitsweise gegenüber von vor 10 Jahren grundsätzlich geändert (z.B. das Umsteigen auf Flash Speicher), während sich in den 10 Jahren davor nur relativ wenig getan hat. Frische Studenten von der Uni kennen mitunter kein Makefile mehr, weil sie es nicht mehr brauchen. Signalcontroller haben zumindest in der Masse erst ein Alter von sechs/sieben Jahren erreicht. Heute sind sie in jedem Handy drin und machen diese so klein. Viele Dinge, wie der USB Stick und die digitalen Fotoapparate dürften gar keinen Artikel haben, wenn man eine solche Zeitspanne vorraussetzt. Selbst die Beschreibungen von popeligen Straßen in Wikipedia sind jetzt schon auf dem neuesten Stand. Zum Beispiel war die Bundesautobahn 31 vor 10 Jahren kaum sinnvoll zu befahren. Jetzt ist sie fertig.-- 84.132.89.9 15:58, 27. Nov. 2006 (CET)

Ich arbeite mit dem PIC18F4685 welcher also zur PIC18 Familie gehört, allerdings besitzt er die Harvard-Architektur welcher seinen Speicher in Programm und Datenspeicher teilt. Im Wiki steht es anders. nachzulesen in dessen manual.

Ich denke das stand und steht auch so dort, lediglich bei der Programm-Speicheraufteilung könnte es ein Missverständnis gegeben haben - habe das jetzt etwas klarer formuliert (hoffentlich). NobbiP 17:18, 20. Jan. 2009 (CET)

Unklarheit bei Grundsätzliches -> dsPIC30: Motion-Controlfamilie, mit Interface für Quadratur Encoder, spezieller Motor Control PWM, CAN usw. 12 KB bis 144 KB Flash, 28 bis 80 Pins. Quadratur Encoder war von mir gesucht und verweist auf Inkrementalgeber, dort ist dazu aber nichts zu finden. Ist es nun dasselbe? Wenn ja, könnte es dort ja erwähnt werden oder hier warum dorthin verwiesen wird, danke.

Befehlssatz pro/contra

Letzter Kommentar: vor 17 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

Habe damit begonnen den Artikel komplett zu überarbeiten, was mir dabei nicht so gefällt ist der Abschnitt mit dem PICmicro#Befehlssatz, würde diesen gern komplett herausnehmen, da er den Artikel komplett sprengt, wenn er auch die anderen Familien berücksichtigen soll. Bitte um Kommentare speziell zu diesem Abschnitt aber auch gern Kommentare, Hinweise, Ergänzungswünsche zu den Anderen --NobbiP 14:50, 9. Dez. 2006 (CET)

Super Arbeit, Coole Bilder :-)
Mal ein Tipp/Vorschlag:
Wenn du mehr über PICs schreiben willst, als in diesen Artikel passt, komm auf Wikibooks und eröffne ein Buch.
Ich würde auch als Co-Autor mit Arbeiten (Fotos und Doku von kleineren Projekten, beim erklären von Grundlagen bin ich nicht so gut).
-- MichaelFrey 19:41, 9. Dez. 2006 (CET)
Hi Michael, für ein Buch reicht es bei mir sicher nicht, auch die Zeit langt dafür nicht. Wenn du aber hier noch ein bisschen mithelfen willst? Was sagst du zu dem Abschnitt Befehlssatz? (s.o.) Was muss noch ergänzt werden? --NobbiP 19:53, 9. Dez. 2006 (CET) P.S. habe auch auf Wikibooks einen Account, aber bisher nur wenig dort gemacht, kleinere Ergänzungen etc. Wenn jemand anderes dort ein PIC oder anderes Controller Buch schreiben will, würde ich mich gern hin und wieder einbringen. --NobbiP 19:56, 9. Dez. 2006 (CET)

ausgelagerte Bereiche

Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Folgende Bereich habe ich aus dem Artikel herausgenommen, die würden besser in ein Projekt bei Wikibooks passen, insbesondere wenn man auf die verschiedenen Familien Rücksicht nehmen möchte sprengen sie den Artikel. Hab sie aber mal hier gerettet, falls der Widerspruch zu groß oder andere Ansätze darauf zurückgreifen möchten. --NobbiP 18:49, 14. Dez. 2006 (CET)

Interrupt

Jeder Interrupt kommuniziert mit der Software über zwei Bits, von denen eines verwendet wird, um den Interrupt zu aktivieren (z. B. T0IE für Timer 0 – Interrupt Enable). Das andere Bit wird von der Hardware auf 1 gesetzt, wenn der Interrupt ausgelöst wurde (z. B. T0IF – Interrupt Flag). Es muss rückgesetzt werden, bevor der Rücksprung aus der Interruptroutine erfolgt. Die Bits für die Standard-Interrupts liegen im Register INTCON. Die Aktivierungsbits für erweiterte Interrupts liegen SFR PIE (Peripheral Interrupt Enable), die Flag-Bits in PIR. Weitere wichtige Bits sind GIE (Global Interrupt Enable) und PEIE (Peripheral Interrupt Enable), wobei ersteres wenn rückgesetzt alle Interrupts blockiert und letzteres nur die erweiterten.

Wird ein Interrupt ausgelöst, dann wird zunächst GIE rückgesetzt, damit kein zweiter Interrupt die Interruptroutine unterbricht. Danach springt das Programm auf den Interruptvektor. Nun kann die Software durch abfragen der einzelnen Flag-Bits herausfinden, welcher Interrupt ausgelöst wurde (wobei z. B. durch die Abfolge der Abfrage eine Prioritätssteuerung realisiert werden kann) und entsprechend reagieren. Durch den Rücksprungbefehl RETFIE wird GIE wieder gesetzt. Ist nun noch ein Flag gesetzt, dann wird der Interruptvektor wieder angesprungen.

Befehlssatz

Wie schon oben erwähnt handelt es sich bei PICs um RISC-Prozessoren, sie verfügen also über einen sehr kleinen, aber effektiven Befehlssatz. Ein Befehl bzw. ein Befehlswort im Programmspeicher, dies sind zwischen 12 und 24 Bit (siehe oben), entspricht einem kompletten Befehl inklusive Argumenten, jeder Befehl außer Sprungbefehle wird innerhalb eines Zyklus abgearbeitet. Ausnahmen davon gibt es nur bei der Enhanced Familie mit 5 möglichen Befehlen, die aus zwei Wörtern bestehen können und bei den 16 Bit Controllern, welche aber auch nur wenige 2-Wort-Befehle haben. Die ALU bei den 8 Bit PICs ist eine Ein-Adress-Maschine. Bei Befehlen, die zwei Argumente benötigen, ist eines immer das W (Work)-Register. Aber keine Regel ohne Ausnahme(n), die Enhanced PICs können auch Datentransfer von einer Speicherzelle zu einer anderen Speicherzelle (MOVFF adr1,adr2 ; adrx=RAM oder SFR, benötigt 2 Worte und 2 Zyklen).

Bei den 16 Bit Controllern gibt es einen Satz von 16 x 16 Bit Registern, die alle für die meisten Befehle zur Verfügung stehen, jedoch haben einige davon auch Sonderaufgaben, z. B. für den Stack oder für DSP-Befehle.


Das Befehlsformat lässt sich nach den Argumenten in drei Gruppen einteilen.

Befehle für Byte-orientierte Register

Es handelt sich hier um Befehle, die Werte des Datenspeichers ver- oder bearbeiten. Sie erhalten als Argumente eine 7-Bit-Zahl f, die die Adresse des Registers angibt, und ein Bit d, das angibt, wo das Resultat der Operation hingespeichert werden soll. d=0 bedeutet hier, das Ergebnis soll in das W-Register gespeichert werden, bei d=1 wird das Ergebnis in das durch f adressierte Register geschrieben. Beispiele:

  • ADDWF f,d (Addition von f und W)
  • SUBWF f,d (Subtraktion W von f)
  • ANDWF f,d (logisches UND)
  • IORWF f,d (logisches ODER)
  • MOVF f,d (Move-Befehl kopiert f entweder auf W oder auf sich selbst)
  • MOVWF f (kopiert den Inhalt von W auf f)

Der Sinn von MOVF f,1 besteht darin, dass MOVF das Zero-Bit setzt. Siehe später.

Befehle für Bit-orientierte Register

Diese Befehle sprechen gezielt einzelne Bits an. Sie sind auf den gesamten Datenspeicher anwendbar. Als Argumente werden die 7-Bit-Adresse des Registers f im Datenspeicher und die Stelle des Bits b (3 Bit) in diesem.

  • BCF f,b (Bit Clear File ... Bit löschen)
  • BSF f,b (Bit Set File ... Bit setzen)
  • BTFSC f,b (Bit Test File and Skip if Clear)
  • BTFSS f,b (Bit Test File and Skip if Set)

Bei den letzten beiden Befehlen handelt es sich um die hauptsächlich verwendeten Verzweigungsbefehle. Skip bedeutet, dass wenn die Bedingung erfüllt ist, der nächste Befehl übersprungen werden soll. Die anderen Verzweigungsbefehle des PIC sind DECFSZ (decrement file and skip if zero) und INCFSZ (increment file and skip if zero). Beide sind für Zählschleifen gedacht.

Befehle für literale Werte

Diese Befehle sind durch ein L im Namen gekennzeichnet. Sie benötigen als Argument nur den konstanten Wert, der zweite Operand ist das W-Register. Beispiele:

  • ADDLW k (Addition einer Konstanten zu W)
  • SUBLW k (Subtraktion von W von einer Konstanten)
  • ANDLW k (UND-Verknüpfung einer Konstanten mit W)
  • MOVLW k (eine Konstante ins W Register schreiben)
  • XORLW k (EXOR-Verknüpfung von W mit einer Konstanten)
  • RETLW k (RETurn with literal in W)

Kontrollbefehle

Hier noch ein paar Befehle, die den Programmfluss koordinieren bzw. andere Features der CPU bedienen.

  • CALL k
  • GOTO k

Dies sind der Unterprogrammaufruf bzw. der Jump-Befehl. Die übergebene Konstante ist die 11-Bit Zieladresse in der Page.

  • RETFIE
  • RETURN
  • RETLW k

Hierbei handelt es sich um die Rückkehrbefehle für Interrupt und Unterprogramme.

RETLW wird auch für Look-Up-Tables eingesetzt.

  • SLEEP ... Schaltet den Prozessor in den Schlafmodus. Hierbei wird der Stromverbrauch auf ein Minimum reduziert. Er wird durch einen Interrupt wieder erweckt.
  • CLRWDT ... Setzt den Watchdog-Timer zurück.
  • TRIS ... bei älteren PICs zu konfiguration der I/O Pins.

Anwendungen des PICs

Letzter Kommentar: vor 17 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt

Es wäre interessant zu wissen, in welchen existierenden populären Produkten ein PIC beispielsweise Anwendung findet. Ich meine damit keine allgemeinen Anwendungsbeschreibungen, denn diese sind unerschöpflich, sondern konkrete Produkte z.B. Handys, Automobilsteuerung oder Spielkonsole dieser oder jener Firma, oder in Bank/Creditcards etc. -- 84.132.85.216 01:19, 5. Mär. 2007 (CET)

Hallo IP, die Zahl der verschiedenen Anwendungen ist tatsächlich unerschöpflich, mir sind selbst unzählige bekannt. Die Antwort nach deiner Frage ist aber dennoch nicht lösbar. Es gibt fast keine Firma, die sich selbst gern als Anwender bzw. Verwender eines bestimmten Bauteils für eine konkrete Anwendung genannt sehen möchte. Stichworte Firmen-Know-How, Wettbewerbsvor- bzw. -Nachteile usw. --NobbiP 08:26, 5. Mär. 2007 (CET)
Es gibt doch Chip Karten mit PIC drin?
Elektor hat von einiger dazu einen Artikel Veröffentlicht.
Refernzenzen: [1] und [2]
Playstation (en:PIC microcontroller achso: http://dogbreath.de/PS1/ChipRemoval/Chip.html doch nichts ...)
BASIC Stamp, en:PICAXE, en:OOPic.
Immerhin ein Ansatz.
-- MichaelFrey 19:42, 5. Mär. 2007 (CET)


[3] sieht ganz Interresant aus.
[4] nee, nicht das wahre.
[5] könnte was sein.
[6] BMW klingt vielversprechend.
[7]
Bei gelegenheit versuch ich einen Absatz daraus zu machen.
-- MichaelFrey 19:24, 6. Mär. 2007 (CET)
[8] [9] -- MichaelFrey 07:43, 7. Mär. 2007 (CET)

Wozu braucht man einen Bootloader?

Letzter Kommentar: vor 17 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

Mir will es absolut nicht in den Kopf, wozu man einen Bootloader bei den PICs braucht. Lese ich den Artikel Boot-Loader, so heißt es da, dass damit die Firmware geladen wird. Aber dazu hat man doch einen ICD2. Wozu braucht man dann noch einen Bootloader? -- 84.132.62.174 03:00, 11. Jun. 2007 (CEST)

Spontan:
Pickit 2 (ebenfalls ein Programmiergerät von Microchip) sind eine PIC Schaltung.
Um die Firmware des Programmiergerätes zu Aktualisieren (passiert relativ oft) hat es (wahrscheinlich) einen Bootloader ein Programmiert.
(Wäre ja zum Totlachen, wenn man für ein Update der Firmware des Programmiergerätes ein weiteres Programmiergerät brauchte ... ;-)
Andere Anwendungen sind Geräte die zu Kunden geht. Anstelle alle alten Geräte zurück zu rufen kann jeder Kunde das sein Gerät selbst z.B. mit einer Speicherkarte oder per USB aktuallisieren. USB/Speicherkarte als Update Pfad macht besonders dann sinn, wenn in der Anwendung (z.B. Messwertloger) diese Schnittstellen sowieso vorhanden sind.
Natürlich stellen diese Updates auch ein Risiko dar, das jemand das Programm deasembliert, aber Risiko und Aufwand muss man wie immer gegeneinander Abwägen.
Leider finde ich im Artikel den Zusammenhang nicht, so das ich nicht weiss ob die Antwort passt.
-- MichaelFrey 14:24, 11. Jun. 2007 (CEST)

Super. Ich habe es endlich verstanden. Vielen Dank :-) -- 84.132.107.252 19:16, 14. Jun. 2007 (CEST)

-- Pic16fan

Es gibt noch einen Grund für Bootloader: Sie sind einfach viel flotter! Habe gerade wieder ein Projekt entwickelt und mich bewußt für den 18F4550 mit USB entschieden, weil ich den noch nicht probiert hatte bisher UND weil er eben USB hat. Mittels Bootloader kommt die Firmware ungefähr um den Faktor 5-10mal schneller rein, was kleine Änderungen (so sie z.b. bei der Erstanlage von Libraries für Peripherie sehr oft geschehen) extrem beschleunigt. Auch, wie schon gesagt, läßt sich damit insbesondere bei den USB-Varianten super "In-Field" vom Kunden updaten, einfach nen Programm mit Firmware geschickt und ab damit. Das aber nur am Rande ... (22:29, 5. Jan. 2010 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Wozu braucht man ein RTOS?

Letzter Kommentar: vor 17 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt

RTOS ist ein Betriebssytem für PICs. Liest man den Artikel RTOS hier auf Wikipedia, dann wird nicht klar wozu es dienen soll. Wenn ich eine Anwendung für den PIC entwickle, dann schreibe ich ein Programm in Assembler oder in C, compiliere es und schreibe es in den PIC. Das war es. Wozu in aller Welt brauche ich jetzt ein Betriebssystem? -- 84.132.62.174 03:06, 11. Jun. 2007 (CEST)

Du meinst konkrett FreeRTOS?
Mir fällt gleich auf, das das relativ grosse und Leistungsstarke PICs sind.
Ich Persönlich habe sowas noch nie verwendet (nur kleine PIC und Asembler verwende ich), kann mir aber ein paar Dinge vorstellen die ein OS machen könnte:
  • Portabilität
  • kein "Rum schlagen" mit "irgendwelchen" Timern
  • Multi Tasking (also Umschalten zwischen Programmteilen)
  • Verwaltung von Ressourcen (2 Subroutinen wohlen gleichzeitig das EPROM beschreiben)
  • Neustarten Toder Tasks (ich weiss das es dafür auch den Watchdog direkt in der Hardware gibt)
Vielleicht bringt dich das weiter.
Ansonsten geht gehört diese Frage eher zu FreeRTOS.
-- MichaelFrey 14:36, 11. Jun. 2007 (CEST)

Vielen Dank. Aber so richtig klar ist es mir immer noch nicht, wie das Programmieren eines PICs mit einem Betriebssystem abläuft - im Unterschied zur Standardprogrammierung. Ich bin mal Deinem Rat gefolgt und habe diesselbe Frage bei FreeRTOS gestellt. -- 84.132.107.252 19:20, 14. Jun. 2007 (CEST)

PIC-"Familien"

Letzter Kommentar: vor 16 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt

Unter "Grundsätzliches" steht eine Bemerkung zu den PIC-Familien: "... die ‚Familien‘ PIC10Fxx, PIC12F(C)xx und PIC16F(C)xxx voneinander unterschieden. Genau genommen sind dies aber keine eigenständigen Familien, sondern nur durch die Anzahl ihrer Pins voneinander abweichende Gehäusevarianten ..." Meines Wissens nach ist das aber ein bischen anders. Die hier angesprochenen "Familien" haben zwar alle einen 8-Bit-RISC-Kern, aber Sie unterscheiden sich voneinander als "Familie" doch nicht durch die Pinanzahl und Gehäuse!? Steht das 10/12/16 nicht für die Breite der Befehlsworte? So habe ich das jedenfalls im Kopf. Bitte um Anmerkungen oder Korrektur erfahrener PIC-Anwender. --88.66.133.20 23:22, 18. Nov. 2007 (CET)

Diskussionspunkt nach unten verschoben NobbiP 11:00, 19. Nov. 2007 (CET)
Das genau ist der Grund, warum ich das in dem Abschnitt erwähnt habe, direkt dahinter stehen die "echten Familien", bzw. deren Unterschiede. Ein PIC10 gehört also zu den Baseline wie auch PIC16F54 usw. Grüßle NobbiP 11:00, 19. Nov. 2007 (CET)

Freier Compiler

Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt

Ich habe eine Frage: Was ist an einem Compiler frei, wenn er nur auf einer Seite heruntergeladen und dann nur von Studenten und Privatpersonen genutzt werden kann? Bitte, kann jemand den Artikel klarer formulieren? Das sollte jetzt nicht zu hart tönen, viel mir aber beim durchlesen auf. Christian Riggenbach 23:04, 8. Jul. 2008 (CET)

Frei steht hier zuersteinmal für "Kostenfrei", es gibt, wie die große Anzahl von verfügbaren Compilern eben auch verschiedene Modelle:
  • Microchip C18, eigene Entwicklung, nur Kostenfrei, nach Ablauf der Testzeit von 3 Monaten werden die Optimierungen abgeschaltet, der Compiler kann aber ohne die Code-/Laufzeit-Optimierungen noch voll weiter genutzt werden
  • Microchip C30 und C32, auf gcc basierend, daher ist der Sourcecode auch frei bei Microchip (via GCC Lizenzmodell auch von woanders?) herunterladbar, für die fertige Runtimeversion wie C18 (3 Monate Kostenfrei, nach Ablauf...)
  • gcc steht ebenfalls, auch unabhängig von Microchip, zur Verfügung
  • diverse Lizensierungen, z.B. Shareware, lizenzbewehrte "Freeware" usw.
  • diverse Drittanbieter, reine Kommerzversionen, die a) zum kostenfreien Testen nur kleine Codemengen erzeugen können oder b) sich nach unterschiedlich kurzer Zeit (als voll funktionsfähige Compiler) nicht mehr benutzen lassen. Danach muß bei beiden Testmodellen eine Vollversion erworben werden. (IAR, Hi-Tech, Knudsen, CCS usw.)
Hilft dir das etwas ? Grüßle NobbiP 23:36, 8. Jul. 2008 (CEST)

Hobby und Privatverwendung

Letzter Kommentar: vor 14 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Der Abschnitt liest sich wie Werbung, wenn jemand etwas Zeit erübrigen kann währen auch einige Formulierungen wie "einige" (= welche) etc. mal zu verifizieren. -- A1000 10:46, 23. Jul. 2010 (CEST)

Letzter Kommentar: vor 14 Jahren7 Kommentare1 Person ist an der Diskussion beteiligt

Gemäss WP:WEB sind die meisten Weblinks ohnehin unzulässig, aber ich begründe einzeln hier die Streichungen: -- MichaelFrey 19:49, 6. Sep. 2010 (CEST)

Commons: PIC microcontrollers – Sammlung von Bildern, Videos und Audiodateien
PIC-Assembler-Befehle
Informationen rund um den PIC (Tutorials, Projekte, Datenblätter, Wiki usw.)
PIC-Portal mit vielen Informationen und Selbstbau-Projekten
Freie IDE für Mikrocontrollerentwicklung unter Linux
Sicherheit des Kopierschutzes von PIC und anderen Mikrocontrollern:

Tragbare Computer-Code-Lernhilfe CODEBUG

Letzter Kommentar: vor 8 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

Laut

http://codebugforum.co.uk/viewtopic.php?f=12&t=30&p=94&hilit=Hardware+spec#p94

benutzt die in der Absatz-Überschrift genannte Lernhilfe, siehe z.B.

http://www.pollin.de/shop/dt/NzAzNzkyOTk-/Bausaetze_Module/Entwicklerboards/Sonstige_Boards/Tragbare_Computer_Code_Lernhilfe_CODEBUG.html

einen "18F25K50". Das steht auch so auf dem IC der Lernhilfe.

Laut

https://en.wikipedia.org/wiki/Micro_Bit

ist diese Lernhilfe aus einem "computer education system" der BBC hervor gegangen.

MaVoe (Diskussion) 22:03, 26. Jan. 2016 (CET)

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:PICmicro/Archiv&oldid=156621103“