Der XC32-Compiler, der mit der MPLAB-IDE kommt, ist funktional beschnitten und optimiert offenbar nur kaum. Die Optimierungsfunktionen bekommt man nur in der Kaufversion. Leider scheint es aber die Lizensierungsvariante, bei der man für einen Tag eine Lizenz kaufen und nutzen kann nicht mehr, statt dessen gibt es z.B. dieses Dongle für einen Fantasiepreis. Deswegen meine Frage: gibt's für den PIC32 irgend einen Ersatz aus der Open-Source-Welt? Irgend einen schönen GCC oder so? Ich sehe es nicht wirklich ein, für mein Miniprojektchen einen 4stelligen Betrag hinzublättern. Danke!
Zonk schrieb: > Irgend einen schönen GCC oder so? Das ist ein GCC! Geh zu Microchip und bring uns den Quelltext. http://ww1.microchip.com/downloads/en/DeviceDoc/xc32-v2.20-full-install-release-notes.html PS: Dann versuch auch ich ihn zu übersetzen.
Zonk schrieb: > für den PIC32 irgend einen Ersatz aus der > Open-Source-Welt? es gibt "medizin" zum xc32, die auch gleich den xc8/xc16 von dem lizenz virus heilt. die apotheke lässt sich im netz finden. ... funktionier gut seit jahren. mt
Moin, Und es gibt Unmengen anderer µController, die mit vernuenftigen tools programmierbar sind. SCNR, WK
Die Toolchain (beschnitten oder teuer - Pest oder Cholera) war immer schon die Schwachstelle der Microchip-Controller. PIC32 allerdings ist ja intern MIPS. Vielleicht kommt man mit dem offiziellen MIPS Port des gcc weiter?
Im "chipkit core" ist ua. eine uneingeschränkte pic32 gcc toolchain enthalten.
Wer auf den beschnittenen XC compiler rumreitet, bezeugt seine eigene Unwissenheit. Hauptsache lästern, ohne je geprüft zu haben. In der freien Variante sind O0, O1 und O2 freigeschaltet. Das sollte für den Hobbyist kein Hindernis sein. Bei einigen meiner Programme fegt ein PIC32 mit O1 den STM32F103 mit O3 von der Bühne. Dafür ist das Binary 40% größer als das des M3. Anders ausgedrückt brauchte die ursprüngliche Lösung mit dem STM 28mA und durch den PIC wurde nur noch 22mA benötigt (dann allerdings mit O3). Und wie man zu dem O3 kommt, ist im Netz hinreichend beschrieben. Die Medizin ersetzt den xclm (proprietär). Könnte mir vorstellen, dass es dagegen Gesetze gibt. Und die MCHPchen XC selber bauen ist auch keine hohe Kunst. Oder doch eher die Binärpatches an GPL Sachen? Die specs-File Lösung ist spektakulär einfach.
So einen PIC32 kann man auch in (Maximite-)Basic programmieren. Machen scheinbar die Australier gerne.
Zonk schrieb: > Irgend einen schönen GCC oder so? Ich sehe es nicht wirklich ein, für > mein Miniprojektchen einen 4stelligen Betrag hinzublättern. Tja, unter der Haube handelt es sich ja sogar um einen GCC, nur das Microchip das nicht so ganz wahrhaben will und "seinen" Compiler für viel Geld unter die Leute bringt, sofern denn alle Optimierungen möglich sein sollen. Daher gibt es auch "Medizin". Microchip muss zwar dank GPL den Source-Code rausrücken, weigert sich aber seit Jahren deren XCxy-Compiler wirklich frei verfügbar zu machen. D.h. sie liefern den Quelltext aber keine Build-Tools, geschweige denn Binaries. Für mich persönlich ist so ein Verhalten komplett indiskutabel, weshalb ich deren Produkte meide wie der Teufel das Weihwasser. neuer PIC Freund schrieb im Beitrag #6082215: > In der freien Variante sind O0, O1 und O2 freigeschaltet. Das sollte für > den Hobbyist kein Hindernis sein. O2 ist meiner Meinung nach meistens das Optimum für einen Mikrocontroller. Manchmal möchte man jedoch auch mit Os übersetzen, je nachdem wie knapp man mit dem Flash ist. So wirklich groß sind die Unterschiede zwischen O2 und Os jedoch nicht, weder was die Größe, noch was die Geschwindigkeit angeht. Ich frage mich wer von den Leuten hier wirklich O3 einsetzt und wie da die Ergebnisse bezüglich Geschwindigkeitszuwachs sind. Ich denke, dass O3 selbst auf dem Desktop nur selten Sinn macht. Benchmarks von Phoronix haben etwa gezeigt, dass mit einem GCC mit O3 kompilierte Programme eher gleich schnell und häufig sogar geringfügig langsamer sind als jene, die mit O2 kompiliert wurden. Das liegt natürlich mitunter daran, dass sie in jedem Fall größer sind. Der theoretische Geschwindigkeitszuwachs wird dann durch den IO-Flaschenhalls zunichte gemacht. Für einen Mikrocontroller dürfte das sogar noch stärker gelten. Das einzige wo es meiner Meinung nach Sinn macht, sind extrem zeitkritische Routinen, bei denen man mittels Compilerdirektive geziehlt die Optimierung für diese eine Funktion auf O3 stellt. Das bringt aber nur dann etwas, wenn der auf den Code auch entsprechend schnell zugegriffen werden kann, d.h. man sollte den dann aus dem RAM ausführen. Dann hat man aber wieder das Problem der Buskollision, wenn Code und Daten gleichzeitig aus dem RAM gelesen bzw. ins RAM geschrieben werden sollen, d.h. das ganze macht nur mit TCM bzw. CCM Sinn.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.