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.
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 mitIch 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.
Dann kann man leicht mit #if 1 zwischen den Versionen umschalten.Code:#if 0 alter code #else neuer code #endif
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.
Lesezeichen