Forum: Mikrocontroller und Digitale Elektronik XC8: error: (1098) conflicting declarations for variable "_INTCONbits"


von Ingo F. (ingof)


Lesenswert?

Versuche gerade einen Quelltext von C18 auf XC8 zu migrieren.
Habe es endlich geschafft dass MPLab-X mit ein paar warnungen 
kompiliert.

Allerdings kommt beim linken eine Fehlermeldung:
error: (1098) conflicting declarations for variable "_INTCONbits"
1
Microchip MPLAB XC8 C Compiler (Free Mode) V1.45
2
Build date: Nov 15 2017
3
Part Support Version: 1.45
4
Copyright (C) 2017 Microchip Technology Inc.
5
License type: Node Configuration
6
7
:: warning: (1273) Omniscient Code Generation not available in Free mode
8
C:\Program Files (x86)\Microchip\xc8\v1.45\include\pic18f4685.h:35017: error: (1098) conflicting declarations for variable "_INTCONbits" (C:\Program Files (x86)\Microchip\xc8\v1.45\include\pic18f4685.h:32235)
9
(908) exit status = 1
10
nbproject/Makefile-Brd_V2__18F4685_XC8.mk:707: recipe for target 'dist/Brd_V2__18F4685_XC8/production/EMS-Gateway.X.production.hex' failed
11
make[2]: Leaving directory 'D:/GITlab/EMS-Gateway/EMS-Gateway.X'
12
nbproject/Makefile-Brd_V2__18F4685_XC8.mk:90: recipe for target '.build-conf' failed
13
make[1]: Leaving directory 'D:/GITlab/EMS-Gateway/EMS-Gateway.X'
14
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
15
make[2]: *** [dist/Brd_V2__18F4685_XC8/production/EMS-Gateway.X.production.hex] Error 1
16
make[1]: *** [.build-conf] Error 2
17
make: *** [.build-impl] Error 2
18
19
BUILD FAILED (exit value 2, total time: 13s)

Ich habe absolut keine Ahnung mehr wo ich noch suchen soll.
Wenn ich das richtig verstehe wird INTCONbits in Zeile 32235 und 35017 
unterschiedlich deklariert.

Scheint aber nicht so zu sein.
Auch habe ich bei mir nirgendwo INTCONbits oder _INTCONbits definiert.

Hat jemand ein Tipp was diese Fehlermeldung soll und wie ich die 
Fehlerstelle finden kann???

Bin etwas ratlos....

von Volker S. (vloki)


Lesenswert?

Du hast die PLIB installiert?

Leider wurden in den XC8 PIC-Header nach v1.34 einige Änderungen 
vorgenommen und jetzt gibt es bei vielen Kompatibilitätsprobleme 
zwischen neuem Header und der Info in der "alten" Lib. Die Bibliotheken 
für betroffene PICs müssen neu erstellt werden.
http://www.microchip.com/forums/FindPost/897197

: Bearbeitet durch User
von Ingo F. (ingof)


Lesenswert?

Ja, habe ich installiert.

Also sollte es mit XC8 1.34 funktionieren??

Werde den mal zusätzlich installieren und dann in den 
Projekteigenschaften den 1.34 selektieren...

von Volker S. (vloki)


Lesenswert?

Ja, mit der v1.34 müsste es gehen. Möglicherweise auch mit der neuesten 
Version, wenn man den Header mit dem aus v1.34 überschreibt. Soll man 
laut mad_c aber nicht machen ;-)

von Ingo F. (ingof)


Lesenswert?

Ok, scheint zu klappen.

Vorher hat der C18 alles mit massenhaft Reserve im RAM kompiliert
Jetzt bekomme ich beim XC8 folgendes:
../c018iz_ex.c:119: error: (1250) could not find space (2 bytes) for 
variable __cinit

von Volker S. (vloki)


Lesenswert?

Diese Initialisierungs- Dateien gibt es beim XC8 nicht.
Beim C18 wurden die dem Projekt ja normalerweise über das Linkerscript 
zugefügt.  Was "spezielles" steht da drin?

z für Initialisierung mit Zero?
ex irgendwas mit extended?

: Bearbeitet durch User
von Ingo F. (ingof)


Lesenswert?

Volker S. schrieb:

> z für Initialisierung mit Zero?
> ex irgendwas mit extended?

