Nachdem ich mir einen Wolf suche wo mein Fehler liegt, dass ich kein
eigenes "printf" mit den PIC16FXXX Controllern und SDCC hinbekomme,
finde ich im Manual unter "Known Bugs":
1
4.5.9.1 Function arguments
2
3
Functions with variable argument lists (like printf) are not yet supported. Similarly, taking the address of the first argument passed into a function does not work: It is currently passed in WREG and has no address..
D.h. doch, dass das mit SDCC grundsätzlich nicht funktionieren wird!
(oder sehe ich das falsch?)
Gibt es einen freien (am besten open source) Compiler unter Linux, der
mit variabler Argumentenanzahl funktioniert ?
Ich weiß, dass es dir nicht unbedingt hilft, aber du solltest mal
überlegen ob du auf einem kleinen 8-Bit µC wirklich mit "hungrigen"
Funktionen wie printf arbeiten willst.
Das ist nicht mein "Problem". Mein "Problem" ist, dass ich mir eine
eigene Konsolenbasierende Umgebung (Linux) erarbeite, bei denen alle von
mir eingesetzten Familien ähnlich programmiert werden sollen (und von
daher auch eine sehr abgespeckte Version von printf verwendet werden
soll).
Mit einem PIC hatte ich bisher gar nichts zu tun, aber ich möchte den
(eigentlich nicht für mich, sondern für andere) mit implementieren und
ungerne würde ich eine Printf-Version weglassen.
Eine abgespeckte Printf-Version bspw. für einen MCS-51 belegt hier (mt
SDCC) und ohne float-Unterstützung ca. 1kB. Das hätte ich auch gerne für
einen PIC (auch wenn ich es im Moment gar nicht benötige).
@Max D.
Das angehängte Beispiel erzeugt mittels SDCC Compiler und Textausgabe
mittels abgespecktem printf sowie eine Ausgabe über serielle
Schnittstelle und blinkender LED für einen STM8S103 Controller 1019
Bytes !
Ich finde das für eine 8 Bit MCU (mit insgesamt 8kB Flash) nicht zuuuu
viel!
Fuer Linux verwende den Hitech Lite. Windows hat eine andere
Lizenzpolitik !
Wieso hast du dies nicht gleich gesagt, deine Beschreibung der IDE klang
nach was Plattformuebergreifendes oder Windows.
Seit 2009, als Hitech von Microchip aufgekauft wurde hat Microchip die
freizuegige Linux lizenz gemoppt, also ist suchen angesagt.
Zumindest war es der einzige kommerzielle Compiler welcher fuer Linux
eine
kostenlose Version lieferte, welche kommerziellem Einsatz explizit
erlaubt.
Ich meine die Free Versionen der XC Compiler sind auch komerziell
nutzbar. Egal unter welchem Betriebssystem. Auf der Produktseite steht:
########################################################################
Microchip’s line of award-winning MPLAB® XC C Compilers provides a
comprehensive solution for your project’s software development and is
offered in free, unrestricted-use downloads.
########################################################################
Es bestehen natürlich Einschränkungen hinsichtlich der verfügbaren
Optimierung. Nur dafür muss man dann eine Lizenz kaufen oder mieten.
Ob Ralph die (free) Compiler als Paket mit seiner IDE jetzt auch
verteilen darf, oder ob sich die potenziellen User den Compiler selber
von Microchip holen müssen? (sollte aber nicht das Riesenproblem sein,
den Compiler separat zu installieren)
Ralph S. schrieb:> Das angehängte Beispiel erzeugt mittels SDCC Compiler und Textausgabe> mittels abgespecktem printf sowie eine Ausgabe über serielle> Schnittstelle und blinkender LED für einen STM8S103 Controller 1019> Bytes !
Gerade mal ohne die blinkende LED getestet. XC8-Free braucht mit den
Funktionen printf() und delay() aus der Bibliothek 620 Bytes ;-)
Ralph S. schrieb:> Functions with variable argument lists (like printf) are not yet> supported.
Das dürfte am Hardwarestack liegen. Warum nimmst Du nicht die moderneren
PIC18 und höher?
Ralph S. schrieb:> Eine abgespeckte Printf-Version bspw. für einen MCS-51 belegt hier (mt> SDCC) und ohne float-Unterstützung ca. 1kB.
Die 8051 hatten ja auch schon immer einen Softwarestack. Die 8051 sind
alle core-kompatibel zueinander, da gibt es keine verschiedene
Befehlssätze.
Peter D. schrieb:> Das dürfte am Hardwarestack liegen. Warum nimmst Du nicht die moderneren> PIC18 und höher?
Ich befürchte ja auch, dass das am Hardwarestack liegt.
Warum ich keinen PIC18 nehme: Es geht nicht um ein konkretes Projekt, es
geht darum, meine Softwaretools zu erweitern damit bei Bedarf auch ein
Programm für einen PIC16 kompiliert werden kann (und bevor ich in meinen
Anleitungen schreibe, dass eine variable Argumentenliste nicht geht...
und ich dann eines besseren belehrt werde, möchte ich sicher sein, dass
es tatsächlich nicht geht).
: - ) ... wenn die Bestellung von PIC18F Controllern eintrifft, wird
meine Challenge von neuem beginnen !
Ralph S. schrieb:> Peter D. schrieb:>> Das dürfte am Hardwarestack liegen. Warum nimmst Du nicht die moderneren>> PIC18 und höher?>> Ich befürchte ja auch, dass das am Hardwarestack liegt.
Verstehe ich nicht.
Meint ihr den Hardwarestack für die Funktions-Adressen?
Hat der überhaupt irgendwas was mit den Parametern (Daten-Stack) zu tun?
Ist es ein Problem der geringen (Hardware)Stack-Tiefe bei den kleinen
PICs?
Volker S. schrieb:> Gerade mal ohne die blinkende LED getestet. XC8-Free braucht mit den> Funktionen printf() und delay() aus der Bibliothek 620 Bytes ;-)
Sorry, war nicht für einen PIC16 sondern PIC18F26K22. PIC16 kann ich
gerade nicht hardwaremäßig (UART) testen. Im Simulator sieht es aber gut
aus.
putchar() wird auf jeden Fall mit den korrekten Daten aufgerufen.
(<450 WORDs bei 16F877A)
Volker S. schrieb:> Verstehe ich nicht.> Meint ihr den Hardwarestack für die Funktions-Adressen?> Hat der überhaupt irgendwas was mit den Parametern (Daten-Stack) zu tun?
Ein Softwarestack vereinfacht erheblich die Übergabe größerer
Argumentenlisten und die Sicherung von Arbeitsregistern (Push/Pop).
Peter D. schrieb:> Ein Softwarestack vereinfacht erheblich die Übergabe
Ja, ich meinte jetzt den Zusammenhang zwischen dem Hardwarestack und dem
Softwarestack. Ist es demnach einfacher, wenn es nur einen Softwarestack
gibt und nicht einen Hardwarestack für die Rücksprungadressen und einen
Softwarestack für die Daten?
Volker S. schrieb:> Ist es demnach einfacher, wenn es nur einen Softwarestack> gibt und nicht einen Hardwarestack für die Rücksprungadressen und einen> Softwarestack für die Daten?
... das dürfte wohl des Pudels Kern sein !