SDCC & PIC16887: Fehler in erzeugter ASM-Datei

[Ralph S. (jjflash)]

Ich kämpfe mit der PIC-Serie wie doof (und ich bitte gleich um 
Entschuldigung, mit der PIC-Familie beschäftige ich mich erst seit 3 
Wochen).

Im Anhang ist mein C-Programm und mein Makefile.

Der SDCC will dieses Programm partout nicht (korrekt) übersetzen. Das 
Programm soll mein eigenes printf implementieren und dieser Code 
funktioniert bereits mit AVR, STM32 und NXP mit den entsprechenden 
GCC-Compilern und der Code funktioniert auch mit MCS51 und STM8 mit dem 
SDCC Compiler...

Nur mit PIC will er nicht (und wie gesagt mit PIC beschäftige ich mich 
erst seit kurzem).

Zur Verfügung habe ich derzeit leider nur einen PIC16F887 (andere sind 
bestellt).

Der Compiler übersetzt das Programm, die erzeugte ASM-Datei ist jedoch 
fehlerhaft, denn beim Übersetzen treten dann folgende Fehlermeldungen 
auf:

sdcc -mpic14 --use-non-free -p16f887 -Wl-b1 --std-c99 --opt-code-size -DF_CPU=16000000ul -I./ -I../include -c leds_887.c -o leds_887.o
leds_887.asm:452:Error[128]   Missing argument(s).
leds_887.asm:458:Error[128]   Missing argument(s).
leds_887.asm:753:Error[128]   Missing argument(s).
Error[181]   System error while writing object file.

In der ASM-Datei kann ich dann feststellen, dass MNEMONICs

BANKSEL

ohne weiteren Parameter / Argument generiert wurden. Der Fehler tritt 
innerhalb von my_printf auf wenn ich den Zeiger s mit s++ inkrementieren 
will:

Zeile 449 ff.

;  .line  281; "leds_887.c"  s++;
  MOVLW  0x01
  ADDWF  r0x1025,W
  BANKSEL  
  MOVWF  ( + 0)
  CLRF  ( + 1)
  RLF  ( + 1),F
  BANKSEL  r0x1026
  MOVF  r0x1026,W
  BANKSEL  
  ADDWF  ( + 1),F

Zeile 752 ff.

;  .line  326; "leds_887.c"  s++;
  BANKSEL  
  INCF  ( + 0),F
  BTFSC  STATUS,2
  INCF  ( + 1),F

Woran liegt das?
Muß ich Speicherbänke "händisch" angeben und wenn ja, wie mache ich das 
?

Compiliert habe ich das zuerst mit SDCC 3.6.0 (hier traten 4 Fehler 
auf), habe dann den brandneuen 3.7.0 installiert, hier traten dann "nur" 
3 Fehler auf.

(sorry, wenn ich das jetzt schreibe: Ich wußte schon, warum ich mich 
bisher um die PIC's gedrückt hab - auch die Datenblätter lesen sich 
irgendwie nicht so sonderlich gut)

[blubb (Gast)]

Den Bug gibts wohl schon seit 2011 (damal auf PIC14)
https://sourceforge.net/p/sdcc/bugs/1863/

[Klaus (Gast)]

Ralph S. schrieb:
> (sorry, wenn ich das jetzt schreibe: Ich wußte schon, warum ich mich
> bisher um die PIC's gedrückt hab - auch die Datenblätter lesen sich
> irgendwie nicht so sonderlich gut)

Da kann ich dich nicht wirklich verstehen. Du magst die PICs nicht und 
benutzt dann auch noch einen dubiosen Compiler statt der freien IDE von 
Microchip. Tritt die PICs doch einfach in die Tonne und mach was 
anderes.

Ich komme mit den PICs gut klar, fang aber jetzt nicht extra was mit AVR 
oder Arduino an nur um dann darüber rumzunörgeln.

MfG Klaus

[Ralph S. (jjflash)]

Klaus schrieb:
> Ich komme mit den PICs gut klar, fang aber jetzt nicht extra was mit AVR
> oder Arduino an nur um dann darüber rumzunörgeln.

Erstens nörgle ich nicht rum, sondern ich bin gefrustet, das ist ein 
Unterschied !

Zweitens bin ich dennoch unvoreingenommen ob die PICs "gut oder 
schlecht" sind, sie müssen etwas "haben" sonst würde Arizon Microchip 
nicht so viele davon verkaufen.

Drittens liegt das "Problem" das ich habe nicht am PIC sondern an mir 
oder am SDCC.

Sicherlich tritt ein Fehler wie er bei mir auftaucht bei den Tools des 
Herstellers nicht auf.

Klaus schrieb:
> benutzt dann auch noch einen dubiosen Compiler statt der freien IDE von
> Microchip.

... genau das will ich eben nicht, weil ich eine eigene Umgebung 
schreibe, die durchweg viele Bastler-MCUS unterstützen soll damit ich 
die unterschiedlichen MCUs alle gleich oder zumindest sehr ähnlich 
programmieren kann. Hierfür bekommen dann die Funktionen für die 
unterschiedlichen MCUs alle denselben Namen.

Ob der SDCC "dubios" ist weiß ich nicht, er hat bisweilen ein paar 
"Macken", aber in Verbindung mit STM8 und MCS51 funktioniert er gut.

Es gibt von Microchip zwar eine frei "Lite" Compilerversion, da ich aber 
das was ich mache (unentgeltlich) weitergeben möchte sehe ich nicht, ob 
ich das mit dem Microchip Compiler machen darf. Außerdem (und das ist 
für mich auch ein Hinderungsgrund) benötigt der XC8 Compiler für ein 64 
Bit Linux die Compatibility-Libraries und das ist genau das was ich auf 
gar keinen Fall mag (weil das auf meinem System manchmal für Probleme 
gesorgt hat).

