CCS8 -- unsigned int zählt nicht über >32767

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.

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?

Ä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?

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

>> 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 ?

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.

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?

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

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.

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.

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.

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.

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

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

..,- 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?

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.

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.

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.

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?

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,

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