Versucht es doch mal hiermit:
https://www.piccircuit.com/shop/soft...kit2-plus.html
Versucht es doch mal hiermit:
https://www.piccircuit.com/shop/soft...kit2-plus.html
Danke Dir, "indeas", diese Software kannte ich noch nicht.
Ich schaue mir das mal genauer an. Geht das auch mit dem PicKit3, das habe ich nämlich mehrfach hier rumliegen...
Meine verwendeten PICs sind zumindest in der DeviceList vorhanden.
Siro
Moin zusammen
der "Meckerer" ist wieder da
Nachdem die MPLAB-IDE nun gänzlich ausgerastet ist, habe ich ALLES von MPLAB deinstalliert
und auch mit Everything alle Hinterlassenschaften gesucht und entfernt und das war so Einiges..
Alle neu runtergeladen und installiert.
Soweit alles okay.
Feststellung:
Der Projektname innerhalb der IDE stimmt generell NICHT mit den Ordnernamen auf dem Datenträger überein.
Extrem problematisch wird es wenn man dann noch "Rename" innerhalb der IDE benutzt.
Über das angehängte .X habe ich mich ja schon länger geärgert, aber das geht wohl "leider" generell nicht anders:
Nun habe ich ein Projekt innerhalb der IDE umbenannt.ProjectName.X
The project directory created by the IDE to contain all of the projects files.
The directory's name is simply the project's name with a ".X" appended.
In most cases, this is where all of your source files and header files will be placed.
You may also create subdirectories for them or place them in directories external to your project.
Dafür gibt es im Menü extra den Punkt "Rename"
ABER: das passiert NICHT auf der Festplatte.
In der IDE habe ich nun ein Projekt V2.12
welches sich auf der Festplatte im Ordner V2.11.X befindet.
Damit ist das Chaos vorprogrammiert. Das ist für mich völlig untragbar....
ich wollte euch auch nur darüber informieren, damit euch nicht ein ähnliches Chaos wiederfährt.
und wünsche ein Bugfreies Wochenende
Siro
Ich hatte es ja schon einmal geschrieben, wenn ich eine neue Datei anlege oder in den Ordnern in der IDE verschiebe ... spiegelt sich das auf der Festplatte auch nicht wieder.
In Atmel Studio kann man sich wenigstens darauf verlassen und man kann sogar Dateien die zwar im Ordner sind aber nicht im Projekt mit einem Klick anzeigen lassen.
Ich werde das Atmel Studio vermissen ... danke Microchip ... back to Eclipse
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
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 MplabX als "Filemanager" benutzen wollte, würde ich auch nicht "Projects" sondern "Files" benutzen.Wenn ich z.B. einen Verzeichnisbaum im Projektfenster der IDE sehe, der nicht annähernd mit meiner Verzeichnisstruktur übereinstimmt bin ich schon überfordert.
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
Geändert von Klebwax (16.02.2019 um 08:50 Uhr)
Strom fließt auch durch krumme Drähte !
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
Lesezeichen