Hallo zusammen, ich möchte eine dezimal Wert auf meinem Sain Smart TFT Display ausgeben. habe in meinen Programm folgende Zeile: Serial.print(Wert, DEC); dieser Wert wird jetzt ganz normal im Serial Monitor als Dezimalzahl angezeigt. muss ja dann mit der Funktion myglcd.print arbeiten, richtig? Hat jemand einen Tip wie ich das über das TFT Diplay lösen kann? vielen dank im Voraus
TiMa schrieb: > ich möchte eine dezimal Wert auf meinem Sain Smart TFT Display ausgeben. Womit? Mit welcher Plattform? Welcher Programmiersprache? Welcher Entwicklungsumgebung?
TiMa schrieb: > Hat jemand einen Tip wie ich das über das TFT Diplay lösen kann? Hast du denn zu deinem Display keine Software dazu gekriegt? Da wird es ja wohl in typischer Arduino Manier eine fix&fertig vorgefertigte Klasse geben, die in deinem Programm dieses Display repräsentiert. In dieser Klasse siehst du mal nach, was die dir als Ausgabefunktionen zur Verfügung stellt.
es handelt sich um die normale Arduino Entwicklungsumgebung. eine Software habe ich leider nicht dazu bekommen :/
TiMa schrieb: > es handelt sich um die normale Arduino Entwicklungsumgebung. > > eine Software habe ich leider nicht dazu bekommen :/ Dann musst du dir eben eine im Web suchen. Du bist ja schliesslich nicht der erste, der dieses LCD mit einem Arudino benutzt. Sieh dir halt mal bei anderen an, welche Arduino Lib die benutzen und warum. Hier zb http://www.mathias-wilhelm.de/arduino/beispiele/lcd-graphic-displays/ gibt es ein paar Tips. Es gibt aber auch noch jede Menge anderer Webseiten, die sich bei Google mit dem Suchbegriff "sainsmart tft arduino library" finden lassen. Willkommen in der Welt der Großen, in der man auch mal selber aktiv werden muss.
:
Bearbeitet durch User
ok alles klar.. habe gerade schone eine Funktion gefunden: myGLCD.print("Wert: (DEZ)", CENTER, 290); mit der werde ich es mal ausprobieren.
Das hier http://arduino.cc/en/Reference/TFTLibrary könnte auch interessant sein. Ich sag absichtlich könnte, weil ich auch erst mal recherchieren müsste, ob dein spezifisches SeinMart da mit reinfällt.
TiMa schrieb: > myglcd.print arbeiten, richtig? hmm, myglcd und TFT passt nicht zusammen für myglcd gilt:
1 | myGLCD.print("OCRxA= ", LEFT, 16); // Text -> String |
2 | myGLCD.printNumI( OCRxA, (6*9), 16, 5, ' '); // numerisch |
man beachte den Unterschied zu *myGLCD.print* und *myGLCD.printNumI* TiMa schrieb: > jemand einen Tip wie ich das über das TFT Diplay lösen kann?
1 | tft.println(F("-0,1234567")); // Text -> String |
2 | tft.println(mass2string(dezi_mass1)); // numerisch in string umwandeln |
3 | .......
|
4 | |
5 | // vielleicht etwas umständlich aber es funktioniert, bbin kein softie
|
6 | char *mass2string(uint16_t mass) |
7 | { char _tmp[MAX_STRING]={0}; |
8 | char _tmp2[MAX_STRING]={0}; |
9 | char *ptr_chr; |
10 | |
11 | strcpy(_tmp, insert_char(trimm_string('0', utoa(mass, _tmp, 10), 4), ',', 3)); |
12 | ptr_chr=_tmp; |
13 | while(*ptr_chr) |
14 | { if(*ptr_chr == '0' && *((char *)(ptr_chr+1)) !=',') |
15 | *ptr_chr == ' '; |
16 | else
|
17 | break; |
18 | ptr_chr++; |
19 | }
|
20 | strcpy(_tmp2, ptr_chr); |
21 | strcpy(_tmp, trimm_string(32, _tmp2, 5)); |
22 | return _tmp; |
23 | }
|
Joachim B. schrieb: > // vielleicht etwas umständlich aber es funktioniert, bbin kein softie Nö Es scheint nur so, dass es funktioniert. > char *mass2string(uint16_t mass) > { char _tmp[MAX_STRING]={0}; > .... > return _tmp; > } Die Adresse einer funktionslokalen Variable zurückzugeben ist ein absolutes No-No. Wird die Funktion verlassen, dann existiert diese Variable nicht mehr. Der Aufrufer hat dann eine Speicheradresse zu einer Variablen, die es nicht mehr gibt. Je nachdem, was in der Zwischenzeit mit dem Speicher alles gemacht wird (was teilweise ausserhalb der Kontrolle des Programmierers liegt) kann alles mögliche passieren. Alles mögliche beinhaltet auch "Funktioniert wie erwartet" - ist aber trotzdem falsch.
Karl Heinz schrieb: > Die Adresse einer funktionslokalen Variable zurückzugeben ist ein > absolutes No-No. Wenn man sie (die lokale) aber static macht dann ist es sicher.
Arduinoquäler schrieb: > Wenn man sie (die lokale) aber static macht dann ist es sicher. Trotzdem ist es Murks, wenn man auf diese Art eine lokale Variable global verfügbar macht. Das ist etwa die Ebene, wo man auch mit GOTO im Programm hin und herspringt...
:
Bearbeitet durch Moderator
Karl Heinz schrieb: > Nö > Es scheint nur so, dass es funktioniert. jau da hatte ich auch schon mal Kummer ohne zu wissen warum Arduinoquäler schrieb: > Wenn man sie (die lokale) aber static macht dann ist es sicher. auch das hatte ich schon mal versucht, aber static klaut eben Speicher und ich dachte ich könnte den sparen und habe static wieder ausgebaut und zumindest sah es so aus als wenn es geht. Verdammt ich werde nie echter softie, wie können Funktionen Variablen zurückgeben ohne ewig den temporären Speicher zu blockieren?
:
Bearbeitet durch User
Joachim B. schrieb: > Verdammt ich werde nie echter softie, wie können Funktionen Variablen > zurückgeben ohne ewig den temporären Speicher zu blockieren? In C zb dadurch, dass nicht die Funktion den Speicher hält, sondern der Aufrufer dafür zuständig ist, entsprechenden Speicher bereit zu stellen, in den die Funktion reinschreiben kann. Oder warum denkst du, musst du bei zb utoa oder auch sprintf das genau so machen?
:
Bearbeitet durch User
Karl Heinz schrieb: > In C zb dadurch, dass nicht die Funktion den Speicher hält, sondern der > Aufrufer dafür zuständig ist, entsprechenden Speicher bereit zu stellen, > in den die Funktion reinschreiben kann. > Oder warum denkst du, musst du bei zb utoa oder auch sprintf das genau > so machen? jetzt wo du es sagst :-) und trotzdem wäre ja der Speicher reserviert und fehlt dem RAM, OK man könnte ihn mehrfach verwenden, bei einer Textzeile ist es ja überschaubar, nur Mehrfachnutzung der Funktion mit nur einem temporären Speicher geht halt nicht. danke für den Denkanstoß
Joachim B. schrieb: > könnte ihn mehrfach verwenden, bei einer Textzeile ist es ja > überschaubar, nur Mehrfachnutzung der Funktion mit nur einem temporären > Speicher geht halt nicht. Yep. Jetzt hast du zb erkannt, was das große Problem von strtok ist und warum da eine 2.te Version strtok_r 'nachgebessert' wurde.
1 | char *strtok(char *str, const char *delim); |
2 | char *strtok_r(char *str, const char *delim, char **saveptr); |
(Die Argumentliste erzählt eigentlich schon die ganze Geschichte, wenn man sie lesen kann :-)
:
Bearbeitet durch User
Karl Heinz schrieb: > Yep. > Jetzt hast du zb erkannt, was das große Problem von strtok ist und warum > da eine 2.te Version strtok_r 'nachgebessert' wurde. wobei das r irritiert, denkt man sofort an reverse wie bei strstr zu strrstr, wobei ich lernen musste das gcc strrstr nicht kennt, ist das ein Mist mit der Inkompatiblität von C.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.