Software Problem

[Chris (Gast)]

Hallo,

ich Programmiere einen PIC16 in MPLAB8 mit dem HI-TECH Compiler. Bei 
dieser Codezeile bekomme ich immer diesen Fehler:

Error   [712] C:\Projekte\...\main.c; 371. für diesen Ausdruck kann kein 
Kode erzeugt werden

ui_a[i] = (unsigned int)(((unsigned short long)ui_a[i] * ui_b[i]) / ui_c[i]);

ui steht für unsigned int. Die Variable i ist vom Typ unsigned char.

Wenn ich eine Zahl als Index von ui_a[] wähle, funktioniert es 
komischerweise:

ui_a[2] = (unsigned int)(((unsigned short long)ui_a[i] * ui_b[i]) / ui_c[i]);

Und das hier funktioniert auch:

ui_a[i] = 4;

Hat jemand eine Idee für mich?

[hmmm (Gast)]

(unsigned short long)...

decisions...decisions... :)

[Sebastian Hepp (Gast)]

Müssen Indizes von Arrays nicht immer den Typ Integer haben?

[Hans K. (gamp)]

Sebastian Hepp schrieb:
> Müssen Indizes von Arrays nicht immer den Typ Integer haben?

nö, hauptsache ganzzahlig

[B. S. (bestucki)]

hmmm schrieb:
> (unsigned short long)...
>
> decisions...decisions... :)
Das ist ein 24Bit Datentyp ;)

Sebastian Hepp schrieb:
> Müssen Indizes von Arrays nicht immer den Typ Integer haben?
unsigned char ist ein Integer. Normalerweise benutzt man size_t, aber 
wenn man einen uC programmiert und von vornherein weiss, dass der 
grösste Wert kleiner 255 ist, so kann man gut und gerne unsigned char 
verwenden.

[Chris (Gast)]

hmmm schrieb:
> decisions...decisions... :)
?
Den Wert habe ich gewählt, weil das Zwischenergebnis der Multiplikation 
übersteigt den 16 Bit Bereich, darum der kurzzeitige Umstieg auf 24 Bit. 
Sollte ich das anders machen?

[foo (Gast)]

Chris schrieb:
> Den Wert habe ich gewählt, weil das Zwischenergebnis der Multiplikation
> übersteigt den 16 Bit Bereich, darum der kurzzeitige Umstieg auf 24 Bit.
> Sollte ich das anders machen?

Ist jetzt nicht dein Ernst?
Es gibt keinen

short long

 Datentyp

[Yalu X. (yalu) (Moderator)]

foo schrieb:
> Es gibt keinen
> short long
> Datentyp

Das ist eine C-Erweiterung dieses Compilers und steht für einen
24-Bit-Integer-Typ.

be stucki schrieb:
> Das ist ein 24Bit Datentyp ;)

Wieso der Smiley? Hast du geraten? Wenn ja, hast du einen guten Riecher
gehabt :)

[Tom (Gast)]

Chris schrieb:
> Error   [712] C:\Projekte\...\main.c; 371. für diesen Ausdruck kann kein
> Kode erzeugt werden

Ist das alles an Fehlermeldung, was man von teuerer Profi-Software 
bekommt?

1.c: In function ‘main’:
1.c:9: error: both ‘long’ and ‘short’ in declaration specifiers

[Tom (Gast)]

Nachtrag: Die seltsame benannte Erweiterung war mir unbekannt. 
Vorherigen Beitrag also ignorieren.

[foo (Gast)]

Yalu X. schrieb:
>> Es gibt keinen
>> short long
>> Datentyp
>
> Das ist eine C-Erweiterung dieses Compilers und steht für einen
> 24-Bit-Integer-Typ.

Na, wer unbedingt nicht portablen Code schreiben will, bitte.
Ich bleib beim Standard (ANSI C90), und da gibt es kein short long.

[Justin (Gast)]

ui_a[i] = (unsigned int)(((unsigned short long)ui_a[i] * ui_b[i]) / ui_c[i]);

Wenn "short long" (24 Bit) nicht der Fehler ist, dann ist der Ausdruck 
für den Compiler zu komplex, um diesen in Code umzusetzen?

[Tom (Gast)]

When compiling for baseline devices, some complex expressions may
cause compile-time errors (712) Can’t generate code for this expression. The expres-
sions should be simplified to work around this. This may require the use of additional variables to store
intermediate results. This is most likely with long integer or floating-point arithmetic.

[Yalu X. (yalu) (Moderator)]

Tom schrieb:
> When compiling ...

Mist, wollte ich auch gerade schreiben ;-)

Eigentlich hätte ich ja erwartet, dass ein Compiler – wo erforderlich –
komplizierte Ausdrücke selbstständig in kleinere Häppchen zerlegt.

[Mark B. (markbrandis)]

Johannes S. schrieb:
> Sebastian Hepp schrieb:
>> Müssen Indizes von Arrays nicht immer den Typ Integer haben?
>
> nö, hauptsache ganzzahlig

Was genau ist denn der Unterschied zwischen Integer und Ganzzahl? :)

[foo (Gast)]

Also den Compiler mit der Plattform hätt ich schon über'd Häuser 
gschmissen...
Zu komplex... lieb.

[Detlef _. (detlef_a)]

>> ich Programmiere einen PIC16 in MPLAB8 mit dem HI-TECH Compiler.

Der Compiler ist Schrott, der hat mich auch schon mal den letzten Nerv 
gekostet:
Beitrag "PIC Port I/O mit HiTech C"

Jetzt nehme ich dieses Ding
http://www.mikroe.com/mikroc/pic/

läuft sauber, ohne Allüren und stabil, bin damit sehr zufrieden.

Cheers
Detlef

[Chris (Gast)]

Danke Euch! Dann werde ich den Ausdruck einfach mal vereinfachen und auf 
lange Sicht einen neuen Compiler nehmen...

[Rufus Τ. F. (rufus)]

Versuch mal, das ganze mit 32 Bit rechnen zu lassen, also nur mit long 
anstelle von short long. Vielleicht überfordert der dann resultierende 
Ausdruck den Compiler ob seiner Komplexität etwas weniger.

Ansonsten scheint das eine Art Bascom unter den C-Compilern zu sein, 
wenn bereits ein so simpler Ausdruck solch eine Fehlermeldung zur Folge 
hat ...

[Takao K. (takao_k)]

Hitech C ist doch veraltet?

[JumenReizWotsch (Gast)]

Rufus mäkelte:
>Ansonsten scheint das eine Art Bascom unter den C-Compilern zu sein,
>wenn bereits ein so simpler Ausdruck solch eine Fehlermeldung zur Folge
>hat ...

Du kannst wohl nicht mit Bascom umgehen, sonst würdest Du mit Deinem Tun
dort nicht solche Fehlermeldungen erzeugen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

JumenReizWotsch schrieb:
> Du kannst wohl nicht mit Bascom umgehen, sonst würdest Du mit Deinem Tun
> dort nicht solche Fehlermeldungen erzeugen?
Du hast wohl den Thread nicht gelesen.
Oder kann Bascom jetzt endlich mehr als 2 Operanden pro Rechenschritt?
Leider findet man so auf die Schnelle nichts zum Thema...