-
Thread
LCD I2C ATmega32 initialisieren
(); unsigned char string[] = "Hi World"; lcd_print(string); lcd_command(LCD_DISPLAYON | LCD_CURSORON | LCD_BLINKINGON); // Display Hintergrundbeleuchtung ein i2c_start_wait(LCD_I2C_DEVICE+I2C_WRITE); i2c_write
Welche Belegung hat dieser Adapter? Siehe dazu: https://arduino-info.wikispaces.com/LCD-Blue-I2C Marcus M. schrieb im Beitrag #4909963: > Versuche ich einen String auszugeben ("Hi World"), geht die > Hintergrundbeleuchtung aus. Ein klares Indiz dafür, dass die Belegung anders ist, als
-
Thread
Keine GPS Datenanzeige auf GLCD Display (Navilock 552ettl)
Die Punkte von dummy und Dieter Frohnapfel hab ich nun umgesetzt. Nun steht [c] while(NextChar != '$'); // Warte auf erstes Zeichen [/C] und [c] while((NextChar != '*') && (StringLen < MaxLen - 1)){ [/C] im Code. Anbei nun noch die Funktion lcd_puts. Die Microcontrollerei find ich echt geil und spannend aber solche Fehler kosten auch den letzten Nerv. [c] // --------------------------------- // put string to screen (from ram) // --------------------------------- void lcd_puts(uint8_t* font,char* string) {while(*string)lcd_putc(font,*string++);}
-
Thread
Attiny25 serielle Kommunikation
<< PB1); // PB1 auf Low }; else { return;} } else{ return;} }} [/c] Die Länge des Strings wurde so gewählt, da das Protokol am Ende eines Strings immer das Abbruch-Krit. <CR> hat. Am schnluss muss eigentlich nur der string pwrc0000 bzw pwrc0001 aus dem Protokoll
<util/delay.h> > > #include "avr305.h" > > #include <string.h> > > int main() { > > char c; > while(c=readc()){ > > if(readc()='p') Das Zeichen wird in der while-Schleife bereits eingelesen, daher reicht ein Vergleich mit c. Außerdem musst
-
Thread
Program ROM R8C25
Der M16C sollte laut Renesas von der Struktur her mit der R8C/Tiny Familie gleich sein. Angeblich macht es keinen Unterschied, ob man im HEW den M16C oder R8C auswählt. Die Dateien, die angelegt werden sind die
> Der M16C sollte laut Renesas von der Struktur her mit der R8C/Tiny > Familie gleich sein. Angeblich macht es keinen Unterschied, ob man im > HEW den M16C oder R8C auswählt. Die Dateien, die angelegt werden
-
Thread
String vergleichen
verstehen, was du da überhaupt machst. Ich denke (und rate) mal: * Du holst dir vom Handy einen String. * In diesem String ist die Prozentzahl in irgendeiner Form codiert. * Du weist wie die Strings aussehen muessen, und hast alle vom Handy benutzten Strings im EEprom abgelegt. * Die Aufgabe ist es jetzt aus dem String abzuleiten ob du die Ladung anstossen musst oder nicht. Nein. Ich verstehs immer noch nicht. Warum musst du alle möglichen Strings abklappern um zu entscheiden ob du jetzt laden musst oder
-
Thread
C: große datenmenge in array
rein ins project-dir da drinnen machst dann <<<<<<<<<<<<<snip>>>>>>>> liebe_exe_die_aus_dem_string_ein_c_array_macht.exe make.exe %1 <<<<<<<<<<<<snip>>>>>>>>> die exe legt einfach eine cpp-file an wo dann das array definiert und geladen wird..in welcher form is ja egal... schaut dann ca
das auch auf mehrere zeilen aufsplitten... char meinarray[]="+CMGR: 1,,20\n069134660405F1040C9845631792580\ 5000040703871906280012D\nOK"; damit gehts... und wenn du beim string der vom handy kommt noch alle \r\n durch \n ersetzt (also einfach \r am uart ignorieren ;) ) dann hast 0 probs..
-
Thread
C-Code übersichtlich?
15CAlarm30:OFF\r\n"; while(1) { while (!(UCSRA & (1<<RXC))); //warten auf RXC = 1 c=UDR; for(c=0;c<255;c++) {while (!(UCSRA & (1<<UDRE))); UDR=alarm1[c];} for(c=0;c<255;c++) {while (!(UCSRA & (1<<UDRE))); UDR=alarm2[c];} } return 0; }
Spaltenposition x / 10 * irgendeine_Konstante beträgt. #define ESC "\x1B" void Transmit( char* String ) { while( *String ) { while( !(UCSRA & (1<<UDRE)) ) ; UDR = *String++; } } int main() { char Buffer[20]; int i; ... Transmit( ESC "1B[2J" ); for
-
Thread
C, ist die abschliessende Null bei Strings automatisch dabei?
aber vielleicht weiss jemand die Antwort auf die eigentlich triviale Frage auf Anhieb. Wenn ich in C einen String wie im Beispiel gleich beim Anlegen initialisiere, ist die abschliessende Null dann automatisch mit dabei, oder muss ich die selber irgendwie hinten dranfrickeln? [c]uint8_t msg = "Liebe
der Italienischen Oper!"; Die ist automatisch dabei. Allerdings solltest Du es so schreiben: [c]char msg[] = "Liebe Freunde der Italienischen Oper!";[/c] Das erzeugt eine Array, in das der String mit abschließender Null passt. Für Zeichenketten ist char der richtige Datentyp und nicht uint8_t.
-
Thread
C Verständnissfrage Pointer (ja wieder mal ;-) )
gefunden wurde! Alles andere ist nämlich ein Spiel mit dem Feuer [C] // replace EOL to 0x00 (use as string) vline = strchr(sline, 0x0D); if( vline != NULL ) *vline = 0x00; [/C] Die
Danke für die Tips. Ich gehe das jetzt mal alles durch. Ich habe vor einigen Jahren mal etwas in C programmiert. Mir fehlt da einfach die Übung. Das Ende des Strings habe ich nicht beachtet, da der String ja aus einer Datei ausgelesen wird. Spätestes beim EOF ist ja das Ende des Strings. Aber Du
-
Thread
suggest parentheses around assignment used as truth value
errors src/string/strcat.c: In function 'strcat': src/string/strcat.c:7: error: suggest parentheses around assignment used as truth value[/c] Deine Meldung sieht aber ein wenig anders aus... Mein Compiler ist gcc
> Warum nimmst du für dein Programm nicht die string.h (die gehört doch > AFAIK zum C-Standard)? string.h gehört in die C-Lib, was aber meines Wissens entweder standard oder "nahezu-standard" ist. Ich nehme die nicht, weil ich die nicht verfügbar
-
Thread
LCD an PortC
uint8_t x, uint8_t y); /** @brief Display character at current cursor position @param c character to be displayed @return none */ extern void lcd_putc(char c); /** @brief Display string without auto linefeed @param s string to
none */ extern void lcd_data(uint8_t data); /** @brief macros for automatically storing string constant in program memory */ #define lcd_puts_P(__s) lcd_puts_p(PSTR(__s)) /*@}*/ #endif //LCD_H [/c] die avr-includes sind in der main.h
-
Thread
Zahl in String umwandeln
Der ganze Code schreit danach, weggeworfen zu werden (falls er für einen 8-Bit µC gedacht ist)
Udo Schmitt schrieb im Beitrag #2506856: > Lernen was die C API bietet macht aber auch Sinn. > @Judgin F.: > Gibt es einen besonderen Grund warum du nicht itoa() benutzt? itoa() gehört aber eben gerade *nicht* zum C Standard ;-)
-
Thread
Z180-Stamp Modul
| ..0 ..0 ..0 ..0| 0060 0c 94 b3 30 0c 94 d4 63 0c 94 fe 63 0c 94 b3 30 | ..0 ..c ..c ..0| 0070 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | ..0 ..0 ..0 ..0| 0080 0c 94 32 63 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 | .2c ..0 ..0 ..0| 0090 0c 94 b3 30 0c 94 b3 30 0c 94 b3 30 0c 94 c0 64 | ..0 ..0 ..0 ..d| 00a0 0c 94 b3 30 0c 94 b3 30 0c 94 ce 71 0c 94 b3 30 | ..0 ..0 ..q ..0| 00b0 0c 94 b3 30 0c 94 b3 30 0c
-
Thread
Parameter an Funktion
wieso ich Müll rauskriege, wenn ich eine Funktion habe: int sendstring(char *s) { unsigned char c = 0; while(s[c] != 0) if( USR & 0x20 ) UDR = s[c++]; return(0); } int main(void) { sendString("Hallo, Du da!\n\r\0"); return(0); } ich auf dem Terminal nur Müll angezeigt
----------------------------------------------- // send a ProgMem string to UART0 Transmit-buffer //--------------------------------------------------- { char c=pgm_read_byte(str); // get first char from ProgMem while (c) // while not string-end
-
Thread
16-Bit Zahl auf LCD
. > [C] char Buffer[8]; uint16_t Wert; Wert = TCCR1; utoa( Wert, Buffer, 10 ); lcd_string( Wert ); [/C] Wobei lcd_string eine Funktion ist, die einen Textstring auf einem LCD ausgeben können
, 10 ); lcd_string( Buffer ); [/c]
-
Thread
Mehrere Werte über RS485 versenden
gibt das Programm die Werte seriell in einer Zeile aus. Diese > Werte müsste ich jetzt in einen String bekommen? Deine Zeile ist doch schon ein lesbarer Text-String. Aber "Human-Readable" macht halt die Empfangsseite nicht unbedingt einfacher. Wenn ich von Maschine zu Maschine (µC zu µC) kommuniziere
gibt das Programm die Werte seriell in einer Zeile aus. Diese >> Werte müsste ich jetzt in einen String bekommen? > > Deine Zeile ist doch schon ein lesbarer Text-String. Aber > "Human-Readable" macht halt die Empfangsseite nicht unbedingt einfacher. > > Wenn ich von Maschine zu Maschine (µC
-
Thread
UART String senden
vor? Code: [c] #include <avr/io.h> #include <string.h> #define OSCSPEED 8000000 /*OSC in Hz*/ void InitUART(uint32_t baud) { uint16_t baudrate=(OSCSPEED/(16*baud))-1; /*Set baud rate*/ UBRRH
...... [/code] Seltsam finde ich außerdem das strlen() für den String "TEST" den Wert 6 zurückgibt: [code] 4C 45 4E 47 54 48 3A 06 - LENGTH:. [/code] Habe leider kaum Erfahrung mit µC deshalb kann ich mir darauf einfach keinen Reim machen
-
Thread
UART empfängt nur 2 zeichen
_puts(char *s, unsigned int len){ while (*s) { /* so lange *s != '\0' also ungleich dem "String-Endezeichen(Terminator)" */ rs485_putc(*s); s++; } } [/c] Empfangen tue ich mit einem zweiten mega328 [c] if((UCSR0A & (1<<RXC0))){ uart_gets(uart_string, sizeof(uart_string
Oder besser: [c] uart_string_dup = uart_string; uart_str_complete = 0; lcd_gotoxy(0,0); lcd_puts(uart_string_dup); [/c]
-
Thread
Casten macht Probleme
> txt ist doch ein String und kein Pointer. Strings sind(tm) Pointer. Letztenendes kommt es drauf welchen Zeigertyp man wie und wie oft braucht. uint8_t* txt = (uint8_t*)"C9"; [..] dez = (uint8_t)Hex2Dez(txt, 2);
Karl Heinz Buchegger schrieb im Beitrag #3228193: > char* c = "Hallo"; [pre]warning: initialization discards 'const' qualifier from pointer target type[/pre] Hier ist wohl gemeint [c]const char *c = "Hallo";[/c] Ab GCC 4.0 wird kein -fwritable-strings
-
Thread
Serielle Kommunikation zwischen PC(Windows) und µC (STM32)
; SerialBuffer = ""; // Reset string } [/c]
increment; hvAntwort = transmit_apd(channelNumber, 0b1000, incrementValue); RS485_SendString(COM2, itoa(incrementValue, ausgangsBuffer, 10), CRLF); buf[0] = '\0'; //Inhalt des Buffers löschen } } } [/c]
-
Thread
Inzwischen C++ sinnvoll auf einem AVR?
ersetzt, was auch die Länge der Funktionsnamen verkürzt und die Datenkapselung begünstigt. Statt [c]DisplayWrite(Display, String);[/c] schreibe ich nun [c]Display.Write(String);[/c] was meiner Meinung nach angenehmer und übersichtlicher ist. Hardwarenahe Dinge sind nahezu idetisch wie in C und
hat die das gleiche machen, aber > mit unterschiedlichen Parametertüpen aufrufen möchte. > Z. B.:[c]void send(const char c) { > ... > } > > void send(const char* s) { > while(*s) { > send(*s++); > } > }[/c] Und wie sendest du einen String, der im Flash steht?
-
Thread
Problem mit 'String st'
Ich nehme an du benutzt C++? Dort gibt es keine Klasse die String heißt sondern höchstens std::string. Gibts im Header <string>.
das grad' > nix... Was ist dein Problem? was sagt der Compiler? Noch mal zum verständnis: In C++ gibt es *keine* Standardklasse die "String" heisst. Es gibt aber die Klasse "string", im Namensraum "std". [c] #include <string> void foo(std::string st ... [/c]
-
Thread
Datenlogger 10Kanal
dataString = ""; int analogPin; // read seven sensors and append to the string: for (analogPin = 0; analogPin < 6; analogPin++) { dataString += String(analogRead(analogPin)) + ","; } dataString += String(analogRead(analogPin)); // the last data without komma if (myFile) { myFile.println(dataString); } else { DEBUG_PRINTLN("error opening filestring")
-
Thread
Funktion funktioniert nur einmal
Ich hab eine Lösung gefunden: Ich dachte immer, dass ich mit dem Befehl: [c] strcpy(string,""); [/c] den String leere. Aber anscheinend hat das bei mir nicht geklappt. Jetzt hab ich folgendes gemacht: [c]laenge = strlen(string); for(i=0;i<=laenge;i++) { string[i]
memset(string,0, sizeof(string)) dauert etwas länger und schreibt über die komplette länge ein 0 rein. Ein String in C ist nicht wie in Pascal definiert. In C endet der String wenn eine 0 kommt, in Pascal wird
-
Thread
string-Objekte auf dem Heap
Holger S. schrieb im Beitrag #3093614: > http://www.cplusplus.com/reference/string/string/compare/ Eben, seit wann vergleicht man Strings mit == und != ? Ah so, mit C++ verwechselt. Wenn == und != korrekt überladen sind, dann geht das so.
meiner Bibliothek gemacht wird: [c] inline bool operator==(const string& _Left, const string& _Right) { // test for string equality return (_Left.compare(_Right) == 0); } [/c] Oha na sie mal an, ist ja dasselbe. Vielleicht
-
Thread
integer Variable als Kommazahl
. Aus deinem Code: [c]result /= 102,3; //10V anzeigen[/c] Dies wird nicht das tun, was du dir erhoffst. Du benutzt hier den Kommaoperator und result wird durch 102 geteilt. 102.3 wäre richtig, falls du Fliesskommazahlen
[c] result += ADCW; } // ADC wieder deaktivieren ADCSRA &= ~(1<<ADEN); result /= 3; // result /= 102,3; //10V anzeigen return result; } [/c] Und dann in main() [c] uint8
-
Thread
Per UART empfangenen String weiterverarbeiten
Hallo @ all. Ich fange gerade an mit C zu programmieren und habe ein paar Fragen zu folgender Situation : Ich möchte eine per UART empfangenen String (GCC-Tutorial) weiterverarbeiten, der bzw. die Strings sind wie folgt aufgebaut :
// Noch ein '\0' anhängen um einen Standard // C-String daraus zu machen *Buffer = '\0'; } [/c] Ich dachte mir jetzt nach der Zeile '*Buffer='\0' ' zunächst via [c]switch(buffer[1]) case('1'):....; break; case('2'):....; break; ....
-
Thread
#define in einen String eintragen
Moin, wie kann ich mehrere #defines nacheinander in einen String oder ein Array eintragen? [c] #define expr_1 'A', 'B', 'C', 'D' #define expr_2 'E', 'F', 'G', 'H', 'I', 'J' #define expr_3 'K', 'L', 'M' char *string_1; string_1 = "ABCD"; char *string_2; string_2 = expr_1; printf("\r%s", string_1); //geht printf("\r%s", string_2); //geht nicht [/c]
-
Thread
String ein ausgeben
hallo, Viellecht kann mir einer von euch helfen, ich habe ein Temperatur-Modul mit einem ATmega8 mit 16 DS18S20 Sensoren. Dieses Temp-Modul sendet die Daten über eine Uart in ascii, 1.Sensornummer 2stellig 2.Temperatur 2stellig vorm Komma 3.Vorzeichen Plus oder Minus je nach Temperatur draußen 4.Nachkommastelle 1stellig Diese Daten wollte ich nun mit einen Atmega128 mit der UART-Lib von Peter Fleury einlesen und umwandeln und dann wieder Ausgeben,aber leider bekomme ich das so nicht hin. vielleicht kann mir jemand weiterhelfen. danke mfg [c] char Eingabe[7]; int Count
-
Thread
Hilfestellung zu C-Code für Mikrocontroller
>Funktioniert aich nicht. Sind jetzt ja auch Strings in chars. In Hochkommas darf nur ein Zeichen, Zeichenketten kommen in ". strings müssen mit strcmp verglichen werden. Einfach "==" geht nicht. also in main [c] int main(){ read_port("P98
AUch wenn ich nicht glaube, dass du da eigentlich mit Strings arbeiten willst: http://www.mikrocontroller.net/articles/FAQ#Wie_funktioniert_String-Verarbeitung_in_C.3F
-
Thread
Scheduler für AVR
lpm r18, Z > while (tmp != 0) { > 9a: 21 11 cpse r18, r1 > 9c: 01 c0 rjmp .+2 ; 0xa0 <lcd_string_P+0xa> > } > } > 9e: 08 95 ret > tmp = pgm_read_byte(++data); > a0: 01 96 adiw r24, 0x01 ; 1 > a2: f9 cf rjmp .-14 ; 0x96 <lcd_string_P> Lieber Herr Apollo M., das ist nicht mein Code! Mein ist etwas anders: [c] tmp = pgm_read_byte(++data); [/c] gibt es in meinem Code nicht! So kleine Unterschiede machen schon große Unterschiede
-
Thread
MSP430 F5529 Wobbel-Generator
nachwievor fliegt mir der string mist um die Ohren. Hatten im Unterricht diese als extern void eingeführt, liegen die Sachen in der Header-Datei oder in einer anderen Quelldatei, z.B. ein seperates C-Programm?
Antonowan225 schrieb im Beitrag #6098701: > nachwievor fliegt mir der string mist um die Ohren. > > Hatten im Unterricht diese als extern void eingeführt, liegen die Sachen > in der Header-Datei oder in einer anderen Quelldatei, z.B. ein seperates > C-Programm? Es wird
-
Thread
Pointer in ISRs
/Fehler: Bereits am Senden } else { TXBUF=Ausgang; //zu übertragenden String in Puffer schreiben UCSRB |= (1 << UDRIE); //Interrupt einschalten zum Sendestart return 0; //TX beginnt fehlerfrei } } [/c] ...und wenn ich den Inhalt aus der ISR unverändert
[c]volatile unsigned char *TXBUF;[/c] Nicht der Inhalt deines Puffers muss volatile sein, sondern der Pointer. Also: [c]unsigned char * volatile TXBUF;[/c]
-
Thread
String Splitten in C (WinAvr)
Hallo ! Ist es möglich mit C einen String, den man vom PC per UART geschickt bekommt, nach einem bestimmten Delimiter zu splitten ? Ich benutze WinAvr und finde einfach keine Funktion dafür. Gruß, G.
wirklich nicht schwer eine solche Funktion selber zu realisieren. Ansonsten schau mal in die string.h
-
Thread
printf-Funktion geht nur ohne Variable.
Ich meine, das 2 Zeichen ankommen. Dezimal 1 und dezimal 19. Als ASCII-string natürlich nur symbole... Edit: Ok, das selbe Problem wie ursprünglich. entferne ich die Variable aus dem String, also: [C] sprintf(Buffer,"Wert: X\n"); [/C] dann sehe ich im Terminal
lokalisieren oder gar zu beheben. Was soll das hier heissen? >entferne ich die Variable aus dem String In dem String ist keine Variable. Das hier: [c] sprintf(Buffer,"Wert: X\n"); [/c] >dann sehe ich im Terminal "Wert: X" ist jedenfalls kein Fehler sondern völlig richtig. Genau so steht
-
Thread
ATmega1284P Beschreiben in falschen Speicherbereich?
(u8_Ausrichtung == RECHTSBUENDIG) u8_XCoordString -= u8_WidthInPixel; for ( j=0; j < l; j++ ) { // analog zu c=strarray[i][j] wenn alles im RAM c = (Tu8)( pgm_read_byte( pstrflash++ ) ); LCD_schreiben(u8_XCoordString, u8_YCoordString, u8_font, c); u8_ZeichenBreit = ZeichenBreiteBestimmen(c, u8_font); u8_XCoordString += u8_ZeichenBreit; } }[/c] Was ist, wenn TextArray im Speicher > 64kB liegt?
-
Thread
UART sendet Zeichen mehrmals ATMega1280
Hallo zusammen, ich möchte einen String an die µC senden und dieser soll dann wieder zurück gesendet werden. Das funktioniert soweit auch, wenn ich ein delay von 1sec einbaue. Nehme ich das delay weg, sendet die UART den String mehrmals
- 1 ) *Buffer++ = NextChar; StringLen++; } } } while( NextChar != '\n' ); *Buffer = '\0'; } [/C]
-
Thread
[AVR] Grammatik für AVR C (avr-gcc)
zu einem string literal expandiert? Nach dem Preprozessing kommt da also sowas raus wie: [c] sprintf(prompt, "[bt-cmd@""%u""]$ ", ...[/c] > Ist der Befehl nun nur in avr-gcc enthalten oder auch im reinen > GnuC? Es ist ISO-C90. Stichwort: string concatenation. Der AVR-GCC hat eigentlich keinerlei Syntaxerweiterungen gegenüber dem GCC ,,aus der Dose''. OK, eine hat(te) er: binäre Konstanten (mit 0b
-
Thread
Frage zum Aufteilen von C-Programm in mehrere Dateien
<string.h> #include <stdio.h> } [/C] .. Das mache ich ja schon in der main.c: [C] { #include <avr/io.h> #include <avr/interrupt.h> #include <avr/sleep.h> #include <string.h> #include <stdio.h>
<avr/sleep.h> #include <string.h> #include <stdio.h> //usw, was ich halt so brauche #include "a.h" #include "b.h" #endif [/c] main.c, a.c, b.c : [c] #include "includes.h" [/c] a.h, b.h: [c] //Keine Includes
-
Thread
Unterschiede zwischen ARM und ATmega in der Programmierung
Initialisierungs-Code in Gewicht. Mir ist noch ein ein angenehmer Vorteil von ARM versus AVR eingefallen: Bei Strings muss man als C Programmierer nicht mehr zwischen RAM und Flash unterscheiden, da beide Speicher im selben Adressraum liegen. Dadurch entfällt das bei AVR standardmäßige Kopieren aller Strings ins
Stefan U. schrieb im Beitrag #5319188: > Eine mögliche Erklärung: Weil Strings in C normalerweise veränderbar > sind. String Literale normalerweise nicht, es sei denn man initialisiert ein Array damit. Das Problem ist halt, dass man einem Pointer nicht ansieht ob er in
-
Thread
Fehler nach Einfügen einer Else-Anweisung
Wenn ich diese Funktion verwende: [c] lcd_stringCenter_P((PSTR)"ID unknown.", 1); [/c] Er schmeißt dann aber bei mir einen Feher raus: Error 6 too few arguments to function 'lcd_stringCenter_P'
Es muss heißen: [c]lcd_stringCenter_P(PSTR("ID unknown."), 1);[/c]
-
Thread
String besteht nur aus 0xFF - Linkerproblem? AVR Studio 7
und uart_puts verwendet. uart_putc (Char) funktioniert tadellos. uart_puts funktioniert nur für Strings mit einer Länge von 3-4 Zeichen. Bei längeren Strings werden nur 0xFF Bytes übertragen. Hier meine Main-Loop. [c] const char a[] PROGMEM = {'H','e','y',0}; const char b[] PROGMEM = {
definiere und die ASCII-Codes da nacheinder eintrage, dann klappt es. Weise ich dem char[] (RAM) einen String zu, klappt es nicht. Speichere ich einen String im FLASH und kopiere diesen in den char[] Buffer mittels strcpy_P, so hängt sich der µC weg. Beim Debugging in der Simulierung vom Atmel-Studio kann
-
Thread
Enum zu char array mappen mit verschiedenen Datentypen
(array_string[sensor2]); } [/c]
foo(void) { int i; for(i = 0; i < sensormax ; i++) { print_char_string(array_string[i]); print_number(array_Data[i]); } } [/c]
-
Thread
C++: Funktionspointer auf "fremde" Methode einer Klasse
Hallo, folgende Situation: Ich habe einen kleinen Skript-Interpreter geschrieben (Visual C++ 2005), der Scriptdateien abarbeiten kann. Der funktioniert auch schon prima. Ich habe diesen Interpreter als Klasse implementiert und füttere diesen mit Strings die dann abgearbeitet werden. Nun benötige
Wurst wrote: > folgende Situation: > Ich habe einen kleinen Skript-Interpreter geschrieben (Visual C++ 2005), > der Scriptdateien abarbeiten kann. Was für Script Dateien? >Der funktioniert auch schon prima. > Ich habe diesen Interpreter als Klasse implementiert und füttere diesen > mit Strings
-
Thread
ISR und Stackgröße
Da scheint es noch einige Unklarheiten zu geben, was Stringverarbeitung angeht [C] strncpy(breitengrad, "Warte...",8); [/C] Dre String "Warte..." hat keine Länge von 8 Zeichen, sondern es sind 9 Zeichen (du hast auf das abschliessende \0 vergessen). Ausserdem solltest du dir
zweitens macht er die notwendige Anpassung von alleine, wenn sich mal die Arraygröße verändert. [C] strncpy(breitengrad, "Warte...", sizeof(breitengrad)); [/C] strncpy ist aber nur die halbe Miete, denn strncpy hat hier ein Designproblem: Wenn der String gerade noch ohne das obligatorische \0
-
Thread
avr-gcc: __DATE__ formatieren / "initializer element is not constant"
, der den C-String __DATE__ parsed und in einen Tag (Julian Day) umwandelt. Das verbraucht weder RAM noch Flash und kostet auch zur Laufzeit nichts. Wenn Interesse besteht, stelle ich das auch gern zur Verfügung
String initialisieren darf – anders als in C.
-
Thread
Timer und Interrupts beim ATmega 128
;-) Ähm. Das ist Grundlagen - C Programmierung - Strings. In jedem C Buch irgendwo im ersten Drittel des Buches in einem eigenen Kapitel über Strings lang und breit und 25 Variationen ausgewälzt. [[String-Verarbeitung in C]]
;-) > > Ähm. > Das ist Grundlagen - C Programmierung - Strings. > In jedem C Buch irgendwo im ersten Drittel des Buches in einem eigenen > Kapitel über Strings lang und breit und 25 Variationen ausgewälzt. > > [[String-Verarbeitung
-
Thread
Sammelbestellung AR488 kompatibler USB-GPIB Adapter. Interesse?
[c] #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #define maxbuf 50 int main(int argc, char** argv) { char buf[maxbuf]; int n;
[c] #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #define maxbuf 50 int main(int argc, char** argv) { char buf[maxbuf]; int n;
-
Thread
C Problem, String vergleich
Hi, hab versuch ein C Prgramm zu schreiben für ein Atmega8 mit 8Mhz. Es sollte einen ankommenden String von der RS232 mit einem im MC abgelegten String vergleichen. So sieht es bis jetzt aus: #include <avr/io.h
USART_I (); sei(); //Interrputs EIN sschalten for (;;) {} } also wenn der string richtig ist wird die LED leuchten PORTB2! FEHLER: Wenn ich jetzt denn richtig sende, leuchtet sie auch, aber wenn ich einen falschen string senden und dannach wieder den richtigen. Leuchtet nix
-
Thread
Zuweisung von Strings an ein Array
uart_putc(32); } } } int main(void) { foo(1); . . foo(4) } [/c] Auf meinem Terminal kommt da nur noch Murx raus. Ist es ein Problem, dass ich mehrere Strings in die Arrays schreibe, oder besser gesagt so wie ich sie da reinschreibe? Vielleicht sitze ich einfach
mich jetzt noch mal in Ruhe rangesetzt. Oben war ein Fehler von mir: Ich rufe natürlich nicht: [c] foo(1); . . foo(4): [/c] sondern: [c] foo(0); . . foo(3): [/c] auf. Nochmal zu dem 2D-Adressierten, ich dachte immer das waere genau anders herum, also: 0-0 1-0 2-0 .... 3-4 4-4