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
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?
Nop schrieb:> wolle g. schrieb:>> bzw. wie könnte man das Problem lösen?>> %uwolle 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?
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 ...
Ä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?
>> 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?
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_tzahla;
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
constcharvers[]="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_ti=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
chararray[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
chararray[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.
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.
..,- 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:> 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...
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/2896348http://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
Thread beobachten
Seitenaufteilung abschalten