PICKit3 programmierspannung lässt sich nicht auswählen

Ich muss schon wieder mal etwas Frust ablassen wegen der MPLAB-X

Ich wollte mal eben nur "eine Zeile" ändern...
so war die Idee vor 2 Stunden

Ich habe ein funktionierendes Projekt.

Nun wollte ich eine Kleinigkeit ändern.
Also habe ich das Projekt im Projektexplorer mit "Cut" kopiert
und mit Paste eingefügt.
Damit ich ein neues Projekt habe.

Das funktioniert vorne und hinten nicht.
Also habe ich die "eine" Source Datei, mehr ist das wirklich nicht, per Hand dort hin kopiert.
Compilieren geht.

Nun wollte ich den Chip programmieren, das geht nicht.
Irgendwas stimmt angeblich mit der Versorgong vom PICKit3 nicht.
Dann stellte ich fest, das er die Einstellungen "FALSCH" kopiert hat,
dort steht eine falsche Programmierspannung. Es müssen 5V sein und er hat 3,25 eingestellt.
Okay, also wollte ich sie umstellen, daber das geht auch nicht.
Er stellt die die geforderten 5V garnicht zur Auswahl.

Der eingestellte PIC 12F1840 ist aber richtig.

Das gesamte Projekt kopieren geht total in die Hose.
Ich lege jetzt ein komplett neues Projekt an.

Ich weis auch nicht warum er an alle meine Ordner IMMER ein .X ranhängt, ich hab noch nicht gefunden
wo man das deaktivieren kann. Grausaaaaaaaaaammmm....

Bei dem ersten Projekt geht es, beim kopierten kann ich die 5V Spannung nicht einstellen.
Der Scrollbalken geht nicht weiter runter, da ist wirklich Ende;)
Anhang 33975
Hm, schlechte Qualität,
ich pack die Bilder mal einzeln hier ein:

Hier geht es:
Anhang 33976

Hier leider nicht mehr
Anhang 33977

wie man sieht hat er nichteinmal die Configuration richtig kopiert....(Release und Simulator)

{edit}
Bei einem erneuten Versuch hat er nichtmal mer den Makefile kopiert.
Hier läuft alles völlig drunter und drüber.
Ich schmeiss den ganzen Kram jetzt runter und installiere es neu.....


Ich lass mal hier nur die eine Frage stehen:

Wie kann ich verhindern, das MPLAB an meine Ordner immer ein .X anhängt ?
Wenn mein Projekt "Test" heist, dann legt er einen Ordner mit "Test.X" an.
Wenn ich da ein .X haben wollte, hätte ich das bestimmt angegeben.

Mit der Programmierspannung hat sich jetzt auch geklärt.
Es war ein 12LF1840 eingestellt anstelle eines 12F1840. (hab ich vermutlich selbst verursacht, weil er den Typen auch nicht richtig kopiert hat :p )

Siro

Hallo Siro !

Also wegen einem "X" am Ende des Projektnamens würde ich mich nicht ärgern, zumal ich die free version vom XC Compiler verwende.
Kann sein, dass das MPLab X daraus die Version erkennt und weiss , wie es mit anderen älteren Projekten umzugehen hat.

Das mit der Programmierspannung kenn ich nicht, das sich das umstellt. Ich werde nur bei jedem neuen(!!) Projekt gefragt, ob ich mit der vorgegebenen Spannung..hier +5 V einverstanden bin....ich markiere dann "nicht mehr nachfragen in diesem Project.
Auch bei meinen anderen Enwicklerboard, das mit 3,3V arbeitet habe ich keine anderen Abfragen. benutze auch PICKIT-3 mit der wohl neuesten Firmware(geht ja automatisch).

Gruss
Gerhard

Zitat:

---

Zitat von Siro

Ich muss schon wieder mal etwas Frust ablassen wegen der MPLAB-X

---

Ich kann ja verstehen, wenn du Probleme mit einer Toolchain hast. Aber, Microchip macht einen Umsatz von rund 4 Milliarden $ mit seinen Chips. Dafür müssen schon eine Menge Programmierer mit seinen Tools arbeiten und damit auch klarkommen.

Zitat:

---

Ich wollte mal eben nur "eine Zeile" ändern...
so war die Idee vor 2 Stunden

Ich habe ein funktionierendes Projekt.

Nun wollte ich eine Kleinigkeit ändern. Also habe ich das Projekt im Projektexplorer mit "Cut" kopiert und mit Paste eingefügt. Damit ich ein neues Projekt habe.

