PICKit3 programmierspannung lässt sich nicht auswählen

[Siro]

Ja Ceos, ich hatte das noch garnicht so richtig wahrgenommen.

Das muss man echt mal gesehen haben...

[Klebwax]

So ganz kann ich das nicht verstehen. Tools, die "Projekte" verwenden haben jedes ihr eigenes System. KiCad erzeugt dazu einen Ordner und legt eine Datei gleichen Namens (was ich mir nicht aussuchen kann) mit der Endung .pro (die ich nicht frei wählen kann) in diesem Ordner an. So What

MplabX legt einen Ordner mit dem Projektnamen und der Endung .X an. Ist nun mal so. Beide tun das, um zu erkennen, daß es sich um ein für sie relevantes Projekt handelt. Andere Systeme machen es anders, erwarten z.B. immer eine package.json im Projektdirektory oder irgendeine Lizenzdatei, auch wenn ich sie nicht brauche. Wenn man das nicht will, darf man das entsprechende Tool nicht benutzen.

Jetzt zu

Wenn ich z.B. einen Verzeichnisbaum im Projektfenster der IDE sehe, der nicht annähernd mit meiner Verzeichnisstruktur übereinstimmt bin ich schon überfordert.

Wenn ich MplabX als "Filemanager" benutzen wollte, würde ich auch nicht "Projects" sondern "Files" benutzen.

Ich hab die Darstellung im Projektfenster nie als "Verzeichnisbaum" betrachtet. Für mich ist das die logische Struktur meines Projektes, nicht die physikalische. Es ist so etwas wie die graphische Darstellung des Makefiles. Alles was in "Source" dargestellt ist, muß übersetzt werden, die Headerfiles natürlich nicht. Ändert sich ein Sourcefile, muß nur dieser übersetzt und alles gelinkt werden. Hat sich eine Library oder der Linkerfile geändert, muß nur neu gelinkt werden. Hat sich ein Headerfile geändert, müssen alle Sourcen, die diesen anziehen neu übersetzt werden. Wo die Files liegen ist da nicht vorgegeben. Manche Sourcen und Header gehören auch zu anderen Projekten und liegen ganz woanders. So benutze ich eine gemeinsame Sourcelibrary für I2C, die zentral an anderer Stelle liegt. Wenn die irgendwann stabil ist, entferne ich sie aus dem Sourcezweig und setze nur noch das Objekt in den Libraryzweig. Ich finde das alles ganz übersichtlich.

Bei selbstgebauten Buildumgebungen macht man das ähnlich, benutzt aber gerne das Filesystem für die Zuordnung der Files und baut sein Makefile passend auf. So übersetzt man z.B. alles was in "./source" steht. Will man da etwas externes mit drin haben, setz man einen Link auf diesen File nach source. Erzeugt man einen weiteren Sourcefile am falschen Platz, wird er nicht berücksichtigt. Liegt ein Objekt am falschen Ort, wird es nicht gelinkt. Dafür darf man Versuche die beim deguggen so entstehen, nicht in ./source lassen, da sie sonst immer mitübersetzt werden und mir spätestens beim linken Probleme machen. Das kann man so mögen oder auch nicht.

MfG Klebwax

[Siro]

Ich akzeptiere deine Meinung Klebwax,
ich habe da anscheinend eine andere Denkweise.

Für mich spiegelt ein Projektfenster meine Dateiarchitektur, was sie aber augenscheinlich in der MPLAB-IDE nicht macht.
Das ist "für mich" sehr verwirrend. Ich hab immer eine Verzeichnis, (was ich selbst bestimme wie es heisst) und dann
folgen, wenn überhaupt, Unterverzeichnisse.

Die Ordner in dem Projektfenster
-Header Files
-Important Files
-Linker Files
-Source Files
-Libraries
-Loadables
existieren ja auch nicht auf der Platte.
Die verwaltet MPLAB irgendwie intern. Hat vermutlich eine Art Liste mit Zeigern auf die entsprechende Dateien.
Und ich kann hier auch noch eigene "Unterordner" oder ich nenne das mal Kategorien erstellen,
hab ich grad mal ausprobiert.
Hat alles was für und wieder, will ich nicht abstreiten.

Übrigens kann man bei "Rename" einen Haken setzen, dass auch der Ordner mit umbenannt wird, habe ich grad gesehen.
Das macht es wieder etwas "ordentlicher"

Begeistern tut mich die IDE nicht wirklich, aber man kann es nie allen recht machen.
Ich nenne das mal Gewöhnungsbedürftig und man muss schon echt aufpassen.

Ich hab letztens auch mehrfach Software geändert und in den PIC programmiert, jedoch völlig ohne Änderung.
Es war nicht das Projekt aktivert in dem ich die Änderungen vorgenommen habe. Auch eine böse Falle...

Achja, und nicht den Haken beim Programmer PicKit3 vergessen, der war auch weg...
natürlich nur wenn man den PIC nicht in der Schaltung mit eigener Versorgung programmiert.



Siro

[Klebwax]

Für mich spiegelt ein Projektfenster meine Dateiarchitektur, was sie aber augenscheinlich in der MPLAB-IDE nicht macht.
Das ist "für mich" sehr verwirrend. Ich hab immer eine Verzeichnis, (was ich selbst bestimme wie es heisst) und dann folgen, wenn überhaupt, Unterverzeichnisse.

Das kannst du ja weiter so halten. Du packst dein eigenes Projektdirektory einfach in das von MplabX erzeugte Direktory mit dem .X. In diesem tummeln sich ja auch noch mehr Dinge, die automatisch erzeugt werden wie der Makefile und verschiedene Direktories (nbproject, build ..) in denen sich weitere Makefiles befinden und in denen die Zwischenprodukte des Compilers und des Linkers entstehen. Da findet man die Objekte, Map- und Elf-Files.

Ich schrieb ja schon, daß ich eigentlich kein Fan von IDEs bin, und daher auch kaum Erfahrung mit MS Studio oder Eclipse habe. Aber was netbeans so kann, ist schon eine Menge. Man kann in der History des Files zurückgehen und sich graphisch die gemachten Änderungen anzeigen lassen. Wenn man richtig mit Doxygen umgehen kann, zeigt es die Dokumentation zu eigenen Funktionen beim Editieren. Und da ich mich wegen der PICs nun mal damit beschäftigen muß, benutze ich netbeans auch für PC Programme z.B. in C oder Javascript.

Die Ordner in dem Projektfenster

Interpretire diese "Ordner" einfach als Fileklassen und nicht als Direktories im Filesystem. Das ist doch so üblich. "Meine Bilder" liegen möglicherweise verteilt in verschiedenenn Direktories und einige auch in der Cloud.

MfG Klebwax

[PICture]

Hallo!

Ich schrieb ja schon, daß ich eigentlich kein Fan von IDEs bin, und daher auch kaum Erfahrung mit MS Studio oder Eclipse habe.

Ich möchte nur kurz ergänzen, daß ich ale Assemblerprogramme für PICs, nur mit einfachstem Assemblerprogramm vom Microchip und eigenem Programmablaufdiagramm, wie früher für PC's beruflich, mit Texteditor geschrieben habe.