Das SDCC 4.1.0 Release kommt näher. Auch diesmal gab es seit dem vorigen wieder deutliche Fortschritte. Sorgen machen aber zur Zeit insbesondere die pic-Ports. Es besteht die Gefahr, dass die pic14- und pic16-Ports in zukünftigen Releases nicht mehr enthalten sein könnten. Schon seit langem gibt es für diese beiden keinen Maintainer. Die gputils, die von SDCC für die pic-Ports genutzt werden, haben keinen Maintainer. Auch die Build-Infrastruktur der pic-Ports ist teils etwas holprig. Gelegentlich gibt es Patches von Nutzern, aber erstens sind diese selten und zweitens ist es natürlich Aufwand, zu beurteilen, wie gut diese sind, erst recht für SDcc-Entwickler, die nicht mit PIC vertraut sind. Es wäre sehr hilfreich, wenn wenigstens die Regression tests für pic mit weniger Fehlern durchliefen. 2019 gab es zuletzt eine größere Verbesserung am pic14-Port (aus Patches eines Nutzers). Seither laufen die Regression tests durch (danach ist zwar bei mir dei Konsole unbenutzbar, aber immerhin kann man per make --no-print-directory test-pic14 &> log brauchbare Ausgabe in log erhalten). Aus meiner Sicht empfiehlt sich für pic14: * Das Problem mit der nach Ausführen der regression tests unbenutzbaren Konsole finden und beheben * Bugs, die zum Fehlschlagen von regression tests führen, beheben. * Unterstützung für long long und unsigned long long für pic14 implementieren (so dass auch tests, die diese Datentypen verwenden kompilieren). * Einzelne Tests, die auf pic14 nicht ausgeführt werden können (z.B. wegen zu kleinem Speicher) für pic14 deaktivieren. * Das Problem mit der build-Infrastruktur (anscheinend wird manchmal zur Buildzeit automake ausgeführt, was fehlschlägt, wenn die Version des lokalen automake nicht zu der passt, mit der eine andere Datei erstellt wurde) beheben. Durch die pic14-Verbesserungen 2019 ist pic16 nun hinter pic14 zurückgefallen. Für pic16 wäre der erste SChritt, die regression-Tests soweit zum Laufen zu bringen, dass man sinnvolle Ausgabe erhält (zur Zeit bei jedem Test " (f: 0, t: 0, c: 0, b: 0, T: 0)" - eigentlich sollte links der Name des tests stehen, und die beiden Nullen links sollten angeben, wieviele Fehlschläge es bei wie vielen Assertions gab, also etwas so: "abs (f: 0, t: 6, c: 1, b: 1151, T: 3288)"). Danach dürften ähnliche Schritte wie bei pic14 anstehen. Ich habe den Eindruck, dass es hier im Forum einige PIC-Nutzer gibt. Eventuell finden sich darunter ja welche, die ein paar Patches zu SDCC oder gputils beitragen könnten. Für den Einstieg könnte ich zwar durchaus Fragen zu SDCC beantworten, kenne mich aber nicht mit PIC aus.
:
Bearbeitet durch User
Hallo was spricht gegen die Nutzung des freien MPLAB und XC8? Gruß gerhard
Franko P. schrieb: > Hallo > was spricht gegen die Nutzung des freien MPLAB und XC8? > > Gruß > gerhard Meines Wissens sind diese zwar kostenlos, aber nicht frei. Auch wird von XC8 wohl nur C90 und C99 unterstützt, während bei SDCC auch neuere C-Standards wie C11 verfügbar sind.
Bitte 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.