---

Erst mal zu diesem Fall. Wenn es nur um eine Kleinigkeit geht und ich leicht wieder auf den alten Stand will, kommentiere ich den alten Code aus und schreib den neuen rein. Manchmal ist das etwas unhandlich wegen Kommentar in Kommentar. Dann lasse ich das den Präprozessor machen mit

Code:

---

#if 0
alter code
#else
neuer code
#endif

---

Dann kann man leicht mit #if 1 zwischen den Versionen umschalten.

Ich hab zu wenig Erfahrung mit "Projekten" egal mit welchem Tool. Ich hab möglicherweise zu lange auf der Shell-Ebene gearbeitet. Manche haben ihre Pfade und Abhängigkeiten gern relativ, andere absolut und manche auch gemischt. Ich traue mich daher nicht, Projekte als ganzes zu kopieren. Dies gilt ganz besonders für MPLAB, da ich damit je nach Rechner sowohl unter Windows als auch mit verschiedenen Linux Versionen am gleichen Projekt arbeite.

Ich erzeuge an jedem Ort (anderes Direktory oder anderer Rechner) ein neues Projekt. Damit stellt die IDE, der Schaltplaneditor oder das Layoutprogramm seine globalen Abhängigkeiten richtig ein. Dann kopiere ich die Sourcen da hinein und füge sie dem Projekt (als existing) hinzu. Und das unabhängig davon ob es C-Code, Schaltpläne oder Layouts sind. Die Struktur muß dabei nicht flach sein, es ist bei MPLABX kein Problem, unter dem Projektdirektory eines für includes und eines für sourcen zu haben.

Der Nachteil dieses Verfahrens ist, daß Einstellungen die nicht in den Sourcen stehen, an jedem Ort neu gemacht werden müssen. Bei MPLAB sind das nicht viele, sie betreffen nur Compiler und Debugger. Und es muß auch nur beim ersten Mal gemacht werden. Um das Ganze abzuschließen, die Sourcen verwalte ich mit einem Versionskontrollsystem, das sowohl von Linux als auch von Windows unterstütz wird. So kann ich an einem Rechner entwickeln und Debuggen, commite den aktuellen Stand, wechsle den Rechner, update und mache an der gleichen Stelle weiter.

Das angehängte .X stört mich nicht. Ein Projekt ist bei mir erstmal ein Direktory. Darin finden sich alle möglichen Files, Texte, PDFs etc. Außerdem gibt es dort Direktories für Schaltpläne, Layouts und auch eins für Code (und möglicherweise eines für PC-Code zum Ansteuern des Projektes). Bei manchen DIRs sagt der Name, was drin ist, bei Code für MPLAB ist da halt ein .X dran, kann ich mit leben. Ist das ganze größer, gibt es unter Projekt.X noch ein .include, ein .src oder ein .lib. Dies ist meine persönliche Organisation, das passt aber mit den von mir verwendeten Tools ganz gut zusammen.

MfG Klebwax

P.S. Du moserst ja öfter an den PICs rum. Du scheinst sie ja nicht zu mögen. Das ist ja auch in Ordnung, man muß ja nicht alles gut finden. Aber: warum verwendest du sie dann? Es gibt doch viele Alternativen mit vergleichbaren Eigenschaften. Da ist doch Frust und Misserfolg vorprogrammiert.

Zitat:

---

Ich kann ja verstehen, wenn du Probleme mit einer Toolchain hast. Aber, Microchip macht einen Umsatz von rund 4 Milliarden $ mit seinen Chips. Dafür müssen schon eine Menge Programmierer mit seinen Tools arbeiten und damit auch klarkommen.

---

O-Ton eines Support Mitarbeiter (gehört als Business Kunde und schon mindestens bis Tier 3 durchtelefoniert) für den XC Compiler, im Dialog über den Unsinn den der Compiler manchmal macht (im konkreten Fall war es ein wiederholter Struct-Zugriff der länger dauerte als das kopieren per Pointer, trotz maximaler Optimierung) und warum man dafür Geld bezahlen muss:

"Bei Microchip gibt es keine Querfinanzierung, jede Abteilung muss sich selbst finanzieren, daher muss die Compiler Abteilung ebenfalls irgendwo Gebühren verlangen"

Wenn das tatsächlich deren Mentalität ist, verstehe ich warum die Dokumentation teilweise fürn A**** ist, weil es keine dedizierten Doku Schreiber gibt, sondern jeder Entwickler selbst die Doku schreiben muss udn dass dann einfach als Lose Sammlung von Guides als Manual Tituliert wird.

