Announcement: there is an English version of this forum on 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.
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
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? > > %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?
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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.
:
Bearbeitet durch User
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.
Schon mal das hier versucht? http://processors.wiki.ti.com/index.php/Printf_support_for_MSP430_CCSTUDIO_compiler
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
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?
:
Bearbeitet durch User
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
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
Thread beobachten
Seitenaufteilung abschalten