Forum: Mikrocontroller und Digitale Elektronik PIC14, SDCC und "variable argument lists "


von Ralph S. (jjflash)


Lesenswert?

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 ?

von Max D. (max_d)


Lesenswert?

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.

von Ralph S. (jjflash)


Lesenswert?

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).

von Ralph S. (jjflash)


Angehängte Dateien:

Lesenswert?

@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!

von pic (Gast)


Lesenswert?

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.

von Volker S. (vloki)


Lesenswert?

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)

von Volker S. (vloki)


Lesenswert?

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 ;-)

von Peter D. (peda)


Lesenswert?

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.

von Ralph S. (jjflash)


Lesenswert?

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 !

von Volker S. (vloki)


Lesenswert?

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)

von Peter D. (peda)


Lesenswert?

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).

von Volker S. (vloki)


Lesenswert?

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?

von Ralph S. (jjflash)


Lesenswert?

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 !

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
Noch kein Account? Hier anmelden.