Es geht um SDCC v.3.6.0 unter Linux und PIC16F Controller. Jetzt bastel ich schon eine Weile dran herum und werde nicht schlau. Im Netz findet man permanent immer "etwas" das einem sagt, der SDCC kann Code für PIC16F erzeugen. Man findet auch Hinweise, dass es die sogenannten GPUTILS benötigt. Ich habe beides installiert, aber nirgendwo finde ich eine Librarie pic14.lib (o.ä.) ein einfacher Compileraufruf: sdcc -mpic14 -p16f887 blink_f887.c führt immer zu einem : cannot generate code for target 'pic14' ----------------------------------- Zu '--use-none-free' bin ich ja noch gar nicht gekommen. Hrpmf... Wer kennt ein gutes Setup-Tutorial hierfür (kann ich irgendwie alles nicht glauben, mein Setup für STM32 war - soweit ich mich erinnern kann - einfacher). ----------------------------------- Sehe ich das richtig, dass der Linker für die PIC-Controller NICHT Bestandteil von SDCC ist, sondern das von GPUTILS vorgenommen wird und dass im SDCC keine Library hierfür vorhanden ist (auch wenn es Unterverzeichnisse hierfür in /usr/share/sdcc ... gibt) ? ----------------------------------- Wie gesagt, wenn einer eine gute Anleitung für das "builden" einer SDCC Toolchain für PIC16F hat: ich bin sehr dankbar dann dafür !
:
Verschoben durch Moderator
Ist etwas Overkill, aber vielleicht hilft es dir, wenn du MPLABX installierst und das SDCC Plugin. Könnte mir vorstellen, dass man beim Build alle Aufrufe im Output Window sehen kann. https://sites.google.com/site/rmaalmeida/mplabx-sdcc-toolchain
Ich arbeite mit PIC18f2680 un das alles unter CodeBlocks. Vieleicht kann das helfen: 1. SDCC downloaden und instalieren 2. gputils downloaden und instalieren 3. CodeBlocks downloaden und instalieren 4. CodeBlocks starten 5. in"Settings->Compiler and debuger->Selectet compiler" "sdcc compiler" wählen und mit "set as default" und "O.K" bestetigen Weill: SDCC < 3 used .rel as object extension. SDCC >=3 uses .o as object extension. Settings -> Compiler and Debugger -> Other settings -> Advanced Options -> Others -> Object file extension auf "o" ändern wenn SDCC >=3. Von Wikipedia: Starten Sie zunächst Ihre IDE Code :: Blocks. Dann nutzen Sie im Menü "Einstellungen" -> "Compiler und Debugger", um die SDCC Compiler-Optionen einrichten. Wählen Sie den "SDCC Compiler" Klicken Sie auf die Schaltfläche "Set as Default" Klicken Sie auf der Registerkarte "Toolchain executables" Klicken Sie auf den Reiter "Additional Paths" Überprüfen Sie die Pfade für die Installation und weitere Verzeichnisse. Normale Installations-Verzeichnis "C:\Program Files\SDCC" Normale zusätzliche Verzeichnisse "C:\Program Files\SDCC\bin" und "C:\Program Files\gputils\bin" Klicken Sie auf der Registerkarte "Search Directories" Überprüfen Sie die Suchverzeichnisse Normalen Compiler-Suche Verzeichnis "C:\Program Files\SDCC\include" PIC normalen Compiler-Suche Verzeichnis für SDCC 3.0 und höher von "C:\Program Files\SDCC\non-free\include" Normale Linker Suche Verzeichnis "C:\Program Files\SDCC\lib" Zweitens, erzeugen Sie ein leeres Projekt. In der Menüleiste wählen Sie "File" -> "New" -> "Project". Wählen Sie "Empty Project" und klicken auf GO. Geben Sie die erforderlichen Informationen ein. Sie erhalten Warnmeldungen, dass Code::Blocks does not know how to setup somethings; sie ignorieren es. Ändern Sie nun das Projekt, damit es mit SDCC arbeitet; In der Menüleiste wählen Sie "Project" -> "Properties";, wählen Sie die Registerkarte "Build Targets". Unter Ziel-Optionen ändern "Type" auf "Native". Beachten Sie, Sie müssen, um alle Ziele zu setzen, um "native" haben. Also, wählen Sie das andere Ziel, wenn sie auf dem richtigen Ebene existieren. Stellen Sie den Projekt-Build-Optionen; In der Menüleiste wählen Sie "Project" -> "Build Options". Unter dem "Compiler Settings" und unter dem Reiter "Compiler-Flag", stellen Sie entweder die CPU-Flag für PIC 16 oder 14 Bit-Befehle. In der Menü Project->Build options->Compiler Settings->Compiler Flags: stellen Sie entweder die CPU-Flag für PIC 16 oder 14 Bit-Befehle. In der Menü Project->Build options->Compiler Settings->Other options: -p18f2680 --obanksel=2 --optimize-cmp --optimize-df --use-non-free In der Menü Project->Build options->Linker settings->Links libraries: C:\Program Files\sdcc\lib\pic16\libc18f.lib
Läuft gerade ... aber eigentlich ist mir das viel zu heftig. Ich möchte eine so schlanke "Compilerdistribution" wie möglich haben und der MPLABX verschlingt schon knappe 650MB im Download. (Das Ziel ist eine Textmode IDE für verschiedene Prozessoren mit verschiedenen Familien. AVR, MCS51, STM32, NXP und STM8 laufen schon) ... wenn das nichts wird, wird PIC16 wohl weggelassen werden... schön wäre es aber schon !
skorpionx schrieb: > 1. SDCC downloaden und instalieren > 2. gputils downloaden und instalieren > 3. CodeBlocks downloaden und instalieren > 4. CodeBlocks starten > 5. in"Settings->Compiler and debuger->Selectet compiler" "sdcc compiler" > wählen und mit "set as default" und "O.K" bestetigen Werde ich mal machen um zu sehen, ob und wie der Aufruf des SDCC dann vonstatten geht ...
skorpionx schrieb: > SDCC < 3 used .rel as object extension. > SDCC >=3 uses .o as object extension. Ich hab den SDCC bisher nur mit MCS51 und STM8 am Funktionieren, aber hier produziert SDCC 3.6.0 (das ist wie ich denke im Moment die aktuellste Version) ebenfalls .rel Dateien
Ralph S. schrieb: > Ich möchte eine so schlanke "Compilerdistribution" wie möglich haben und > der MPLABX verschlingt schon knappe 650MB im Download. Ja klar, die Idee war auch installieren zum anschauen wie es gehen könnte und dann wieder löschen. Die Hinweise von skorpionix klingen aber auch interessant.
:
Bearbeitet durch User
Ralph S. schrieb: > Wie gesagt, wenn einer eine gute Anleitung für das "builden" einer SDCC > Toolchain für PIC16F hat: ich bin sehr dankbar dann dafür ! minimal, rudimentär: https://quozl.linux.org.au//pic16f84-sdcc-blink/
2^5 schrieb: > was gibt denn "sdcc -v" aus? das ist ja mein Problem, obwohl das Version 3.6.0 ist, steht da nichts von PIC14 und PIC16. Auf meiner Hauskiste (Linux 64 Bit habe ich jetzt eine Source kompiliert mit Option Parts all) ... die (uralte) 32 Bit Kiste (auf der das zum Schluß laufen soll) ist noch am kompilieren. Auf dem 64 Bit Rechner macht er jetzt einen Compilergang, macht aber noch diese Fehler:
1 | warning: Relocation symbol "_cinit" [0x0000] has no section. (pass 0) |
2 | warning: Relocation symbol "_cinit" [0x0004] has no section. (pass 0) |
3 | warning: Relocation symbol "_cinit" [0x001E] has no section. (pass 0) |
4 | warning: Relocation symbol "_cinit" [0x0022] has no section. (pass 0) |
5 | warning: Relocation symbol "_cinit" [0x0000] has no section. (pass 0) |
6 | warning: Relocation symbol "_cinit" [0x0004] has no section. (pass 0) |
7 | warning: Relocation symbol "_cinit" [0x001E] has no section. (pass 0) |
8 | warning: Relocation symbol "_cinit" [0x0022] has no section. (pass 0) |
ich denke, ich komme dem PIC-Controller auf die Spur. Wenn alles fertig ist, soll es mal wie in den Screenshots aussehen (und neben den schon funktionierenden fuer AVR, STM32, LPC, STM8, MCS51 und eben auch noch fuer PIC16/PIC18 ). :- ) eben extrem oldschool wie ich das von gaaaaaaaanz ganz früher mit Borland C++ gewohnt war
Die Optik gefällt mir. ;) Läuft das auch noch auf nem 486er? STM32 Proggen auf nem 486er wär irgendwie ganz Cool. ;)
Ich schrieb: > Läuft das auch noch auf nem 486er? STM32 Proggen auf nem 486er wär > irgendwie ganz Cool. ;) Lachen muss, sicher nicht. Es läuft auf alten Thin Clients (mit akzeptabler Geschwindigkeit) wie z.Bsp.: dem hier: https://www.ebay.de/sch/i.html?_from=R40&_trksid=m570.l1313&_nkw=thin+client+hp&_sacat=0 Oder einem HP-T5000 mit VIA EDEN 800 MHz CPU. Bei diesem hab ich das DOM entnommen, einen 1 Euro USB-Kartenleser zerlegt und die Platine an die USB Pins angelötet. Der läuft jetzt mit einer 4GB Karte. Das ganze läuft auch fast schon komplett auf einem Raspberry PI Zero. Einzig hier muß ich den PI noch überreden, dass er den Parityfehler eines CH340G nicht mehr hat. Wenn ich dem hier nicht auf die Schliche komme, werde ich einen STM32 Bootloader mit der echten seriellen Schnittstelle des PI's füttern müssen. Meine Textmode IDE bedient den Bootloader eines STM32 automatisch: Die RTS Leitung sendet 3 Impulse, die auf einen ATtiny13 gehen. Erfolgen die 3 Impulse innerhalb eines gewissen Zeitfensters, schaltet der Tiny den Bootloadermodus des STM32 ein. Erneute 3 Impulse schaltet den Bootloadermodus wieder aus und führt einen Reset am STM32 durch. Um das auf einem Raspi zum Laufen zu bringen mache ich mir keine Sorgen. Im Moment kämpfe ich mit dem Startup eines PIC16F887. Ich habe die Teile halt noch nie in der Hand gehabt. Wenn ich den in den Griff bekomme, werde ich auch diesen nach demselben Schema programmieren können, wie die anderen Familien. Bisher habe ich mich um die PIC gedrückt (einfach, weil ich vor über 25 Jahren die erste Generation in der Hand hatte, die in Assembler programmieren mußte und ich das fürchterlich gefunden hatte). Morgen bekomme ich einen solchen Chip und dann werde ich sehen, wie weit in der Hardware schon etwas funktioniert.
Hallo alle. Ich weiss, dass meine Frage off-topic ist, aber was fuer ein Linux console IDE ist es an den Bildern vom Ralph S? Ich mache nicht viel in der Linux Welt, aber dieses IDE hat mich and die alte TurboVision Zeiten erinnert. Danke.
igor schrieb: > Ich weiss, dass meine Frage off-topic ist, aber was fuer ein Linux > console IDE ist es an den Bildern vom Ralph S? Ich bin am schreiben dieser IDE (und wird ewig nicht fertig, weil mir immer wieder neue Dinge einfallen und ich auch immer wieder am erweitern der Quellcodes für die Microcontroller bin). igor schrieb: > aber dieses IDE hat mich and die > alte TurboVision Zeiten erinnert. Genau das soll es ja auch machen. Das ist die FreeVision Bibliothek aus FreePascal (die auf modifizierten TurboVision Code von Borland stammt). Die Shortkeys von damals hab ich aber geändert auf CTRL-C für Block kopieren und CTRL-V für einfügen, weil man sich an die von Microsoft eingeführten Tastenbelegungen einfach zu start gewöhnt hat.
Ein SDCC 3.6.0 ist alt. Der hier installierte meldet schon 3.6.5. und das ist bestimmt nicht die letzte Version...
Ralph S. schrieb: > Ich bin am schreiben dieser IDE (und wird ewig nicht fertig, weil mir > immer wieder neue Dinge einfallen und ich auch immer wieder am erweitern > der Quellcodes für die Microcontroller bin). Ist es ein opensource Projekt, oder eine Freizeit aktivitaet?
Ralph S. schrieb: > 2^5 schrieb: >> was gibt denn "sdcc -v" aus? > > das ist ja mein Problem, obwohl das Version 3.6.0 ist, steht da nichts > von PIC14 und PIC16. > Dann wurde er wohl unter Verwendung von ./configure --disable-pic14-port --disable-pic16-port erstellt (möglicherweise weil wer auch immer ihn kompilierte keine gputils installieren wollte). Wo hast Du den SDCC den her? Philipp
:
Bearbeitet durch User
Ralph S. schrieb: > Wie gesagt, wenn einer eine gute Anleitung für das "builden" einer SDCC > Toolchain für PIC16F hat: ich bin sehr dankbar dann dafür ! Ganz normal: 0) SDCC-Quellen (z.B. tarball oder aus dem svn) holen 1) Alle Abhängigkeiten installieren, insbesondere ein halbwegs aktuelles gputils 2) SDCC konfigurieren, via "./configure", wenn das Fehler meldet, siehe 1) 3) SDCC kompilieren, via "make" (oder make -j 4 oder so wenn es schneller gehen soll und ensprechend Kerne vorhanden sind) 4) SDCC installieren, via "make install" (erfordert root) Je nach Geschmack kann man die einzelnen Schritte noch variieren. Philipp
:
Bearbeitet durch User
aktuelle kamera schrieb: > Ein SDCC 3.6.0 ist alt. Allerdings immer noch das aktuelle Release. Aber ich bin zuversichtlich, dass sich das noch diesen Monat ändert. Philipp
Ich programmiere meinen PIC 18F2680 von Anfang parallel mit SDCC und Microchip Compiler. Durch Definition: #define MICROCHIP_C18 0 und dann Abfragen: #if MICROCHIP_C18 einzelne Teile werden angepasst auf beide Compiler. Das was mir sehr stört beim SDCC ist diese Begrenzung: #2589 Only 85 pointer possible in rom. This is too few! Ich habe mir einen Interpreter für Visualisierung geschrieben und dazu brauche ich viel Vordefinitionen in ROM. Es gibt auch Fehler aber mit denen kann (muss...) man sich arrangieren...
ich hab jetzt für 32- und 64 Bit den SDCC aus den Quellen kompiliert und SDCC übersetzt mir nun bis. Der Linker gibt leider noch folgende Warnungen aus:
1 | warning: Relocation symbol "_cinit" [0x0000] has no section. (pass 0) |
2 | warning: Relocation symbol "_cinit" [0x0004] has no section. (pass 0) |
3 | warning: Relocation symbol "_cinit" [0x001E] has no section. (pass 0) |
4 | warning: Relocation symbol "_cinit" [0x0022] has no section. (pass 0) |
Was muß ich in SDCC deklarieren, damit das Linkerscript von GPUTILS das korrekt referenziert und die Codesegmente korrekt eingestellt sind? Aus vergangenen IHK-Prüfungen hab ich jetzt einen PIC16F887 gefunden, mit dem werde ich, bis mein Satz Controller ankommt, testen. Leider liegen das Teil nicht in meiner Wohnung sonst würde ich noch heute Abend ausprobieren ob das blinkt oder nicht. Heute in der Mittagspause konnte ich zumindest ein HEX-File aus dem Internet über einen ATMega328 (als Arduino) flashen und weiß zumindest, dass die Hardware funktioniert. (Sorry wenn ich das hier poste. Für euch muß sich meine Frage genauso anfühlen, wie wenn ich ähnliches ueber AVR oder STM32 lese..) PIC eben absolutes Neuland für mich und ich weiß noch nicht einmal, ob sich das Auseinandersetzen damit lohnt. Heute Abend bin ich, weil ich einen Hardwaretest nicht machen kann, am Lesen, welche Werte die CONFIG-Words haben müssen (sehe ich das richtig, dass das, das Equivalent zu den AVR-Fuses ist, nur dass der PIC (ähnlich zu STM8 und STM32) nach einem Controllerreset eingestellt wird ?
>> Ein SDCC 3.6.0 ist alt. > Allerdings immer noch das aktuelle Release. Der 3.6.5 hier wird nicht an einem Baum gewachsen sein. Die Entwickler empfehlen ausdruecklich fuer neu aufgenommene Architekturen, wie z.B. die kleinen PICkels sich mit aktuellen Versionen zu versorgen.
aktuelle kamera schrieb: >>> Ein SDCC 3.6.0 ist alt. > >> Allerdings immer noch das aktuelle Release. > > Der 3.6.5 hier wird nicht an einem Baum gewachsen sein. > > Die Entwickler empfehlen ausdruecklich fuer neu aufgenommene > Architekturen, wie z.B. die kleinen PICkels sich mit > aktuellen Versionen zu versorgen. An die "aktuelle kamera": Dir ist aber schon durchaus bewußt, dass Philipp Klaus Krause einer der Entwickler von SDCC ist ????? (abgesehen davon läuft das SDCC jetzt ja, weil - aus welchem Grund auch immer - ich keine PIC Unterstützung hatte. Bisher hab ich es nur für STM8 verwendet und ganz selten noch MCS-51) Eine Version höher als 3.6.0 muß ein Snapshot gewesen sein ...
Teo D. schrieb: > Sollte der Thread nich besser in 'Compiler & IDEs' untergebracht werden? stimmt Freddi schrieb: > Schau mal mit unter > > /usr/share/gputils/lkr ... genau da bin ich schwer am schauen ! Obwohl ich immer Skrupel habe an etwas lang eingeführtem und getestetem zu schrauben. Die Erfahrung sagt mir, dass der Fehler zu 99,9% bei mir liegt... Okay, vllt. nur 99%
>warning: Relocation symbol "_cinit" [0x0000] has no section. (pass 0)
Glaube ich auch schon mal gehabt zu haben. Downgrade gputils auf
offizielle Version (zuvor svn-build) hat geholfen.
aktuelle kamera schrieb: >>> Ein SDCC 3.6.0 ist alt. > >> Allerdings immer noch das aktuelle Release. > > Der 3.6.5 hier wird nicht an einem Baum gewachsen sein. > Für Releases verwendet SDCC (zumindest seit ca 20 Jahren, wie es davor war weiß ich nicht) Versionsnummern, deren letzte Ziffer 0 ist. 3.6.5 war die Versionsnummer, die von Ende November 2016 bis Ende April 2017 verwendet wurde. Dein 3.6.5 ist also wohl aus den Quellen von damals kompiliert oder aus einem Snapshot jener Zeit. Wenn Du es genauer wissen willst: Direkt nach der Versionsnummer gibt sdcc--version noch eine Revisionsnummer aus. Philipp
Philipp Klaus K. schrieb: > aus einem Snapshot jener Zeit Vorsicht mit Snapshot. Es können manche alte Fehler beseitig sein aber neue ganz triviale Fehler drin sein. Vor einigen Jahren in einer solchen Version funktionierte Postinkrement Var++ nicht.
>sdcc --version
SDCC :
mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/
h
c08/s08/stm8 3.6.5 #9842 (MINGW32)
published under GNU General Public License (GPL)
Ob ich mir den selber kompiliert hab, weiss ich gar nicht mehr.
02/16/2017 06:02 3,719,680 sdcc.exe
Vielleicht mal Zeit einen neuen zu bauen.
Ja bei mir unter Debian (unstable): SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/TININative/ds400/hc08/s08/stm 8 3.5.0 #9253 (Mar 19 2016) (Linux) published under GNU General Public License (GPL) auch keine pics. Hier steht: https://sourceforge.net/p/sdcc/discussion/1865/thread/d3b853ef/?limit=25 "pic14 and pic16 ports are non-free because of licence requirements by Microchip (header files), so if you've installed the sdcc package from debian repos, it won't work. You would need the sdcc-non-free package which you said it's not available (I don't know its status)." also muss du den compiler fuer Pics selber bauen.
Möglicherweise wird in Zukunft Debian SDCC auch mit PIC-Unterstützung ausliefern: https://lists.debian.org/debian-legal/2018/01/msg00000.html Philipp
Jo... hab mal gputils und sdcc neu gebaut: sdcc --version SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/ hc08/s08/stm8 3.6.9 #10226 (Linux) unbedingt, aber auch gputils bauen und installieren
Hmm.... ich habe mal folgendes gefunden https://sourceforge.net/p/sdcc/mailman/message/29445610/ und das hier in die main.c gesetzt:
1 | void _sdcc_gsinit_startup(void) |
2 | {
|
3 | __asm pagesel _main __endasm; |
4 | __asm goto _main __endasm; |
5 | }
|
dann verschwinden die _cinit warnings. Leider kann ich es nicht testen, mangels hardwareaufbau... keine Lust alles raus zu kramen
Oooooh, das werd ich mal nach den närrischen Tagen ausprobieren.... im Moment ist Kölle angesagt. Hm, prinzipiell gestaltet sich PIC schwieriger als angenommen... aber wird.
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.