Ja, genau das... der Extended-Mode geht ja nicht mehr mit XC8

Habe jetzt die Datei und das Linkerscript heraus genommen. Jetzt läuft 
der Compiler durch.

Jetzt ärgert mich aber immer noch die bedingte Compilierung des 
AN1310-Bootloaders.

Habe noch keinen Ersatz für
1
upper(), high() und low()
Auch dieser Vergleich will nicht so ganz:
1
#if (ERASE_FLASH_BLOCKSIZE > .255)

Bekomme immer
1
error: (119) invalid expression in #if line

von vloki (Gast)


Lesenswert?

Ingo F. schrieb:
> Jetzt ärgert mich aber immer noch die bedingte Compilierung des
> AN1310-Bootloaders.

Ist der nicht in Assembler geschrieben?
Wie hängt der jetzt genau mit deinem XC8 Projekt zusammen?

von Ingof (Gast)


Lesenswert?

vloki schrieb:
> Ingo F. schrieb:
>> Jetzt ärgert mich aber immer noch die bedingte Compilierung des
>> AN1310-Bootloaders.
>
> Ist der nicht in Assembler geschrieben?
> Wie hängt der jetzt genau mit deinem XC8 Projekt zusammen?
Der Assembler-Bootloader war beim c18 so eingebunden dass er sofort mit 
kompiliert wurde. Aber die bedingte Kompilierung des MPASM will mit dem 
XC8 nicht.

Der Bootloader lag im Adressbereich bis 0x3ff
Bei 0x0430 begann das eigentliche Programm und die Interuptvectoren sind 
nach 0x0408 und 0x0418 umgezogen.

Also muss ich zumindest irgendwie eine Sprungadresse an diese Adressen 
bekommen. Im Moment hat der XC8 alles soweit nach hinten geschoben wie 
möglich?!

muss jetzt also nur das schaffen was das alte Linkerscript geschafft 
hat....

von Volker S. (vloki)


Lesenswert?

Haben wir schon mal gemacht. Ich schau morgen nach, wie das genau 
ging...

von Volker S. (vloki)


Lesenswert?

Ingof schrieb:
> Der Bootloader lag im Adressbereich bis 0x3ff

Muss das so bleiben? (ist eigentlich nicht soooo sinnvoll)

Den AN1310 Bootloader kann man ja so konfigurieren, dass er am Ende des 
Programmspeichers liegt.

Dann muss man für die Anwendung gar nichts tun, außer den benötigten 
Platz am Ende blckieren.

Die Interruptvektoren muss man dann gar nicht umleiten und der 
Resetvektor wird von der PC-Software für den Bootloader automatisch 
umgebogen, falls da ein goto steht. (was bei den Microchip Compilern der 
Fall ist)

Wenn der Bootloader am Anfang des Programmspeichers bleiben soll, dann 
steht soweit ich mich erinnere in der Application Note was zu tun ist.
<edit> XC8 ist praktisch nur der neue Name für HI-TECH C </edit>

Ein bisschen was hat auch Nico auf PIC-Projekte zusammen getragen:
https://pic-projekte.de/blog/bootloader-fur-pic16-und-pic18/

: Bearbeitet durch User
von Thomas E. (picalic)


Lesenswert?

Servus,

ich kenne es so, daß der Bootloader, wenn er bei Addresse 0 anfängt, die 
Reset- und Interrupts an die Startadresse der Applikation durchreicht. 
Also z.B. bei PIC16xxxx:
Wenn der Bootloader in 0..0x0FF liegt und der App-Bereich ab 0x100 
startet:
Resetvektor orig. 0x000 -> durch BL auf 0x100
Interruptvektor 0x004 -> durch Bootloader auf 0x104

Für den XC8 Linker stellt man dafür dann bei "Code Offset" 0x100 ein.

