wenn ich kompiluiere bekomme ich nur "libsdcc.lib: No such file or directory" was fehlt denn nun bei sdcc, der kann doch pic oder was? Gruss Stephan
:
Verschoben durch User
> der kann doch pic oder was? kann er. nur die libs sind ev nicht mehr dabei da teile davon non-free sind. ich hab sdcc selbst übersetzt, und die non-free option angemacht. $ pwd /usr/local/share/sdcc/non-free c-1po:/usr/local/share/sdcc/non-free$ ll total 16 drwxr-xr-x 4 root root 4096 Jun 7 2013 ./ drwxr-xr-x 5 root root 4096 Jun 7 2013 ../ drwxr-xr-x 4 root root 4096 Jun 7 2013 include/ drwxr-xr-x 5 root root 4096 Jun 7 2013 lib/ c-1po:/usr/local/share/sdcc/non-free$ ls lib/ pic14 pic16 src siehe zb https://bugs.launchpad.net/ubuntu/+source/sdcc/+bug/1077918
Peter, danke fuer eine erste Reaktion. ich hab den Bug-Beschrieb deines Verweises gelesen: der Hinweis auf das Paket "sdcc-libraries" ist fuer mich schon mal neue Info. Bin nun am "falschen Rechner" und pruefe dies entspr. morgen nach. Herzlichen Dank! Ich hatte mein Problem viel detaillierter beschrieben: * <Beitrag "sdcc, cin2h.pl fuer PIC16f5x oder PIC16f84 - Einstiegshuerden :-/"; Aber anscheinend muss in diesem Forum die Anfrage einen gewissen Grad an Schluddrigkeit aufweisen um ueberhaupt eine Reaktion zu provozieren... :-) gute Nacht Stephan
mein System sagt dass das Paket "sdcc-libraries" tatsaechlich bereits installiert ist.
Stephan schrieb: > Ich hatte mein Problem viel detaillierter beschrieben: > * <Beitrag "sdcc, cin2h.pl fuer PIC16f5x oder PIC16f84 - > Einstiegshuerden :-/" > First Post im Thread: Autor: Stephan (Gast) Datum: 12.05.2014 16:00 > Aber anscheinend muss in diesem Forum die Anfrage einen gewissen Grad > an Schluddrigkeit aufweisen um ueberhaupt eine Reaktion zu > provozieren... :-) First Post im Thread: Autor: Stephan (Gast) Datum: 12.05.2014 20:22 Das sind 4:22 Stunden. Etwas ungeduldig, oder ? Verwundert... A.
Andreas H. schrieb: > Das sind 4:22 Stunden. Etwas ungeduldig, oder ? > Verwundert... wenn ich sehe wie schnell und wie viel auf andere, extrem mager beschrieben Anfragen eingegangen wird, bin ich auch verwundert! nix fuer ungut. S. R. schrieb: > Aber da sind nur die freien Bibliotheken drin, nicht die > unfreien für PICs. :-) ja, weiter bitte! Ich haeng an deinen Lippen... schliesslich finde ich 141 *.[Sc] Dateien in ".../pic1[46]/libsdcc/" und 28 *.h Dateien in ".../include/pic1[46]/" Verzeichnisse: """ $ find /usr/share/sdcc/lib/src/ -name libsdcc /usr/share/sdcc/lib/src/pic16/libsdcc /usr/share/sdcc/lib/src/pic14/libsdcc $ find /usr/share/sdcc/lib/src/pic1*/libsdcc -type f | wc -l 141 $ find /usr/share/sdcc/include/ -iname '*.h' | grep 'pic1[46]' | wc -l 28 $ """ ich muesste doch was mit "cinc2h.pl" machen, verstehe dessen Anleitung aber nicht. Anwendungsbeispiele von cinc2h.pl Bitte! Stephan
Stephan schrieb: > Andreas H. schrieb: >> Das sind 4:22 Stunden. Etwas ungeduldig, oder ? >> Verwundert... > > wenn ich sehe wie schnell und wie viel auf andere, extrem mager > beschrieben Anfragen eingegangen wird, bin ich auch verwundert! > > nix fuer ungut. Durch Forum zuspamen machst du es auch nicht besser. Kann evt auch daran liegen, dass nunmal weniger Leute eine Antwort auf deine Frage bereit haben, als auf eine Frage wie man den Vorwidersand einer LED berechnet. Beim Problem selbst kann ich leider nicht helfen.
Kann der SDCC eigentlich wirklich PIC, oder tut der nur so? Die PIC-Unterstützung war ja lange Zeit sehr schlecht. Ich habe den SDCC etwas intensiver mit MCS-51 genutzt, und so richtig begeistert war ich da nicht. Man muss schon wissen, was für Schwächen der Compiler hat, und dementsprechend Code schreiben, mit dem der gut klarkommt. Und MCS-51 gehört ja (angeblich) zu den am Besten unterstützten Architekturen beim SDCC.
Stephan schrieb: > Andreas H. schrieb: >> Das sind 4:22 Stunden. Etwas ungeduldig, oder ? >> Verwundert... > > wenn ich sehe wie schnell und wie viel auf andere, extrem mager > beschrieben Anfragen eingegangen wird, bin ich auch verwundert! Naja, meist haben die Leutz dann aber auch schon selber was probiert, z.B. das, was im sdccman.pdf, Seite 68 (für Version 3.3) steht (aka "Wie sieht ein pic makefile für den SDCC aus, incl. compile & link"). Andere fragen sich vermutlich was an " cinc2h.pl (common-inc2h.pl) This program parse the gpasm header (p1xxx.inc) files and creates from them the SDCC header and device library files. In addition it needs the gpprocessor.c file also. These is included in the source package of gputils. " unklar ist. Spätestens bei den nächsten 100 Zeilen Comment sollte ja klar werden, dass es ein Tool ist, das aus den Microchip .inc files die SFRs und I/O infos rauszieht. Und extra für die "mager Informierten": Hintergrund ist, dass die original .inc Files von Microchip nicht GPL konform sind und man sie darum nicht problemlos weitergeben darf. A.
Andreas, danke fuer's reinkniehen in mein Problem. Andreas H. schrieb: > Naja, meist haben die Leutz dann aber auch schon selber was probiert, > z.B. das, was im sdccman.pdf, Seite 68 (für Version 3.3) steht (aka "Wie > sieht ein pic makefile für den SDCC aus, incl. compile & link"). also, unter <Beitrag "sdcc, cin2h.pl fuer PIC16f5x oder PIC16f84 - Einstiegshuerden :-/"; habe ich dokumentiert was ich "schon selber was probiert" habe. In diversen aufzufindenden Tutorials wird mit einem Banalstbeispiel "test.c" (praktisch leere main() Funktion) erstmal verifiziert dass sdcc sich uebrhaupt aufrufen laesst - dies tut bei mir. Als 2tes ein Banalstbeispiel "test_include.c" (irgendein #include + praktisch leere main()) um zu verifizieren dass die libs sitzen und erreichbar sind. Hierzu braucht es wohl kein makefile oder? Zumindest lese ich in den Tutorials nix davon... > Andere fragen sich vermutlich was an > > " cinc2h.pl (common-inc2h.pl) > > This program parse the gpasm header (p1xxx.inc) files and creates > from them the SDCC header and device library files. In addition it > needs the gpprocessor.c file also. These is included in the source > package of gputils. > " > > unklar ist. Spätestens bei den nächsten 100 Zeilen Comment sollte ja > klar werden, dass es ein Tool ist, das aus den Microchip .inc files die > SFRs und I/O infos rauszieht. Dies habe ich gesehen, gelesenn und verstanden. Es bleibt meine Frage: muss ich dies einsetzen, um fuer ein PICmicro der als unterstuetz gelistet ist, sdcc benutzen zu koennen? > Und extra für die "mager Informierten": Hintergrund ist, dass die > original .inc Files von Microchip nicht GPL konform sind und man sie > darum nicht problemlos weitergeben darf. Dies hatte ich ebenfalls gesehen, gelesen und verstanden, es bleibt meine Frage: da ich ja sowohl .h wie .S wie .lib Dateien in pic1[46] Verzeichnisse finde, ist dies vollstaendig? brauche ich mehr von diesen Dateien? wenn ja welche? wo ist die Anleitung diese in meine host Installation einzupflegen? Mittlerweile habe ich noch festgestellt dass --verbose nicht das Aequivalente von -V ist, deshalb hier ein durchlauf mit -V: """ $ sdcc -V -mpic14 -p16f84 test.c + /usr/bin/sdcpp -nostdinc -Wall -D__SDCC_PROCESSOR="16f84" -DSDCC_PROCESSOR="16f84" -D__SDCC_PIC16F84 -obj-ext=.o -D__SDCC=3_3_0 -DSDCC=330 -D__SDCC_REVISION=8604 -DSDCC_REVISION=8604 -D__SDCC_pic14 -DSDCC_pic14 -D__pic14 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /usr/bin/../share/sdcc/include/pic14 -isystem /usr/share/sdcc/include/pic14 -isystem /usr/bin/../share/sdcc/include -isystem /usr/share/sdcc/include test.c + /usr/bin/gpasm -o test.o -c test.asm + /usr/bin/gplink -I/usr/bin/../share/sdcc/lib/pic14 -I/usr/share/sdcc/lib/pic14 -I/usr/bin/../share/sdcc/lib/pic14 -I/usr/share/sdcc/lib/pic14 -w -r -o test test.o libsdcc.lib pic16f84.lib libsdcc.lib: No such file or directory + /usr/bin/gplink -I/usr/bin/../share/sdcc/lib/pic14 -I/usr/share/sdcc/lib/pic14 -I/usr/bin/../share/sdcc/lib/pic14 -I/usr/share/sdcc/lib/pic14 -w -r -o test test.o libsdcc.lib pic16f84.lib returned errorcode 256 $ $ sdcc -V -mpic14 -p16f84 --use-non-free test.c + /usr/bin/sdcpp -nostdinc -Wall -D__SDCC_PROCESSOR="16f84" -DSDCC_PROCESSOR="16f84" -D__SDCC_PIC16F84 -obj-ext=.o -D__SDCC_USE_NON_FREE -DSDCC_USE_NON_FREE -D__SDCC=3_3_0 -DSDCC=330 -D__SDCC_REVISION=8604 -DSDCC_REVISION=8604 -D__SDCC_pic14 -DSDCC_pic14 -D__pic14 -D__STDC_NO_COMPLEX__ -D__STDC_NO_THREADS__ -D__STDC_NO_ATOMICS__ -D__STDC_NO_VLA__ -isystem /usr/bin/../share/sdcc/include/pic14 -isystem /usr/share/sdcc/include/pic14 -isystem /usr/bin/../share/sdcc/include -isystem /usr/share/sdcc/include -isystem /usr/bin/../share/./pic14 -isystem /usr/share/./pic14 -isystem /usr/bin/../share/. -isystem /usr/share/. test.c + /usr/bin/gpasm -o test.o -c test.asm + /usr/bin/gplink -I/usr/bin/../share/sdcc/lib/pic14 -I/usr/share/sdcc/lib/pic14 -I/usr/bin/../share/sdcc/non-free/lib/pic14 -I/usr/share/sdcc/non-free/lib/pic14 -I/usr/bin/../share/sdcc/lib/pic14 -I/usr/share/sdcc/lib/pic14 -I/usr/bin/../share/sdcc/non-free/lib/pic14 -I/usr/share/sdcc/non-free/lib/pic14 -w -r -o test test.o libsdcc.lib pic16f84.lib libsdcc.lib: No such file or directory + /usr/bin/gplink -I/usr/bin/../share/sdcc/lib/pic14 -I/usr/share/sdcc/lib/pic14 -I/usr/bin/../share/sdcc/non-free/lib/pic14 -I/usr/share/sdcc/non-free/lib/pic14 -I/usr/bin/../share/sdcc/lib/pic14 -I/usr/share/sdcc/lib/pic14 -I/usr/bin/../share/sdcc/non-free/lib/pic14 -I/usr/share/sdcc/non-free/lib/pic14 -w -r -o test test.o libsdcc.lib pic16f84.lib returned errorcode 256 $ """
greg schrieb: > Ich habe den SDCC etwas intensiver mit MCS-51 genutzt, und so richtig > begeistert war ich da nicht. Man muss schon wissen, was für Schwächen > der Compiler hat, und dementsprechend Code schreiben, mit dem der gut > klarkommt. Magst du das mal näher ausführen? Ich wollte demnächst ein längeres Projekt mit dem machen (aber Z80). Auf was muss man da direkt achten, oder hilft nur stupide ASM lesen?
greg schrieb: > Kann der SDCC eigentlich wirklich PIC, oder tut der nur so? Die > PIC-Unterstützung war ja lange Zeit sehr schlecht. Vor etwa einem Jahr gab es zuletzt noch ein paar Verbesserungen bei den PIC. Das pic16-Backend ist deutlich besser als pic14. Aber das Niveau der anderen Backends erreichen beide nicht. Da müsste mal jemand der die PIC kennt etwas Zeit reinstecken (und wohl auch in die gputils, die SDCC verwendet). Philipp
S. R. schrieb: > greg schrieb: >> Ich habe den SDCC etwas intensiver mit MCS-51 genutzt, und so richtig >> begeistert war ich da nicht. Man muss schon wissen, was für Schwächen >> der Compiler hat, und dementsprechend Code schreiben, mit dem der gut >> klarkommt. > > Magst du das mal näher ausführen? Ich wollte demnächst ein längeres > Projekt mit dem machen (aber Z80). Auf was muss man da direkt achten, > oder hilft nur stupide ASM lesen? Das mcs51-Backend ist eines der ältesten. Im Gegensatz zu pic14 sollte es da kaum Bugs geben. Allerdings wurden einige interessante Optimierungen, die in anderen Backends (stm8, z80 und verwandte, teils auch hc08, s08) implementiert wurden, bisher nicht für mcs51 implementiert. Das z80-Backend sollte ebenfalls kaum Bugs haben, und auch halbwegs brauchbaren Code erzeugen. Als Schwächen (also C-Code, für den SDCC manchmal wenig effizienten asm-Code generiert) fallen mir gerade ein: Zugriff auf Member von lokalen struct / union und arithmetische Operationen auf 32-bit Ganzzahlen. Ansonsten gibt es auf https://sourceforge.net/p/sdcc/wiki/z80/ bzw. Im Kapitel 4.3 des Handbuchs noch ein paar Hinweise dazu, dem SDCC zu helfen, effizienten Code für Z80 zu generieren. Philipp
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.