Forum: Compiler & IDEs CCS8 -- unsigned int zählt nicht über >32767


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Wolle G. (wolleg)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
a) mit CCS8 lassen sich beim mir, im Gegensatzt zu IAR, keine Zahlen
 > 32767 darstellen bzw.  beim Hochzählen entstehen  bei > 32767 
negative Werte.
was könnte hier schief laufen?
lt. slau 132r.pdf Seite 90 sollte dies aber möglich sein.

b) wenn ich bei
 sprintf(zaa,"%d",zahla);
an Stelle von d (vorzeichenbehaftete Dezimalzahl)
u (vorzeichenlose Dezimalzahl) verwende, kommt die Fehlermeldung:
 in minimal Modus nicht verwendbar
wie könnte man auf Voll-Modus umstellen?
kleine Anmerkung: Ich bin Programmierlaie

: Bearbeitet durch User
Beitrag #5598566 wurde vom Autor gelöscht.
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
wolle g. schrieb:
> was könnte hier schief laufen?

Das bereits genannte %d gibt nichts oberhalb von 32767 aus. Nicht die 
Zahl ist das Problem, sondern das Verfahren zur Anzeige.

: Bearbeitet durch User
von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> wolle g. schrieb:
>> was könnte hier schief laufen?
>
> Das bereits genannte %d gibt nichts oberhalb von 32767 aus. Nicht die
> Zahl ist das Problem, sondern das Verfahren zur Anzeige.

Aber warum funktioniert's mit IAR? bzw. wie könnte man das Problem 
lösen?

