Hallo! Ich möchte dieses Projekt ausführen: Ein Temp-Geber gibt die Temp in einem PWM-Signal aus. Das soll von einem MC gelesen, bearbeit( umgerechnet) und dann auf 3 LED-Anzeigen (Temp von 0°C bis 120°C) ausgegeben werden. Mit PICs 16F84 habe ich vor Jahren erfolgreich gearbeitet, daher möchte ich bei PICs bleiben. Früher war alles in Assembler geschrieben, nun möchte ich doch auf eine Hochsprache umsteigen. Drei Fragen: 1) Reicht ein 16-bit-PIC aus oder muss es ein 32-Bitter werden? 2) Läßt sich dieses Projekt auch mit dieser Arduino-Prog-Sprache umsetzen? Hintergrund: Es gibt gerade so Angebote über ein Microchip "chipKIT-Uno-32-Entwicklungsboard", das eben diese Ard.-Prog.-Spr. unterstützt. 3) Wenn es denn doch C sein sollte: Was könnte mir bei der Einführung da weiterhelfen? Meine English-Kenntnisse reichen nicht, um die engl.-sprachigen You-Tube-Videos ausreichend zu verstehen. Beim Lesen könnte es reichen, aber falls es einen deutschen Text/ ein Buch in Deutsch für C-Anfänger geben sollte, das auf MicroController-Anwendungen ziehlt, und nicht auf PC-C-Programmierung, dann bitte ich um Tipps. Grüße, wilhelmT
Für die Aufgabe kann so gut wie jeder PIC oder AVR genommen werden. Nehm den, an den du am besten rankommst. Für die Programmierung würde ich mir ein Buch besorgen ohne Bezug auf MC. Der Rest ist im Datenblatt oder her oben in den zig Tuts zu finden.
Be Ti schrieb: > 2) Läßt sich dieses Projekt auch mit dieser Arduino-Prog-Sprache > umsetzen? Hintergrund: Allemal, du willst doch nur alle Sekunde oder meinetwegen 5x pro Sekunde eine Temperatur erfassen und auf ein 3 stelliges Led Sieben-Segment Display ausgeben. Oder wie ist der Satz zu verstehen: Be Ti schrieb: > und dann auf 3 LED-Anzeigen (Temp von 0°C bis 120°C) > ausgegeben werden. Da langweilt sich jeder 8 Bit µC zu Tode. Es reicht in einfacher Arduino Uno. Wenn du natürlich mit den größeren Boards experimentieren möchtest, geht das auch. Zum Ansteuern der Led Sieben-Segment Anzeigen suche nach Multiplexing hier bei den Artikeln und Grundlagenartikeln, wenn dunichts findest melde dich nochmal.
Stefan S. schrieb: > Für die Aufgabe kann so gut wie jeder PIC oder AVR genommen werden. Es wäre mir neu, dass man 8-bit-MCs in C programmieren kann/ sollte. > Nehm den, an den du am besten rankommst. Meine Grundfragen waren nicht darauf gerichtet, Bezugsquellen zu eruieren. > Für die Programmierung würde ich mir ein Buch besorgen ohne Bezug auf > MC. Dieser "Tipp" grenzt vermutlich an groben Unfug. Da sagt Sprut das genaue Gegenteil, und der ist eine anerkannte Größe. > Der Rest ist im Datenblatt Au man, ein C-Anfänger schaut also ins Datenblatt und beginnt mit dem C-Schreiben! > oder her oben in den zig Tuts zu finden. Es soll Tutorials geben? Welche Überraschung! Geht "Beratung" auch konkret oder nur in so unverbindlich allgemeinen "Tipps" wie bei dir? Nach deinen Nichtssagenden Hinweisen bin ich nur älter, aber um keine einzige Hilfestellung klüger geworden. Gruß, wilhelmT
Arduino Sprache auf Pic32 -- da wirst du wohl weder deutsche Literatur noch kompetente Hilfe in diesem Forum finden. Und wenn C auf Pic dann besser 18F. Die Abweichungen zwischen normalem C, und dem was sich auf so einem Mikrocontroller machen lässt, sind nicht ganz so groß. Und die Englisch-Kenntnisse werden durch das Youtube-Schauen immer besser.
Der Pic16F1827 ist der moderne Nachfolger des 16F84. Man sollte ihn in C programmieren, XC8 Compiler. Ein Beispielprojekt eines Temp.-Sensors mit PWM Signal (des SMT160-30) findet sich im Internet. Dort realisiert mit einem PIC18F2550 da noch anderes dort angeschlossen ist. Siehe http://www.technik.dhbw-ravensburg.de/~lau/datenlogger.html Programm dort in PDF verlinkt. Wenn ganz neu mit PIC begonnen wird, eignet sich zum Einstieg das ORGINAL PicKit3 bzw. gleich das "PicKit3 Debug Express" (das ist die Platine DM164130-9 dabei). Siehe http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=dm164130-9 Beispielprogramme dazu hier http://ww1.microchip.com/downloads/en/DeviceDoc/PICkit3_Starter_Kit.zip Gruss
Udo Schmitt schrieb: > Allemal, du willst doch nur alle Sekunde oder meinetwegen 5x pro Sekunde > eine Temperatur erfassen und auf ein 3 stelliges Led Sieben-Segment > Display ausgeben. Nein, zeitkritisch gehts da nicht ab. Selbst 10 Sekunden Wartezeit bis zur nächsten Ausgabe wäre kein Prob > Es reicht in einfacher Arduino Uno. Danke für deine Einschätzung. Hätte ich nicht gedacht. Meine Annahme war, dass mehrfache Umrechnungen nötig wären, und dass die in 8bit nicht oder nur mit für Anfänger unübersichtlichem Gestrampel zu erledigen sein würden. Es bleibt für mich der Wunsch, nach Möglichkeit einen Pic zu nehmen. Um aber in den Genuss dieser Ardunino-Uno-Plattform zu kommen, scheint es bei Microsoft nichts Kleineres als einen 32-Bitter zu geben. Anfängerfrage: Könnte ich mit einem einfachen Arduino Uno - so wie du es vorgeschlagen hattest - beginnen, und das Programm später in C auf einen anderen PIC übertragen? Grüße, wilhelmT
Be Ti schrieb: > Es wäre mir neu, dass man 8-bit-MCs in C programmieren kann/ sollte. Das ist schon so seit mindestens 10 Jahren. Cross Compiler gab es auch schon vor 30 Jahren. Be Ti schrieb: >> Für die Programmierung würde ich mir ein Buch besorgen ohne Bezug auf >> MC. > Dieser "Tipp" grenzt vermutlich an groben Unfug. Definitiv nicht. Wenn du C auf einem µC lernen willst machst du dir selbst das Leben schwer. Auf einem PC hast du einfache Ein und Ausgabe, eine IDE die dir alles einfacher macht und einen Leistungsfähigen Debugger, mit dem du siehst was im Programm passiert. Da kannst du 10mal schneller lernen. C ist fast unabhängig vom verwendeten Prozessor. Aber wie du möchtest... Be Ti schrieb: > s soll Tutorials geben? Welche Überraschung! Geht "Beratung" auch > konkret oder nur in so unverbindlich allgemeinen "Tipps" wie bei dir? > Nach deinen Nichtssagenden Hinweisen bin ich nur älter, aber um keine > einzige Hilfestellung klüger geworden. Irgendwie wie der Witz mit dem Manager im Ballon :-( Wenn du konkret eine Info willst, nimm den Kernighan Ritchie, der ist nie verkehrt.
Be Ti schrieb: > Hallo! Ich möchte dieses Projekt ausführen: Ein Temp-Geber gibt die Temp > in einem PWM-Signal aus. Das soll von einem MC gelesen, bearbeit( > umgerechnet) und dann auf 3 LED-Anzeigen (Temp von 0°C bis 120°C) > ausgegeben werden. Ein PWM-Signal zu erfassen kann u.U. etwas aufwendiger sein, insbesondere kann es erfordern das Capture Feature eines Timers zu benutzen. Kommt drauf an, wie hoch die Frequenz ist und wie genau man das machen möchte. Evtl. ist es einfacher, die PWM zu Gleichspannung zu glätten und in den ADC zu schieben. > Mit PICs 16F84 habe ich vor Jahren erfolgreich > gearbeitet, daher möchte ich bei PICs bleiben. Früher war alles in > Assembler geschrieben, nun möchte ich doch auf eine Hochsprache > umsteigen. Wenn du von Assembler auf C umsteigst, dann bringt es eher wenig, die Plattform beizubehalten. Denn eine der Stärken von C ist ja die Plattformunabhängigkeit. > Drei Fragen: > 1) Reicht ein 16-bit-PIC aus oder muss es ein 32-Bitter werden? Auch ein 8-Bitter reicht. C Compiler gibts dafür auch. > 2) Läßt sich dieses Projekt auch mit dieser Arduino-Prog-Sprache > umsetzen? Hintergrund: Es gibt gerade so Angebote über ein Microchip > "chipKIT-Uno-32-Entwicklungsboard", das eben diese Ard.-Prog.-Spr. > unterstützt. Arduino auf PIC Basis wäre mir neu. Ansonsten geht das sicher. > 3) Wenn es denn doch C sein sollte: Was könnte mir bei der Einführung da > weiterhelfen? Meine English-Kenntnisse reichen nicht, um die > engl.-sprachigen You-Tube-Videos ausreichend zu verstehen. Das Handbuch zur verwendeten IDE. Am besten lernt man mit einem Tutorial.
Be Ti schrieb: > Anfängerfrage: Könnte ich mit einem einfachen Arduino Uno - so wie du es > vorgeschlagen hattest - beginnen, und das Programm später in C auf einen > anderen PIC übertragen? Du programmierst bei Arduino soweit ich mir das angesehen habe so beinahe C. Ich weiss leider nicht inwieweit diese Arduinosprache unabhängig vom verwendeten Arduino ist. Reine C Programmierung ist etwas anspruchvoller, da die Arduino Bibliothek alles verbirgt was µC spezifisch ist. Nachtrag: Um Englisch wirst du nicht herumkommen, im Endeffekt braucht man immer irgendwann das Datenblatt.
:
Bearbeitet durch User
Das alles ist schon 20 Stufen zu hoch.... Fang mal mit ner LED an zu blinken! Dann meldets du dich in einigen Wochen - also 2015 - nochmal obs geht! Dann sehen wir weiter.... Klausi
Die verwendetet Teile aus der Arduino Library nach Pic übertragen wird so aufwendig - komplett neu schreiben ist einfacher.
Noch einer schrieb: > Arduino Sprache auf Pic32 -- da wirst du wohl weder deutsche Literatur > noch kompetente Hilfe in diesem Forum finden. Hab' vor einigen Tagen von Conrad-Electronic eine Werbemail bekommen, die mich angefixt hat. Darin wird angeboten: - ein MIcrochip "chipKIT-Uno32-Entwicklungsboard" - ein Buch "Schnellstart mit dem " ...." aus dem Conrad-Verlag Aber wie du schon sagst, ich fürchte, mich damit auf eine (fast) einsame Insel zu begeben, und der Einzige zu sein, der.... > Und die Englisch-Kenntnisse werden durch das Youtube-Schauen immer > besser. Bei deinem Statement mußte ich erst lachen. Du kennst meine E-Kenntnisse nicht. Habe heute ein solches Video geschaut, und weiß auch, dass der Vortragende PICs in hohen Tönen gelobt hat, aber ein mindestens 6-malige Wiederholung wäre nötig, und bei seinem Slang evtl. noch mehr. Das ist einfach eine Qual für mich. Und dann evtl. noch ein engl. Vortrag über C.....? Mir fehlt der rechte Glaube, leider! Grüße, wilhelmT
Udo Schmitt schrieb: > Be Ti schrieb: >> Es wäre mir neu, dass man 8-bit-MCs in C programmieren kann/ sollte. > > Das ist schon so seit mindestens 10 Jahren. Mein letzter MC-Einsatz war vor 16 Jahren. > Wenn du C auf einem µC lernen willst machst du dir > selbst das Leben schwer. Auf einem PC hast du einfache Ein und Ausgabe, > eine IDE...... Das ist wohl ein Mißverständnis. Ich bezog mich auf Sprut, der sagte, dass man als C-Anfänger nicht allgemeine Bücher über C-Programmierung für PCs nehmen sollte, sondern irgendwas, was sich speziell auf Anwendungen am MC spezialisiert ist. > Irgendwie wie der Witz mit dem Manager im Ballon :-( > Wenn du konkret eine Info willst, nimm den Kernighan Ritchie, der ist > nie verkehrt. Ich würde gerne mitlachen. Muss ein Insider-Speach sein. Gruß, wilhemT
Klausi schrieb: > Das alles ist schon 20 Stufen zu hoch.... > Fang mal mit ner LED an zu blinken! > Dann meldets du dich in einigen Wochen - also 2015 - nochmal obs geht! Da hast du meine Eingangsdarstellung nicht verstanden. Ich habe in Assembler eine Haussteuerung erstellt, in welcher 12 PICs sich gemeinsam u.a. um die Rolladensteuerung verdient machen. Alles selbst angefertigt, die Hardware, das Assembl.-Prog., auch den Bus und sein Protokoll selbst erfunden. Nur von C habe ich keine Ahnung. Gruß, wilhemT
Für C sollte man die PIC16 und kleiner eher meiden, da hat der Compiler doch schon arge Einschränkungen, etwa durch den sehr kleinen Stack und zerstückeltes "RAM". Arduino ist halt C++ mit Biblioteken für die µC Funktionen. Durch die Abstraktion ist das in Grenzen auch auf andere µC Portabel und braucht auch etwas mehr Resourcen - Ausgangspunkt ist aber halt die 8 Bit AVR Hardware. Wenn schon Arduino, dann sollte man beim AVR (ggf. auch ARM) bleiben - da ist die Unterstützung im Forum und Hilfe einfacher. Die Abhängigkeit vom µC ist in der Hochsprache nicht groß - es macht also nicht viel aus wenn man zum AVR oder ARM wechselt. Aber es wird schon schwer wenn man da eine exotische Variante wählt, denn manche Probleme kommen halt doch von der Hardware.
Be Ti schrieb: > Meine Annahme > war, dass mehrfache Umrechnungen nötig wären, und dass die in 8bit nicht > oder nur mit für Anfänger unübersichtlichem Gestrampel zu erledigen sein > würden. > Es bleibt für mich der Wunsch, nach Möglichkeit einen Pic zu nehmen. Um > aber in den Genuss dieser Ardunino-Uno-Plattform zu kommen, scheint es > bei Microsoft nichts Kleineres als einen 32-Bitter zu geben. Wenn du C verwenden möchtest, wird es dir genau dieses Gestrampel abnehmen. Wenn du einen PIC verwenden möchtest, dann spricht genau wie bei jedem anderen Hersteller nichts dagegen. Wenn du Angst hast, ein 8bit Prozessor würde das nicht schaffen, dann kann ich dir deine Story von deinem Projekt das du vor langer Zeit mit (einem) sorry "zwölf" PIC16 realisiert haben willst, nicht glauben. Wenn du damals zum letzten mal einen uC proggramiert hast und so möglicherweise noch nie einen einfachen (Hardware) Debugger wie beispielsweise ein PICKIT benutzt hast, dann kannst du vermutlich auch mit Arduino glücklich werden. PS: vergiss den C für PC Quatsch, da hat Oktopussi schon irgendwie recht. (Nur leider weiss ich jetz auch kein C für uC Turorial in Deutsch ...) ((Spruts "C für PICs" ist doch gar nicht so schlecht))
:
Bearbeitet durch User
Ich weiß nicht, was alle immer haben. Ich hab schon so oft PIC16 (auch mal den PIC16F84A) oder auch PIC12 in C programmiert. Und oh wunder, es hat immer funktioniert. Und ob ein Array nun auf 2 RAM-Bänke aufgeteilt ist oder nicht, juckt mich ja nicht. Es kann auch sein, dass auf nem PIC18 der Code um 5% kleiner und/oder schneller ist. Und? Sofern das nicht stört, ist es doch egal. Dafür kann man ein bisschen Geld sparen. Compiler gibts auch genug, der XC8 unterstützt die kleinen PICs ja auch nicht umsonst. Ich würde an deiner Stelle das PICKIT3 mit dem Board inkl. PIC18F... nehmen. Hab ich auch. Hat nicht viel drauf. Ein paar LEDs, nen Poti und nen Taster. Reicht zum Rumspielen und um in C warm zu werden. Als ich mit C angefangen habe, war es auch mit einem Tutorial für PCs. Denn ob eine Funtion, Datentypen, Libs, structs, Pointer, Arrays, .... in einem Programm für den PC genutzt werden oder für einen uC, macht sogut wie nie einen Unterschied. Ein paar Hardwarebezogene Dinge gibt es dann doch noch, aber das steht in der Hilfe des Compilers und/oder in den meist vorhandenen Beispielprogrammen (z.B. Configs). Ich nutze MikroC for PIC. Die IDE finde ich etwas besser als MPLAB (X) und die Hilfe finde ich deutlich übersichtlicher.
Michael Skropski schrieb: > Ich würde an deiner Stelle das PICKIT3 mit dem Board inkl. PIC18F... > nehmen. Hab ich auch. Hat nicht viel drauf. Ein paar LEDs, nen Poti und > nen Taster. Reicht zum Rumspielen und um in C warm zu werden. Danke für eure Hilfen, bevor das vergessen wird. So langsam gewinne ich Vorstellungen, was werden könnte: Hardware: Bei Pics kann ich also bleiben. Bei der Prozessorwahl sehe ich das so: Da ich kein Ingenieur bin, der eine Serie von 1000 Stück auflegen soll und dabei um fast jeden Cent und auch Platz kämpfen muss, ist es mir egal, ob ein MC 2,80 € oder 15 € kostet. Wichtig für mich ist, dass der MC mehr als ausreichend Platz an Ports hat, und ich mich nicht mit Doppelbelegung, Multiplexing etc. belasten muss, und dass genug Speicher drauf sind, um auch Hochsprachen oder ineffizienten Code eines Anfängers fassen zu können. Software: Es gibt ja nun mal dieses Buch in Deutsch, in welchem Einführung für den 32bit-Microchip Prozessor mit Uno-Umgebung geboten wird. Das müßte doch die Einführung in C erleichtern. Die Microchip (einfachen) 32-Pinner sind pinkompatibel mit den einfachen 16-Bittern. Also stelle ich mir vor, ich fange mit dieser 32bit-Uno-Umgebung an, switsche nach Erlernung der C-Grundlagen um auf die Microsoft 16-bitter, die dann mit ihrem C und vergleichsweise hoffentlich überschaubaren Anpassungen an die andere MC-Struktur mit den vorigen Uno-Programmen zu betreiben sein würden. Wäre das aus eurer Sicht ein gangbarer Weg? Der beste Weg für mich wäre derjenige, bei welchem der Einstieg in C am einfachsten gelingt. Gruß, wilhemT
Wahnsinn.
> Der beste Weg für mich wäre derjenige, bei welchem der Einstieg in C am
einfachsten gelingt.
Auf dem PC lernen.
Alles andere ist Schwachsinn, wie sich Tag für Tag immer wieder hier im
Forum zeigt. Ein ordentliches C-Buch kostet nicht die Welt, Compiler
gibts am PC für umsonst. Hast du das erste Drittel des Buches durch
(dort wo Filehandling anfängt), dann hast du das Rüstzeug um problemlos
auf dem µC zurecht zu kommen und die wenigen Techniken zu lernen, die
spezfisch für µC Programmierung sind. Was nicht heisst, dass du nicht m
PC weiter lernen sollst. Filehandling und dynamische Datenstrukturen
sind genauso wichtig, wie alles andere, auch wenn sie auf kleinen µC so
erst mal nicht vorkommen werden. Und genau davon handelen die restlichen
2 Drittel des Buches.
Aber Datentpen, Funktionen, Funktionsargumente, Strukturen, Arrays,
Pointer, Strings, Rechenregeln, Datentypen in Expressions, ... das alles
ist am PC und am µC identisch. Nur das du am PC ein Anzeigegerät hast
und am µC hast du erst mal nichts und bist auf detektivischen Spürsinn
bei der Fehlersuche angewiesen. Und Fehlersuche, das ist das, womit du
gerade am Anfang 90% deiner Zeit verbringen wirst.
Und nein. Auch wenn ich Sprut sehr schätze, aber in diesem Fall geb ich
ihm nicht recht.
:
Bearbeitet durch User
Es stimmt schon. Man sollte zumindest einmal in C hineingeschnuppert haben. Wenn man die Grundlagen beherrscht erfasst man die Besonderheiten der Controllerprogrammierung ganz anders. Aber Kennenlernen der Grundelemente reicht vollkommen aus. btw du sagtest du hast PICs in Assembler programmiert. Warum nicht dabei bleiben was du kannst? Zumindest wenn es dir nur um die Umsetzung eines Projektes geht.
Harald Nagy schrieb: > ....du sagtest du hast PICs in Assembler programmiert. Warum nicht dabei > bleiben was du kannst? Zumindest wenn es dir nur um die Umsetzung eines > Projektes geht. Da ist was dran. Mit Assembler fühle ich mich heimisch. Und hatte tierischen Spass daran, einzelne Bits in Schleifen hinein und wieder heraus zu verfolgen, und dann mit dem Simulator zu sehen, wo das dann doch auf der Strecke geblieben war. Wovor ich mich aber ebenso tierisch fürchte, sind die erwarteten vielen Unrechnungsaktionen. Vom Einlesen der Dauer eines Impulses, dem Umsetzen in Temperatur-Werte, und die dann in 3 Sieben-Segment-LEDs auszugeben erwarte ich furchtbar viele Umrechungen. Sowas hatte ich noch nicht, und da schwitze ich schon beim Gedanken daran. Deshalb wollte ich auf C los, weil das angeblich diese Umrechnungen einfacher macht. Gruß, wilhemT
Be Ti schrieb: > Da ich kein Ingenieur bin, der eine Serie von 1000 Stück > auflegen soll und dabei um fast jeden Cent und auch Platz kämpfen muss, > ist es mir egal, ob ein MC 2,80 € oder 15 € kostet. Ich weiß, was du meinst, dennoch würde ich auch bei Einzelstücken schon den günstigeren nehmen. Vorallem, wenn man vlt 2 kauft, falls man beim löten oder bei der ersten Inbetriebnahme den PIC abrauchen lässt. Dann sind das schon 5,40€ gegen 30€. Von der Differenz kann man die restlichen Bauteile und Platine kaufen ;) Be Ti schrieb: > Wichtig für mich > ist, dass der MC mehr als ausreichend Platz an Ports hat, und ich mich > nicht mit Doppelbelegung, Multiplexing etc. belasten muss, und dass > genug Speicher drauf sind, um auch Hochsprachen oder ineffizienten Code > eines Anfängers fassen zu können. Ich würde dir da die PIC18F4xK22 oder K50 (USB) empfehlen, die kommen im DIP40/TQFP44 Gehäuse. Wenns mehr sein soll, dann die PIC18F6xK22 oder K50 im TQFP64 Gehäuse. Sind sonst soweit ich es im Kopf habe identisch. Ist auch nicht so n großer Sprung vom PIC16, wie zu PIC24/dsPIC bzw. PIC32. Primär willst du ja C lernen, dann brauchste dir nicht "mehr Aufwand" wie nötig machen. Be Ti schrieb: > Es gibt ja nun mal dieses Buch in Deutsch, in welchem > Einführung für den 32bit-Microchip Prozessor mit Uno-Umgebung geboten > wird. Das müßte doch die Einführung in C erleichtern. Ohne das Buch gesehen zu haben (und Werten zu wollen) würde ich nicht mein Vorhaben an ein Buch, dass im Angebot ist, festmachen. Soweit ich weiß, kann man die ChipKits auch mit der Arduino IDE programmieren. Doch ich sehe da 2 "Probleme": 1. Ist die Sprache soweit ich weiß auch an C++ angelehnt. D.h. wenn du damit durch bist, hast du dir vielleicht was angewöhnt, was C++ spezifisch ist und du somit nicht für die (vom Hersteller gestellten) Compiler XC8 und XC16 nutzen kannst (also 8bit und 16bit PICs). 2. Ist Arduino dafür gemacht, leichtes schnell zu machen. Du lernst da aber denke ich nichts über Interruphandling mit C, was ja nicht grade unerheblich ist. 3. Du gewöhnst dich gleich an MPLABX (oder ich an MikroC, ist aber nur mit Codebegrenzung kostenlos). Der Vorteil ist, dass du mit der jeweiligen IDE warm wirst und mit dieser dann JEDEN PIC programmieren kannst. Wenn du die Arduino IDE nutzt, kannst du damit umgehen, wenn du aber dann einen 8bit oder 16bit PIC nehmen willst, musst du dich erstmal an die neue IDE gewöhnen. Be Ti schrieb: > Wäre das aus eurer Sicht ein gangbarer Weg? Der beste Weg für mich wäre > derjenige, bei welchem der Einstieg in C am einfachsten gelingt Gehbar ist vieles. Mein Vorschlag wäre dennoch am PC zu üben. - Du sparst dir das überspielen auf den PIC. Das sind zwar immer nur ein paar Sekunden, aber nach ein paar mal, geht zumindest mir das aufn Nerv. - Du brauchst erstmal KEINE Hardware und musst auch für Software keinen Cent ausgeben. Du hast keinerlei Kabelage und brauchst nie an Hardwarefehler, Verbindungsfehler o.ä. denken. - Du brauchst dir erstmal keine Gedanken um die uC spezifischen Dinge wie Config und Initialisierung zu machen. - Die Ein- und vorallem Ausgabe ist "luxuriöser", auch wenn es dann wieder ein kleiner Schritt zurück ist, wenn du dann für nen PIC programmierst. Also entweder am PC (mit z.B. Visual C Express) für die Grundlagen und danach mit der endgültigen IDE für PICs oder gleich mit der IDE für PICs. Die erste Variante hat die genannten Vorteile des Kompforts, ist aber auch zuerst ne andere Umgebung (was dir widerum später ggf zugute kommt, wenn du eine Software für den PC schreiben willst, um eine uC-Schaltung mit dem PC steuern willst). Die zweite Variante ist die Zielstrebigste, du kommst also am schnellsten zum Ziel (alle PICs programmieren zu können). Dafür würde die von mir genannte Platine reichen, wenn du nicht gleich von vornherein eine Lib für Uart->PC oder LCD nutzen willst. Das macht den Einstieg in C auch wieder etwas komplizierter, weil du einfach blind irgendwie etwas zum laufen bringst, aber noch nicht weißt, was das ist, wie man mit umgeht und wie es funktioniert.
Be Ti schrieb: > Harald Nagy schrieb: >> ....du sagtest du hast PICs in Assembler programmiert. Warum nicht dabei >> bleiben was du kannst? Zumindest wenn es dir nur um die Umsetzung eines >> Projektes geht. > Da ist was dran. Mit Assembler fühle ich mich heimisch. Und hatte > tierischen Spass daran, einzelne Bits in Schleifen hinein und wieder > heraus zu verfolgen, und dann mit dem Simulator zu sehen, wo das dann > doch auf der Strecke geblieben war. > Wovor ich mich aber ebenso tierisch fürchte, sind die erwarteten vielen > Unrechnungsaktionen. Vom Einlesen der Dauer eines Impulses, dem Umsetzen > in Temperatur-Werte, und die dann in 3 Sieben-Segment-LEDs auszugeben > erwarte ich furchtbar viele Umrechungen. Sowas hatte ich noch nicht, und > da schwitze ich schon beim Gedanken daran. Deshalb wollte ich auf C los, > weil das angeblich diese Umrechnungen einfacher macht. > Gruß, wilhemT Naja, das muss jeder selbst wissen. Manchen macht es ja spaß in ASM zu programmieren. Für mich war es mittel zum Zweck. Dahet war ich sehr sehr froh, als ich PICs endlich mit C programmieren konnte. Sehr viel schneller (beim erstellen vom Code) und vorallem übersichtlicher. Ich werde nie wieder ASM proggen, wenn ich es nicht umbedingt muss. Lieber gebe ich 5€ mehr für nen uC aus, der schneller ist und ich wieder etwas Luft mit C habe. Das Problem hatte ich aber noch nie, nichtmal ansatzweise.
Hallo Michael, bleibe mir, bzw. diesem Fred noch ein bischen treu, ich sehe da Möglichkeiten, zu einem Ergebnis zu kommen. Habe jetzt leider keine Zeit, meine Frau drängt mich vom PC weg ins Theater. Melde mich morgen wieder, grüße, wilhelmT
Be Ti schrieb: > Es wäre mir neu, dass man 8-bit-MCs in C programmieren kann/ sollte. Was ist den daran so neu? Das geht doch schon seit Jahren und ist nicht unbedingt unüblich dass auch die 8-biter mit Hilfe von C programmiert werden. Be Ti schrieb: > Mein letzter MC-Einsatz war vor 16 Jahren. Du berufst dich auf Wissen von vor 16 Jahren? Und das in der Programmierwelt? Das sind ja praktisch Jahrtausende die du da heran ziehst.
Ich berufe mich nicht! Ich schrieb in einem einzigen, kurzen Satz im Konjuktiv.....und tusch, habe nun vielfach zur Kenntnis genommen, dass man auch 8-Bitter in C programmieren kann.....und freue mich drüber, weil ich davon profitieren könnte. Nun sehe ich etwas klarer, was bedeutet, dass ich nun zwei Ziele ins Visier gefaßt habe. Das Langzeit-Ziel ist PIC24 mit 16 bit, weil die 16 bit-Berechnungen da am besten aufgehoben sein werden, und der vor allem sehr viele Pinne zur Verfügung stellt. Das Ganze dann in C, und da werde ich mir einfach vornehmen, mich über einen längeren Bereich einzuarbeiten. Das Kurzzeit-Ziel: Dem weiter oben geschilderten Argument eines Users, dass es weniger um die mc-Plattform und auch nicht die Sprache geht, sondern schlicht die Unterstützung - z.b. hier im Forum - werde ich folgen, und mir einen einfachen Uno zulegen. Mit dem arbeite ich mich ein, und werde die grundlegenden Prinzipien meines geplanten Projektes ausarbeiten, alles im kleinen Maßstab, aber dann weiß ich wenigstens, wie der Hase überhaupt laufen könnte. Jetzt würde ich mich über Hinweise freuen, ob es da irgendwo Komplett-Kits für den Einstieg gibt. Grüße, wilhelmT
Be Ti schrieb: > Michael Skropski schrieb: >> Ich würde an deiner Stelle das PICKIT3 mit dem Board inkl. PIC18F... >> nehmen. Hab ich auch. Hat nicht viel drauf. Ein paar LEDs, nen Poti und >> nen Taster. Reicht zum Rumspielen und um in C warm zu werden. > Danke für eure Hilfen, bevor das vergessen wird. So langsam gewinne ich > Vorstellungen, was werden könnte: > Hardware: Bei Pics kann ich also bleiben. Bei der Prozessorwahl sehe ich > das so: Da ich kein Ingenieur bin, der eine Serie von 1000 Stück > auflegen soll und dabei um fast jeden Cent und auch Platz kämpfen muss, > ist es mir egal, ob ein MC 2,80 € oder 15 € kostet. Wichtig für mich > ist, dass der MC mehr als ausreichend Platz an Ports hat, und ich mich > nicht mit Doppelbelegung, Multiplexing etc. belasten muss, und dass > genug Speicher drauf sind, um auch Hochsprachen oder ineffizienten Code > eines Anfängers fassen zu können. Die oben genannten PIC18 sind sicher sinnvoll. Zwei schöne Alternativen möchte ich aber trotzdem noch erwähnen: 32bit : PIC32MX250F128B 16bit : PIC24FV32KA301 Beide gibt es im DIP - Package. Den 24er eignet sich gut für batteriebetriebene Geräte. Man kann ihn auch direkt mit 5V versorgen (beim Bestellen auf ...FV... achten). der 32er ist relativ leistungsfähig und hat USB, mit dem kann man auch aufwändige Sachen realisieren. Trotzdem gibt es ihn als DIP. Die vielen Features lässt man als Anfänger einfach links liegen, wenn man die zwei PICs erst mal kennt, kann man später auch komplexe Projekte damit realisieren ohne gleich wechseln zu müssen. Ports setzen und PWM augeben / einlesen sin nicht schwieriger als beim PIC18.
Be Ti schrieb: > Nun sehe ich etwas klarer, was bedeutet, dass ich nun zwei Ziele ins > Visier gefaßt habe. Das Langzeit-Ziel ist PIC24 mit 16 bit, weil die 16 > bit-Berechnungen da am besten aufgehoben sein werden ... > Das Ganze dann in C Mit Verlaub, aber das ist Unsinn. Wenn du in C programmierst, dann macht der C-Compiler die Arithmetik für dich. Wenn du dem sagst, er soll zwei 32-Bit Integer addieren, dann macht der das. Vollkommen egal, ab das Target ein 8-Bit AVR, ein 16-Bit PIC oder ein 32-Bit ARM ist. Der einzige Unterschied ist, daß es auf den kleinen µC länger dauert. Und deswegen ist deine Bekanntheit mit PIC16x auch kein Argument dafür, bei Microchip zu bleiben. C ist überall C. Außerdem haben PIC24 (16 Bit) außer dem Namensbestandteil PIC genau gar nichts mit den 8-Bit PICs zu tun. Und die 32-Bit PIC sind in Wirklichkeit MIPS Cores. > Das Kurzzeit-Ziel: Dem weiter oben geschilderten Argument eines Users, > dass es weniger um die mc-Plattform und auch nicht die Sprache geht, > sondern schlicht die Unterstützung - z.b. hier im Forum - werde ich > folgen, und mir einen einfachen Uno zulegen. Das ist sicher nicht verkehrt. Auf jeden Fall wirst du zu AVR hier mehr Hilfe bekommen als zu PIC.
Axel Schwenke schrieb: > Be Ti schrieb: > >> Das Langzeit-Ziel ist PIC24 mit 16 bit, weil die 16 >> bit-Berechnungen da am besten aufgehoben sein werden ... >> Das Ganze dann in C > > Mit Verlaub, aber das ist Unsinn. Wenn du in C programmierst, dann macht > der C-Compiler die Arithmetik für dich. Meine Überlegung war, dass in den 16-bittigen PIC24 die Matheroutinen hardwaremäßig vorhanden sind. Es fehlt mir halt sowohl die Erfahrung mit C-Compilern, als auch die Vorstellung davon, was da so alles geht. Schwitz, es gibt immer wieder neue Argumente. Grüße, wilhelmT
Be Ti schrieb: > Das Langzeit-Ziel ist PIC24 mit 16 bit, weil die 16 > bit-Berechnungen da am besten aufgehoben sein werden, und der vor allem > sehr viele Pinne zur Verfügung stellt. Es stimmt, die 16bit PICs haben bessere Mathematik-Funktionen in Hardware und haben auch 16bit Register und können somit auch 16bit Berechnungen schneller lösen. Dazu kommt noch, dass der Takt nur durch 2 geteilt wird, nicht um 4. Doch du musst auch die relation sehen: In C macht es keinen Unterschied, ob die Berechnung auf nem 16bitter oder 8bitter geschieht. Die Frage ist, ist das wichtig? Wenn du beide mit 40MHz Taktest, ist das ein Fsys von 20MHz beim PIC24 und 10MHz beim PIC18/16. Angenommen eine Operation braucht auf dem PIC24 nur 4 Takte und auf dem PIC18 20 Takte, ist das eine Differenz von 200ns zu 2us, also 10mal so lange, aber das ist absolut uninteressant, wenn man jede ms eine Regelung machen will oder sogar nur alle 100ms ein Display neu beschreiben will. Das höchste, was alle PIC Familien als Pins/Package haben ist ein TQFP100 bzw BGA121 (mit freien Pins), also egal ob 8bit, 16bit oder 32bit. Be Ti schrieb: > Dem weiter oben geschilderten Argument eines Users, > dass es weniger um die mc-Plattform und auch nicht die Sprache geht, > sondern schlicht die Unterstützung - z.b. hier im Forum - werde ich > folgen, und mir einen einfachen Uno zulegen. Wie gesagt wird das damit auch gehen, wobei ich das Argument für falsch erachte. Wieso sollte ich mit Basic anfangen, wenn ich C lernen will? Und es ist Hilfreich ein Forum zu haben, in dem man Dinge nachfragen kann. Aber 1. finde ich nicht, dass man daran alles andere drumbauen muss/sollte und 2. ist hier im Forum die Hilfe zu AVR ebenso da, wie für Arduino, PICs oder sonstwas. Es kommt immer auf die Frage und die Bereitschaft des Fragenden an, wieviel ihm wie freundlich geholfen wird. Ich habe hier jedenfalls noch nie eine Frage zu PICs gesehen, die nicht gelöst werden konnte, auch wenn hier 10 mal mehr AVR Leute unterwegs seien sollten. Axel Schwenke schrieb: > Das ist sicher nicht verkehrt. Auf jeden Fall wirst du zu AVR hier mehr > Hilfe bekommen als zu PIC Wie gesagt würde ich das nicht unterschreiben. Zumindest wenn es um wirklich hilfreiche Antworten geht. Be Ti schrieb: > Es fehlt mir halt sowohl die Erfahrung mit > C-Compilern, als auch die Vorstellung davon, was da so alles geht. Ansich kann man sagen, das alles geht, sofern man weiß wie. Es ist (aus meiner Sicht) sehr sehr sehr viel komfortabler als ASM und dafür eventuell minimal ineffizienter (je nach Compiler). Be Ti schrieb: > Schwitz, es gibt immer wieder neue Argumente Ja, weil es auch unterschiedliche Geschmäcker und Meinungen gibt. Letztendlich musst du dich entscheiden. Hilfe wirst du hier bekommen unabhängig von deiner Entscheidung. Meine Meinung hab ich ja geschrieben, ich würde es immer wieder so machen, weiß aber, dass das keine allgemeingültige Regel ist.
Be Ti schrieb: > Axel Schwenke schrieb: >> Be Ti schrieb: >> >>> Das Langzeit-Ziel ist PIC24 mit 16 bit, weil die 16 >>> bit-Berechnungen da am besten aufgehoben sein werden ... >>> Das Ganze dann in C >> >> Mit Verlaub, aber das ist Unsinn. Wenn du in C programmierst, dann macht >> der C-Compiler die Arithmetik für dich. > Meine Überlegung war, dass in den 16-bittigen PIC24 die Matheroutinen > hardwaremäßig vorhanden sind. Die Matheroutinen befinden sich in der Laufzeitbibliothek des C-Compilers. Sie sind für einen 16-Bit Kern natürlich anders als für einen 8-Bit Kern. Aber im Ergebnis ist das vollkommen schnuppe. > Es fehlt mir halt sowohl die Erfahrung mit > C-Compilern, als auch die Vorstellung davon, was da so alles geht. > Schwitz, es gibt immer wieder neue Argumente. Mein Punkt war eher, daß es weniger Argumente gibt als du annimmst. Insbesondere mußt du dir für eine so unkomplizierte Aufgabe wie von dir angepeilte keinerlei Gedanken darüber machen, ob eventuell die Arithmetik einer 8-Bit ALU zu langsam sein könnte. Ist sie nicht. Auch der kleinste 8-Bitter wird zu 95% der Zeit Däumchen drehen. Auch die Unterschiede zwischen PIC und AVR werden von C zu einem gewissen Grad nivelliert. Klar, die magischen Variablennamen für Ports, Timer & Co unterscheiden sich. Genauso wie die Includefiles in denen sie definiert sind. Aber das sind Kleinigkeiten, die man auch relativ leicht abstrahieren kann. Arduino macht es doch vor. Der Arduino Due ist ein ARM, die kleineren sind ATmega. Trotzdem sieht die Umgebung für die Anwendungen gleich aus. Michael Skropski schrieb: > Axel Schwenke schrieb: >> Das ist sicher nicht verkehrt. Auf jeden Fall wirst du zu AVR hier mehr >> Hilfe bekommen als zu PIC > > Wie gesagt würde ich das nicht unterschreiben. Zumindest wenn es um > wirklich hilfreiche Antworten geht. Das wird wohl nur daran liegen, was du als hilfreich ansiehst. Aber ich sehe hier nirgends ein PIC-Äquivalent zum AVR-Tutorial oder AVR-GCC-Tutorial. Und Leute wie PeDa oder Johann L. scheint es in der PIC-Fraktion auch nicht zu geben. Ich lese da immer nur Spinner, die jaulen als ob ich sie persönlich beleidigt hätte, wenn ich sage daß ich die Architektur der kleinen PIC bis einschließlich PIC18 häßlich finde. Klar, C deckt das Elend weitgehend zu. Aber schön wird es dadurch trotzdem nicht.
Uiii, schon wieder Glaubenskrieg :-) Einen großen Vorteil einiger modernerer PICs hat kein Atmel: Remappable Peripherals. Viele Bastelprojekte finden auf 2-Layer-Platinen statt. Wer schon einmal eine komplexere Platine mit einem voll belegten TQFP64 oder mehr auf 2 Lagen mit dem Pinning herumgeärgert hat, sollte folgedenden anschauen: PIC24FJ126GC006 Man kann alle Peripherals bis auf wenige Ausnahmen fast überall herausfahren. Das ist ein unschlagbarer Vorteil, um Überkreuzungen zu vermeiden - man kann fast alles im µC auskreuzen, ohne faule Kompromisse mit den Peripherals eingehen zu müssen. Das kann - meines Wissens nach - kein AVR und kein STM32. Weil das zur Laufzeit geht, kann damit einen Peripherie-Block auf eine beliebige Anzahl auf Pins multiplexen. Man braucht 20 UARTs? Kein Problem - solange es nicht gleichzeitig sein muss.
Axel Schwenke schrieb: > Das wird wohl nur daran liegen, was du als hilfreich ansiehst. Aber > ich sehe hier nirgends ein PIC-Äquivalent zum AVR-Tutorial oder > AVR-GCC-Tutorial. Und Leute wie PeDa oder Johann L. scheint es in > der PIC-Fraktion auch nicht zu geben. Ja, ein Tutorial vermisse ich auch. Habe selber mal drüber nachgedacht eins zu schreiben. Ich meinte aber mehr hier im Forum. Chris D. fällt mir da auf anhieb ein. Wie auch immer. Immer als ich ne Frage hatte oder ich einen Thread bzgl. PIC verfolgt habe, wurde immer eine Lösung gefunden. Dann ist es aus meiner Sicht auch egal, ob 2 aktive User mit Ahnung dabei sind oder 50. Das verkürzt höchstens die Zeit bis zur Lösung. Zumal oft C oder allgemeine Elektronik/Digitaltechnik das Problem ist. Axel Schwenke schrieb: > Ich lese da immer nur Spinner, die jaulen als ob ich sie persönlich > beleidigt hätte, wenn ich sage daß ich die Architektur der kleinen PIC > bis einschließlich PIC18 häßlich finde. Manche Leute reagieren so, als wenn man seine Familie beleidigen würde, das stimmt (bei fast allen Bereichen). Ich enthalte mich da eigentlich immer, weil ich eben nur die PICs kenne. Außer einen 80C535, den ich im Studium kennengelernt hatte und dem ich egal welchen PIC vorziehen würde, selbst die Gurke eines 16F84. Ich weiß wie es funktioniert, das tut es auch so wie ich denke, aber ob etwas hässlich oder umständlich ist kann ich nicht beurteilen. Mich hat es nie gestört und darauf kommt es mir an - das ich an mein Ziel komme und verstehe, was wie wieso funktioniert. Das einzige, wo ich dann auch mal schreibe und "die PICs verteidige", ist, wenn ich genau weiß, das jemand etwas falsches sagt, wieso auch immer. Wenn jemand sagt, er nimmt keine PICs, weil das Logo doof ist, ok. Kann ich nicht nachvollziehen, aber bitte. Doch wenn jemand einfach Fehlinformationen hat oder wenn einer jemanden von PICs abbringen will, indem er stuss labert, kann ich mich meistens nicht zurück halten^^ (damit meine ich keinen hier im Thread) WehOhWeh schrieb: > Uiii, schon wieder Glaubenskrieg :-) > > Einen großen Vorteil einiger modernerer PICs hat kein Atmel: Remappable > Peripherals. Bisher war es noch keiner, finde ich;) Man muss aber dazu sagen, dass die "modernen PICs" die 16bitter und ggf die 32 bitter sind, die glaube ich noch nie in irgendeiner Kritik standen. Das sind ja immer nur die 8bitter gewesen. Und von denen hat meines Wissens nach kein Modell remappable Pins, sonst sag mir gerne, welcher ;) Finde ich aber auch echt nett und hat mir schonmal sehr das Layout erleichtert. Ob AVRs oder STM32 das haben weiß ich nicht (zumindest bei den ARMs hätte ich es gedacht), aber es sind 100%ig nicht die einzigen. Die PSoC5 von Cypress find ich ja auch interessant, da kannst du ja alles frei wählen (zumindest jeweils die Analogen und Digitalen IOs). Ich weiß nicht, wieso die so selten erwähnt oder warscheinlich auch benutzt werden. Günstig sind sie allerdings auch nicht.
Michael Skropski schrieb: > Das sind ja immer nur die 8bitter gewesen. Und von denen hat > meines Wissens nach kein Modell remappable Pins, sonst sag mir gerne, > welcher ;) PIC18F46J11 z.B. http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC18F45J11 Für ein paar einzelne Pins gibt es das auch z.B. beim PIC12F1840
:
Bearbeitet durch User
Michael Skropski schrieb: > Es stimmt, die 16bit PICs haben bessere Mathematik-Funktionen in > Hardware und haben auch 16bit Register und können somit auch 16bit > Berechnungen schneller lösen. In C macht es keinen Unterschied, ob die > Berechnung auf nem 16bitter oder 8bitter geschieht. > Die Frage ist, ist das wichtig? Nein, das ist sogar unwichtig. Wie oben gesagt, würde die Aktualisierung alle 10 Sek reichen. > Wie gesagt wird das damit auch gehen, wobei ich das Argument für falsch > erachte. Wieso sollte ich mit Basic anfangen, wenn ich C lernen will? > Und es ist Hilfreich ein Forum zu haben, in dem man Dinge nachfragen > kann. > Hilfe wirst du hier bekommen unabhängig von deiner Entscheidung. Es scheint sich für mich heraus zu kristiallisieren, dass ich mir möglicherweise nicht wirklich einen Gefallen tue, wenn ich gleichzeitig das Langzeitziel, 16 bit auf PIC in C, und das Kurzzeitziel, schneller Erfolg mit einfachem Arduino verfolge. Weil es da dann ja schon um unterschiedliche Hardware ginge, die ja wohl selbst mit der Adr.-Plattform irgenwie zu lernen und zu berücksichtigen wäre. Habe mal bei Microchip rumgeschaut. Den von dir empfohlenen PIC18F43K20 scheint es nicht mehr zu geben, der ist nicht mehr gelistet. Es gibt da noch die PICs mit 45/46/47 als Endziffern. Ja, das liest sich recht ordentlich. Jetzt stelle ich trotzdem die ketzerische Frage: Warum 8-Bitter, wenn es auch 16-Bitter gibt?. Die sind ja "moderner", wie du selbst sagtest, haben die Hardware Multiplikation und Division, etc. Ein Argument für 8-Bitter und gegen 16-Bitter habe ich allerdings gerade selbst entdeckt. Für die 8-Bs würde ein PICkit3 Programmer reichen, den gibts mit Demoboard für 58 €. Wenn ich das richtig sehe, kann der aber nur MCs mit max. 20 Pinnen bearbeiten. Da ich ja nun auf deutlich mehr raus möchte, käme nur der MPLAB ICD3 in Frage, der von 8 bis 32-Bit alles programmiert. Der kostet dann aber alleine - ohne Demoboards - schon 175 €. DAS wäre ein Argument, muss aber gleich dazu sagen: Mein Ziel ist es nicht, ALLES und das ganz billig, also für unter 30 € zu erhalten. Für eine gute Erstausrüstung bin ich bereit, auch Geld auf den Tisch zu legen. Noch zur Auswahl eines PICs: Bei den PIC24Fs soll es welche geben, die besonders ausgestalteten CCP-Eingang haben. Da meiner ja als erstes Pulslängen messen soll, wäre das noch ein Argument. Softwaremäßig wäre dann noch zu klären, wie ich einen möglichst einfachen Einstieg in C finden würde. Mein Englisch reicht zum Lesen von Büchern, für engl. Videos leider nicht (zu schnell, zuviel Slang). Ein gutes deutsches Buch wäre der Bringer. Grüße, wilhelmT
Be Ti schrieb: > Den von dir empfohlenen PIC18F43K20 > scheint es nicht mehr zu geben http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC18F43K20 > Da ich ja nun auf deutlich mehr > raus möchte, käme nur der MPLAB ICD3 in Frage, der von 8 bis 32-Bit > alles programmiert. Hier findest du eine Liste mit dem Supportet Devices in den "MPLAB X IDE Release Notes": http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=PG164130
Be Ti schrieb: > Es scheint sich für mich heraus zu kristiallisieren, dass ich mir > möglicherweise nicht wirklich einen Gefallen tue, wenn ich gleichzeitig > das Langzeitziel, 16 bit auf PIC in C Du musst das ja nicht machen. Du kannst auch einen 8bitter, z.B. PIC18 nehmen und in C programmieren. Du kennst im Großen und ganzen die Hardware, lernst C und ist für deine Anforderungen massig ausreichend. Wenn du dann C kannst und dich in die IDE eigearbeitet hast, kannst du auf nen 16bitter wechseln. Und das dürfte viel schneller gehen, als der Wechsel von der Arduino IDE. Be Ti schrieb: > Jetzt stelle ich trotzdem die ketzerische Frage: Warum 8-Bitter, wenn es > auch 16-Bitter gibt?. Die sind ja "moderner", wie du selbst sagtest, > haben die Hardware Multiplikation und Division, etc. Oder warum nicht PIC32, ARM oder gleich ein Raspberry Pi? Oft ist es der Preis, die Lötbarkeit und/oder die Einfachheit, weswegen ich hauptsächlich PIC18 nehme. Es gibt ganz tolle, neue dsPIC33EP/EV (5V), mit massig RAM/ROM, 70MIPS und ne PWM Auflösung von 6ns. Kosten aber glaube so um die 5-8€, wohingegen ein PIC18 in dem gleichen Gehäuse (gleiche IO Anzahl) nur 2€ kostet. Und den PIC18 muss man nicht "so aufwendig" konfigurieren. Und letztendlich ist es egal, ob der PIC18 zu 30% ausgelastet ist oder der dsPIC zu 5%. Es kommt eben darauf an, was man braucht. Mit den 8bittern kann man meines Erachtens schon sehr viel machen. Be Ti schrieb: > Für die 8-Bs würde ein PICkit3 Programmer reichen, den > gibts mit Demoboard für 58 €. Wenn ich das richtig sehe, kann der aber > nur MCs mit max. 20 Pinnen bearbeiten. Da ich ja nun auf deutlich mehr > raus möchte, käme nur der MPLAB ICD3 in Frage, der von 8 bis 32-Bit > alles programmiert. Definitiv nicht. Es gibt ja auch nicht wenige 8bitter mit > 20 Pins. Das PICKIT3 kann jeden verfügbaren PIC brennen, ich bin mir ziemlich sicher auch die neuen PIC32MZ. Ein ICD3 ist aber schneller (interessant wenn man wirklich mal 512kB Flash programmieren muss) und, wie der Name schon sagt, besser beim Debuggen. ABER ein PICKIT3 kann auch debuggen und wie gesagt auch alles flashen.
Be Ti schrieb: > Für die 8-Bs würde ein PICkit3 Programmer reichen, den > gibts mit Demoboard für 58 €. Wenn ich das richtig sehe, kann der aber > nur MCs mit max. 20 Pinnen bearbeiten Warum nicht nur das PICKIT3 und ein Steckbrett ? Da kannst du dann alle PICs drauf brennen und was du sonst noch anschließen willst, steckst du auf das Steckbrett. Wenn du fertige Boards haben willst, dann kann es teuer werden. Dann schau dich hier mal um: http://www.mikroe.com/pic/development-boards/
Be Ti schrieb: > Für die 8-Bs würde ein PICkit3 Programmer reichen, den > gibts mit Demoboard für 58 €. Wenn ich das richtig sehe, kann der aber > nur MCs mit max. 20 Pinnen bearbeiten. Das PICkit3 ist zwar das Low Cost Tool, programmiert aber alle PICs und debuggt die meisten. Die, die ein ICSP-Interface haben, und das haben eigentlich alle, die mehr als 8 Pins haben. Ich holte mir vor einem Monat das PICkit3 bei Reichelt, da ist auch ein Board mit einem PIC18F45K20 dabei. Aber ich holte mir für eigene Basteleien auf dem Steckbrett noch ein paar PIC18F26K20 dazu, die sind ähnlich dem auf dem Board, allerdings DIP mit 28 Pins fürs Steckbrett. Das funktioniert prächtig, flashen, debuggen. Alles unter MPLAB X, das alte MPLAB verwende ich nicht mehr. Der C-Compiler XC8 ist auch gratis, dafür hat er lediglich nur Einschränkungen in den Optimierungsoptionen. Das ist für die meisten Anwendungen aber leicht verschmerzbar, besonders im Hobby.
Hi, Max H. schrieb: > Michael Skropski schrieb: >> Das sind ja immer nur die 8bitter gewesen. Und von denen hat >> meines Wissens nach kein Modell remappable Pins, sonst sag mir gerne, >> welcher ;) > PIC18F46J11 z.B. > http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC18F45J11 > > > Für ein paar einzelne Pins gibt es das auch z.B. beim PIC12F1840 Für ein paar Ausgewählte Peripherials gibt es das bei den meisten der neuesten PIC16. Da hat man dann mehrere Mögliche Pins zur Auswahl. HAt mir gerade beim PIC12F1572 einiges an Schweiß erspart. (Ist natürlich kein Vergleich zu den Möglichkeiten der größeren) Zu den Modellen: "Früher" (Bis Anfang dieses Jahrzehnts) war es so, das man die PIC16F nur mit Einschränkungen in C programmieren konnte. Es gab auch keinen C Compiler von Microchip selbst dafür. (Es war natürlich trotzdem möglich, z.B. mit dem HI-TECH Compiler) Für die Programmierung in C wurden die Modelle ab 18F aufwärts empfohlen. Seit dem hat sich aber bei den PIC16 einiges getan. Die Grenzen zu den PIC18F sind fließend geworden. Für die meisten der neueren PIC16 gilt diese Einschränkung daher nicht mehr. Einige davon sind sogar Leistungsfähiger als manch älterer PIC18. Damit einhergehend hat Microchip bei den neuen PIC16 auch ein neues Pinnlayout eingeführt. Dies ist nun mit der Pinnbelegung bei den PIC18F identisch. Da auch derselbe Compiler für PIC16 und PIC18 Verwendung finden kann (XC8) ist damit auch möglich innerhalb des Projektes ohne weitere Hardwareänderungen zwischen der PIC16 und PIC18 Familie zu wechseln. (allerdings zum Preis das man beim Wechseln des µC innerhalb der PIC16 Familie jaetzt auf das Pinnlayout achten muss, da Microchip Neuentwicklungen in beiden Layoutvarianten herausbringt) Karl Heinz schrieb: > Wahnsinn. > Be Ti schrieb: >> Der beste Weg für mich wäre derjenige, bei welchem der Einstieg in C am >> einfachsten gelingt. > > Auf dem PC lernen. > Alles andere ist Schwachsinn, wie sich Tag für Tag immer wieder hier im > Forum zeigt. Ein ordentliches C-Buch kostet nicht die Welt, Compiler > gibts am PC für umsonst. Hast du das erste Drittel des Buches durch > (dort wo Filehandling anfängt), dann hast du das Rüstzeug um problemlos > auf dem µC zurecht zu kommen und die wenigen Techniken zu lernen, die > spezfisch für µC Programmierung sind. [..] > Und nein. Auch wenn ich Sprut sehr schätze, aber in diesem Fall geb ich > ihm nicht recht. Hier meine vollste Zustimmung! Wer noch keine Erfahrung mit C hat, der sollte UNBEDINGT erst einmal auf dem PC Anfangen und erst wenn man die Grundlagen halbwegs sicher beherrscht auf den µC umsteigen. Zwar meckert der Cross-Compiler für den µC bei groben Syntaxfehlern genauso wie beim PC, aber bei kleineren (logischen) Fehlern bleibt er einfach Stumm und der µC macht einfach irgendwas (oder gar nichts) und du hast einfach nur eine "BlackBox" von der du erst einmal nicht weiß warum die sich nicht wie erwarte verhält. war kann man auch auf dem µC Debuggen, aber das setzt schon wieder etwas Erfahrung vorraus. Beim PC ist das alles sehr viel einfacher Nachzuverfolgen. Und so mach ein Fallstrick für Einsteiger den die µC bieten ist da gar nicht erst vorhanden. -> Daher: Die Grundlagen von C auf den PC lernen, dann erst den Wechsel auf den µC wagen. Zur µC Wahl: Für das konkrete Projekt sind sicher fast alle aktuellen µC Familien geeignet. Egal ob ATMEGA, diverse PIC Familien, oder eines der bekannteren Cortex Derrivate. ISt eine Geschmacksfrage sowie eine Frage der Anforderungen und vor allem auch der Verfügbarkeit. Für die PIC spricht das alle Familien mit denselben Entwicklungswerkzeugen bearbeitet werden können. So hat man jedes mal aufs neue die freie Wahl ob nun 8, 16 oder 32Bit. Die Originale Programmierhardware mit Debugfunktion (PICKIT3) ist günstig (ab 30 Euro) und gleichzeitig sehr robust. Die Unterstützt vom Uralten 4MHz PIC16C84 bis zum aktuellen 200MHz PIC32MZ mit 2MB Programmspeicher und 512kB RAM die ganze Palette. Es gibt eine Menge an Frameworks und Beispielen vom HErsteller direkt. Zudem sind die sehr Bastelfreundlich, es gibt Vertreter aller Familien auch im DIP Gehäuse, selbst 32Bitter mit USB HOST Funktion usw. sind in DIP zu bekommen. Wobei die STM32 aber auch nicht zu verachten sind. Da ist man zwar auf 32Bit festgenagelt, aber auch da gibt es schon recht kleine Vertreter... Und nach Oben tut sich kein großer Unterschied zu den Regieonen welche auch die "großen" Microchip PIC beherschen. Nur den kompletten Neueinstieg in die ATMEGA würde ich mir sehr gut überlegen. Zwar sind die im 8Bit bereich zu den PIC nahezu gleichwertig (wenn auch mit deutlich weniger Flexibilität bei der Peripherie und Gehäuseformen - vieles an neuen ist nich tmehr in DIP verfügbar) aber nach Oben wird die Luft halt dünn. Klar gibt es die ATMEGA32, aber die führen einfach ein Nischendasein, überhaupt kein Vergleich zu den PIC32 oder den CORTEX-M. wenn also mal mehr Leistung notwendig sein sollte, dann würde das wieder bedeuten, neue Tools, neue Umgebung, neues Lernen (Wobei das Lernen sowieso nie enden sollte, da der µC Markt ständig in Bewegung ist) Axel Schwenke schrieb: > Das ist sicher nicht verkehrt. Auf jeden Fall wirst du zu AVR hier mehr > Hilfe bekommen als zu PIC. Axel Schwenke schrieb: > Ich lese da immer nur Spinner, die jaulen als ob ich sie persönlich > beleidigt hätte, wenn ich sage daß ich die Architektur der kleinen PIC > bis einschließlich PIC18 häßlich finde. Also die "jaulenden Spinner" kenne ich eher von der ATMEGA Fraktion. Sicher gibt es solche EXTREM-FANBOYS bei allen µC Familien, aber den ATMEGAS sind die einfach nur eine PEST. Die meisten derjenigen die ich hier kenne und die PIC, STM32, NXP oder was auch immer empfehlen, die sind anderen Familien durchaus aufgeschlossen, können Begründen warum sie für diese Frage gerade das Frabrikat xxx Empfehlen, verweisen aber nicht selten auch darauf das es noch andere Fabrikate gibt die genauso oder zumindest fast genauso geeignet sind... Diejenigen die mir persöhnlich hier bekannt sind (einschließlich mir) verwenden aktiv mehrere Familien parallel. Ich mag PIC, aber wenn mir eine andere Familie für das konkrete Projekt Vorteile biete, dann nehme ich die andere Familie. Da bin ich recht emotionslos. Aber wehe man erwähnt irgendwo das ATMEGA nicht die Krone der Schöpfung ist, dann geht sofort das Geheule los. Da wird um sich geschlagen und gebissen was das Zeug hält... Wobei das durchaus ein Internationales Problem zu sein scheint. http://www.eevblog.com/2010/02/22/eevblog-63-microchip-pic-vs-atmel-avr/ Man achte nur mal auf Daves Äusserungen über diese ATMEL FANBOYS (ab 5.30min) Axel Schwenke schrieb: > wenn ich sage daß ich die Architektur der kleinen PIC > bis einschließlich PIC18 häßlich finde. > Klar, C deckt das Elend > weitgehend zu. Aber schön wird es dadurch trotzdem nicht. Naja, das ist ja auch ein völlig "sachliches" Argument... Sicher, das darf deine Meinung sein und zumindest bei den älteren PIC16 die definitiv auf einem 30 Jahre alten Entwurf basieren ist das ja auch nicht ganz falsch. In den Zeiten wo diese "alten" PIC Stand der Technik waren und man zudem noch fast alles in ASM schrieb, da hätte man das durchaus auch als Argument nehmen können... Aber heute ist das einfach kein Argument mehr, denn selbst wenn man mit einem "betroffenen" PIC arbeitet, bekommt der Einsteiger davon überhaupt nichts mehr mit. Denn den interessiert einfach nicht ob das interne Design "schön" oder "hässlich" ist, den interessiert einfach nur was am ende herauskommt. Und da spielt - wie von dir richtig erkannt - dank C compiler das Grunddesign überhaupt keine Rolle mehr. Wohl aber die Frage wie viel man mit derselben Ausrüstung Programmieren kann, in welchen Gehäusen man etwas bekommt, was die Erstausrüstung kostet usw. Axel Schwenke schrieb: > Das ist sicher nicht verkehrt. Auf jeden Fall wirst du zu AVR hier mehr > Hilfe bekommen als zu PIC. So lange man mit "mehr" die reine "Quantität" der antworten meint, so lange stimmt das durchaus. Das Problem ist dabei nur QUANTITÄT != QUALITÄT !!! Bei der zahl der Qualitativ hochwertigen und damit wirklich Hilfreichen Anworten unterscheiden sich die drei am häufigsten hier vertretenen Familien (ATMEGA, STM32, PIC) kaum noch. Allerdings ist das "Rauschen" bei den STM32 und den PIC deutlich geringer. Es fällt also wesentlich leichter die Sinnvollen Antworten von denenen anderer Einsteiger die auf dem völlig falschen Pferd sind aber meinen trotzdem etwas schreiben zu müssen zu unterscheiden. Aber letztendlich hat der TE seine Entscheidung schon getroffen. Wobei ich die aber nicht wirklich glücklich finde. Entweder will jemand etwas schnell am Laufen haben oder überhaupt erst einmal mit wenig Aufwand in die µC Welt hineinschnuppern, dann ist ARDUINO sicher nicht Verkehrt. Oder jemend will wirklich tiefer Einsteigen. Wenn aber von vorne herein feststeht das man tiefer eintauchen möchte, würde ich keinesfalls den Umweg über Arduino gehen. Denn die Vereinfachung ist da ja nur gegeben wenn man die Arduino Funktionen auch nutzt. Diese haben aber wenig mit den generellen C und der "normalen" Programmierung von µC zu tun, sondern nehmen einen alles komplexe ab. Leider zu dem Preis das die Möglichkeiten sehr beschränkt sind. Will man aber dieses Korsett sprengen, dann muss man direkt vieles Umlernen. DAHER -> Wenn feststeht das es keine Eintagsfliege werden soll, dann lasse den ARDUINO besser links liegen und steige gleich richtig ein. PIC ist dafür keine schlechte Wahl, aber auch mit diversen CORTEX Modellen liegst du nicht völlig abseits. Das darf dann ruhig auch einer von ATMEL sein, es muss nicht Zwingend ST oder NXP draufstehen. (Je nachdem was an Ausstattung gewünscht ist) Mit ATMEGA würde ich heute aber nur noch einsteigen wenn du von vorneherein weist das du definitiv nie über solch einfache Anwendungen hinaus willst... Gruß Carsten
Carsten Sch. schrieb: > Aber letztendlich hat der TE seine Entscheidung schon getroffen. > Wobei ich die aber nicht wirklich glücklich finde. > Entweder.......Oder jemend will wirklich tiefer Einsteigen. > Gruß Carsten Ich sprach von Herauskristiallisieren, und meinte damit aber schon: Doch kein "schneller Arduino", sondern den Weg: PIC24 mit C. Nun habe ich erst mal einige Irrtümer aufgeklärt, und die wurden s.o. auch von euch geklärt: Das PICkit3 kann doch (fast) alles programmiern, von 8- bis 32 bit. Und den von Michael empfohlenen PIC18F43K20 gibt es doch noch in Produktion. Da ist allerdings einiges seltsam. Wenn ich die M-HP aufrufe und in die 8-bit-Liste gehe, ist der Typ dort nicht enthalten, daher meine Annahme. Gibt man den Typ aber in die Suchmaske ein, wird er gefunden und als lieferbar erklärt. Hm...... Jedenfalls gibt es hier im Forum offenkundig User, welche kundig und hilfsbereit sind. Ein dickes Dankeschön !! Also nun.....ich schaue mich jetzt quasi noch um, ob es da kleine, fertige Boards zu kaufen gibt, und natürlich nach wie vor nach einem guten Einsteiger-Buch in C , möglichst in deutsch. Gruß, wilhelmT
wilhelmT schrieb: > Das PICkit3 kann doch (fast) alles programmiern, von 8- bis 32 bit. > Und den von Michael empfohlenen PIC18F43K20 gibt es doch noch in > Produktion. Nicht fast. Alles. Und direkt den habe ich nicht empfohlen, sondern die Familie: Michael Skropski schrieb: > Ich würde dir da die PIC18F4xK22 oder K50 (USB) empfehlen, die kommen im > DIP40/TQFP44 Gehäuse. Wenns mehr sein soll, dann die PIC18F6xK22 oder > K50 im TQFP64 Gehäuse. wilhelmT schrieb: > ich schaue mich jetzt quasi noch um, ob es da kleine, > fertige Boards zu kaufen gibt Wie gesagt gibt es das PICKIT3 auch mit einem Demoboard: http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=DV164131 Gibt es bestimmt irgendwo günstiger, als vom Hersteller. Carsten Sch. schrieb: > Für ein paar Ausgewählte Peripherials gibt es das bei den meisten der > neuesten PIC16. Da hat man dann mehrere Mögliche Pins zur Auswahl. > HAt mir gerade beim PIC12F1572 einiges an Schweiß erspart. > (Ist natürlich kein Vergleich zu den Möglichkeiten der größeren) Gut zu wissen, muss ich mich mal umgucken. Dein Name ist mir da entfallen, sorry ;) : Michael Skropski schrieb: > Axel Schwenke schrieb: >> Das wird wohl nur daran liegen, was du als hilfreich ansiehst. Aber >> ich sehe hier nirgends ein PIC-Äquivalent zum AVR-Tutorial oder >> AVR-GCC-Tutorial. Und Leute wie PeDa oder Johann L. scheint es in >> der PIC-Fraktion auch nicht zu geben. > > Ja, ein Tutorial vermisse ich auch. Habe selber mal drüber nachgedacht > eins zu schreiben. Ich meinte aber mehr hier im Forum. Chris D. fällt > mir da auf anhieb ein.
Hi, wilhelmT schrieb: > Das PICkit3 kann doch (fast) alles programmiern, von 8- bis 32 bit. > Und den von Michael empfohlenen PIC18F43K20 gibt es doch noch in > Produktion. Da ist allerdings einiges seltsam. Wenn ich die M-HP aufrufe > und in die 8-bit-Liste gehe, ist der Typ dort nicht enthalten, daher > meine Annahme. Welche 8 Bit Liste meinst du? In der Produktübersicht der PIC18 ist der enthalten... http://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1004&mid=10&lang=en&pageId=74 Bei dem PIC18F43K20 handelt es sich im übrigen um eine "Sparversion" des PIC18F45K20 welcher beispielsweise beim PICKIT3 Debug Express verwendung findet. Das bedeutet die µC PIC18F43K20, PIC18F44K20, PIC18F45K20 & PIC18F46K20 haben exakt denselben Kern und Peripherie. Lediglich der Programm & Datenspreicher verdoppelt sich jeweils immer beim Nächstgrößeren. Selbes Spiel mit den 23k20...26k20. Dies sind wieder dieselben Controller, nur im kleineren Gehäuse, da sind dann einfach einige Pins nicht nach aussen geführt. In großen Stückzahlen sind die kleineren/speicherärmeren µC dabei einige Cent günstiger, in kleinen Stückzahlen ist das aber nicht immer der Fall, da lohnt es sich mal zu schauen was die nächst größeren bei diesem Händler Kosten. Es ist also relativ egal welchen man nun genau nimmt, so lange der Speicher für das konkrete Programm ausreicht. Ausser der Einstellung des Controllers in der IDE muss nichts geändert werden. D.H. selbst wenn unwahrscheinlicherweise der 43K20 eingestellt werden würde, könntest du einfach mit dem 45k20 weitermachen. Selbst wenn du nur das HEX File hättest. (Da nach oben hin ja Binärkompatibel) Du kannst also munter beschaffen was jeweils gerade am einfachsten für dich zu beschaffen ist. (Hängt vom Händler ab, der 45K20 dürfte aber am weitesten verbreitet sein.) Ich selbst habe im Laborvorratsbestand (neben einigen anderen Unterfamilien mit anderen Funktionalitäten) praktisch nur den PIC18F46K20 Bei den anderen Untergruppen dasselbe - immer nur jeweils den "Speichergrößten" auf Vorrat. Da kann ich dann das benötigte Ausprobieren und für die Produktionsunterlagen musste ich dann vor der gründlichen Testphase nur noch schauen wo meine Firmware reinpasst und mit dem wurde dann getestet und Produziert. (Bin aber jetzt nicht mehr freiberuflich... daheim nur noch als Hobby) Aber das kann jeder selbst halten wie er will. ISt bei einigen auch eine Frage des Geldes... Der 43er ist bei Reichelt ca 70 cent Billiger als der 46er. Für einen Schüler/Studenten der den Mehrspeicher nicht braucht und auch mal den einen oder anderen in der Lernphase grillt kann das schon einen Unterschied machen. wilhelmT schrieb: > Ich sprach von Herauskristiallisieren, und meinte damit aber schon: Doch > kein "schneller Arduino", sondern den Weg: PIC24 mit C. > Nun habe ich erst mal einige Irrtümer aufgeklärt, und die wurden s.o. > auch von euch geklärt: Ich habe beim Beitragschreiben zwischendurch länger Telefoniert... Als ich den Beitrag begonnen habe waren deine "neuen" Antworten noch nicht da. Gruß Carsten
Carsten Sch. schrieb: > Aber das kann jeder selbst halten wie er will. ISt bei einigen auch eine > Frage des Geldes... Der 43er ist bei Reichelt ca 70 cent Billiger als > der 46er. Für einen Schüler/Studenten der den Mehrspeicher nicht braucht > und auch mal den einen oder anderen in der Lernphase grillt kann das > schon einen Unterschied machen. Wegen der Preise (und Verfügbarkeit) kann man sich hier https://www.microchipdirect.com/ orientieren. Da kann man IMHO auch als Privater kaufen. MfG Klaus
Carsten Sch. schrieb: > Hier meine vollste Zustimmung! > > Wer noch keine Erfahrung mit C hat, der sollte UNBEDINGT erst einmal auf > dem PC Anfangen und erst wenn man die Grundlagen halbwegs sicher > beherrscht auf den µC umsteigen. Also wenn ich ein vernünftiges Tutorial wüsste, welches C direkt anhand von µC Beispielen einführen würde, würde ich das auch empfehlen. Bei den PC Tutorials wird man sehr viel Zeit mit Sachen verschwenden, die man nacher auf einem uC nie brauchen wird. Carsten Sch. schrieb: > Zwar meckert der Cross-Compiler für den µC bei groben Syntaxfehlern > genauso wie beim PC, aber bei kleineren (logischen) Fehlern bleibt er > einfach Stumm und der µC macht einfach irgendwas (oder gar nichts) und > du hast einfach nur eine "BlackBox" von der du erst einmal nicht weiß > warum die sich nicht wie erwarte verhält. war kann man auch auf dem µC > Debuggen, aber das setzt schon wieder etwas Erfahrung vorraus. Die Fehlermeldungen und die Unterstützungen sind bei den uC Compilern (ich kenne nur C18 und XC8) wirklich nicht unbedingt die besten. Allerdings bin ich der Meinung, daß man am besten von Anfang an die BlackBox Geschichte vermeidet indem man den Umgang mit Simulator und Debugger gleich mitlernt. zur Auswahl des Kontrollers: falls es ein PIC werden sollte würde ich für Anfänger auch die 18FxxK22 Familie empfehlen, weil die eine der wenigen von den neuen ist, die den großen Versorgungsspannungsbereich bis 5,5V und nicht nur bis 3,6V abdeckt
Gibt noch diesen Compiler für die verschiedenen Sprachen: http://www.mikroe.com/mikroc/pic/ Ist aber nicht umsonst. Würde ihn aber jedem anderen Compiler vorziehen. Aber ist halt Geschmacksache. Da es von allen Compiler Demos gibt, kann man es ja ausprobieren, was einem am besten liegt.
Carsten Sch. schrieb: > Welche 8 Bit Liste meinst du? > In der Produktübersicht der PIC18 ist der enthalten... Da fehlte mir der Überblick. Beim Aufruf dieser Unterrubrik "8-bi-Pic" war mir nicht aufgefallen, dass es da rechts noch so ein Eingabefeld gibt, und das ist immer vorgeingestellt auf "newest". Gettz habich abba den gaanz vollen Überblick......über die genannte Liste. Es wird jetzt also dieses PicKit3 mit Demoboard, das C gibts ja gleich dazu, und damit gehts einfach mal los. Muss jetzt leider weg, die heilige 20:00 Uhr Zeit mit der Kultsendung "Nachrichten" im Ersten beginnt. Husch.... und Grüße und Danksagungen an ALLE, wilhelmT
So, das PICkit 3 debug express ist bestellt. Ob's was wird, ist eine andere Sachek. Die Bestellung erfolgte bei Farnell. Die scheinen etwas eigen, rigoros zu sein. Da war ich Kunde, konnte mich aber heute nicht einloggen, die Daten waren futsch. Hab' mich neu angemeldet, obs geklappt hat, wird die Zukunft zeigen. Jetzt suche ich weiter nach Tutorials für C und entspr. Büchern. Gruß, wilhemT
wilhelmt schrieb: > So, das PICkit 3 debug express ist bestellt Die Dokumentation zu dem Teil war mal recht gut. Leider gibt es soweit ich weiß noch keine neue Version (für MPLAB-X) das kann ziemlich frustrierend werden, falls du versuchst dich durch die alte Doku mit den neuen Tools zu arbeiten. Als Neueinsteiger die "alte" IDE zu verwenden ist natürlich auch wieder blöd ... Du kannst dir auch hier (dort der erste link ) http://picforum.ric323.com/viewtopic.php?f=60&t=70 was von mir anschauen, das irgendwie nie fertig wird aber für das Anlegen des ersten Projektes mit der MPLAB-X hilfreich sein könnte. (Momentan schreibe ich gerade mal wieder dran rum, weil auch bei unseren Studenten NULL Vorkenntnisse in C vorhanden zu sein scheinen) Ich habe hier auch so ein Set rumliegen, dass ich zwar schon lange nicht mehr benutzt habe. Frag lieber gleich nach wenn du wirklich mit der mitgelieferten Doku nicht zurecht kommst. Irgendeiner wird schon helfen. Die mit den Kits mitgelieferte Software ist meist auch nicht auf dem aktuellen Stand, weil das alles sich rasend schnell ändert :-( Der "neue" XC8 Compiler mag zwar in der PRO Version ganz toll sein, aber wenn du nur die FREE version benutzen möchtest, dann solltest du entweder den älteren C18 Compiler verwenden oder dir niemals das Disassembly anschauen ! Ansonsten viel Spass !!!
:
Bearbeitet durch User
Volker SchK schrieb: > Ich habe hier auch so ein Set rumliegen, dass ich zwar schon lange nicht > mehr benutzt habe. Frag lieber gleich nach wenn du wirklich mit der > mitgelieferten Doku nicht zurecht kommst. Hallo Volker, ich komme nicht zurecht.....Hiiiieeeellfe! War 'n Spaß, das Kit3 ist ja gerade erst bestellt. Allerdings habe ich zu meiner Verwunderung nur 2 Stunden später schon einen Mail von Farnell mit der Bestätigung der Auslieferung erhalten. Wenn UPS jetzt seinem Namen Ehre macht, kann ich morgen das erste Weihnachtspaket auspacken. Was für'n Set hast du denn da rumliegen? Gibts hier im Forum eigentlich - so wie ich das aus anderen Foren kenne - die Möglichkeit, einem anderen F-Mitglied eine PN zu schicken? Das mit der obigen Hilfe ist übringens nicht so ganz fehl. Tatsächlich beginne ich, an grundsätzlichen Überlegung für mein Projekt zu knabbern. Da besteht z.B. die Möglichkeit, neben dem ursprünglich angepeilten Sensor, der ein PWM-Signal sendet, einen anderen Sensor zu verwenden. Das ist so'n NTC, der eine fürchterlich exponentielle Kennlinie hat. Da werde ich gleich erst mal ein Weilchen über die Forensuche etwas zu finden versuchen. Falls ich da nichts finde, erstelle ich dann doch noch einen Fred. Je nach Such- und Lese-Länge gleich kann es aber sein, dass ein evtl. neuer Fred erst morgen eingestellt wird. Melde dich mal wegen des Sets. Grüße, wilhelmT
Angehängte Dateien:
-
uC_Quick_2012.png
130 KB
wilhelmT schrieb: > Was für'n Set hast du denn da rumliegen? > Gibts hier im Forum eigentlich - so wie ich das aus anderen Foren kenne > - die Möglichkeit, einem anderen F-Mitglied eine PN zu schicken? Na, ein PK3 DebugExpress. Habe ich mal gekauft als es bei Farnell fast billiger war als das PK3 alleine. Im Labor mit den Studenten benutzen wir jetzt allerdings einen eigenen Bausatz den die für 10€ (etwas unter dem Einkaufspreis ;-) kaufen können. Dann lernen die auch noch ein bisschen löten. PM gibt es glaube ich schon. Habe ich noch nicht probiert. Bin neu hier ;-) Ich muss mal schauen ob ich ein Bild von unserem Demo board posten kann (wie das hier funktioniert) wilhelmT schrieb: > Da besteht z.B. die Möglichkeit, neben dem ursprünglich angepeilten > Sensor, der ein PWM-Signal sendet, einen anderen Sensor zu verwenden. > Das ist so'n NTC, In was für einem Medium willst du denn die Temp. messen ? Sensoren gibt es bestimmt wie Sand am Meer. Analoge, I2C, ... Für die Anzeige vielleicht ein LCD ? <edit> Test Bild hochladen Das Bild zeigt eine etwas ältere Version Neu unten rechts nur 2 Taster und einen Encoder mit Tastfunktion in der Mitte Anderer USB-Seriell Wandler links unter dem PIC (jetzt MCP2200 in MSSOP und USB Buchse nicht auf Unterseite)
:
Bearbeitet durch User
wilhelmT schrieb: > Gibts hier im Forum eigentlich - so wie ich das aus anderen Foren kenne > - die Möglichkeit, einem anderen F-Mitglied eine PN zu schicken? Ich weiß nicht, ob du dafür registriert sein musst. Aber ansonsten kannst du jemanden eine PN schicken, derjenige bekommt die Nachricht dann per Mail an die angegebene Adresse. wilhelmT schrieb: > Das ist so'n NTC, der eine fürchterlich exponentielle Kennlinie hat. Da > werde ich gleich erst mal ein Weilchen über die Forensuche etwas zu > finden versuchen. Meines Wissens haben NTCs ebenso wie Pt100 eine feste Formel, mit der man aus dem Widerstandswert die Temperatur berechnen kann. Also brauchst du nur den Widerstand messen (z.B. mit einem Konstantstrom betreiben und dann die Spannung mittels ADC messen) und dann in C die Formel einfügen, mit dem Widerstandswert als Argument/Variable. Ggf spuckt dir da Wikipedia was zu der Formel aus oder ggf auch das Datenblatt des Sensors
Be Ti schrieb: > Softwaremäßig wäre dann noch zu klären, wie ich einen möglichst > einfachen Einstieg in C finden würde. Mein Englisch reicht zum Lesen von > Büchern, für engl. Videos leider nicht (zu schnell, zuviel Slang). Ein > gutes deutsches Buch wäre der Bringer. Microchip hat da so ein Wiki (natürlich auf Englisch) Könnte aber trotzdem hilfreich sein. Da gibt es auch ein Tutorial: - Fundamentals of the C Programming Language - http://microchip.wikidot.com/tls2101:start Das Tutorial ist natürlich speziell auf µCs angelegt. Super ist auch das Forum (wieder Englisch) http://www.microchip.com/forums Da habe ich mich ursprünglich unter anderem auch deshalb angemeldet, um meine Englischkenntnisse etwas zu verbessern. (ok, super sind eigentlich die Leute im Forum, das Forum hat manchmal mit seiner Software arge Probleme) Leider hilft dir keiner dadurch dass er deine sprachliche Ausdrucksweise korrigiert aber allein durch lesen lernt man auch ein bisschen. Zur Not muss dann eben der Leo oder Google oder ... übersetzen. Wie irgendwer schon weiter oben erwähnt hat, ganz ohne Englisch wird es nicht gehen, weil Datenblätter und die Dokumentation der Tools ... Lesen ist am Anfang auch leichter als zuhören oder gar sprechen
:
Bearbeitet durch User
Michael Skropski schrieb: > Meines Wissens haben NTCs ebenso wie Pt100 eine feste Formel, mit der > man aus dem Widerstandswert die Temperatur berechnen kann. Registriert bin ich. Für den Sensor, es ist der Typ "Z-S 088", habe ich ein sehr schönes Datenblatt des Herstellers. In dem befindet sich keine Formel, sondern eine Tabelle, welche für die Temperaturen im Abstand von je 5 ° C den dazu passenden Widerstandswert listet. Da ich über keinerlei Erfahrungen verfüge, wie sowas in einen MC einzubringen ist, fehlt mir auch die rechte Vorstellung. Meine Suche hier im Forum ergab so Vorschläge wie: Die Daten in Excel eingeben, das erstellt dann eine Formel. Oder es gab so Hinweise auf eine Tabelle, die man im MC anlegen solle. Aber weder habe ich jemals eine Formel mit Excel erstellt, noch in einem MC eine Tabelle angelegt. Da muss erst noch diverse Basisarbeit erledigt werden. Das UPS-Paket kommt heute, sitze hier schon in allen Startlöchern, und bereite ein Extra-Hd dafür vor! Gruß, wilhemT
Volker SchK schrieb: > Wie irgendwer schon weiter oben erwähnt hat, ganz ohne Englisch wird es > nicht gehen, weil Datenblätter und die Dokumentation der Tools ... > Lesen ist am Anfang auch leichter als zuhören oder gar sprechen Danke für die Hinweise auf das Microchip-Tutorial und das Pic-Forum. Bin noch nicht dazu gekommen, in diesem F nach zu schauen. Mache ich aber heute im Laufe des Tages. Nein, ohne Englisch geht da nicht allzu viel. Mit Datenbücher- bzw. Blättern komme ich schon zurecht, sonst hätte ich auch nicht mein damaliges Projekt mit der Haussteuerung hinbekommen. Ein Anfänger-Tutorial für C wäre mir in Deutsch aber schon lieber. Und bis ich die engl. sprachigen Videos gleich beim ersten Male verstehe, wird noch so manches Elektron bewegt werden müssen. Gruß, wilhemT
Bei dem Tutorial im Wiki handelt es sich nicht um ein Video ... Im Tutorial wird eigentlich ein XC16 Compiler (für 16bit PICs) benutzt, es dürfte aber kein großes Problem sein das ganze einfach mit einem 8bit Compiler durch zu spielen.
:
Bearbeitet durch User
Volker SchK schrieb: > Du kannst dir auch hier (dort der erste link ) > http://picforum.ric323.com/viewtopic.php?f=60&t=70 > was von mir anschauen, das irgendwie nie fertig wird aber für das > Anlegen des ersten Projektes mit der MPLAB-X hilfreich sein könnte. > (Momentan schreibe ich gerade mal wieder dran rum, weil auch bei unseren > Studenten NULL Vorkenntnisse in C vorhanden zu sein scheinen) So, habe gerade mal den Link verfolgt, und bin auf die deut. Anleitung gestoßen. Katastrophe! Nicht die Anleitung, aber mein Drucker verschlang alles verfügbare Papier und gönnte sich gleich noch 'ne neue Schwarzpatrone! Das ist ja was hoch Erbauliches. Damit werde ich mich nun in den nächsten Tagen beschäftigen. Danke für den Link, danke für dieses Tutorial, und ......ach ja, Volker.....nicht müde werden beim Weiterschreiben! Wir, die Unwissenden, warten darauf! Gruß, wilhemT
wilhelmt schrieb: > . In dem befindet sich keine Formel, sondern > eine Tabelle, welche für die Temperaturen im Abstand von je 5 ° C den > dazu passenden Widerstandswert listet. Bei Wikipedia sind 2 Formeln: de.wikipedia.org/wiki/Heißleiter#Grundlagen Die erste ist eine Näherung und die 2. ist wohl die genaueste. Die für die erste Formel benötigten Koeffizienten sollten eigentlich im DB stehen. In C würde es dann ungefähr so aussehen:
1 | Temp = B*Tn/(B+ln(Rt/Rn)*Tn); |
Dazu müsste man dann die math.h einbinden, um die ln-Funktion zu haben. Vlt gibt es dazu auch eine Näherung als Polynom oder so...
wilhemt schrieb: > Katastrophe! > Nicht die Anleitung, aber mein Drucker verschlang alles verfügbare > Papier und gönnte sich gleich noch 'ne neue Schwarzpatrone! Also ausgedruckt hätte ich das ja nicht unbedingt. Ist noch zu unfertig
wilhelmt schrieb: > Jetzt suche ich weiter nach Tutorials für C und entspr. Büchern. Wenn du das PICkit3 Debug Express gekauft hast - speziell dafür gibt es das Dokument "PICkit3 Debug Express - PIC18F45K20 MPLAB C Lessons". Filename 41370C.pdf. Der C Code für die Beispiele ist nicht ganz so trivial zu finden (ich habe damals eine Weile gesucht). Die Screenshots zeigen zwar das alte MPLAB. Aber wenn man nicht gerade Computer-Legastheniker ist, dann kann man das auch für MPLAB-X verwenden. wilhelmT schrieb: > Gibts hier im Forum eigentlich - so wie ich das aus anderen Foren kenne > - die Möglichkeit, einem anderen F-Mitglied eine PN zu schicken? Dafür muß man sich im Forum registrieren. Da deine Postings immer noch von einem anonymen "Gast" kommen, hast du das anscheinend nicht.
Axel Schwenke schrieb: > Wenn du das PICkit3 Debug Express gekauft hast - speziell dafür gibt es > das Dokument "PICkit3 Debug Express - PIC18F45K20 MPLAB C Lessons". > Filename 41370C.pdf. Der C Code für die Beispiele ist nicht ganz so > trivial zu finden (ich habe damals eine Weile gesucht). Der Code ist mitsamt Anleitung auf der CD beim PICkit, man findet es aber auch auf der Microchip Homepage. Immerhin 12 Beispiele. Denn ich habe ja auch erst relativ neu das PICkit3 Debug Express mit dem Board und noch ein paar separaten Bausteinen PIC18F26K20 fürs Steckbrett. Die Beispiele sind wohl für den obsoleten C18-Compiler geschrieben, ich mußte sie etwas für den XC8-Compiler umgestalten. Z.B. Ärger mit den Pragmas, was ein Compiler kennt, der andere nicht. So viel mal wieder zu C und Portierbarkeit.
Axel Schwenke schrieb: > Dafür muß man sich im Forum registrieren. Da deine Postings immer noch > von einem anonymen "Gast" kommen, hast du das anscheinend nicht. Bei Thread Start war er anscheinen angemeldet sonst meist nicht (Ich kenn mich aber selber noch nicht aus) Nonsens schrieb: > Die Beispiele sind wohl für den obsoleten C18-Compiler geschrieben, ich > mußte sie etwas für den XC8-Compiler umgestalten Ich denke, dass man den C18 schon noch ganz gut verwenden kann. Der Umstieg ist nicht so schlimm, wenn man erst mal damit begonnen hat in C zu programmieren. MCHP hat da auch einen # MPLAB C18 to XC8 C Compiler Migration Guide # Persönlich schreibe ich meine kleinen Beispiele oder inzwischen so, dass sie mit beiden Compilern laufen. Ich hänge noch am C18 und der XC8 in der Free oder Lite Version ist grausig, wenn man Studenten die Resultate von Programmen in Assembler und C zeigen will.
:
Bearbeitet durch User
Volker SchK schrieb: > Ich denke, dass man den C18 schon noch ganz gut verwenden kann. Na klar. Fürs Hobby wahrscheinlich sowieso. Aber heute leiden ja alle an schneller Veraltung, es muß fast täglich nachgeschaut werden, und bei Erscheinung eines Updates sofort herunter ziehen und installieren. Ich bin es aus den 1990-ern sogar noch gewohnt, daß man mal mit einem 10 Jahre alten Tool arbeitete. Das war damals oft so, und keiner dachte sich was dabei. An neue Dinge kam man ohne Internet eh nicht so schnell dran, besonders als Hobbyist. Volker SchK schrieb: > Ich hänge noch am C18 und der XC8 in der Free oder Lite Version ist > grausig, wenn man Studenten die Resultate von Programmen in Assembler > und C zeigen will. Was ist so grausig? Formatierung oder der Code selbst? Sorry, ich schaute da noch nicht hinein. Das geht im Augenblick nicht, weil ich gerade erst einen neuen PC aufsetze, der alte starb vergangene Woche. Ein Compiler der Firma HI-TECH für den PIC12F629 erzeugte wirklich grausiges Listing. Da finden 100 Katzen keine Maus mehr drinne. Den C18 werde ich mir bestimmt auch noch mal herunter laden, und kann dann vergleichen.
Nonsens schrieb: > Was ist so grausig? Formatierung oder der Code selbst? Der Code ! How to explain XC8 / Hi-Tech generated code to our students -> http://www.microchip.com/forums/m668751.aspx Oder das hier:
1 | void main() |
2 | {
|
3 | while (1) { |
4 | if(mGET_BTN_ENC()) mSET_LED_2_ON(); |
5 | else mSET_LED_2_OFF(); |
6 | |
7 | for (time = 0; time < 62500; time++) {;} // wait 1/2 sec. ??? |
8 | mTOG_LED_3(); // then toggle LED |
9 | }
|
10 | }
|
C18 Lite
1 | 75: for(time = 0; time < 62500; time++){;} // wait 1/2 second
|
2 | 00B0 0100 MOVLB 0 // variable time in BANK 0 |
3 | 00B2 6B8A CLRF 0x8a, BANKED // an Adresse 0x8a bis 0x8b |
4 | 00B4 6B8B CLRF 0x8b, BANKED // löschen |
5 | 00B6 0E42 MOVLW 0x24 // Am Beginn der for schleife |
6 | 00B8 5D8A SUBWF 0x8a, W, BANKED // Vergleichswert 62500 == 0xF424 |
7 | 00BA 0E0F MOVLW 0xf4 // ins Arbeitsregister W laden |
8 | 00BC 598B SUBWFB 0x8b, W, BANKED // und von time abziehen |
9 | 00BE E204 BC 0xc8 // Ist Ergebnis = 0 -> Schleife verlassen |
10 | 00C0 2B8A INCF 0x8a, F, BANKED // Sonst time LowByte um 1 erhöhen |
11 | 00C2 0E00 MOVLW 0 // High Byte mit carry |
12 | 00C4 238B ADDWFC 0x8b, F, BANKED // aus increment LowByte |
13 | 00C6 D7F7 BRA 0xb6 // Zur Abfrage am Anfang der Schleife |
14 | 76: mTOG_LED_3(); // then toggle LED |
15 | 00C8 748A BTG 0xf8a, 0x2, ACCESS |
16 | 00CA D7ED BRA 0xa6 |
17 | 77: } |
XC8 Free:
1 | 75: for(time = 0; time < 62500; time++){;}
|
2 | 7FAC 0E00 MOVLW 0x0 |
3 | 7FAE 6E02 MOVWF 0x2, ACCESS |
4 | 7FB0 0E00 MOVLW 0x0 |
5 | 7FB2 6E01 MOVWF time, ACCESS |
6 | 7FB4 0E24 MOVLW 0x24 |
7 | 7FB6 5C01 SUBWF time, W, ACCESS |
8 | 7FB8 0EF4 MOVLW 0xF4 |
9 | 7FBA 5802 SUBWFB 0x2, W, ACCESS |
10 | 7FBC A0D8 BTFSS STATUS, 0, ACCESS |
11 | 7FBE D001 BRA 0x7FC2 |
12 | 7FC0 D001 BRA 0x7FC4 |
13 | 7FC2 D002 BRA 0x7FC8 |
14 | 7FC4 D00C BRA 0x7FDE |
15 | 7FC6 D00B BRA 0x7FDE |
16 | 7FC8 4A01 INFSNZ time, F, ACCESS |
17 | 7FCA 2A02 INCF 0x2, F, ACCESS |
18 | 7FCC 0E24 MOVLW 0x24 |
19 | 7FCE 5C01 SUBWF time, W, ACCESS |
20 | 7FD0 0EF4 MOVLW 0xF4 |
21 | 7FD2 5802 SUBWFB 0x2, W, ACCESS |
22 | 7FD4 A0D8 BTFSS STATUS, 0, ACCESS |
23 | 7FD6 D001 BRA 0x7FDA |
24 | 7FD8 D001 BRA 0x7FDC |
25 | 7FDA D7F6 BRA 0x7FC8 |
26 | 7FDC D000 BRA 0x7FDE |
27 | 76: mTOG_LED_3(); // then toggle LED |
28 | 7FDE A88A BTFSS LATB, 4, ACCESS |
29 | 7FE0 D001 BRA 0x7FE4 |
30 | 7FE2 D002 BRA 0x7FE8 |
31 | 7FE4 0E01 MOVLW 0x1 |
32 | 7FE6 D001 BRA 0x7FEA |
33 | 7FE8 0E00 MOVLW 0x0 |
34 | 7FEA 6E03 MOVWF 0x3, ACCESS |
35 | 7FEC 3A03 SWAPF 0x3, F, ACCESS |
36 | 7FEE 508A MOVF LATB, W, ACCESS |
37 | 7FF0 1803 XORWF 0x3, W, ACCESS |
38 | 7FF2 0BEF ANDLW 0xEF |
39 | 7FF4 1803 XORWF 0x3, W, ACCESS |
40 | 7FF6 6E8A MOVWF LATB, ACCESS |
41 | 7FF8 D7D9 |
Was soll man dazu noch sagen ? (Sorry, die Versionen die das verbrochen haben weiß ich leider nicht mehr)
:
Bearbeitet durch User
Genau wegen dieser absurden "Ergebisse" beim XC8 verwende ich auch den C18 bzw. den cc5x für die 10F, 12F und 16F PICs. Beim cc5x wird auch in der freien Version ASM-Code erzeugt, den man von Hand fast nicht mehr besser machen kann. Einzig die fehlende automatische Optimierung des Bank-Switchings (Eliminierung unnötiger Befehle) vermisse ich. Da lässt sich zur Not aber auch manuell nachsteuern, wenn es im PIC eng wird, in dem man den Code umstrukturiert, das automatische Generieren des Bank-Switching-Codes partiell abschaltet. Dann dafür sorgen, dass die Variablen in den betreffenden Bereichen möglichst auf einer Bank liegen, und die Bankauswahl manuell vornehmen. So bekommt man einen sehr kompakten Code.
:
Bearbeitet durch User
Zunächst Formales: Klar bin ich registriert. Hatte nur neulich festgestellt, dass man eine Antwort auch ohne Einloggen einstellen kann, man muss nur seinen Nicnamen einmal eingeben. Das geht einfach schneller, und deswegen tauchte ich zuletzt immer als angeblicher Gast auf. So, UPS war da, im PIKcit3 debug express - Kit lag keine Cd/DVD bei. Na ja, MCHP empfiehlt ja selbst, sofort nach neuester SW zu schauen. Habe da also das MPLAB IDE downgeladen, und auch den XC8-Compiler. Nach dem C18-C habe ich auch geschaut, der ist aber wohl ein bischen versteckt. Es gibt im Archive ein angebliches Update für einen C-Compiler für 8bit-MCUs in der Größe von ca. 70 MB. Das wird er wohl sein. Frage, - pardon - vornehmlich an Volker, weil ich dessen Script hier habe und durcharbeiten möchte: Wäre es besser, doch den "alten" Compl. zu installieren u zu nutzen? Nicht, dass ich mich jetzt zum Kenner aufschwingen möchte, aber der obige Codevergleich läßt ja schon Unterschiede erblicken. Allerdings möchte ich auch ketzerisch anfügen, dass mich beim Erlernen der C-Sprache ja der Assembler-Code nicht so unbedingt interessieren muss! Oder sehe ich das falsch? Ganz sicher ist es mir zunächst egal, ob der A-Code zu optimieren wäre. Mag sein, dass gestandene C-ler schon aus Berufsehre da eingreifen wollen und müssen, aber mich interessiert doch C! Wie seht ihr das? Dann würde ich gerne wissen, ob ich von der MCHP-Homepage noch dieses laden sollte, was gleich unter dem MPLAB und XC8-Compiler angeboten wird: - MPLAB Code Configurator - Emulation Extension Paks - Micr. Libraries für Application ( die Current V von 2014 scheint abgespeckt zu sein, die Leagcy-V von 2013 noch komplett) Grüße, wilhelmT
:
Bearbeitet durch User
Hi, Nonsens schrieb: > Ein Compiler der Firma HI-TECH für den PIC12F629 erzeugte wirklich > grausiges Listing. Da finden 100 Katzen keine Maus mehr drinne. Zur Erklärung (für diejenigen die noch nicht wissen): Microchips XC8 == weiterentwicklung des HiTEch Compilers! Microchip hat die Firma HiTEch vor einigen Jahren aufgekauft und führt deren Compiler nun als XC Serie fort, da diese insgesamt (in der Vollversion) wohl stabiler/effizienter und über die Serien auch identischer sind als die Microchip C18/C24/C32. Da HiTech aber im Gegensatz zur Fa. Microchip ihren Lebensunterhalt dadurch verdiente das Leute deren Compiler kauften, während Microchip das Compilergeschäft rein als Supportmaßnahme zur Unterstützung des Kundeninteresses an Microchip µC betrachtet hat, wurde da aber (nachvollziehbarerweise) scheinbar erheblich mehr Wert auf einen deutlichen Leistungsunterschied zwischen der Freien und der Bezahlversion gelegt. Die freie Version wurde also bewusst DEUTLICh ausgebremst - und das findet sich bei den XC Compilern immer noch SO deutlich wieder. Bei den alten NON-X Compilern waren die Unterschiede deutlich kleiner... Wobei das aber für den Hobbyisten oder Kleinstückzahlanwender relativ egal ist. Notfalls nimmt man halt das Schwestermodell eine Nummer größer mit ansonsten absolut identischen Eigenschaften (Pinning/Peripherie/Befehlssatz), der Preisunterschied in Kleinstückzahlen ist meistens marginal. Und wenn man es dann wirklich einmal geschafft hat den größten µC einer Typenreihe (wie im Fall der K20 also den Pic18F46K20) vollzubekommen, dann aktiviert man hat die 60 Tage Testphase des Compilers mit voller Optimierung... Nonsens schrieb: > Na klar. Fürs Hobby wahrscheinlich sowieso. Aber heute leiden ja alle an > schneller Veraltung, es muß fast täglich nachgeschaut werden, und bei > Erscheinung eines Updates sofort herunter ziehen und installieren. Teilweise hast du recht, andererseits gibt es durchaus auch ganz Handfeste Gründe den neuen Compiler zu nutzen: Für die µC die zur Zeit der NON-X C-Compiler bereits auf den Markt waren kann man meistens diese Problemlos weiterverwenden. Da gebe ich dir voll recht. Ich verwende z.B. für ältere Projekte und davon ausgehenden Weiterentwicklungen auch noch die "alte" Umgebung mit MPLAB und den "alten" Compilern. (Ohne not stelle ich die Projekte nicht um, das gibt jha auch regelmäßig neue Überraschungen) Allerdings hat Microchip in der Zwischenzeit einige sehr interessante µC herausgebracht die aber nicht(bzw nur mit viel Aufwand) zu den alten Compilern kompatibel sind. Da ist man dann gezwungen auf die XC Serie in der MPLABX Umgebung zu gehen. Ganz neue Projekte beginne ich aber mittlerweile nur mit den XC Compilern. Egal ob der C18/C24/C32 den Baustein unterstützt oder nicht. Allerdings -sofern möglich- mit der alten MPLAB Oberfläche. Ich weiß es gibt dazu andere Meinungen, aber ich mochte diese Oberfläche lieber. Da es sich dabei aber nur um die IDE handelt habe ich ja jederzeit die Möglichkeiten innerhalb weniger Minuten das Projekt in ein MPLABX Projekt zu verwandeln und damit dann auf dem aktuellen STand zu sein. Der Programmcode bleibt identisch, nur die Projekteinstellungen muss man nach der automatischen Umwandlung zur Sicherheit einmal überprüfen. Klaus schrieb: > Wegen der Preise (und Verfügbarkeit) kann man sich hier > https://www.microchipdirect.com/ orientieren. Da kann man IMHO auch als > Privater kaufen. Ja, da kann man als Privater kaufen. Das ist auch einer der Vorteile von Microchip. Man bekommt praktisch jeden Baustein in jeder Bauform auch als Hobbyist. Selbst die ganz ausgefallenen. Und das Bezahlbar. (Kein Mindestbestellwert und 7 Euro Versand (bis 3kg) nach Deutschland ) Allerdings ist Microchipdirekt für die meisten Hobbyisten auch wirklich nur dann eine gute Quelle wenn die sich "richtig" mit Microchip MAterial ausstatten wollen oder aber es tatsächlich um einen "exotischen" µC handelt. Da gibt es halt nur Microchip µC (und Entwicklungszubehör). Wenn man also mehr als nur dieses braucht muss man für ein Projekt mindestens bei zwei Händlern bestellen. Also zweimal Versandkosten. Auch wenn sich die Versandkosten bei MC-Direkt durchaus im Rahmen halten, für ein paar Cent Ersparniss beim Artikelpreis rechnet sich das meist nicht. Gruß Carsten
Be Ti schrieb: > Dann würde ich gerne wissen, ob ich von der MCHP-Homepage noch dieses > laden sollte, was gleich unter dem MPLAB und XC8-Compiler angeboten > wird:... Brauchst du nicht ! Wenn du C18 haben willst, dann gib auf der MCHP Seite "C18" bei der suche ein -> http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=SW006011 Nimm gleich den Lite, vergiss 60 Tage evaluation.
:
Bearbeitet durch User
Hi, Be Ti schrieb: > [...]Nach dem > C18-C habe ich auch geschaut, der ist aber wohl ein bischen versteckt. > Es gibt im Archive ein angebliches Update für einen C-Compiler für > 8bit-MCUs in der Größe von ca. 70 MB. Das wird er wohl sein. JA - Das ist er, das müsste eine "normale" Install sein. > Frage, - pardon - vornehmlich an Volker, weil ich dessen Script hier > habe und durcharbeiten möchte: Wäre es besser, doch den "alten" Compl. > zu installieren u zu nutzen? Ich bin zwar nicht Volker, aber: Es ist gerade zum Lernen für Einsteiger IMMER das Sinnvollste mit den Tools zu Arbeiten auf die sich das Tutorial was man verwendet bezieht. Ich kenne deines jetzt nicht, aber wenn du z.B. auch mal die "Lesson Files" durchgehen willst, dann besser mit MPLAB (ohne X) und C18. Die notwendigen Anpassungen im Code sind für einen Erfahrenen zwar ein Klacks, aber wenn man gerade erst einsteigt... > Allerdings möchte ich auch ketzerisch anfügen, dass mich beim Erlernen > der C-Sprache ja der Assembler-Code nicht so unbedingt interessieren > muss! Oder sehe ich das falsch? Ganz sicher ist es mir zunächst egal, ob > der A-Code zu optimieren wäre. Mag sein, dass gestandene C-ler schon aus > Berufsehre da eingreifen wollen und müssen, aber mich interessiert doch > C! Wie seht ihr das? Zum Einstieg kann man definitiv erst einmal Ignorieren was der Compiler so produziert. Zumindest als Hobbyist oft auch dauerhaft. So lange es läuft läuft es ja. Wichtig wird der produzierte ASM Code erst wenn man in Stückzahlen produzieren möchte (da dann auch 10ct. Preisunterscheid zwischen den µC Varianten plötzlich sehr viel Geld sein können) oder aber wenn etwas nicht so klappt wie es klappen sollte. Was man sich natürlich trotzdem mit der Zeit aneignen sollte, auch wenn man in C Schreibt, das ist mindestens ein Grundverständniss von ASM um im Fehlerfall halt doch mal ins Listing schauen zu können was da passiert sein könnte. (oder ähnliches). Aber das scheint ja bereits vorhanden zu sein. > Dann würde ich gerne wissen, ob ich von der MCHP-Homepage noch dieses > laden sollte, was gleich unter dem MPLAB und XC8-Compiler angeboten > wird: > - MPLAB Code Configurator Der ist nicht für MPLAB sondern für MPLAB-X Wenn du mit MPLAB-X arbeiten willst kannst du den Laden. TIPP: Man kann problemlos die X und NON X Tools nebeneinander Installieren. WEnn man mit dem Pickit3 arbeiten braucht man da nichts weiter zu beachten als das nicht beide IDE gleichzeitig geöffnet sein sollten, da immer nur eine das PK3 verwenden kann. Man kann also lustig hin und her wechseln. (Beim ICD3 muss allerdings vor jedem wechsel der IDE ein Dienstprogramm zum Treiberumstellen aufgerufen werden, beim ICE weiß ich es jetzt gerade nicht -aber PK3 geht wie gesagt ohne jede Einschränkung) > - Emulation Extension Paks Bis jetzt nichts mit zu tun gehabt. > - Micr. Libraries für Application ( die Current V von 2014 scheint > abgespeckt zu sein, die Leagcy-V von 2013 noch komplett) Im Moment würde ich der Legacy2013 ganz klar den Vorzug geben. Besonders wenn auch noch an ein Arbeiten mit der NON-X IDE gedacht wird. Da sind die Files für X und Non-X beide drin und auch für die 32Bit µC ist noch alles dabei. Die ganze 32Bit Serie will Microchip ja auf die Harmony-Umgebung umstellen was ich aber für recht unglücklich halte da so die von mir geschätzte Kompatibilität der Familien völlig verloren geht. (als ERGÄNZUNG währe "Harmony" sicherlich zu begrüßen, aber das es neue 32Bit Frameworks nur noch dafür geben soll stört mich erheblich) Gruß Carsten
Carsten Sch. schrieb: > Nonsens schrieb: >> Na klar. Fürs Hobby wahrscheinlich sowieso. Aber heute leiden ja alle an >> schneller Veraltung, es muß fast täglich nachgeschaut werden, und bei >> Erscheinung eines Updates sofort herunter ziehen und installieren. > > Teilweise hast du recht, andererseits gibt es durchaus auch ganz > Handfeste Gründe den neuen Compiler zu nutzen: Also wenn jemand sowieso daran denkt sich die POR Version anzuschaffen dann auf jeden Fall. Auch sollte man erwähnen, dass der C18 nur PIC18 kann, der XC8 aber alle 8bit PICs (PIC10, PIC12, PIC16). Egal ob C für PIC10/12 jetzt unbedingt sein muss.
:
Bearbeitet durch User
Carsten Sch. schrieb: > Be Ti schrieb: >> [...]Nach dem >> C18-C habe ich auch geschaut, der ist aber wohl ein bischen versteckt. >> Es gibt im Archive ein angebliches Update für einen C-Compiler für >> 8bit-MCUs in der Größe von ca. 70 MB. Das wird er wohl sein. > JA - Das ist er, das müsste eine "normale" Install sein. Im "Archiv" ist nicht die neueste Version (aktuell 3.47)
Be Ti schrieb: > Frage, - pardon - vornehmlich an Volker, weil ich dessen Script hier > habe und durcharbeiten möchte: Wäre es besser, doch den "alten" Compl. > zu installieren u zu nutzen? Im momentanen Stand sicher ja. Ich bin allerdings gerade dabei das ganze auch für XC8 zu erweitern, weil das bei uns auch im Labor verwendet wird. (grrrrr, ich hasse XC8 FREE ;-)
Ja, XC8 in der lite-Version macht schon deutlich mehr Code, bei meinen tests ca doppelt so viel. Das ist bei den XC16&32 aber nicht so gewesen. Da frage ich mich, wieso sie beim XC8 sowas machen und bei den anderen nicht. Ich denke, 8bitter werden von mehr Hobbyisten genommen, aber die werden sich wohl kaum für 1000$ ne Pro Version holen. Ich nutze den MikroC Compiler. Die Oberfläche und Funktionen find ich irgendwie besser. Man hat sogar quasi die gleiche IDE für alle PICs und für ARM und AVR. Wenn ich also mal nen ARM nehmen will, kenne ich die IDE schon. Ist allerdings Codegrößenbeschränkt als Lite-Version. Dafür bekommt man immer die gleiche Optimierung. Bei meinem Test war das Ergebnis vom MikroC so groß wie die ca. 2. beste Optimierungsstufe vom XC8. kostet dafür aber auch "nur" 250$ statt 999$. Aber für dich ist erstmal wichtig, dass du irgendeinen Compiler hast, um loslegen zu können. Wenn du C kannst, kannst du ja immer nochmal gucken, was es noch so gibt.
Michael Skropski schrieb: > kostet dafür aber auch "nur" 250$ statt 999$. Wenn man für 10 cent mehr (oder sogar weniger) die CPU mit dem doppelten Speicher bekommt, kann man sich ausrechen, wann sich die 250$ gegen den free Compiler lohnen Beispiel, Einzelstück PIC12F1822 3,5k Flash 0,96$ DIP 0,88$ SOIC PIC12F1840 7,0k Flash 1,03$ DIP 0,95$ SOIC MfG Klaus PS statt Mannwochen in die Assemblerprogrammierung zu versenken, massiert ein guter Einkäufer die paar Cent in wenigen Minuten weg. Und das schafft auch noch sein Nachfolger, wenn der Assemblerprogrammierer schon lange nicht mehr zur Verfügung steht, sondern nur noch C-Programmierer zu bekommen sind.
Habe nun fleißig mit Bemühen den XC8-Compiler installiert, das MPLAB X IDE gestartet, diverses gelesen und nun - na klar - gleich ein Problem eingehandelt beim Versuch, ein Demoprojekt zu starten. Habe auch den Microchip-Support per Email angeschrieben, wann die antworten....? Siehe meinen Bericht "PIC Demoboard abgeschossen oder falscher Treiber ?" im Forum. Was mich wurmt, ist das Fehlen der nicht mitgelieferten CD mit den üblichen techn. Einweisungen und den wirklich passenden Demoprogrammen. Das hat sich evtl. bitter gerächt, dieses Fehlen. Ist - na klar - auf der MCHP HP für mich auch nicht zu finden. Knurrrrrr.... Gruß, wilhelmT
:
Bearbeitet durch User
Hab' mich ein Weilchen nicht gemeldet, und schreibe nun hier weiter. Weiter....? Ne, alles zurück auf Anfang. Das Demoboard (DB), von dem ich im anderen Fred: Beitrag "PIC Demoboard abgeschossen oder falscher Treiber ?" berichtet hatte, funktioniert nun wieder nicht mehr. Da hatte ich doch mutig versucht, in dem C-Prog für dieses Board nur eine einzige Zahl (für die Länge einer Pause) zu verändern, und dann versucht, das auf dem DB zu laden, aber stattdessen ging gar nichts mehr: Blink- und Schiebestille! Da auch noch jegliche Unterlagen fehlten, sowohl zum DB, als auch zum Pickit3-Brenner, und das MPLAB X IDE sich als nicht intuitiv rausstellte, gings nicht weiter. Frust! Gestern Nachmittag trudelte doch noch eine Mail von Microchip ein, vom deut. Support. Diese Mail enthielt 2 Links, und einer davon brachte zumindest die Unterlagen für das MPLAB zum Vorschein. Die beiden anderen fehlen immer noch. Dafür habe ich aber eine Beschreibung und Prog-Beispiele für das noch etwas einfachere Demo-Board für den PICkit3-Programmer (P3) gefunden, in welchem nur 4 Leds stecken. Und für dieses gibts halt eine Anleitung, in welcher ein Einstiegskurs mit einfachen Prog-Beispielen enthalten ist, und die sind gleichzeitig in Assembler und C geboten. Das hat mir so gut gefallen, dass ich gleich bei MCHP himself auch dieses Demoboard noch bestellt habe. Das werde ich erst mal alles durcharbeiten. Unter den Unterlagen, die ich heute für das MPLAB runtergeladen hatte, war u.a. auch ein File mit einem Poster, auf welchem die Inbetriebnahme des P3P bebildert ist. Und dabei durfte ich feststellen, dass ich da doppelt Pech gehabt hatte. Denn so'n Poster war auch in meinem von Farnell gekauften Demo-Kit dabei, aber.....aber in dessen Poster fehlte aus unerfindlichen Gründen just jener Teil, welcher in Kürzestschritten die Erstellung eines Programms im MPLAB illustriert. Schiete! Es geht also wie in der Andernacher-Springprozession mit meinen C-Bemühungen voran: 1 Schritt nach vorn, einen seitlich nach vorn und einen zurück. Bis ich mit dem MPLAB-X klarkomme, wird es auch noch so bleiben. Au man, als ich dunnemals - vor 17 ? Jahren - mein erstes Pic-Kit kaufte, lagen da zwei ganz dicke Bücher drin, eines beschäftigte sich nur mit dem indiv. PIC-Controller, das andere enthielt sämtliche Prog-Routinen, die MCHP dafür bereit hielt, und das waren viele. Zudem gabs noch eine echte CD mit MPLAB, und Prog-Beispielen...und und und...Früher war doch alles besser! Grüße, wilhelmT
Soll das heissen , du hast schon ein PK2 ???
Oh nein sorry du meinst sicher das aller erste Teil. So was ganz ohne Gehäuse. Liegt bei mir auch noch rum ...
Tja, das hast du von dem PIC Kram. Viele nehmen AVR, kann man machen, würde ich nicht, ich würde dir den MSP430 ans Herz legen. Sehr simpel für den Einstieg, es gibt mehrere Entwicklungsumgebungen und man kann auch ganz einfach mit gcc und dem Texteditor seiner Wahl arbeiten. Cortex-M sind auch recht toll, hier kann ich Silicon Labs, ST und Nordic empfehlen. Allerdings ist die Toolchain insgesamt wesentlich komplizierter aufzubauen, insbesondere wenn du mit C++ arbeiten möchtest. Generell solltest du C am Computer lernen - wesentlich einfacher und die Schnittstellen sind auch wesentlich einfach anzusprechen, UART aufm µC ist etwas ganz anderes als ein printf oder cout...
@ vloki: Bislang habe ich das PICkit 3 debug express - Kit, in welchem der PICkit 3-Programmer enthalten ist und ein Demobard, auf dem ein PIC18F45K20 sitzt, und auf dem ein Port komplett mit Leds bestückt ist. Das ist die etwas erweiterte Einstiegsversion von Microhip. Die "normale" E-Version enthält denselben Progr., aber ein einfacheres Board mit PIC16Fxxx und "nur" 4 Leds (das habe ich jetzt nachbestellt). @ Manfred: Ganz herzlichen Dank für deine Empfehlungen, aber für mich ist der Einstiegs-Zug abgefahren. Habe mich ja - siehe oben - schon beraten lassen, und hatte mich entschieden, auf Grund meiner Vorbelastung mit PIC16F84 bei MCHP zu bleiben. Es gibt so irre viele Möglichkeiten, in die C-Programmierung einzusteigen, sowohl was die Hardware als auch die Software anbelangt. Welches nun der einzig richtige Weg ist, dürfte eine Entscheidung verlangen, die von einem C-Anfänger sicher nicht zu treffen ist. Wenn ich aus dem Rathaus rauskomme, dann weiß ich es..... Gruß, wilhelmT
Manfred schrieb: > Tja, das hast du von dem PIC Kram. Kannst du das überhaupt beurteilen ? Also ich bin seit 15 Jahren glücklich damit. Bestimmt wäre ich auch mit Controllern eines anderen Herstellers genauso glücklich, aber es hat sich halt so ergeben ;-) Vorher habe ich C166 und C51 programmiert, mit Datenbüchern noch auf Deutsch. Geil. Die Entwicklungsumgebung (Keil) war auch ok, nur ein bisschen teuer auf die Dauer. Also ich schätze ich könnte mit allem zurecht kommen. Was man schon 15 Jahre kennt, ist eben einfacher. Nur auf einen richtigen Debugger könnte ich wahrscheinlich nicht mehr verzichten. Programme aufspielen über einen Bootloader und Strings über die serielle Schnittstelle ausgeben wie das anscheinend viele Arduino Fans tun, das kommt mir vor wie in der Steinzeit ... @Willhelm, sei nicht so sprunghaft und kauf nicht ständig neue Boards. Meistens gibt es eine sehr einfache Lösung für ein Problem (ich habe da etwas Erfahrung ;-) Kaufst du dir jedes mal neue Tools in der Hoffnung, dass es mit denen einfacher geht, kaufst du dir nur neue potenzielle Probleme ! Mit einer Detaillierten Beschreibung deines Problems findet sich bestimmt schneller eine Lösung und du erfährts dann vermutlich auch, was du falsch gemacht hast. Das mit der Beschreibung eines Problems ist natürlich nicht so einfach, da habe ich auch so meine Erfahrungen :-(. Meistens lautet die Beschreibung ungefähr so: "Das geht nicht" Dann muss man ca. 5 mal Nachfragen um eine Vorstellung davon zu bekommen was derjenige eigentlich genau getan hat und was er damit bezwecken wollte ... Die andere Mäglichkeit ist ins Blaue hinein zu raten. Wenn man das schon oft genug gemacht hat und schon 100 mal den geichen Fehler gesehen hat, dann erreicht man da auch eine recht hohe Trefferquote. Egal, genug gelabert. Die Doku ist ein echtes Problem, weil sie selten auf dem aktuellen Stand ist !
Angehängte Dateien:
-
test1.jpg
31 KB
Volker SchK schrieb: > sei nicht so sprunghaft und kauf nicht ständig neue Boards. Widerspruch, euer Ehren! Schon der Kauf des zweiten Kits, der 3 gleichen Demo-Boards (DB) - davon eines mit dem gleichen PIC bestückt - hat Nutzen gebracht. Gebracht hat es mir die Erkenntnis, dass ich den mir zugedachten Erfolg mit dem Programmieren des ersten DBs nicht meinem Talent zu verdanken habe, sondern MCHP. Denn das 1. DB war genau wie das 2. DB schlicht vorprogrammiert und brauchte nur Saft! Jetzt fehlen mir hier Smileys, aber sehr! Vom Kauf des 3. DBs, dem ganz einfachen mit 4 Leds verspreche ich mir Vieles, nämlich überhaupt erfolgreich anfangen zu können. Denn zu diesem DB liefert MCHP eine ausführliche, verständliche Anleitung mit und hier wird geboten, was ich gesucht hatte: PIC-Hardware, mit MPLAB zu bearbeiten, in C, und dann einfache, gut erklärte Beispiele. Dass zugleich noch Assembler geboten und auch dringend angeraten wird, sehe ich als zusätzlichen Vorteil. Da ist meine Chance, etwas zu raffen, am größten. Das also werde ich durcharbeiten. Danach kommt das zunächst gekaufte DB dran, und dann sehen wir weiter. Die Lieferung hat MCHP für den 25.12. zugesagt. Das wird eine schöne Beschehrung! > Mit einer Detaillierten Beschreibung deines Problems findet sich > bestimmt schneller eine Lösung und du erfährts dann vermutlich auch, was > du falsch gemacht hast. Ein bischen besser als "geht nicht" kann ich schon beschreiben: Weil ich zu diesem Zeitpunkt noch über keinerlei Doku verfügte, hatte ich im MPLAB rumgestöbert und zu meiner Freude Demo-Progs entdeckt, und eines davon geladen: "PICDEM2PlusPIC18F4520_1". Das enthielt ein Prog - dargestellt in dem Bild - , von dem ich grauenhaft naive C-"Nachwuchskraft" flink annahm, es handele sich um das für meine 1. Demoplatine (mit 7 leds) Passende, welches ein Bit am Port B längs schiebt. In dem hatte ich dann die Zahl 10000 zu einer 1000 verändert, wollte das in das Board schieben, und hatte dazu mit den Symbolen im Projekt (?)-Fenster rumgespielt, also mit den "Projekt Properties", "Refresh Debug Tool Status", "Toggle SW BP", und dann mit denen in der waag. Leiste "Build Projekt", "Run P.","Make and Programm device....", etc. in der stillen Hoffnung, da intuitiv was zu bewirken. Hat ja auch geklappt (fehlt wieder ein Smiley), nix ging mehr. Stand jetzt: Die nötigen Unterlagen (bis auf erweit. DB) liegen endlich vor, teils schon ausgedruckt, bei den ca. 250 Seiten für das MPLAB ziere ich mich noch. Das würde 'ne Tagesbeschäftigung, mein Drucker druckt beidseitig, legt aber nach der 1. Seite eine Trockenpause von fast 10 sek ein.....Werde mich also durch diese Dokus wühlen müssen und warte auf die neue D-Platine, mit der ich dann endlich anfangen möchte. So siehts im Moment aus. Grüße, wilhelmT
:
Bearbeitet durch User
Ok, die zwei Boards sind schon ok. Hätte ich auch empfohlen ;-) ------------------------------------------------------------------------ 12.3 Empfehlenswerte Microchip Einsteiger Kits Das PICKIT 3 Starter Kit beinhaltet ein PICKIT3, eine kleine Demoplatine mit IC-Sockel für 8/14/20 Pin PICs, jeweils einen PIC16F1829-I/P. / PIC18F14K22-I/P und dem größten Umfang an Beispielprogrammen in „C“ und Assembler. ( Der in „C“ den Beispielen verwendete Compiler ist allerdings XC8 ) Auch die PICKIT 2/3 Debug Express Kits sind günstigsten Einsteiger Sets inklusive Programmier- und Debuging- Tool, bei denen der verwendete PIC jedoch verlötet ist. Die User-Guides der Kits sind verhältnismäßig gut, wenn auch manchmal in bestimmten Punkten wie z.B. den Informationen zu „Linkerscripten“ veraltet. Die Beispielprogramme in den User Guides aller Kits, können natürlich auch auf anderer (eigener) Hardware ausprobiert werden ... ------------------------------------------------------------------------ - Da du schon mal proggramiert hast, dürfte die Übertragung auf einen anderen PIC eigentlich nicht das Problem sein, wenn du erst mal wieder drin bist ;-) Was bei deinem Beispiel fehlt sind die Konfigurations-Bits mit den Einstellungen für den Oszillator. Lies dir mal das entsprechende Kapitel durch ! Meine Beispiele müsstest du eigentlich auch leicht auf deine Hardware übertragen können. Es ist immer das selbe, Schaltplan Datenblatt usw. Merkwürdig finde ich auch "PORTB=". PORT ist bei PIC18 ein Eingang und LATB der zugrhärige Ausgang. Wieso wird einem Eingang etwas zugewiesen? Das macht in diesem Fall nichts aus, da das Schreiben von PORT im LAT landet. Ich schau mir das Beispiel mal noch genauer an ...
WilhelmT, was für eine IDE und welchen Kompiler willst du jetzt eigentlich benutzen ?
Na, das frisch installierte MPLAB X-IDE u den XC8. Was mir fehlt, mir ganz persönlich: Ich träume für den Anfang nicht von einem akademischen Höhenflug, sondern wünsche mir dieses: Eine sehr simple Anleitung für die Erstellung eines sehr simplen C-Progs und eine sehr simple, aber genaue Anleitung, die mir vorbetet, was vom Aufrufen des MPLAB X IDEs über das Schreiben des Progs und die genaue Einstellungen und das Programmieren des Demo-Boards an Einzelschritten zu tun ist. Das würde ich mir anschauen, schlicht nach machen wollen, und dann wüßte ich einmal, wie es generell funktioniert. Das würde mir Tage an Einarbeitungszeit ersparen, davon träume ich. Intellektuelle Klimmzüge dürfen gerne warten und pädagogischer Ergeiz darf auch gerne erst später zum Einsatz kommen. Einmal durchblicken....das wäre ein Start nach Maß. Gruß, wilhelmT
Als erstes erstellt man ein neues Projekt File->New Project 1. Chose Project -> Categories: Microchip Embedde -> Projects: Standalone Project 2. Select Device -> Family (Advanced 8-bit...) Device: PIC18F45K20 (K nicht vergessen ;-) 3. --- 4. Select Tool -> PICkit3 (einstecken und Seriennummer auswählen) 5. --- 6. Select Compiler -> XC8 ... 7. nach Belieben (aber kein Netzwerkpfad \\.., Desktop im Netzwerk ...) ((keine Sonderzeichen, Leerzeichen, Umlaute ...)) ------------------------------------------------------------------------ ----- Im Projects Fenster (links) Rechtsklick auf das neu angelegte Projekt: Im Pop-up menue dan NEW -> C Source file (besser nicht main file) - eine neue Datei wird angelegt und sollte auch im Editor geöffnet sein ------------------------------------------------------------------------ ----- In der neuen datei ein paar Kommenttare einfügen /*...mehrzeilige Kommentare */ // Kommentar bis zum Ende der Zeile mit #include <xc.h> wird danach unter anderem (und über 27 Ecken) der Prozessorheader (p18f45k20.h) eingebunden der die Namen sämtlicher Register (und deren Bits) des Prozessors deklariert. ------------------------------------------------------------------------ -------- Als nächstes muss man die Konfigurations Bits des PICs festlegen. Dazu öffnet im Menü Window -> PIC memory views -> Configuration Bits den Dialog und stellt mit Hilfe des Datenblattes ALLE ein. Dann klickt man den Button "Generate Source Code to O..." Button und kopiert den erzeugten Code in die Quelldatei. ------------------------------------------------------------------------ -------- Wenn du soweit bist, poste die Datei hier ;-) <edit> Mit Programmieren in C hat das bisher noch gar nichts zu tun. Es wäre vermutlich gut, wenn du auch noch eine eigene Vorstellung formulieren känntest, was dein erstes Programm tun soll.
:
Bearbeitet durch User
Ich bin mir nicht sicher ob ich hier auch noch meinen Senf zum Besten geben soll. Auch will ich keine Religion betreiben und nur über meine eigenen Erfahrungen berichten. Also was solls... Ich arbeite seit 1999 mit dem CCS PIC Compiler. Das kam so, weil ab damals der CCS bei uns das offizielle Werkzeug für die C Programmierung eines PICs in der Firma bei uns war. Damals hatte ich noch NULL Ahnung mit PICs und kannte bis dahin nur Motorola Assembler mit 68HC11. Eines Tages wollte mein Chef dass ich eine kleine Steuerung für 20 Relais zum Ein- und Ausschalten der Netzspannung von wissenschaftlichen Geräten auf die Beine stellen sollte. Eine kleine Platine mit RS232 Schnittstelle und 5V Regler gab es schon in der Firma. Vorgabe war es mit einem 16F877 zu arbeiten. Nach Installierung der Werkzeuge arbeitete ich mich durch einige Beispiele und es stellte sich heraus, man konnte damals schon wirklich gut mit dem Compiler arbeiten. Nach einigen zig Projekten über die Jahre hinweg bin ich heute immer noch recht damit zufrieden. Der Umfang des Compilers wuchs überd die Jahre um alle gängige Typen seitdem zu unterstützen. Bis auf den PIC32 arbeitete ich bereits mit allen gängigen PIC Familien und hattte nie wirkliche Probleme. Ab und zu gab es Versionen vom Compiler mit Bugs. Die Kundenbetreuung war allerdings sehr gut und Probleme wurden meist innerhalb eines Tages behoben. Abgesehen davon, findet sich ab und zu das wirkliche Problem nur vor dem Computer auf dem Sessel:-) Was ich beim CCS Compiler angenehm finde ist, dass die Fuses im Source Code schon konfiguriert werden können und (wenn man will) viele Chip Initialisierungs Makros und Funktionen schon vorhanden sind. Es sollte überhaupt kein Problem bereiten Um Z.B. ein LED zum Blinken zu bringen. Es gibt viele, viele brauchbare Beispiele. (USB, Serial, Bootloader, FAT, CAN, I2c einfaches RTOS). Was für den Anfänger günstig ist, dass es viele lauffähige Beispielprogramme für gängige Peripherie Ics gibt wie z.B. RTC, SPI, I2C usw. Im Vergleich zum MC compiler finde ich dass man viel weniger Arbeit mit dem CCS hat um die Chip Peripherien richtig zu konfigurieren. Es gibt ein IDE und einen Lader. Ich arbeite meist nur mit einem Editor (Textpad) und C.L. Das IDE/Debugger finde ich etwas gewöhnungsbedürftig. Für MPLAB(x) gibt es auch plug-ins. MPLAB verwende ich nur als Lader weil MPLABX meinen alten ICD2 nicht mehr unterstützt. Ist allerdings kein Problem mit dem Pickit3. Jedenfalls lohnt es sich meiner Meinung nach sich den CCS anzusehen. Es gibt eine limitierte freie Version (Leider nur 4kB groß). Auch wenn es zum Teil wie Werbung für den CCS aussieht, ist das nicht meine Absicht. Ich kann nur sagen, für mich war der Umgang mit diesem Werkzeug recht positiv und habe es mir selber (Hobby) gekauft und arbeite sehr gerne damit. Obwohl es am ersten Blick so aussieht, als ob Man CCS Sourcen nicht ohne Weiteres leicht portieren kann, hat es mir bis jetzt noch nie viel Schwierigkeiten gemacht Projekte die am PIC ins Leben gerufen worden waren auf andere MCs zu übertragen (Cortex-M3, AVR, 8051er, Zilog-encore z8). Auch umgekehrt. Ich wünsche Euch noch schöne Festtage und einen guten Rutsch ins Neue Jahr. Mfg, Gerhard
:
Bearbeitet durch User
micha schrieb: > Hallo, > schau doch mal unter: > http://pic-projekte.de > dort gibt es eine deutsche Anleitung. Super Link, werde ich mir merken. Fürchte aber, dass das WilhelmT nicht zielführend genug ist. Es scheint das "Hallo Welt" zum sofort loslegen zu fehlen.
Gerhard O. schrieb: > Was ich beim CCS Compiler angenehm finde ist, dass die Fuses im Source > Code schon konfiguriert werden können und (wenn man will) viele Chip > Initialisierungs Makros und Funktionen schon vorhanden sind. Es sollte > überhaupt kein Problem bereiten Um Z.B. ein LED zum Blinken zu bringen. > Es gibt viele, viele brauchbare Beispiele. (USB, Serial, Bootloader, > FAT, CAN, I2c einfaches RTOS). Was für den Anfänger günstig ist, dass es > viele lauffähige Beispielprogramme für gängige Peripherie Ics gibt wie > z.B. RTC, SPI, I2C usw. Natürlich kann (könnte) man auch mit CCS Arbeiten. Vor allem wenn man sich schon mit einem Tool auskennt, sieht man vermutlich immer nur die Vorteile oder vergleicht mit Sachen die vor langer Zeit mal aktuell waren. Ich greif mal den zitierten Absatz heraus. Also die Fuses (ConfigBits) kann man bei den MCHP Compilern auch so lange ich denken kann im Quellcode setzen. Mit der neuen IDE kann man Sie sogar nur noch im Quellcode setzten. Mann kann, muss aber nicht, dafür den entprechenden Dialog benutzen Beispiele und lauffähige Programme gibt es von MCHP vermutich extrem viel mehr. Für unzählige verschiedene Demo Boards. Für Anfänger ist das dadurch leider extrem unübersichtlich und es wird dann meistens das falsche ausgewählt. Bibliotheken gibt es natürlich auch. Das größte Problem im Moment ist meiner Meinung nach die Umstellung auf die neue IDE und neue Compiler welche sich jetzt schon jahrelang hinzieht, wobei die Aktualisierung der Doku für die Demo-Boards nicht ansatzweise hinterher kommt. Wenn man einzelnen Aussagen von Leuten mit tausenden von Posts im MCHP Forum trauen kann, dann ist CCS der am wenigsten Standard konforme Compiler von allen. Die Portierung von Code der MCHP Compilern dürfte deshalb auch nicht schwieriger sein als von CCS Code. Kleines aktuelles Beispiel: -> Beitrag "float byte Umwandlung PIC18F" Am besten ist man als Anfänger dran, wenn man jemanden hat der sich mit einem best. Tool schon Jahre beschäftigt. Dann wird man am schnellsten den Einstieg schaffen, auch wenn das nicht unbedidngt das beste Tool sein muss. Wenn man es dan einigermaßen gerafft hat, sind die anderen Tools meistens doch irgendwie ähnlich und der Umstieg wäre an sich kein großes Problem. ABER man ist ja faul und so bleibt man meist beim ersten.
:
Bearbeitet durch User
Volker SchK schrieb: > Wenn du soweit bist, poste die Datei hier ;-) Es gibt Neues: Vor 20 Min klingelte es an der Tür und da war doch tatsächlich die Weihnachtsüberraschung von MCHP eine ebensolche und schon da! Dieses Tool enthielt nicht nur, wie angekündigt, die einfache DemoPlatine - die mit 4 Leds - , sondern gleich 3 Stück. Zwei sind leer, eine war bestückt, die MCU - ein PIC16Fxxx - und es gab einen Sockel, und es lag auch noch ein PIC18Fxxx drin. Jetzt könnte es also losgehen. Könnte! Danke erst mal, Volker, für die Anleitung. Leider......leider steht Weihnachten verdammt dicht vor der Tür, meine Frau hat mich soeben zu Anderem eingeteilt, und ich kann noch nicht sagen, wann ich endlich.....Melde mich aber, sobald es weiterging. Danke für alle wohlmeinenden Tipps, werde aber bei den bisherigen Vorgaben - MPLAP X IDE, und CX8 bleiben, um nicht völlig orientierungslos zu werden. Bis bald, WilhelmT
Be Ti schrieb: > eider steht > Weihnachten verdammt dicht vor der Tür, meine Frau hat mich soeben zu > Anderem eingeteilt, Ich hoffe meine erwischt mich nicht, wie ich hier so meine Zeit verplempere. Die Anleitung findest du so, mehr oder weniger, auch auf PIC Projekte zu dem micha einen Link gepostet hat. Nur geht es dann nicht so richtig weiter ... (natürlich meiner pers. Meinung nach)
Schau doch einmal auf der verlinkten Seite links unter Microcontroller. Dort stehen verschiedene Tutorials.
Zurück vom Einkauf der Lebensmittel für Weihnachten: Die pure Fleicheslust kommt da wieder hoch! Drucke mir gleich die Anleitung von Volker aus, und schaue unter dem Link von micha nach. Stichwort "Drucken"! Es hieß da im Script von Volker sinngemäß: immer das Handbuch für die (jeweilige) MCU dabei haben und dort immer reinschauen! Hm.....das Datenblatt für den im Demoboard steckenden PIC hat ca. 450 Seiten! Soll ich....muss ich.., also meinen Drucker derart quälen? Schließlich stünden da immer auch noch die 270 Seiten für das MPLAB x IDE an...... Gruß, wilhelmT
Bist du wahnsinnig ;-) Reinschauen am Monitor reicht. Findet man best. auch schneller was, mit der Suchfunktion. Super ist, wenn man zwei Monitore hat ...
Nein. Grade bei dsPICs macht das kein Spaß. Ich finde die Manuals sehr gelungen. Auch schön mit den Kapiteln, die einen den Zugriff erleichtert. Ich suche eigentlich nie was mittels der Suchfunktion. Wenn ich ne PWM ausgeben will, gucke ich unter CCP->PWM und da steht am Anfang alles was man braucht. Es reicht also quasi eine oder 2 Seiten zu lesen. Aber ausdrucken. Niemals. Höchstens zu den einzelnen Modulen die "Setup" Seite, also was man machen muss, damit es läuft. Aber das lohnt sich auch nur, wenn man immer den gleichen PIC nimmt. Sucht man sich jedesmal den passenden, kann das auch wieder anders aussehen. Ich hab mir jedenfalls nur einmal ein DB ausgedruckt - in der Ausbildung vom 16F84. War aber für die Prüfung und es war nicht mein Drucker ;) Letztendlich habe ich auch nur 3 oder 4 Seiten von gebraucht... Volker SchK schrieb: > Super ist, wenn man zwei Monitore hat ... Auf jedenfall. Als meime Grafikkarte abgeraucht ist, konnte ich nur einen ans Mainboard stecken, bis die neue kam. Eine Qual^^ Wenn ich mir bald nen neuen PC zusammen stelle, kommt eine Grafikkarte rein, die 3 Monitore gleichzeitig ansteuen kann. Dann kommen meine beiden 19"er weiter hoch an die Wand und darunter kommt ein neuer FullHD (bei gutem Angebot 4K) Monitor mit min. 24". Dann kann ich unten das Board routen, auf einem ist der Schaltplan und aufm dritten dann ein Datenblatt oder Firefox.
:
Bearbeitet durch User
Michael Skropski schrieb: > Ich suche eigentlich nie was mittels der Suchfunktion. Wenn > ich ne PWM ausgeben will, gucke ich unter CCP->PWM und da steht am > Anfang alles was man braucht. Es reicht also quasi eine oder 2 Seiten zu > lesen. Klar, wenn man mal weiß wie die Manuals aufgebaut sind und schon einige Jahre mit PIC Manuals zugebracht hat. Oder wenn man nicht zu faul ist, das Inhaltsverzeichnis zu öffnen ... Bei den Übungen im Labor der Hochschule hab ich manchmal das Gefühl, Inhaltsverziechnis sei etwas völlig unbekanntes ;-)
:
Bearbeitet durch User
Volker SchK schrieb: > Bei den Übungen im Labor der Hochschule hab ich manchmal das Gefühl, > Inhaltsverziechnis sei etwas völlig unbekanntes ;-) Hehe, ich glaub, man kann die Überschriften im Inhaltsverzeichnis sogar direkt anklicken und kommt dann dahin. Ich habe jetzt aber den blöden Acrobat Reader runtergeschmissen. 1. Hats schon n bisl gedauert, bis er geöffnet war 2., und das war der Hauptgrund n neuen Reader zu nehmen, die ganzen aufklappbaren Lesezeichen waren beim öffnen der PDF schon offen. Es war also egal, ob man die PDF runter scrollt oder aber das Lesezeichenverzeichnis ;)
Das mit dem bis auf das letzte aufgeklappte Inhaltsverezichnis ist echt voll nervig. Dass man das nicht mit einem Klick reduzieren kann auch. Ich habe festgestellt, dass das beim Erstellen den pfds festgelegt wird. (als ich mein eigenes Dokument erstellt und ewig rumprobiert habe damit das nicht der Fall ist) Ich bevorzuge allerdings auch einen anderen Reader. Unter Windows, Foxit
Volker SchK schrieb: > Das mit dem bis auf das letzte aufgeklappte Inhaltsverezichnis ist echt > voll nervig. Dass man das nicht mit einem Klick reduzieren kann auch. > > Ich habe festgestellt, dass das beim Erstellen den pfds festgelegt wird. > (als ich mein eigenes Dokument erstellt und ewig rumprobiert habe damit > das nicht der Fall ist) Hm. Wenn ich ein Projekt mache, habe ich ein Ordner "Datenblätter" wo halt alle besagten reinkommen. Wenn ich da ein DB vom PIC mit Aceobat Reader öffne, sind alle Lesezeichen aufgeklappt. Mit dem PDF XChange Viewer aber nicht, obwohls die gleiche Datei ist. Bei dem Viewer könnte man aber alle Lesezeichen schließen bzw. Öffnen.
Ja, viele Wege führen von Rom:-) Volker, Deine Argumente kann ich gut nach vollziehen. Du hast natürlich in vielen Punkten vollkommen recht. Ich finde aber, Konformität zwischen verschiedenen Chip Compilerm ist bei Mikrocontrollern sowieso nicht sooo wichtig. Bis jetzt konnte ich noch alles auf anderen MCs zum laufen kriegen. Macht halt mehr oder weniger viel Arbeit. Mit der Wahl der Werkzeuge ist es halt oft so, dass man das Werkzeug wählt das man kennt. Wenn ich also in der Firma damit arbeite dann hat man auch bei eigenen Projekten schon praktische Erfahrungen. Preislich ist CCS auch relativ günstig. Die kommerziellen Versionen MCHP compiler sind für den Hobbygebrauch auch nicht gerade billig. Beschränkte Tools mag ich nicht so gern. Übrigens, noch ein Kommentar zu Entwicklungsboards. Über die Jahre habe ich die Erfahrung gemacht, dass man mit einfachen Bords noch am Besten fährt. Z.B. Die Features der Bord die bei einer Version mit dem Pickit3 mitgeliefert wird finde ich gerade richtig. Meist mache ich mir meine eigenen Bords. Manche Bords sind so etwas von einer Eier legenden Vollmilchsau dass man kaum noch IO für externe Anschlüsse übrig hat. Da war der STK500 für AVR besser im Konzept. Naja, ich will nicht zu weit vom Thema abschweifen... Preislich ist CCS günstiger als die MCHP Tools. Ohne Optimierungen möchte ich obendrein auch nicht arbeiten müssen. Ich habe mal mit dem älteren MCHP C18 gearbeitet und es funktioniert natürlich auch recht gut. Aber trotzdem, bei mir sind die Weichen im Moment aus praktischen Gründen auf CCS gestellt. Abgesehen davon bin ich zur Zeit meist (beruflich und Hobby) mit Cortex-M beschäftigt und habe den PIC zugunsten von STM32 seit einiger Zeit eher vernachlässigt. Wie schon bemerkt war es wirklich nicht meine Absicht Euch den CCS aufzudrängen oder dafür zu werben. Grüsse, Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Die kommerziellen Versionen MCHP compiler > sind für den Hobbygebrauch auch nicht gerade billig. Beschränkte Tools > mag ich nicht so gern. Ja ich auch nicht. Mit dem C18 Compiler war das aber gar kein Problem. Ich hatte sogar mal den Fall, dass ich die Optimierung der Pro abschalten musste, weil der meine mühsam erstellte Inline Funktion wieder rausoptimiert hat ;-) Beim XC8 sieht das ganz anders aus. So wie halt beim HiTech was der XC8 ja de facto ist. Nur die Biblitheken sind wohl vom C18.
Gerhard O. schrieb: > Übrigens, noch ein Kommentar zu Entwicklungsboards. Über die Jahre habe > ich die Erfahrung gemacht, dass man mit einfachen Bords noch am Besten > fährt. Z.B. Die Features der Bord die bei einer Version mit dem Pickit3 > mitgeliefert wird finde ich gerade richtig. Meist mache ich mir meine > eigenen Bords. Wobei die man selbst bei den 16-Bit und 32-Bit PIC noch mit Controllern im DIP-Gehäuse relativ gut versorgt wird (PIC24/dsPIC gibts in (14)/18/20/28 Pin und PIC32 zumindest noch in DIP 28. Das kann man leicht noch was auf Lochraster aufbauen. Für PIC32 habe ich überhaupt keine "Entwicklungsboard" mehr gekauft, sondern einfach auf Lochraster mit 28er Sockel, Poti zum "ADC-Spielen" einen MAX3232 2 Buchsenleisten paralell zum Sockel und eine 6-pol Stiftleiste für#n PK3 - kostet keine 10 EURO.....
Chris B. schrieb: > Gerhard O. schrieb: >> Übrigens, noch ein Kommentar zu Entwicklungsboards. Über die Jahre habe >> ich die Erfahrung gemacht, dass man mit einfachen Bords noch am Besten >> fährt. Z.B. Die Features der Bord die bei einer Version mit dem Pickit3 >> mitgeliefert wird finde ich gerade richtig. Meist mache ich mir meine >> eigenen Bords. > > Wobei die man selbst bei den 16-Bit und 32-Bit PIC noch mit Controllern > im DIP-Gehäuse relativ gut versorgt wird (PIC24/dsPIC gibts in > (14)/18/20/28 Pin und PIC32 zumindest noch in DIP 28. Das kann man > leicht noch was auf Lochraster aufbauen. > Für PIC32 habe ich überhaupt keine "Entwicklungsboard" mehr gekauft, > sondern einfach auf Lochraster mit 28er Sockel, Poti zum "ADC-Spielen" > einen MAX3232 2 Buchsenleisten paralell zum Sockel und eine 6-pol > Stiftleiste für#n PK3 - kostet keine 10 EURO..... Ja, da macht MCHP es einem leicht. Für Steckbrett Experimente erstellte ich mir eine kleine Anzahl an Peripherie Einsteckbords. (EEPROM, RTC, SENSOREN, IO-Expander, DAC, ADCs, LCD) das ist dann fast so praktisch wie fertige Bords. Hat den Vorteil dass man nur draufsteckt was man aktuell benötigt. Für SMD habe ich noch Adapterplatinen auf DIP. Ich baute mir in der Vergangenheit oft kleine Einsteckplatinen für verschiedene Familien (PIC, STM32) um "gewichtigere" SMD-Gehaäuse verwenden zu können. Um alles wichtige gleich parat zu haben kommt dann noch standardmäßig immer eine Schnittstelle via I2C für ein LCD Display, DAC, RTC, RS232/485, IO Expander für on board LEDs, Temperatursensor drauf. Eine ISP Schnittstelle ist natürlich auch vorhanden. Manchmal ist dan noch ein 5V Spannungsregler eingebaut. Da nur zwei Port pins für I2C plus Serial für RS232 dafür verbraucht werden hält sich der Verlust an IO in Grenzen. Eine 18F8722 Bord stattete ich mit einem 96-pin DIN41612 Stecker aus und hat sich als Einsteck-Modul für größere Projekte sehr bewährt. Durch die qualitätsmäßig hochwertige Steckverbindung ist die Langzeit Zuverlässigkeit hoch. Für die meisten Peripherien habe ich auch Standard Libs so dass man wieder verwendbaren Code hat und ziemlich schnell zum Ziel kommt. Natürlich hat jeder seine eigenen Vorstellungen wie man am Besten zum Ziel kommt. Grüsse, Gerhard
Volker SchK schrieb: > Gerhard O. schrieb: >> Die kommerziellen Versionen MCHP compiler >> sind für den Hobbygebrauch auch nicht gerade billig. Beschränkte Tools >> mag ich nicht so gern. > > Ja ich auch nicht. Mit dem C18 Compiler war das aber gar kein Problem. > Ich hatte sogar mal den Fall, dass ich die Optimierung der Pro > abschalten musste, weil der meine mühsam erstellte Inline Funktion > wieder rausoptimiert hat ;-) > Beim XC8 sieht das ganz anders aus. So wie halt beim HiTech was der XC8 > ja de facto ist. Nur die Biblitheken sind wohl vom C18. Interessant. Mit dem XC8 habe ich noch nicht gearbeitet. Bei Sprut steht übrigens, dass man angeblich durch Neuinstallierung des C18 wieder die volle Funktionsfähigkeit bekommen soll. Habe ich aber noch nicht selber probiert. Bei mir ist es manchmal ähnlich wie in: "Was der Bauer nicht kennt, ißt er nicht gerne". So bleibe ich halt bequemerweise beim CCS. Gruß, Gerhard
Habe nun fleißig und mit Bemühen heute Nachmittag an zwei Computern verbracht, der eine mit MPLAB X IDE und dem PICkit3 incl. Demoboard, der andere mit Inernet und Datenblättern. Rausgekommen ist wieder nur Frust. Und rausgekommen ist mal wieder die Erkenntnis, dass Fachleute echt prima und zu bewundernde Fachleute sind, dass die aber im Ansatz nicht wissen, was Anfänger brauchen und/ oder sich nicht adäquat ausdrücken können. Zuerst habe ich das PICkit3 mit dem einf. Demoboard (eDB) in Betrieb nehmen wollen. Zu diesem eDB gibts ein User Guide. Na prima, also mal von Anfang an gelesen bis zum ersten Beispiel, in dem eine einzige Led eingeschaltet werden sollte. Das Beispiel durchgelesen, der C-Text sah auch recht einfach aus und jetzt? Nach der Erläuterung des Beispieles gings auf der nächsten Seite mit dem nächsten Beispiel weiter. Also ich mit dem eDB in einer Hand, dem MPLAB auf dem Bildschirm und nun ??? Aha, es gäbe "im Internet" für diese Beispiele den zugehörigen Code. Das "Internet" war dann die HP von MCHP, und dort fand sich irgendwo dann tatsächlich ein Zip-File mit diesen Beispiel-Codes (BC). Den also geladen, entzippt, in einen Ordner gepackt.....und jetzt? Also in MPLAB eine Funktion gesucht, mit welcher man solch einen BC laden kann, den im entpr. Unterverzeichnis gefunden, die Auswahl auf C-Code und schwups...war das Projekt geladen. Toll! Mal durch die angezeigten Files geclickert, und schon zeigten sich rote Meckerzeichen, z.B. hinter "config" wurden die runden Klammern angemeckert. Was nun? Ignorieren und auf Ausführen drücken. Da wurde was compiliert ???, jedenfalls lief da ein Text durch und dadrunter wurden Fehlermeldungen ausgespuckt. Nix rührte sich. Das hat mich doch sehr beeindruckt, dass die von MCHP selbst erstellten Programme nicht funktionierten! Dann habe ich mal das von Volker freundlicherweise erstellte Hilfgerüst für die ersten Schritte ausprobiert. Bis zum Erstellen des Konfigurationswortes bin ich ja gekommen. Aber in dem Datenblatt für den PIC18F14K22 (407 S) nun alle Bits richtig auszusuchen.....habe mein Bestes versucht, aber nach dem ersten Wort sollten laut DB noch weitere ausgefüllt werden, und da war ich überfordert. Dann habe ich im C-Prog des ersten MCHP-Beispielprogs (das mit dem Einschalten der Led) nachgeschaut, aber nicht alle Configurations-Worte (Kürzel), die dort enthalten waren, fanden sich in dem Menü im MPLAB wieder - und umgekehrt. Den Oszillator einzustellen erwies sich als im ersten Anlauf zu komplex. Nu' is aus. Für heute ist Schluss. Morgen wird wg. Weihnachtsvorbereitungen kaum was gehen, und wenn wieder Zeit ist, gilt es, die Deprise zu überwinden. Jetzt bliebe noch, in evtl. andere "Einführungen" zu schauen, z.B. bei Sprut, oder dem von micha verlinkten PIC-Forum....aber meine Hoffnung sinkt. EIN Beispiel....ein Königreich für EIN Beispiel: tue dies, schreibe das, .....was dann auch noch funktionert....das wärs. Gruß und auf Verdacht schon mal schöne Weihnachten, wilhelmT
Hallo Wilhelm, Ich kann Dir leider nicht konkret helfen weil ich nicht mit der selben Entwicklungs Tool Chain arbeite und überhaupt noch keine Erfahrungen damit habe. Deinen Ausführungen nach habe ich den Eindruck dass Du versuchst ein Beispiel, welches wahrscheinlich unter C18 geschrieben wurde, auf der XC8 Toolchain zu bauen. Ich nehme an, dass Du deshalb so viele Fehlermeldungen bekommst. Es wäre wirklich gut wenn sich hier einer der das gelesen hat, dir annehmen könnte um Dir dieses anfängliche Problem lösen zu helfen. Persönlich bin ich der Meinung dass Tools wie der XC8 alles andere als Anfänger freundlich sind. Das sind Tools für industrielle Entwickler. Da ist es kein Wunder wenn man frisch damit einsteigt solche großen anfänglichen Probleme hat. In einer Hochschule würdest Du wahrscheinlich brauchbare und praktische Einführungshilfen bekommen. Alleine bist Du auf Dich selber gestellt. Es hilft am Anfang immens, ein lauffähiges, kompilierfähiges Source Code Projekt zu haben welches als Basis für eigene Versuche dienen kann. Wenn dann später alles funktioniert wird Dir das fast nur wie ein böser Traum vorkommen. Durch solche Probleme muß man durch und es ist am Anfang hart. Da muß man sehr viel Geduld haben und hoffentlich auf der Hilfe anderer aufbauen zu können. Wie gesagt, mit dem XC8 kenne ich mich nicht praktisch aus. Deshalb hoffe ich dass Dir vom Forum jemand richtig helfen könnte die Fehlermeldungen richtig zu prognostizieren. Im Notfall schreibe mir. Ich habe die selbe Bord. Den Xc8 könnte ich auch installieren. Es widerstrebt mir zu bemerken, dass Dir das beim CCS nicht passiert wäre. Deren Beispiele sind wie ich an mir erfahren habe, solange die HW kompatibel ist, alle 100% Lauf- und Baufähig. Aber wie gesagt wenn man diese erste Hürde übersprungen hat wirst Du auch mit dem XC8 wahrscheinlich mit der Zeit wenig richtige Probleme haben. Die Einarbeitung ist halt am Anfang immer eine Herausforderung. Grüße, Gerhard
:
Bearbeitet durch User
Hallo Wilhelm, Was jetzt konkret bei dir schiefgelaufen ist, das kann ich gerade nicht sagen. Dazu müsste ich den Code und den Biuld-Output schon selber vor mir haben. Ich vermute aber das Gerhard mit der Vermutung das deine Beispiele noch für den C18 geschrieben sind nicht falsch liegt. Die Unterschiede zwischen C18 & XC8 sind zwar nicht groß, im Grunde unterscheiden sich einige Compilerdirektiven und ganz ganz wenige Sonderfälle im Syntax. Für jemanden vom Fach sind es wenige Minuten ein Projekt umzustellen. Aber wie du selber merkst ist es für einen Einsteiger eine große Hürde. Manchmal ist das umstellen schwieriger als das Neuschreiben (Natürlich nur wenn Optionale Einstellungen im Code gemacht werden). Volker hat es ja schon angedeutet. Das Problem was du derzeit hast ist sicherlich auch darauf zurückzuführen das sich Microchip bei der Umstellung der IDE nicht gerade mit Ruhm bekleckert hat.Das wurde irgendwie übers Knie gebrochen, aber so Dinge wie BEispiele und vorhandene Einstiegsboards wurden bis jetzt einfach "vergessen" -also nichts angepasst/aktualisiert. Von Microchip gibt es daher im Moment leider ausser den offiziellen HAndbüchern (pdf) udn einigen wenigen Kurzutorials für Umsteiger nur wenige Infos. Beides nicht wirklich für Einsteiger geeignet. Aus unabhängigen Quellen gibt es aber auch noch kaum etwas, da diese Umgebungen recht neu sind. Da es dir im Moment wirklich um die absoluten Grundlagen geht mein ERNSTHAFTER Rat in zwei Dingen: Erstens: Vergiss die nächste Zeit MPLABX und besser auch den XC8. Für MPLAB 8 und C18 gibt es im Gegensatz zu deiner Konstellation sehr viele Beispiele / Tutorials usw. Auch auf absolutem Basisniveau. So waren ja beispielsweise beim PK3-DebugExpress einige Einführungsbeispiele mit Erklärung einiger IDE funktionen dabei. (PK3 Debug Express Lesson Files) IMHO müssten da dann auch dinge wie man überhautp ein Projekt anlegt usw. beschrieben sein. Wenn du aber die Grundlagen erst einmal beherrscht ist der Umstieg auf die X Schiene dann kein wirkliches Problem mehr. Du bist also keinesfalls auf ewig dazu verdammt dann an der "alten" IDE zu hängen. Nur für den Einstieg wird vieles sehr viel einfacher da besser Dokumentiert. Zweitens: Es wurde schon vielfach geschrieben: Wenn es ums C Lernen geht - Das ist auf dem PC MIT ABSTAND am sinnvollsten erledigt. Sorry, aber wer ernsthaft empfiehlt das ein absoluter C neuling direkt auf einem einfachen Mikrocontroller lernen soll hat irgendwo entweder die Bodenhaftung verloren oder aber er meint es gar nicht gut mit den "Neulingen". Wie du ja selbst bemerkst hat alleine die Entwicklugnsumgebung für einen Neuling schon Ihre Tücken bis man das Programm erst einmal im µC hat. (Und das ist bei allen Controllern so) Und wenn man bei einer Fehlermeldung erst einmla rätseln muss ob die jetzt von der IDE, von der HArdware, vom eigenen Code, von irgendwelchen Einstellungen (Stack Size, Heap usw) oder gar von einem BUG im Compiler her kommt, dann lernt man genau GAR NICHTS und ist einfach nur gefrustet. Daher spiele ruhig etwas mit den Controllern und der IDE herum, aber wenn es ums C Lernen geht, dann mache deine ersten SChritte aber dem PC. Und in deinem Fall würde ich das sogar ganz besonders empfehlen, denn für C auf dem PC gibt es im Gegensatz zu C auf dem µC ein sehr reichhaltiges Angebot an deutschsprachiger Einsteigerliteratur. (Oft auch als PDF im Netz) Darunter auch viele Werke die sich nicht nur mit der Sprache an sich beschäftigen, sondern gerade auch mit der jeweils vom Autor bevorzugten IDE. Je nach Geschmack kannst du also entweder eine IDE auswählen und dafür passende Tutorials suchen, oder du suchst ein Tutorial was dir besonders gut gefällt und nimmst die dort behandelte IDE (meistens kostenlos verfügbar) Also wie gesagt: MAch dir das Leben nicht unnötig schwer. Lerne die C Grundlagen auf dem PC, denn das bietet nicht nur viel weniger Frustpotential, nei, ich garantiere du wirst so serh viel schneller in der LAge sein "komplexe" C Programme auf dem µC umzusetzen als wenn du stur mit dem Kopf durch die Wand willst und weiter C nur auf dem µC anschaust. Klingt Paradox ist aber definitiv so! Gruß Carsten
:
Bearbeitet durch User
wilhelmt schrieb: > Jetzt bliebe noch, in evtl. andere "Einführungen" zu schauen Versuchs mal mit dieser: https://www.youtube.com/watch?v=lCzokKzD3-Q
Axel Schwenke schrieb: > Arduino auf PIC Basis wäre mir neu. Ansonsten geht das sicher. Mir auch. Aber wenn es PIC32 sein darf: http://www.digilentinc.com/Products/Detail.cfm?Prod=CHIPKIT-UNO32 Die haben bei mir die Arduinos als "Hilfsprozessor" fast vollständig ersetzt. Echter Nachteil (manchmal zumindestens): PIC32 arbeitet nur mit 3V3 und nicht alle I/Os sind 5V kompatibel. Ansonsten echt nette Steinchen :-) Grüße Andreas
1 | /** I N C L U D E S **************************************************/
|
2 | #include <xc.h> |
3 | |
4 | /** C O N F I G U R A T I O N B I T S ******************************/
|
5 | // nur die ohne die es nicht gehr ;-)
|
6 | #pragma config FOSC = INTIO67 // interner Oszillator
|
7 | #pragma config WDTEN = OFF // kein Watchdog Timer
|
8 | #pragma config LVP = OFF // kein Low Voltage Programming
|
9 | #pragma config PBADEN = OFF // erste Seite PORTB im Datenbuch
|
10 | |
11 | /** D E C L A R A T I O N S *******************************************/
|
12 | void main(void) |
13 | {
|
14 | TRISBbits.TRISB0 = 1; // Pin mit Taster als Eingang |
15 | |
16 | LATD = 0x00; // alle LEDs aus (schon vor der Richtung !) |
17 | TRISD = 0x00; // PORTD bit 0..7 als Ausgang |
18 | |
19 | while (1){ |
20 | while(PORTBbits.INT0 == 1){;} // warte auf Tastendruck [tu nichts} |
21 | LATD++; // register LATD um eins erhöhen |
22 | while(PORTBbits.INT0 == 0){;} // warte auf Taste loslassen {tu nichts} |
23 | }
|
24 | }
|
Ok, hier dein Demo für Debug Express. Nachdem do wie oben beschreiben, eine neue Datei angelegt hast, kopierst du den Mist da hinein. Ich häng am besten ein gepacktes Projekt an, wo auch die Versorgung über PICkit scho eingestellt ist ... Dann drückst du einfach auf das Menü "Debug -> Debug Main Project" Von den Konfigurations Bits sind nicht alle so wichtig aber die Beschreibung steht in einem einzigen Kapitel im Datenblatt auf aufeinanderfolgenden Seiten, da muss man wirklich ncht das ganze Datenbuch lesen ... Als Nächstes kommt die funktion main(), welche jedes C Programm hat egal auf welcher Platform. In der Funktion kommt dann zuerst die Konfiguration der benutzten Pins für Taster und LEDs. Wird das gesammte Register angesprochen dann über den Namen. (z.B. TRISD) Bei einzelnen Pins, kann man das über ein im Prozessorheader definiertes Bitfeld tun. Der Name dieses Bitfeldes ist dann immer der des Registers erweitert mit "bits". Dann kommt ein Punkt, und der name des anzusprechenden Bits oder Bitbereichs im Bitfeld. Sobald man den Punkt geschrieben und dabei keinen Fehler gemacht hat, schlägt die IDE die vorhandenen Auswhahmöglichkeiten vor. TRISBbits.TRISB0 ist also das Bit 0 im Register TRISB wobei TRISB das Register ist, welches die Richtung der Pins an PORTB festlegt. Also wird hier die Richtung von B0 festgelgt. Nach der Konfiguration der Pins, kommt das eigentliche Programm in einer Endlosschleife "while(1){...} Die Bedingung solange(1) kann nie falsch werden. In der Schleife wird darauf gewartet, dass die Taste gedrückt wird. Weil die Taste Low aktiv ist, lautet die Bedingung dafür while(PORTBbits.INT0 == 1){;}" solange der entsprechende Pin 1 ist tue das, was in den geschweiften klammern steht (nichts ;-) Der Vergleich wird durch das doppelte Gleich "==" ausgedrückt "=" wäre eine Zuweisung. Wird die Taste gedrückt wird die Bedingung falsch und das Nichtstun beendet. Dann wird das Register LATD incementiert (der Wert wird binär an den LEDs angezeigt) und auf das Loslassen der Taste gewartet. Wenn man das nicht tun würde (warten auf lösen), dann würden die Befehle in der Endlosschleife so schnell durchlaufen und LATD so schnell incrementiert, dass nicht das Zählen an den LEDs sichtbar würde, sondern es sähe so aus, als ob alle LEDs einfach an wären. Nachdem Lösen der Taste wird wieder auf das nächst Drücken gewartet usw. Schaun wir mal ob es dir gelingt das Projekt zu entpacken, und zu öffnen ...
wilhelmt schrieb: > ... Genau da liegt der Unterschied zum Arduino: Da steckt man USB an, schreibt ein paar Zeilen Code, dann blinkt die LED schon - 10 Minuten Maximum. Dafür lernt man nichts, was man im Beruf gebrauchen könnte und ist sehr eingeschränkt. Bei einem "richtigen" Controller muss erst einmal der Oszillator laufen, Kontakt mit dem Debugger hergestellt werden, kryptische Fehlermeldungen interpretiert werden usw usf. Und dann ist die IDE um Größenordnungen komplexer. Wenn es dich tröstet: Der Frust ist mir nicht fremd. Das geht jedem so - man sitzt vor dieser riesigen komplexen Entwicklungsumgebung und findet nichts, weiß nicht was die ganzen tollen Fremdwörter bedeuten und bekommt nichts auf die Reihe. Es gibt keine gescheiten Beispiele, alle Anleitungen sind anscheinend für Fachkräfte geschrieben etc... Ich persönlich habe 3 Tage gebraucht, bis ich bei meinem ersten Controller (PIC24) einmal den Clock am laufen gehabt habe. Dann ging es aber immer schneller: Erst eine UART mit FT232, dann Interrupts, dann Timer - der Rest ist fast schon pillepalle. Danach ist selbt der Umstieg auf eine andere Controllerfamilie leicht - weil man schon weiß was die Peripherie ungefähr macht und wo man sich die nötigen Informationen besorgen kann. --> Dranbleiben, es lohnt sich wirklich. Man kann mit einem Controller auf dise Art viel mehr anstellen, als mit einem Fertigprodukt wie dem Arduino. Falls dir C noch Schwierigkeiten macht: Ich habe anfangs parallel viele Sachen am PC ausprobiert, mit folgendem Compiler: http://www.bloodshed.net/devcpp.html Zum kurz war ausprobieren ist der perfekt, weil sehr simpel gestrickt.
Für das Low Pin count Board siehts ungefähr so aus
1 | /** I N C L U D E S **************************************************/
|
2 | #include <xc.h> |
3 | |
4 | /** C O N F I G U R A T I O N B I T S ******************************/
|
5 | // nur die ohne die es nicht gehr ;-)
|
6 | #pragma config FOSC = IRC // heisst hier nicht INTIO67
|
7 | #pragma config WDTEN = OFF
|
8 | #pragma config LVP = OFF
|
9 | //#pragma config PBADEN = OFF das gibt es beim 14K22 nicht
|
10 | |
11 | /** D E C L A R A T I O N S *******************************************/
|
12 | void main(void) |
13 | {
|
14 | TRISAbits.TRISA2 = 1; // Pin mit Taster als Eingang |
15 | |
16 | LATC = 0x00; // alle LEDs aus (schon vor der Richtung !) |
17 | TRISC = 0xF0; // PORTC bit 0..3 als Ausgang |
18 | |
19 | while (1){ |
20 | while(PORTAbits.RA2 == 1){;} // warte auf Tastendruck [tu nichts} |
21 | LATC++; // register LATD um eins erhöhen |
22 | while(PORTAbits.RA2 == 0){;} // warte auf Taste loslassen {tu nichts} |
23 | }
|
24 | }
|
Keine Garaantie, kann ich gerade nicht überprüfen
Ich hab mein Board auch mal rausgekramt. Vielleicht finde ich über die Feiertage die Zeit, ein kleines Beispielprogramm zu schreiben (mit MPLABX und XC8). Die Frage ist aber auch: Was kannst du schon in C? Wenn ich dir ein Blinklicht programmiere und du kopierst das in dein Projekt, kompilierst und bekommst es auf dem PIC zum Laufen.. Dann ist das zwar ein Erfolgserlebnis, aber du weißt nicht, was was macht und wieso es funktioniert. Z.B. dass IMMER eine main() Funktion vorhanden sein muss, da diese quasi der Einstiegspunkt nach einem Reset ist. Die darf auch nicht umbenannt werden in z.B. main1(). Gut jetzt weißt du es, aber vergleichbares nicht. Die Syntax eben und ein Programmaufbau (ganz ohne goto's ;) ) Das zu lernen ist vermutlich am PC einfacher. Ich kann aber auch verstehen, dass du jetzt deine Boards nutzen willst, daher hoffe ich, dass ich bald das Programm schreiben kann. Ich werde es auch ausführlich kommentieren. Mit den Configs finde ich den MikroC Compiler sehr nett. Da brauch ich kein Blick ins Datenblatt machen, da kann man alles mittels Vollständigen Text in einem Dropdown Menü ändern: https://asimlink.files.wordpress.com/2011/08/configurations1.jpg Find ich besser als alles mit komischen pragmas zu machen. MikroC hat aber andere (wenige) Schwachpunkte.
Ja die Produkte von Mikroelektronika sind sehr gut. Für Anfänger sehr gut geeignet. Auch sehr gute Erklärung für Einsteiger. Englisch sollte man schon beherschen.
Dich kriegen wir schon durch, Wilhelm! Eure Resonanz freut mich. Ich werde vielleicht auch mal damit spielen weil ich noch keine praktische Erfahrungen mit dem xc8 habe. Also auch von mir grosses Danke. Grüsse, Gerhard
Michael Skropski schrieb: > Ich hab mein Board auch mal rausgekramt. Vielleicht finde ich über die > Feiertage die Zeit, ein kleines Beispielprogramm zu schreiben (mit > MPLABX und XC8). > > Die Frage ist aber auch: > Was kannst du schon in C? Wenn ich dir ein Blinklicht programmiere und > du kopierst das in dein Projekt, kompilierst und bekommst es auf dem PIC > zum Laufen.. Dann ist das zwar ein Erfolgserlebnis, aber du weißt nicht, > was was macht und wieso es funktioniert. Da muss ich Dir leicht widersprechen. Grad beim ersten Mal ist es sehr hilfreich ein kompilierbares, lauffähiges Projekt zu haben weil das erstens die Toolchain und den Programmer/Debugger prüft. Zweitens kann man dann erstmal Änderungen machen und feststellen wie schnell man das Programm brechen kann. So kann man auch viel lernen und war bei mir genau so. Ich fing mit einem lauffähigen Programm an, lies dann eine Menge Dokus, machte Änderungen, forschte nach warum dies und jenes nicht funktionierte so wie ich wollte und dann ging es bald immer besser. > Z.B. dass IMMER eine main() Funktion vorhanden sein muss, da diese quasi > der Einstiegspunkt nach einem Reset ist. Die darf auch nicht umbenannt > werden in z.B. main1(). Gut jetzt weißt du es, aber vergleichbares > nicht. Die Syntax eben und ein Programmaufbau (ganz ohne goto's ;) ) Das > zu lernen ist vermutlich am PC einfacher. Ich kann aber auch verstehen, > dass du jetzt deine Boards nutzen willst, daher hoffe ich, dass ich bald > das Programm schreiben kann. Ich werde es auch ausführlich kommentieren. > > Mit den Configs finde ich den MikroC Compiler sehr nett. Da brauch ich > kein Blick ins Datenblatt machen, da kann man alles mittels > Vollständigen Text in einem Dropdown Menü ändern: > https://asimlink.files.wordpress.com/2011/08/configurations1.jpg > Find ich besser als alles mit komischen pragmas zu machen. MikroC hat > aber andere (wenige) Schwachpunkte. Grüsse, Gerhard
:
Bearbeitet durch User
Volker SchK schrieb: > Für das Low Pin count Board siehts ungefähr so aus/** I N C L U D > E S **************************************************/ > #include <xc.h> > >........ > /** D E C L A R A T I O N S *******************************************/ > void main(void) > { > TRISAbits.TRISA2 = 1; // Pin mit Taster als Eingang > >........ Wenn der Taster an PORTA hängt sollte man aber UNBEDINGT den entsprechenden Pin auf DIGITAL schalten, da alle PIC10/12/16/18 mit Analogfunktionen diese auf PORTA (teilweise auch PORTB) haben, welche per Default aktiv sind. Sonst hat der TO den nächsten Reinfall ;-)
:
Bearbeitet durch User
Michael Skropski schrieb: > Mit den Configs finde ich den MikroC Compiler sehr nett. Da brauch ich > kein Blick ins Datenblatt machen, da kann man alles mittels > Vollständigen Text in einem Dropdown Menü ändern: > https://asimlink.files.wordpress.com/2011/08/configurations1.jpg > Find ich besser als alles mit komischen pragmas zu machen. MikroC hat > aber andere (wenige) Schwachpunkte. Das ging sowohl in MPLAB 8 und nun in X auch: http://pic-projekte.de/wordpress/wp-content/uploads/2014/01/MPLABX_Configbits.png Man gelangt dann zu einem ähnlichen Dropdown Menü, wie Du es am Beispiel gezeigt hast. @Wilhelm: Schön am Ball bleiben :-)
MPLAB X ist ja primär nicht von Microchip, es ist die netbeans IDE mit einigen PIC-spezifischen Plugins. Wenn es also nur um die IDE mit ihren Funktionen geht, gibt es Dokumentationen und Tutorials ohne Ende. Startpunkt könnte hier sein: https://netbeans.org/ Auch die eingebaute Hilfe ist umfangreich. Ich verwende, angestoßen durch MPLAB X, netbeans auch als IDE für die C-Programmierung auf dem PC. Da muß ich die Funktionen und Shortcuts einer IDE nur einmal lernen. MfG Klaus
Es muss wohl auf Weihnachten zugehen: Ich bin total gerührt - und ringe etwas um Fassung! Erwartet hatte ich einen Shitstorm: Vorwürfe, warum ich mich nicht auf reine PC-Arbeit beschränkt hätte, und überhaupt nur Konzentration auf Eines, z.B. auf "C", und nicht überhaupt alles ganz anders, und ggf. Hinweise der Art: ist wohl doch alles etwas viel für dich! Nachdem dies ausgeblieben ist, sitze ich hier und wundere mich: Über die zahlreichen Hilfsangebote im Forum und auch die vielen Worte des Verständnisses und noch mehr über die gutmeinenden Durchhalte-Empfehlungen. In einem bin ich mir sicher: Aufgeben is' nich! Das Erlernen von C hatte ich mir für die Zeit nach meinem Berufsende vorgenommen, und das ist jetzt fast erreicht. Das Hantieren mit Elektronik-Hardware liegt mir derart im Blut, da brauche ich keine Ermunterung. Am besten geht es mir, wenn ich den Lötkolben ankurbeln kann, dann gelingt immer was. Es wird also auch in diesem Projekt weitergehen, da will ich durch, notfalls mit dem Kopf usw.....Das Uno32-Kit ist nach wie vor eine große Versuchung, das gibts ja bei Conrad für wenig Geld incl. deut. Anleitungsbuch. Aber.... aber dann würde ich mich evtl. in diesem System einrichten und stünde trotzdem irgendwann vor den Probs, die ich jetzt habe. Und im Vertrauen, was soll ich mit so'ner Power-MCU, die gut einen PC unterhalten könnte? Was mich jetzt mehr hindert als die grundlegenden Probs ist das Weihnachtsfest. Das fordert nun mal Tribut, und das soll ja auch so sein. Werde immer mal versuchen, mich zwischendurch in meine Werkstatt davon zu stehlen, aber..... Ganz viele herzliche Dankeschön (wie geht der Plural?) an euch, und feiert mal tüchtig. Grüße, wihelmT
Chris B. schrieb: > Wenn der Taster an PORTA hängt sollte man aber UNBEDINGT den > entsprechenden Pin auf DIGITAL schalten, da alle PIC10/12/16/18 mit > Analogfunktionen diese auf PORTA (teilweise auch PORTB) haben, welche > per Default aktiv sind. > > Sonst hat der TO den nächsten Reinfall ;-) Ja stimmt, (darum keine Garantie ...) Also Wilhelm, Datenblatt -> PORTA ... ANSEL ??? -> ANSELbits.??? = ?;
PIC nico schrieb im Beitrag #3937231: > Michael Skropski schrieb: >> Mit den Configs finde ich den MikroC Compiler sehr nett. Da brauch ich >> kein Blick ins Datenblatt machen, da kann man alles mittels >> Vollständigen Text in einem Dropdown Menü ändern: >> https://asimlink.files.wordpress.com/2011/08/confi... >> Find ich besser als alles mit komischen pragmas zu machen. MikroC hat >> aber andere (wenige) Schwachpunkte. > > Das ging sowohl in MPLAB 8 und nun in X auch: > http://pic-projekte.de/wordpress/wp-content/upload... > > Man gelangt dann zu einem ähnlichen Dropdown Menü, wie Du es am > Beispiel gezeigt hast. @Wilhelm: Schön am Ball bleiben :-) Wieso habe ich das immer übersehen? Das wollte ich immer haben^^ Werde ich mir mal zu gemüte führen. Be Ti schrieb: > Es muss wohl auf Weihnachten zugehen: Ich bin total gerührt - und ringe > etwas um Fassung! Erwartet hatte ich einen Shitstorm Bitte nicht weinen ;) Wenn man vernünftig miteinander reden kann, kommt sowas auch kaum vor. Ich habe aber auch das Gefühl, dass die PIC-Fraktion (und die dürfte mittlerweile hier ausschließlich mitwirken) etwas "gechillter" im Umgang mit den Mitmenschen ist. Und das nicht nur bei den Ratschlägen "mit welchem uC man denn anfangen sollte". Be Ti schrieb: > Nachdem dies ausgeblieben ist, sitze ich hier und wundere mich: Über die > zahlreichen Hilfsangebote im Forum und auch die vielen Worte des > Verständnisses und noch mehr über die gutmeinenden > Durchhalte-Empfehlungen. Naja, so hat JEDER mal angefangen und hat auch etwas länger über etwas grübeln müssen, was er heutzutage in ner Minute macht (auch wenn manche es nicht zugeben wollen). Daher kann ich nicht veverstehen, wie man da kein Verständnis für haben kann. Ich kann auch nur sagen, dran bleiben lohnt sich. Das was man alles mit uCs machen kann ist enorm. In eigentlich jedem Projekt von mir ist ein uC bei;) Auch wenn es öfter nicht das aufwendigste bzw. hauptsächliche ist (z.B. uC gesteuertes Netzteil). Be Ti schrieb: > Dankeschön (wie geht der Plural?) Na, Dankeschöne oder Dankeschöns ;)
ES BRENNT! Nein, nicht der W-Baum, aber immerhinque EIN Licht! Gerade ist es mir gelungen, das erste Demo-Projekt des einfachen D-Boards (4 Led) zum Laufen zu bekommen. Hat natürlich auch wieder geklemmt, aber was solls jetzt: Ein kleiner, ein ganz ein kleiner Schritt für mich, aber lass ma! Dem C bin ich damit kaum näher gekommen, das Prog läuft in Assembler, und mein Anteil am Erfolg ist bescheiden: er beschränkt sich darauf, zu erkennen, dass es sinnvoll sein könnte, nach einem File bestimmter Art zu suchen, und es zu finden. Is klar.....es gab wieder Meckermeldungen, der Name wäre zu lang, zuviele spaces......, und nach dem vermutet viel zu frühem Druck auf das grüne Dreieck "Run Projekt" tat sich außer den Meckermeldungen auch kaum was und dann schien auch schon wieder das Ende erreicht. Als ich schon abschalten wollte, tauchte die übliche Warnmeldung auf, man solle auf die Versorgungsspannung für das D-Board achten, und dann lief doch noch was weiter....und dann war erst mal das vorinstallierte Prog mit der wandernden Led im PIC16F1829 weg......und eine Led "stand still". Das sollte ja das Ergebnis dieses ersten Beispiel-Progs sein. Wie sang es sich gleich zu Anfang der "Horror Picture show" doch so wunderschön: "There's a light......in the darkness of our life...." Ne, was ist das schön. Das Licht am Ende des Tunnels beginnt ganz schwach zu schimmern.......jetzt aber alle ab zum Feiern! Und noch mal: Schöne Dankeschüss(e), wilhelmT
Be Ti schrieb: > Ein kleiner, ein ganz ein kleiner Schritt für mich, > aber lass ma! Dem C bin ich damit kaum näher gekommen, das Prog läuft in > Assembler, Spielt gar keine Rolle, gewöhn dich ruhig an die IDE mit Assembler Programmen !
Volker SchK schrieb: > gewöhn dich ruhig an die IDE mit Assembler Programmen ! Nix, kommt nicht in Frage! Wollte die Prog-Beispiele (PB) quasi simultan - also z.B. erst in Assembler, dann in C - ausführen. Bin heute im Dunkeln ein Stück weitergestolpert: Das erste PB wollte in C nicht. Da hab' ich die weiter oben kolportiere Vermutung geteilt, dass diese PBs vielleicht mit dem C18-Compiler entwickelt wurden und deshalb nicht.....Also ich wacker am C18 installieren, dann entsetzt feststellen, dass trotz aller problemlos verlaufener Installationen das MPLAB X IDE den neuen C18 nicht finden wollte. Irgendwann hatte er ihn doch gefunden (Tools, Option, ect..) und der C18 ließ sich als default einstellen. Beim freudigen Aufruf des nächsten (und aller folgenden) PBs war der in der Auswahlliste (Properties) aber dennoch nicht enthalten. Und - tusch - das BP funktionierte in C dann doch. Warum und mit welchem Compiler denn nun....bitte andere Frage! Stand jetzt 14:30 Uhr lassen sich alle Beispiele sowohl in Ass. wie auch in C aufrufen. Es hakt zwar immer noch bei diesen Aufrufen, aber irgendwie komme ich doch zum Ziel. Die ersten 3 BPs sind bi-fach abgearbeitet. Die Absicht: Alle Beispiele in beiden Sprachen durcharbeiten, dabei täglich ein Kapitel C lesen, Hewlett-Packard zwecks Tintenumsatz zum Glück verhelfen, indem doch noch diverse fette Manusripte/Datenblätter komplett ausgedruckt werden, auch versuchen, den Haken aus der MPLAB-Bedienung zu entfernen, und dann mal erst ein Resümmee (da mußte ich erst im Duden nachschauen, wie man das.....) ziehen. Kurz gesagt: Das gestern vermeintlich wahrgenommene unstete Irrlicht konnte heute tatsächlich als das erhoffte Licht ...usw....verifiziert werden. Gleich stürzt die komplette Verwandschaft über uns und den Kuchen her....und keiner außer mir will da über Bits und Bytes reden, voll der Horror! Nu feiert mal schön. Gruß, wilhelmT Es klingelt, muss wech...
Be Ti schrieb: > Stand jetzt 14:30 Uhr lassen sich alle Beispiele sowohl in Ass. wie auch > in C aufrufen. Es hakt zwar immer noch bei diesen Aufrufen, aber > irgendwie komme ich doch zum Ziel. Die ersten 3 BPs sind bi-fach > abgearbeitet. Super, ich denke das schlimmste hast du überstanden ;-)
Das sind ja gute Nachrichten. Trotzdem noch ein paar gut gemeinte Ratschläge: Such dir EIN Beispielprogram aus das auf Deine Hardware passt und Dir generell nützlich ist. Auch vergewissere Dich dass es sich Fehlerfrei bauen lässt und auf den uC geladen werden kann und so funktioniert wie es soll. Dann geh das Programm von oben systematisch Zeile an Zeile durch und versuche zu durch Nachschauen (Datenblatt, Compiler Doku, Internet) zu verstehen welchen Zwecke jede Programmzeile hat und füge Deine eigenen Kommentare hinzu. (Kopier vorher das ganze BP in einen neuen Ordner. Man sollte BP nicht verändern und arbeite nur mit der Kopie) Damit erreichst Du viel. Studiere jede Programmzeile bist Du gründlich vesteht warum sie vorhanden ist. Das gibt Dir zum Anfang einen guten Einblick in die notwendigen Grundeinstellungen des Mikrocontrollers. Dann solltest Du Dich gründlich mit den Peripherien des uC befasssen und nach Beispielen suchen wie sie typisch konfiguriert und eingesetzt werden und wiederum gehe das Programm systematisch Zeile für Zeile durch bis Du genau verstehst was vor sich geht. Gut ist es auch so bald wie möglich zu lernen wie man PORT pins ansteuert und abfragt, wie man den UART gebraucht, die Timer, den ADC, PWM, und später auch die Interrupts. Dann, fang an kleine Änderungen am eigentlichen Programm zu machen wie einen anderen Port pin zu konfigurieren und ansteuern bis es geht. Damit schfft man sich eigenes Vertrauen. (Das war damals für mich sehr nützlich.) Nie vergessen: Mikrocomputer sind wirklich wie kleine Kinder: man muß in alles, aber auch wirklich alles genau sagen was sie tun sollen, sonst machen sie nichts oder was ganz anderes wie Du willst. Zum leichteren Arbeiten mit Den Werkzeugen besorg Dir nach Möglichkeit einen Zweiten großen Monitor. Da tut man sich beträchtlich leichter mit den Dokumenten und vermehrt nicht die Aktien von HP und trägt nicht so viel am Bäumesterben bei. Meistens schaut man sich nur kleine Teile von Handbüchern an und da lohnt sich das Ausdrucken eher weniger. Jedenfalls wünsche ich Dir viel Erfolg und Freude mit dieser (für Dich) neuen Technik. Und habe Geduld, Rom wurde ja schließlich auch nicht an einem Tag gebaut. Grüße, Gerhard
:
Bearbeitet durch User
Angehängte Dateien:
-
Config_Bits.png
70 KB -
Config_Output.png
52 KB
Also ich habe jetzt ein simples Blinklicht gemacht. Als Hilfe habe ich das Datenblatt des PIC18F45K20 und den Schaltplan des Boards genommen (der nicht leicht zu finden war). Dieser ist in der Anleitung "PICkit3 Debug Express PIC18F45K20 - MPLAB C Lessons" -.- Habe ich aber nochmal angehängt hier. Ich versuche mich mal an einer abgespeckten Anleitung: 1. Lege ein Projekt an: a) Klicke auf "File"->"New Project" b) Wähle unter "Microchip Embedded" ein "Standalone Project" aus und klicke auf "Next >" c) Wähle nun unter "Advanced ... (PIC18)" den "PIC18F45K20" aus d) Das PICKIT3 und den XC8 Compiler wählen und schließlich den Speicherort angeben 2. Mit Rechtsklick auf das erstellte Projekt und mit "New"->"New C Main File" eine neue c-Datei erstellen Die erstellte Datei enthält jetzt ein gewissen Standard:
1 | /*
|
2 | * File: newmain.c
|
3 | * Author: Nutzer...
|
4 | *
|
5 | * Created on 26. Dezember 2014, 00:09
|
6 | */
|
7 | |
8 | #include <stdio.h> |
9 | #include <stdlib.h> |
10 | |
11 | /*
|
12 | *
|
13 | */
|
14 | int main(int argc, char** argv) { |
15 | |
16 | return (EXIT_SUCCESS); |
17 | }
|
Man könnte hier die main auch umschreiben in:
1 | void main(){ |
2 | |
3 | }
|
Ich habe jedenfalls noch nie Parameter oder Rückgabewerte einer Main (bei µCs) gebraucht. 3. C-Datei mit dem Grundlegenden füllen a) Zuerst includiert man die xc.h, um die Registernamen uvm nutzen zu können b) Noch über die "#include"s kommt eine Definition, die wir z.B. für die Wartefunktionen brauchen:
1 | #define _XTAL_FREQ 16000000 // Die Frequenz des Quarzes/Oszillators in Hz
|
c) Als nächstes kommt die Config des Controllers. Hierzu gehst du auf "Windows"->"PIC Memory Views"->"Configuration Bits". Es öffnet sich nun ein neues Fenster unten (siehe Config Bits.png). Hier kann man jetzt die nötigen Einstellungen machen (z.B. interner Oscillator). Ist man fertig, klickt man auf "Generate Source Code to Output", woraufhin der Code erzeugt wird (siehe Config Output.png). Das alles kopierst du unter die "#include"s und vor die main-Funktion 4. Das eigentliche Programm schreiben a) Der grobe, allgemeine Aufbau sieht eigentlich immer so aus:
1 | void main(){ |
2 | // Initialisierung der Module/Register
|
3 | while(1){ // Endlosschleife, da wenn die Main beendet wird, das Programm |
4 | // "zuende ist". So wie beim ASM-Befehl END
|
5 | // hier kommt das Programm rein
|
6 | }
|
7 | }
|
b) Steht dieses Gerüst, müssen also zunächst die Register resp. die Module initialisiert werden. In meinem Fall sieht die so aus:
1 | OSCCON = 0b01110011; // 16MHz, Internal Oscillator Block |
2 | |
3 | ADCON0 = 0b00000001; // Channel AN0, Nicht gestartet, ADC Aktiviert |
4 | ADCON1 = 0; // Vss bis Vdd |
5 | ADCON2 = 0b10100110; // rechtsbündig, 8 Tad, Fosc/64 |
6 | ANSEL = 0b00000001; // RA0 -> Analog Input AN0 (Poti) |
7 | ANSELH = 0; // Rest ist Digital IO |
8 | |
9 | TRISA = 0b00000001; // Analoger Input |
10 | TRISB = 0b00000001; // RB0 ist Taster SW1 |
11 | TRISC = 0; // PORTC ist Ausgang |
12 | TRISD = 0; // PORTD sind die LEDs |
Diese Initialisierung braucht man eigentlich nicht mehr ändern, wenn man das nutzt, was auf dem Board ist. Es wird also auch der ADC für den Poti und der Taster konfiguriert. c) Jetzt muss das Blinklicht nur noch programmiert werden. Das KÖNNTE so aussehen:
1 | while(1){ |
2 | LATD = 0xFF; |
3 | __delay_ms(500); |
4 | LATD = 0; |
5 | __delay_ms(500); |
6 | }
|
Es wird also jedes Bit vom PORTD (LATD für den Ausgangs-Latch) auf 1 gesetzt, 500ms gewartet, wieder auf 0 gesetzt und wieder gewartet. Das funktionierte bei mir aber nicht. Es kam die Meldung:
1 | newmain.c:__: error: inline delay argument too large |
Das bedeutet, dass das Argument zu groß ist. Wenn man mit gedrückter Strg-Taste auf die Funktion "__delay_ms" klickt, gelangt man zur definition (in der pic18.h). Dort steht:
1 | #define __delay_ms(x) _delay((unsigned long)((x)*(_XTAL_FREQ/4000.0)))
|
Das bedeutet, je größer _XTAL_FREQ ist, desto kleiner muss x (also die Dauer in ms) sein, da sonst das komplette Ergebnis zu groß wird. Durch testen bin ich darauf gekommen, dass 49ms noch gingen, 50ms aber nicht mehr. Daher musste ich einen kleinen Workaround machen: d) Außerhalb (über) der main-Funktion habe ich eine neue Funktion "warte_10ms" geschrieben:
1 | void warte_10ms(int multi){ |
2 | int i; |
3 | for(i=0;i<multi;i++){ // Extra Warteschleife mit vielfachen von 10ms |
4 | __delay_ms(10); // da bei 16MHz __delay_ms(50) oder mehr einen Fehler macht: |
5 | } // newmain.c:__: error: inline delay argument too large |
6 | }
|
In dieser Funktion wird "__delay_ms(10);" in einer Schleife aufgerufen, die so oft aufgerufen wird, wie die Zahl, die im Übergabeparameter steht. Setzt man diese Zahl auf 50, so wird die Schleife 50x durchlaufen und insgesamt 500ms gewartet. Das Blinklicht ändert sich dadurch zu:
1 | while(1){ |
2 | LATD = 0xFF; |
3 | warte_10ms(50); |
4 | LATD = 0; |
5 | warte_10ms(50); |
6 | }
|
Ich habe es kompiliert und auf das DemoBoard gespielt und es funktioniert. Somit hast du ein Programm, womit du das Board testen kannst. Die c-Datei habe ich auch so nochmal angehangen. Ich hoffe, das konnte dir Helfen. Aber auch wenn das funktioniert, musst du zeitnah lernen, was Schleifen, Funktionen oder Variablen(deklarationen) sind und was das mit der # soll. DAS sprengt den Zeitrahmen, den man hier aufbringen müsste. Dafür sind die C-Anleitungen da.
Ich bin sowohl von der gestrigen Kuchenschlacht, der folgenden Futterei am Raclett wie auch von euren erneuten aufmunternden Worten und konkreten Hilfsangeboten geplättet. @ Gerhard: Du schriebst:"....sobald wie möglich zu lernen wie man PORT pins ansteuert und abfragt, wie man den UART gebraucht, die Timer, den ADC, PWM, und später auch die Interrupts" Bis auf den UART hatte ich das alles schon mal drauf, auch die Interrupts! Aber....aber alles in Assembler, alles für den PIC16F84 und alles vor so ungefähr 17 Jahren. Seitdem war aber nichts mehr, gar nichts, und zumindest bei mir herrscht da mehr erfürchtige Erinnerung an frühere Zeiten, als sofort umsetzbares Wissen. Und genau so, wie du es formulierst, stelle ich mir auch vor, im Weiteren vorzugehen. Michael Skropski schrieb: > Ich hoffe, das konnte dir Helfen. Nix....konntest du nicht!!! Konntest du schon deshalb nicht, weil es gerade schon wieder - siehe gestern - geklingelt hat. Das war der Weckruf für einen ausgiebigen Feiertagsspaziergang. Danach dann schon wieder essen, gemeinsam über die Werthaltigkeit der Weihnachtsgeschenke sinnieren.....und dann ....dann vielleicht kann ich mich feiertags wieder in meine Werkstatt davon stehlen. Deine Arbeit - und natürlich auch die aller anderen, die sich hier eingebracht hatten - wird aber selbstredend gewürdigt und genutzt werden. Irgendwie erscheint mir das Leben und seine Zeit mal wieder als recht kurz und insgesamt zu wenig. Es kribbelt mich in den Fingern, nach dem Demoboard II zu greifen und das Alles gleich auszuprobieren....aber ich seht ja.....frau läßt mich nicht. Ein schlichtes Danke .....und feiert mal weiter, die Gelegenheit ist zu günstig. Grüße, wilhemT
Michael Skropski schrieb: > d) Außerhalb (über) der main-Funktion habe ich eine neue Funktion > "warte_10ms" geschrieben:void warte_10ms(int multi){ > int i; > for(i=0;i<multi;i++){ // Extra Warteschleife mit vielfachen > von 10ms > __delay_ms(10); // da bei 16MHz __delay_ms(50) oder mehr > einen Fehler macht: > } // newmain.c:__: error: inline delay > argument too large > } Ich war wohl doch müder als ich dachte. Nicht dass es so nicht funktionieren würde, aber sinniger wäre es, eine "warte_1ms(unsigned int multi)" Funktion zu machen, wo in der Schleife auch die delay Funktion mit dem Parameter 1 aufgerufen wird und im Hauptprogramm dann auch "warte_1ms(500);" stehen müsste. Somit hat man eine 1ms Auflösung statt 10ms. Mit dem unsigned int (negative Zahlen machen bei der Schleife ja keinen Sinn) kann man dann etwas über 65 Sekunden warten, das sollte reichen. Ist wie gesagt für dieses Beispiel relativ egal, nur ist man dann eingeschränkter, wenn man das nochmal wo anders nutzen will.
Michael Skropski schrieb: >....in der Schleife auch die delay Funktion mit dem Parameter 1 aufgerufen > wird und im Hauptprogramm dann auch "warte_1ms(500);" stehen müsste... Stimmt, Michael, das war mir auch schon aufgefallen und das möchte ich jetzt auch noch kritisch anmerken.......! Jetzt fehlen mir wieder die passenden Smilies.....und ja doch, es hat auch just in diesen Sekunden wieder geklingelt, die W-Futterei verlangt nach Fortsetzung! Gruß, wilhelmT
Wie kann man nur ans Futtern denken wenn der Mikrocontroller ruft...
Gerhard O. schrieb: > Wie kann man nur ans Futtern denken wenn der Mikrocontroller ruft... Wie.....? Öhm....können Männer überhaupt denken? Es war einige Tage ruhig, aber nur hier. Ansonsten feiern, futtern, leider Spazierengehen, und 2x 2 Stück Enkelkinder über Nacht. Sämtliche Bits lagen verstaut im Regal, dafür wurden die Kasperlepuppen rausgeholt. Aber jetzt....aber heute wollte ich Nachmittags wieder an die Front, alleine.....mein Haupt-PC wollte nicht. Zwar Start-Piepser, aber kein Bild. Schwitz, fast alles zerlegt, dann wieder Bild über die Graka in der AMD-GPU. Danach auch wieder Bild über ext. Power-Graka! Der Mann kann nicht alles verstehen. Michael, dann kam dein Progvorschlag dran. Da war ich doch neugierig, ob es mit dem Abkupfern klappen könnte. Erst vermisste ich die 2x genannte "#include"s, aber lass ma, dann wollte sich das nicht compilieren lassen, ein rotes Zeichen kündete Ungutes. Is klar, in der letzten Zeile ein Semikolon vergessen, aber dann blinkten alle Leds, die überhaupt verbaut waren, im Gleichmarsch vor sich hin, und wieder erfüllt andächtiges Staunen den Raum: Eine Led blinken kann ja jeder, aber sieben...?!?! Also: das Abtippen komplett vorgekauter Bit-Nahrung klappt schon. Danke super herzlich, Michael, für deine Arbeit. Sowas hilft dem Opa auf den Micro-Controller! Gerhard: Schlechte Nachricht für dich: Muss jetzt wieder weg, gleich geht es schon wieder ans Futtern, das Gleiche wie Heiligabend: Brühe-Fondue. An alle Helfer und Wegbegleiter: Ihr seid die Besten, das ist eh' schon klar. Wünsche euch einen gelungenen Rutsch ins neue Jahr, dass euch beim Rutschen kein Auge und kein Finger weggeknallt wird, und die Erfüllung so etwa der Hälfte eurer Vorsätze im nächsten Jahr! Alles? Na, die Hälfte ist doch auch schon mal was. Grüße, wilhelmT
Dem Wortlaut dieses Freds entsprechend hat er – der Fred – sich erfüllt und könnte zu Ende sein. Die anfänglichen Fragen wie auch Unsicherheiten sind beantwortet, bzw. beseitigt. Die Hardware ist klar: Microchip PIC 16F1829 / 18F14K22 und 18F45K20, die Software ebenso: Der XC8-Compiler von MCHP, die beiden PICkit 3-Starterboards im 8-bit-Bereich und damit die dazugehörige Entwicklungsumgebung. Die dafür mitgelieferten Einführungs-Progs wie das eine individuell Vorgekaute funktionieren u laufen, im Blätterwald der diversen Unterlagen rauscht es. Würde mal frech sagen: aus dem Tunnel bin ich raus. Ein klares Danke für die Anschubhilfen, auch in potenzierter Form (beides). Eigentlich ist der Fred erledigt......was aber auch wiederum schade wäre um die aus meiner Sicht fruchtbare Kommunikation. Deshalb bin ich so mutig, mich hier gelegentlich zu melden, und auf die Entwicklungsstadien hinzuweisen und sozusagen einen Link zu geben auf spezielle Probleme, für deren Lösung ich den anderen, den allgemeinen Teil in Anspruch nehmen möchte. Ein Teil-Ziel hat sich geändert: Ursprünglich sollte die Werte eines Temperatur-Sensors aus einer gemischten digitalen Datenübertragung mit dem Capture-Modus ausgelesen werden. Das stelle ich erst mal zurück, weil es technisch kompliziert und aufwendig ist, an dieses S-Gemisch überhaupt heran zu kommen. Deswegen möchte ich nun einen eigenen Temp-Sensor verwenden. Der hat eine logarithmische Kennlinie. Um das auswerten zu können, habe ich in diesem Fred nach der Möglichkeit zur Berechnung einer Formel gefragt: Beitrag "Aus Temp-Sensor Tabellen-Werten Formel erstellen" Grüße, wilhelmT
Be Ti schrieb: > Würde mal frech sagen: aus dem Tunnel bin ich raus. Gratulation ! (Aufgeben gilt nicht ;-)
Hallo Wilhelm, Hier gibt es einen kleinen Überblick zum Thema Temperaturmessung: http://www.mikrocontroller.net/articles/Temperaturmessungs_%C3%9Cberblick mfg, Gerhard
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.