Zumindest bei meinem eigenen Bootloader für PIC12/PIC16 
(http://www.picalic.de/bootloader/) funktioniert das so problemlos.

: Bearbeitet durch User
von Volker S. (vloki)


Lesenswert?

Thomas E. schrieb:
> Für den XC8 Linker stellt man dafür dann bei "Code Offset" 0x100 ein.

Scheint beim AN1310 auch so zu sein. (0x400)

von Ingof (Gast)


Lesenswert?

DANKE für die ganzen Antworten.

Volker S. schrieb:
> Muss das so bleiben? (ist eigentlich nicht soooo sinnvoll)

Ja, leider schon. Es werden schon mehrere Geräte benutzt.
Das brennen der neueren Firmware wäre dann für die vroahandenen Nutzer 
nicht mehr möglich.

Volker S. schrieb:
> Scheint beim AN1310 auch so zu sein. (0x400)

Habe das gestern auch gefunden.
Allerdings wäre mir lieber dass der Wert nicht gesetzt ist.
Meine gelesen zu haben dass es dann nicht möglich den Bereich davor zu 
beschreiben.

Also wäre dann der Bootloader nicht mit im Hex-File, oder?

Wenn der Bootloader mit im Hex-File ist kann ich das file zum brennen 
der neuen Hardware benutzen und auch über den Bootloader benutzen.


Aber dazu müsste ich es schaffen dass der Bootloader im Bereich bis 
0x3ff geschrieben wird und der komplette Rest woanders?

Wie kann ich denn an eine bestimmte Stelle im Programmspeicher eine 
Funktion brennen?
Mit Variablen geht das ja über
1
@ 0x0418
.

Mehr habe ich noch nciht gefunden

von Volker S. (vloki)


Lesenswert?

Wenn ich mich richtig erinnere, dann gibt es da keinen Unterschied 
zwischen Variablen und Funktionen. @ sollte auch bei Funktionen gehen.

<edit> 5.8.4 Changing the Default Function Allocation </edit>

<edit2> Vieleicht hilft dir auch das weiter:
https://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en558478.pdf 
</edit2>

: Bearbeitet durch User
von Volker S. (vloki)


Lesenswert?

Volker S. schrieb:
> Vieleicht hilft dir auch das weiter:

Oder besser doch das Webinar, weil im pdf die Abbildungen nicht alle 
drin sind...
https://www.microchip.com/webinars.microchip.com/WebinarDetails.aspx?dDocName=en558478

von Thomas E. (picalic)


Lesenswert?

Ingof schrieb:
> Wenn der Bootloader mit im Hex-File ist kann ich das file zum brennen
> der neuen Hardware benutzen und auch über den Bootloader benutzen.

Ich würde dann erwarten, daß der Bootloader bzw. das PC-Tool sich 
beschwert, weil das HEX-File ja Code enthält, der den Bootloader-Bereich 
überschreiben würde. Eigentlich ist der Bootloader und die Applikation 
doch jeweils ein eigenständiges Programm. Wenn man unbedingt ein 
Hex-File für die Produktion braucht, mit dem man beides "in einem 
Rutsch" auf den Chip brennen kann, kann man dieses ja durch 
Zusammenführen der beiden Hex-Files erzeugen. Das geht notfalls und ohne 
großen Aufwand auch mit einem simplen Texteditor (Notepad?), der 
"Copy+Paste" beherrscht...

von Volker S. (vloki)


Lesenswert?

Thomas E. schrieb:
> Ich würde dann erwarten, daß der Bootloader bzw. das PC-Tool sich
> beschwert, weil das HEX-File ja Code enthält,

Man hat dann vermutlich zwei Versionen. Eine mit Bootloader für die 
Erstprogrammierung und eine ohne für Updates.
Sollte in MPLABX über zwei "Configurations" sehr einfach realisierbar 
sein.
In Einer ist my_bootloader.hex, wie im Webinar ab ~21:20 gezeigt, unter 
den "Loadables" drin in der Anderen nicht.

von Volker S. (vloki)


Lesenswert?

Weil bei mir gerade so ein Teil auf dem Tisch liegt und es mich 
interessiert hat, habe ich das mal ausprobiert.

Dass der AN1310 Bootloader sich nicht selber überschreibt war mir schon 
vorher klar, weil ich das vor einiger Zeit im Code nachgeschaut habe.

Das PC-Tool meckert aber auch nicht rum, wenn im HEX-File auch noch der 
Bootloader drin ist. Nicht mal eine Meldung scheint es wert. Es scheint 
also also eine Konfiguration für Bootloader zu reichen.

Normalerweise arbeiten unsere Studierenden nicht mit Bootloader, sondern 
mit einem PICkit3, aber eine zusätzliche Bootloader-Konfiguration werde 
ich jetzt wohl in unser Demo-Projekt aufnehmen ;-)

von Ingof (Gast)


Lesenswert?

