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.
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.
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
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))
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.
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 PIC18häß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:> 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:> 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 !!!
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
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)
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
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.
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.
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.
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.
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
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.
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.
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
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
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 !
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
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 ...
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.
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
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.
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)
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.
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 ;-)
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
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
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
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
#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
voidmain(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.
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
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 ;-)
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
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
intmain(intargc,char**argv){
15
16
return(EXIT_SUCCESS);
17
}
Man könnte hier die main auch umschreiben in:
1
voidmain(){
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
voidmain(){
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:
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:
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
voidwarte_10ms(intmulti){
2
inti;
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
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
Thread beobachten
Seitenaufteilung abschalten