[Klaus (Gast)]

Ralph S. schrieb:
> ... genau das will ich eben nicht, weil ich eine eigene Umgebung
> schreibe, die durchweg viele Bastler-MCUS unterstützen soll damit ich
> die unterschiedlichen MCUs alle gleich oder zumindest sehr ähnlich
> programmieren kann. Hierfür bekommen dann die Funktionen für die
> unterschiedlichen MCUs alle denselben Namen.

Das wirst du nicht wirklich leisten können. Es gibt so um die 700 
verschiedene PIC. Zu jedem liefert Microchip Headerfiles, die sowohl für 
C als auch für ASM jedes SFR und darin wiederum jedes Bit mit einem 
Symbol bezeichnen. Das sind dann schon mal 10000 Zeilen für einen 
Prozessor. Das willst du für den SDCC sicher nicht selbst machen. Dazu 
kommen dann noch Spezialfunktionen, mit denem man auf besondere Register 
zugreifen kann, die der XC8 eingebaut hat.

MfG Klaus

[Philipp Klaus K. (pkk)]

Ralph S. schrieb:
> Ob der SDCC "dubios" ist weiß ich nicht, er hat bisweilen ein paar
> "Macken", aber in Verbindung mit STM8 und MCS51 funktioniert er gut.

Die stm8 und mcs51 backends (wie auch ds390, hc08, s08, z80, z180, r2k, 
r3ka, tlcs90 und gbz80) sind allerdings auch ausgereifter. Die pic14 und 
pic16 Backends dagegen sind "Work is in progress" (gleich im zweiten 
Satz auf http://sdcc.sourceforge.net/). Wobei allerdings das 
pic16-Backend in deutlich besserem Zustand ist als das pic14-Backend.

Bei SDCC gibt es halt viel zu tun, und nicht genug Entwickler, um alles 
zu machen. Insbesondere gibt es zur Zeit niemanden, der sich mit PIC 
auskennt, und viel Zeit in SDCC stecken kann. Und bei den gputils (von 
den PIC-backends verwendet) gibt es zur Zeit nur einen Entwickler, der 
kaum Zeit für gutils findet.

Philipp

[blupdidup (Gast)]

  char      ch;
  va_list   ap;
  char *ptr;

  va_start(ap,s);
  do
  {
  ptr=s;
    ch= *ptr;
    if(ch== 0) return; 

...

    if(ch=='%')            // Platzhalterzeichen
    {
//      s++;
  ptr++;
      token= *ptr;

[Axel S. (a-za-z0-9)]

Klaus schrieb:
>
> Da kann ich dich nicht wirklich verstehen. Du magst die PICs nicht und
> benutzt dann auch noch einen dubiosen Compiler statt der freien IDE von
> Microchip.

Es gibt keine freie IDE von Microchip. Was es gibt, ist eine kostenlos 
downloadbare, funktional eingeschränkte IDE. Das ist nicht das 
gleiche. "Free Speech" vs. "Free Beer".

Wobei sich diese Compiler vom MCP noch nicht mal als "Free Beer" 
qualifizieren. Eher "kostenloses Mischgetränk aus Bier und irgendeiner 
Limonade, wobei wir weder die Limonade nnch den Biergehalt näher 
spezifizieren". Wenn man Pech hat, kriegt man einen Becher Sprite lite 
pur.

Ja, ok. Es soll Leute geben, die das lecker finden. <schüttel>

[pic (Gast)]

Ich könnte mal versuchen einen alten (16 jahre) sdcc auf sdcc xxx zu 
portieren.
Damals wurde er für Forth und basic als Backend verwendet und es gab 
einen patch + copt welcher alle Fehler diesbezüglich beseitigte.

[pic (Gast)]

Eigentlich sieht der hier beschriebene Fehler so aus als sollten diese 
Banksel einfach mit copt entfernt werden.

[Volker S. (vloki)]

Axel S. schrieb:
> ist eine kostenlos downloadbare, funktional eingeschränkte IDE.

Quatsch, die IDE ist nicht eingeschränkt.
Die Compiler schon, aber da hat sich viel getan.
Es ist längst nicht mehr so ein Mist wie zu Anfang!

Wer meint, SDCC liefert bessere Resultate als XC8 in der kostenlosen 
Version, der kann ja (zum Testen) das SDCC Plugin für MPLABX 
verwenden...

[Axel S. (a-za-z0-9)]

Volker S. schrieb:
> Axel S. schrieb:
>> ist eine kostenlos downloadbare, funktional eingeschränkte IDE.
>
> Quatsch, die IDE ist nicht eingeschränkt.
> Die Compiler schon

Ach toll. Du hast das Haar, das ich in der in der Suppe gefunden habe, 
gleich mal gespalten!

> Wer meint, SDCC liefert bessere Resultate als XC8 in der kostenlosen
> Version

Nun, wie wir gereade gesehen haben, tut er das nicht. Das macht das 
Angebot von MCP nicht besser. Vielleicht weniger verzichtbar. Oder man 
verzichtet gleich ganz auf die PICs.

[vloki (Gast)]

Axel S. schrieb:
> Oder man verzichtet gleich ganz auf die PICs.

Bist du irgendwann mal barfuß in einen (auf dem Rücken liegenden) rein 
getreten?

[Axel S. (a-za-z0-9)]

vloki schrieb:
> Axel S. schrieb:
>> Oder man verzichtet gleich ganz auf die PICs.
>
> Bist du irgendwann mal barfuß in einen (auf dem Rücken liegenden) rein
> getreten?

Ich habe in anderen Threads hier detailliert dargelegt, welche PICs ich 
aus welchen Gründen schlimm finde. 'nuff said