Schade dass die Atmel gefressen haben .... hoffentlich lassen die jetzt nicht auch so stark nach bei neuen Produkten.

Zitat:

---

Du moserst ja öfter an den PICs rum. Du scheinst sie ja nicht zu mögen. Das ist ja auch in Ordnung, man muß ja nicht alles gut finden. Aber: warum verwendest du sie dann? Es gibt doch viele Alternativen mit vergleichbaren Eigenschaften. Da ist doch Frust und Misserfolg vorprogrammiert.

---

Moin zusammen,

erstmal Danke für eure Anteilnahme.

Ja, ich moser tatsächlich viel rum, was aber nicht bedeutet dass ich die PICs nicht mag.
Ganz im Gegenteil. Ich habe derart viel mit den Chips seit "Jahrzehnten" gemacht, dass ich sie nicht missen möchte.
Ich habe aber augenscheinlich Probleme mit der/den Entwicklungsumgebungen und das betrifft die IDE sowie die IPE (die ist für mich gestorben)

Nun habe ich festgestellt, dass das Problem mit dem Projekt kopieren "nicht immer" existiert,
bei einigen Projekten läuft es richtig, bei anderen völlig falsch bis garnicht.

.X:
Ich find das nicht so schön, dass Programme so "intelligent" arbeiten, dass sie selbstätig irgendetwas umbenenn
oder verändern. Das liegt mit Sicherheit auch an den "alten Gewohnheiten"
Wenn ich z.B. einen Verzeichnisbaum im Projektfenster der IDE sehe, der nicht annähernd mit meiner
Verzeichnisstruktur übereinstimmt bin ich schon überfordert.
Ich bekomme auch immer eine Krise wenn Windows im Explorer Ordner anzeigt, die es garnicht gibt oder vorgaukelt die heissen so,
in Wikrlichkeit heissen die aber ganz anders. Bestes Beispiel "User" und "Benutzer".
Versuch mal eine Datei zu finden, oder eine Software zu schreiben, die sich auf einen Ordner bezieht
den es garnicht gibt. Ein Automationsprogramm welches Ordner sichert, wird es auch nicht finden,
denn der Name stimmt ja nicht meinem Namen überein. Das .X sehe ich auch nicht im Projekt-Explorer.


Als ich anfing mit den PICs, gab es immer genau eine .asm Datei, die wurde Assembliert und ein Hexfile erzeugt.
Dann kamen irgendwann Projekte, (ich wuste nichtmal wozu die gut sein sollen) und fand es auch schon unübersichtlich.
nun kommen noch Workspaces dazu.

Das verrücksteste ist nun, das Projete sich auf Projekte beziehen können. Für mich ist es das reinste Chaos geworden.
Aber nur weil ich damit nicht zurecht komme, heisst es ja nicht das es schlecht ist.

Macht euch mal keine Sorgen, die PIC'se bleiben und gucke auch immer wieder nach neuen Typen.
Glücklicherweise haben die neueren ja kein EPROM Fenster mehr... ;) PIC12C508/JW war mein "Erster"


@Klebwax. das mit der bedingten Compilierung ist natürlich eine Möglichkeit. hast Du recht.
Ich habe jetzt sogar einfach die "main.c" kopiert, umbenannt und die "alte" mit Exclude from Build quasi rausgeschmissen.
Das geht recht gut. So brauche ich nichtmal ein neues Projekt anlegen.

Das eigentlich Problem "Programmierspannung lässt sich nicht einstellen" habe ich selbst verursacht.
Weil das Projekt nicht richtig kopiert wurde, fehlte auch die Einstellung des PICs und so habe "ich"
vermutlich den falschen, also die ow Voltage Variante ausgewählt. Dieses Problem habe ich also "selbst" verusacht
nur nicht sofort erkannt...

Ich muss doch gleich noch was anmeckern: ;)
Gathering Compiler Symbols
Ich weis nicht ob man das abschalten kann beim Starten der IDE, er braucht dafür aber ewig und scheint ALLE Projekte abzuklappern...

Siro

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:

Zitat:

---

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.

---

Nun habe ich ein Projekt innerhalb der IDE umbenannt.
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 :)

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

Das muss man echt mal gesehen haben...

Anhang 33991

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

Zitat:

---

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

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.

Anhang 33993

Siro

Zitat:

---

Zitat von Siro

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.

Zitat:

---

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

Hallo!

Zitat:

---

Zitat von Klebwax

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. ;)