Danke für den Link zum Webinar....

Also im Moment habe ich ein MPLAB-X Projekt in C18.

Je nach Platinenversion und Auswahl der Features wird der richtige 
Bootloader und Anwendungsfirmware kompiliert. Und packt alles in ein 
File.
Entweder mit Pickit3 brennen oder über das Bootloaderprogramm brennen.

Stimmt der Bootloader meckert nihct wenn der Bootloader mit im File ist. 
Den Bootloader ist bei mir entsprechend so konfiguriert dass der 
Bootloader selber sich selbst nicht überschreibt. Also stört mich das 
nicht großartig.

Werde mal sehen wie ich am besten auch mit dem XC8 hinbekommen.

Notfalls würde ich dann den Bootloader unter Loadable packen und/oder 
automatisch in das Hexfile reinbasteln lassen. Ich meine das geht auch 
automatisiert mit Hexmate aus dem MPLAB-X.

Kann aber eine Weile dauern bis ich das testen kann...

von Volker S. (vloki)


Lesenswert?

Ingof schrieb:
> Notfalls würde ich dann den Bootloader unter Loadable packen

Ich habe das so vorher auch noch nicht gemacht und nicht mal gewusst, 
dass das so geht. Einfach ausprobiert, ohne irgendwelche weiteren 
Einstellungen und es funktioniert ;-)
Allerdings ist bei uns der Bootloader am Ende des Speichers. Wenn er am 
Anfang ist, dann muss man bestimmt, wie Thomas E. auch erwähnt hat, den 
Code-Offset eintragen.

von Ingof (Gast)


Lesenswert?

Ich bekomme es nicht hin dass ich den Bootloader unter XC8 kompilieren 
kann.
Die Bedingte Kompilierung klappt nicht und habe keine Ahnung ob das zu 
beheben ist.

Selbst wenn ich dann die Bedingte Kompilierung entferne kommen 
massenhaft Fehler. (Dass alles rot markiert wird soll man laut MPLab-X 
Anleitung ignorieren)

Wenn ich es richtig verstehe gibt es keinen richtigen Assembler-Compiler 
beim XC8 wie der MPASM beim C18.

Also müsste ich aus dem einen C18-Projekt zwei Projekte machen.
Ein XC8-Projekt für die Anwendung und ein C18-Projekt mit dem MPASM für 
den Bootloader.

Dann könnte ich das Bootloader-Projekt in "Loadable" packen und der 
Bootloader wird automatisch ein ein HEX-File gepackt.

Das bedeutet also dass ich vom C18-Compiler nicht weg komme.

von Volker S. (vloki)


Lesenswert?

Der Assembler hat mit den C-Compilern eigentlich gar nichts zu tun.
Der wird schon mit der IDE mitgeliefert.
Im Bootloader-Projekt keinen C Compiler auswählen, sondern z.B.:
mpasm -> mpasm(v5.77)....

<edit> Du brauchst auch nicht unbedingt ein Bootloader Projekt, wenn die 
.hex für den Bootloader schon vorhanden ist. Einfach die in "Loadables" 
platzieren.

: Bearbeitet durch User
von Thomas E. (picalic)


Lesenswert?

Volker S. schrieb:
> Ich habe das so vorher auch noch nicht gemacht und nicht mal gewusst,
> dass das so geht.

Hihi - ging mir genauso! Und endlich weiß ich auch, zu was "Loadables" 
gut sind - man lernt halt nie aus!

von Ingof (Gast)


Lesenswert?

Volker S. schrieb:
> Im Bootloader-Projekt keinen C Compiler auswählen, sondern z.B.:
> mpasm -> mpasm(v5.77)

Das ist mir schon klar.

Den MPASM gibt es nirgendwo zum Download. Wird der nicht nur bei der 
Installation vom C18 mit installiert?

Beim C18 habe ich ja auch in den Projekteinstellungen außer Compiler und 
Linker auch MPASM. Beim XC8 aber nicht.

Bin etwas verwirrt....

von Volker S. (vloki)


Angehängte Dateien:

Lesenswert?

Ingof schrieb:
> Bin etwas verwirrt....

Ich auch ;-) Wie gesagt, MPASM ist bei MPLABX dabei.
Wurde bei mir auch immer zur Auswahl angezeigt.

Wenn nicht, kann man ihn vermutlich manuell hinzufügen.

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.