von Nop (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
wolle g. schrieb:
> bzw. wie könnte man das Problem lösen?

%u

von ÄXl (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> wolle g. schrieb:
>> bzw. wie könnte man das Problem lösen?
>
> %u

wolle g. schrieb:
> u (vorzeichenlose Dezimalzahl) verwende, kommt die Fehlermeldung:
>  in minimal Modus nicht verwendbar

steht schon da. Muss wohl nen abgespeckte Version deines "CCS8" (ich 
google das mal) sein?

von ÄXl (Gast)


Bewertung
1 lesenswert
nicht lesenswert
http://processors.wiki.ti.com/index.php/Printf_support_for_MSP430_CCSTUDIO_compiler
umstellen auf "normal" sollte gehen Auf der Seite steht beschrieben, wie 
es geht. Auch wenn es sich hier um eine anderers Problem handelt. (also 
fast).
Google ist aber installiert, oder fragst Du jedesmal Alexa? (ist doch 
wahr)
Ich wusste bis eben nicht, was ein CCS8 überhaupt ist ...

von Wolle G. (wolleg)


Bewertung
-1 lesenswert
nicht lesenswert
ÄXl schrieb:
> Google ist aber installiert, oder fragst Du jedesmal Alexa? (ist doch
> wahr)

Da es hier um µC geht, ist für mich zumeist das Mikrocontrollerforum die 
erste Anlaufstelle.
Für eine google Anfrage würde mir wahrscheinlich auch nicht das richtige 
Stichwort einfallen, zumal meine Englischkenntnisse recht dürftig sind. 
(1 Schuljahr vor 60 Jahren)
Die im Beitrag genannte Seite habe ich mir angesehen und in meinem 
CCS-Programm die dort genannte Änderung vorgenommen.
Vielen Dank für den Hinweis.
CCS meckert mit %u zwar nicht mehr, aber es werden allerdings keine 
Zahlen auf der Flüssigkristallanzeige dargestellt.
Dies betrifft sowohl sprintf als auch printf.
Gibt es dazu noch Hilfevorschläge?

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Man kann die Ausgaben auch zu Fuß machen, dann spielen 
Compilereinschränkungen keine Rolle:
Beitrag "Formatierte Zahlenausgabe in C"

von Bernd N. (_bn_)


Bewertung
-2 lesenswert
nicht lesenswert
>> CCS meckert mit %u zwar nicht mehr, aber es werden allerdings keine
>> Zahlen auf der Flüssigkristallanzeige dargestellt.

Bis du sicher das die Anzeige Ziffern erwartet ? oder doch eher ASCII 
Zeichen ?

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
Bernd N. schrieb:
> Bis du sicher das die Anzeige Ziffern erwartet ? oder doch eher ASCII
> Zeichen ?

Die Frage versteh ich nicht so richtig.
Ich erwarte nur, dass dann, wenn ich z.B. eine Zahl von 0 bis 65536 
eingebe, diese auch angezeigt wird.
Mit IAR funktioniert es ja mit unsigned int und %d bzw. %u . Hier habe 
ich eine Schaltung, wo ein MSP430F1611 verwendet wird.

: Bearbeitet durch User
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Kann es sein das die Wertebereiche des Datentyps auf deinen beiden 
Systemen unterschiedlich sind und deshalb das eine funktioniert und das 
andere nicht? Einfach mal den nächstgrößeren Datentyp probieren?

Beitrag #5601553 wurde von einem Moderator gelöscht.
von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
Kann es sein, dass ich ein Exot bin, welcher CCS einsetzt?
Vielleicht verwendet doch jemand CCS und weiss, was hier falsch läuft.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> Kann es sein das die Wertebereiche des Datentyps auf deinen beiden
> Systemen unterschiedlich sind und deshalb das eine funktioniert und das
> andere nicht?

unsigned int muss immer bis (mindestens) 2^16-1 gehen.

Versuche mal:
1
#include <inttypes.h>
2
#include <stdint.h>
3
4
uint16_t zahla;
5
snprintf(zaa, sizeof(zaa), "%" PRIu16, zahla);

Sollte eigentlich auch so wie von dir gemacht gehen, aber wer weiß was 
TI da verbockt hat. Wenn das auch nicht geht, gehe mal im Debugger 
Step-By-Step durch die Funktion und schaue wo es schief läuft.
1
sprintf(vers,"%s","0050-CCS-TS5435");
geht besser so:
1
strncpy(vers, "0050-CCS-TS5435", sizeof (vers));
Oder gleich viel einfacher:
1
const char vers [] = "0050-CCS-TS5435";
Und
1
for (z=0; z<26;z++)
2
   {
3
   c=vers[z];
4
   lcd_write_command(LCD_CMD_WRITE_DATA, c);
5
   }
Geht einfacher so:
1
for (size_t i = 0; i < sizeof(vers)-1; ++i)
2
  lcd_write_command(LCD_CMD_WRITE_DATA, vers [i]);
Generell sollte man Variablen nicht (mehr) am Anfang der Funktion 
definieren, sondern erst dann wenn man tatsächlich einen Wert für sie 
hat, und sie direkt damit initialisieren. So kann man nie versehentlich 
eine Variable nutzen, wenn sie noch keinen Wert hat.
Für Array-Größen/Indices sollte man i.A. size_t verwenden wenn man nicht 
explizit einen Grund hat es anders zu tun; size_t ist immer genau groß 
genug dafür.
Man kann sich auch angewöhnen das Pre-Inkrement (++i) statt 
Post-Inkrement (i++) zu verwenden, denn ersteres ist die einfachere 
Operation welche man meistens nur haben will (Zahl inkrementieren, Wert 
zurückgeben), während zweiteres eine (meist) unnötig komplexe Operation 
bedeutet (temporäre Kopie anlegen, Original inkrementieren, Kopie 
zurückgeben). In C macht das keinen Unterschied, weil die Compiler das 
wegoptimieren können. Wenn man aber auf C++ wechselt und nicht mehr nur 
mit Zahlen sondern z.B. mit Iteratoren arbeitet, kann es dann doch einen 
Unterschied machen. Für die Lesbarkeit ist es auch besser, nur das 
hinzuschreiben, was für das Programm tatsächlich erforderlich ist.

: Bearbeitet durch User
von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Niklas G. schrieb:
> geht besser so:
> strncpy(vers, "0050-CCS-TS5435", sizeof (vers));

Vorsicht beim Gebrauch von strncpy.

Die Funktion hat eine richtig böse Nettigkeit, sie lässt nämlich die das 
Stringende bildende '\0' in bestimmten Situationen weg, nämlich dann, 
wenn die Länge des zu kopierenden Strings (das zweite Argument) nicht 
kleiner ist als die als drittes Argument angegebene Anzahl von Zeichen.

Beispiel:
1
char array[10];
2
3
strncpy(array, "01234567890123456789", 10);

In diesem Falle enthält array[9] nicht die erwartete '\0', sondern das 
Zeichen '9'. Da array[] aber nur 10 Elemente hat, kann es nicht mehr 
zuverlässig mit herkömmlichen Stringfunktionen verwendet werden; wo im 
Speicher hinter dem letzten Arrayelement die nötige terminierende '\0' 
steht, ist eine Frage des Zufalls.

Wenn man in diesem Falle denkt, man könnte dem Verhalten so ein 
Schnippchen schlagen:
1
strncpy(array, "01234567890123456789", 9);

dann fällt man damit je nach Situation auch unangenehm auf die Fresse, 
denn array[9] wird in diesem Falle nie beschrieben und enthält also mehr 
oder weniger zufällige Daten - es sei denn, es wird vorher explizit mit 
'\0' initialisiert.

Besser ist /strlcpy/:
1
char array[10];
2
3
strlcpy(array, "01234567890123456789", 10);

Hier wird array[9] erwartungsgemäß mit '\0' beschrieben, so, wie es die 
meisten beim oberflächlichen Lesen der Dokumentation von strncpy 
erwarten.

Das gleiche gilt übrigens auch für die Paarung strncat & strlcat.

Ärgerlicherweise sind die strl..-Funktionen nicht in jeder Variante der 
C-Standardbibliothek enthalten.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Vorsicht beim Gebrauch von strncpy.
> Die Funktion hat eine richtig böse Nettigkeit, sie lässt nämlich die das
> Stringende bildende '\0' in bestimmten Situationen weg, nämlich dann,
> wenn die Länge des zu kopierenden Strings (das zweite Argument) nicht
> kleiner ist als die als drittes Argument angegebene Anzahl von Zeichen.

Es gibt noch eine weitere strncpy-Nettigkeit, die zwar nicht als "böse" 
bezeichnet werden kann, aber durchaus "suboptimal" ist.

Ist die Länge des zu kopierenden Strings (2. Argument) kleiner als die 
angegebene Länge (3. Argument), füllt strncpy() mit mehrfachen '\0' 
den Target-String auf, obwohl in den meisten Anwendungsfällen ein 
terminierendes '\0' reichen würde.

Während die strncpy()-Funktion in Deinem skizzierten Fall zuwenig macht, 
macht er im zweiten Fall meist zuviel. Selten braucht man mehrfache 
String-Terminatoren.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
Nachdem ich  die hier gegebenen Vorschläge ausprobiert (ich muss das mal 
so sagen) habe, bin leider noch nicht weiter gekommen.
Textdarstellung hatte von Anfang an funktioniert.
Deshalb noch einmal die Frage, ob schon jemand mit
CCS (Code Composer Studio von TI) unsigned int Zahlen richtig
(0 bis 65536) darstellen kann.

von ..,- (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Rufus Τ. F. (rufus) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wenn man sich diese Dokumentation ansieht und das mit dem Fehlerbild 
vergleicht, riecht das streng nach der Variante "minimal", die eben "%u" 
nicht kennt.

von Niklas G. (erlkoenig) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
..,- schrieb:
> Schon mal das hier versucht?
>
> 
http://processors.wiki.ti.com/index.php/Printf_support_for_MSP430_CCSTUDIO_compiler

Du bist 1 Woche zu spät:

ÄXl schrieb:
> 
http://processors.wiki.ti.com/index.php/Printf_support_for_MSP430_CCSTUDIO_compiler
> umstellen auf "normal" sollte gehen Auf der Seite steht beschrieben, wie
> es geht. Auch wenn es sich hier um eine anderers Problem handelt. (also

Und es scheint nicht geholfen zu haben:

wolle g. schrieb:
> CCS meckert mit %u zwar nicht mehr, aber es werden allerdings keine
> Zahlen auf der Flüssigkristallanzeige dargestellt

von ..,- (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ok,
wenn die ursprüngliche Programmversion mit %d, die ja noch was 
dargestellt hatte, aber mit "minimal" gebaut wurde, nach der Umstellung 
nach "full" bzw. "nofloat" ohne Codeänderung nicht mehr funktioniert, 
dann würde ich mal nachschauen, ob das neue Binary überhaupt noch in den 
Flash passt. Am Code selbst kann es ja dann nicht liegen.

Und falls es nach der Umstellung noch läuft, aber nach der Codeänderung 
auf %u nicht mehr, dann würde ich ebenfalls nochmal die Größen 
überprüfen.

Ob das CCS beim Compilieren oder beim Flashen hier einen Fehler anzeigt, 
wenn das Binary nicht in den Flash passt, weiß ich nicht, da ich CCS 
nicht benutze.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
..,- schrieb:
> Ob das CCS beim Compilieren oder beim Flashen hier einen Fehler anzeigt,
> wenn das Binary nicht in den Flash passt, weiß ich nicht, da ich CCS
> nicht benutze.
Ich versuche mal zu "übersetzen".
Meinst Du, dass die  erzeugte Programmdatei nicht in den 
Programmspeicher passen würde?
Wenn ich CCS richtig deute, dann wurde der Programmspeicher nur zu ca. 
1% gefüllt.

Noch einmal die Frage:
Wer hat mit CCS erfolgreich gearbeitet?

von Niklas Gürtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wolle g. schrieb:
> Wer hat mit CCS erfolgreich gearbeitet?

Ich, aber nicht mit MSP430 ;-)

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> In diesem Falle enthält array[9] nicht die erwartete '\0', sondern das
> Zeichen '9'. Da array[] aber nur 10 Elemente hat, kann es nicht mehr
> zuverlässig mit herkömmlichen Stringfunktionen verwendet werden; wo im
> Speicher hinter dem letzten Arrayelement die nötige terminierende '\0'
> steht, ist eine Frage des Zufalls.

Naja, man kann danach eben nur noch die Stringfuktionen nutzen, die auch 
dieses n im Namen haben und damit ebenfalls ein Längenlimit bekommen.

> Ärgerlicherweise sind die strl..-Funktionen nicht in jeder Variante der
> C-Standardbibliothek enthalten.

Es ist keine Standard-Funktion. Streng genommen dürfte sie gar nicht 
vorhanden sein - zumindest nicht im Header string.h. Daher kann es je 
nach Compiler auch sein, dass man die Funktionen erst nutzen kann, wenn 
man den Standard-Modus verlässt.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
Niklas Gürtler schrieb:
> wolle g. schrieb:
>> Wer hat mit CCS erfolgreich gearbeitet?
>
> Ich, aber nicht mit MSP430 ;-)

Meinst Du, mein Problem wäre MSP430-spezifisch?
Mit welcher CCS-Version funktioniert es bei Dir?
Da ich mit CCS8.0.0.00016_win32 noch keinen Erfolg hatte, habe ich mir 
die neueste  Version CCS8.2.0.00007_win32 herunter geladen.
Hier ist es noch schlimmer. Schon beim Installieren wird gemeckert, dass 
eine Datei fehlen würde und die Installation bleibt hängen.
Vielleicht kommt demnächst etwas Neues.

von Niklas Gürtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
wolle g. schrieb:
> Meinst Du, mein Problem wäre MSP430-spezifisch

Ja.

wolle g. schrieb:
> Mit welcher CCS-Version funktioniert es bei Dir?
Version 8. Welche genau weiß ich grad nicht.

Ich benutze das CCS für den Cortex-A mit dem GCC Compiler. Das ist was 
ganz anderes als beim MSP430, da ist praktisch nur die grafische 
Benutzeroberfläche gleich...

von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
wolle g. schrieb:
> ..,- schrieb:
>> Ob das CCS beim Compilieren oder beim Flashen hier einen Fehler anzeigt,
>> wenn das Binary nicht in den Flash passt, weiß ich nicht, da ich CCS
>> nicht benutze.
> Ich versuche mal zu "übersetzen".
> Meinst Du, dass die  erzeugte Programmdatei nicht in den
> Programmspeicher passen würde?
> Wenn ich CCS richtig deute, dann wurde der Programmspeicher nur zu ca.
> 1% gefüllt.
>
> Noch einmal die Frage:
> Wer hat mit CCS erfolgreich gearbeitet?

Ich fing vor ein paar Wochen mit der aktuellen runtergeladenen Version 
von CCS und dem MSP430FR5994 Launchpad an.

Installation unter W7X64 funktionierte ohne besondere Probleme wenn auch 
bald zeitweise komische Probleme mit dem Debugger auftraten die auch bei 
den Beispielen auftraten, welche nach eventueller nochmaliger CCS 
Installation verschwanden. Unter W10X64 und W10X32 auf anderen PCs 
funktionierte alles immer tadellos. Seitdem habe ich nun keine Probleme 
mehr mit CCS.

von Wolle G. (wolleg)


Bewertung
0 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Unter W10X64 und W10X32 auf anderen PCs
> funktionierte alles immer tadellos. Seitdem habe ich nun keine Probleme
> mehr mit CCS.

Das lässt hoffen. Nur die Frage, warum geht es bei mir nicht?
Ich verwende einen Laptop mit Windows 10.
Aber noch einmal die Ausgangsfrage: die Darstellung von
unsigned int Zahlen im Bereich 0 bis 65536 funktioniert bei Dir 
fehlerfrei?
Muss man für 'sprintf' zusätzlich weitere *.h Dateien einbinden?

: Bearbeitet durch User
von Al3ko -. (al3ko)


Bewertung
0 lesenswert
nicht lesenswert
wolle g. schrieb:
> Das lässt hoffen. Nur die Frage, warum geht es bei mir nicht?
> Ich verwende einen Laptop mit Windows 10. Aber noch einmal die
> Ausgangsfrage: die Darstellung von
> unsigned int Zahlen im Bereich 0 bis 65536 funktioniert bei Dir
> fehlerfrei?
> Muss man für 'sprintf' zusätzlich weitere *.h Dateien einbinden?

Hi wolle,
ich habe viel mit den TI DSPs in CSS gearbeitet und bin oftmals 
verzweifelt (liegt aber an meinem Unwissen hinsichtlich uC).

Ich persönlich habe SEHR gute Erfahrung mit dem TI Forum und deren 
Support dort gemacht.

ja, das erfordert eine Anmeldung - vielleicht nicht jedermanns Sache. 
Allerdings wurde mir dort oft und zeitnah (innerhalb eines Tages) von TI 
Mitarbeitern geholfen.

Vielleicht wäre das eine Option für dich?

Viel Erfolg,

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Bewertung
0 lesenswert
nicht lesenswert
wolle g. schrieb:
> Gerhard O. schrieb:
>> Unter W10X64 und W10X32 auf anderen PCs
>> funktionierte alles immer tadellos. Seitdem habe ich nun keine Probleme
>> mehr mit CCS.
>
> Das lässt hoffen. Nur die Frage, warum geht es bei mir nicht?
> Ich verwende einen Laptop mit Windows 10.
> Aber noch einmal die Ausgangsfrage: die Darstellung von
> unsigned int Zahlen im Bereich 0 bis 65536 funktioniert bei Dir
> fehlerfrei?
> Muss man für 'sprintf' zusätzlich weitere *.h Dateien einbinden?

Muss mich entschuldigen. Habe Deine Frage auf die Installation und 
Betrieb von CCS bezogen gehabt und nicht um eas es Dir wirklich ging und 
war deshalb etwas OT.

Sieh Dir mal diesen Link an:

https://forum.43oh.com/topic/1289-tiny-printf-c-version/
http://www.msp430launchpad.com/2012/06/using-printf.html
Github: https://gist.github.com/nicholasjconn/2896348

http://www.sparetimelabs.com/tinyprintf/tinyprintf.php
(Hat auch sprintf() )

Hier noch das Compiler Referenz Manual:
http://coecsl.ece.illinois.edu/me461/MSP430%20Guides/TI_CompilerReference.pdf

Nach etwas durchstöbern im Internet bekam ich schon den Eindruck, daß 
die T.I. Realisierung der Printf Sachen im CCS etwas uC praxisfremd 
erfolgte. In meinem Program ist mir vor ein paar Wochen auch 
aufgefallen, daß %u nicht funktioniert hat; habe es aber auf später 
verschoben der Sache auf den Grund zu gehen weil ich im Augenblick keine 
Zeit habe mich mit dem 430er zu befassen. Bei anderen uC braucht der 
printf Support viel weniger Platz mit mehr Funktionalität.

Beim PIC CCS Compiler (nicht mit TI verwandt) braucht der printf Support 
kaum mehr als 2K. Auch beim Arduino sind deren äqivalenten Funktionen 
nicht so platzhungrig.

Naja, es wird sich mit der Zeit bestimmt irgendeine adäquate bessere 
Lösung finden lassen.

Grüße aus dem verschneiten Edmonton,
Gerhard

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.