-
Thread
STM32 F103 - I2C Probleme
12, "Hallo!");//write string - you set coordinates and string // u8g_DrawBox(&u8g, 30, 30, 35, 35);//draw some box /* while(HAL_I2C_Master_Transmit(&hi2c1, 0x3C,(uint8_t*) outbuffer, sizeof(outbuffer), (uint32
ein Signal (Siehe Anhang). Auf der SDL Leitung passiert aber nix (durchgehend 3,3V). Code: [c] void draw(void) { u8g_SetFont(&u8g,u8g_font_profont10);//set current font u8g_DrawStr(&u8g, 2, 12, "Hello!");//write string - you set coordinates and string u8g_DrawBox(&u8g, 30, 30, 35,
-
Thread
PIC LCD Ausgabe von Strings
nicht jedes Mal beim Setzen von Bits in Port B die LCDE Leitung neu setze, ist diese einzeln an PortC. Die Beschaltung sollte soweit stimmen, da ich mit einer bestimmten Variante meines Codes (der hier geposteten) das Display soweit ansteuern kann und es string0 in einer Zeile meiner Wahl ausgibt. Füge
_2 call OutLcdDaten INCF INDEX, F GOTO OUT_STRING_1 OUT_STRING_2 RETURN GET_STRING_ADDRESS ADDWF PCL, F RETLW STRING0-STRING0 RETLW STRING1-STRING0 RETLW STRING2-STRING0 RETLW STRING3-STRING0 ;;;;;;;;;;;;;;;;;;;;;;;;;;
-
Thread
I2C Peripherie ansteuern
das Relayboard (PCF8574) zu testen, dabei kam es zu folgenden Problemen: erstes Problem: .\Obj\i2c.o: In function `I2C_Config': .\src/i2c.c:41: undefined reference to `__udivsi3' i2c.c (Auszug): void I2C_Config(unsigned long clk_bus) { _CURRENT_I2C_CLK_ = clk_bus; /* Initialize I2C bus
>.\src/i2c.c:41: undefined reference to `__udivsi3' Vieleicht mal #include "math.h" >siprintf(string,"\n\rExpander = 0x%02X, ec = %d",dataByte,ec); siprintf() kenn ich nicht. Könnte sprintf() sein ;)
-
Thread
sprintf in C - Nullen dynamisch auffüllen
http://home.fhtw-berlin.de/~junghans/cref/FUNCTIONS/format.html oder ein C-Buch lesen?
Ein richtiges printf kennt "*". Und dann sieht das ganze so aus: [c] sprintf(MyCharArray, "%0*i", breite, MyInt); [/c]
-
Thread
STM32 Zeichen filtern
Müsste das nicht so heißen: [c] if ((GPS1[2] == 'V') && (GPS1[3] == 'T')) [/c] Strings fangen bei [0] an!
Wo ist die Null Terminierung char GPS1[] = ['a','b','c','d','e','f','g','h',0]; Bitte unterscheide zwischen chars und strings Du solltest dir noch mal die Kapitel Felder (Arrays) und Pointer sowie Strings durchlesen ( in deinem C Buch )
-
Thread
seltsames i2c verhalten
,..: [C] lcd_clear(); if(i2c_start(adr+I2C_READ)) //Temperatur-Sensor check lcd_string("i2c: nein"); else lcd_string("i2c: yeah"); i2c_stop(); [/C] wenn ich den return wert allerdings zwischenspeicher funktioniert das acknowledge (bekomme "i2c: yeah" ausgegeben): [C] unsigned char temp; lcd_clear(); temp=i2c_start(adr+I2C_READ); if(temp) //Temperatur-Sensor check lcd_string("i2c: nein"); else lcd_string("i2c
-
Thread
C++ oder C auf uc
ich finde diese zeile interessant wie grausam: [c] 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++." [/c] für mich ist die C++ nachahme in C der totale CRAP was soll dr mist ? warum
Assembler Code ansieht, kann mitunter sehen, daß Funktion und Aufruf beider Varianten (C und C++) in identischem Code resultieren. Von Spracheigenschaften wie Exceptions oder RTTI würde ich vorerst Abstand nehmen. Auch auf Laufzeitelemente wie std::string oder Streams im allgemeinen würde
-
Thread
Int mit float multiplizieren
Simulation das Programm*/ freq=1/periodendauer; /*weiterer unkritischer Code zum senden eines Strings per RS232*/ T0OF=0; freq=0; } return 0; }[/c] Ich hoffe ihr habt einen Rat für mich. Bitte bezieht euch auf das Problem. Dankeschön Grüße
9]=0x0D; /*Stringlaenge auslesen und String senden*/ stringlaenge=sizeof(string); string_senden(string); } return 0; }[/c] Das Senden des Strings funktioniert. Das benutze ich auch schon seit ein paar Programmen
-
Thread
#define als String "umdefinieren"
"123" (als String!) einsetzen soll? Gibt´s da ne Möglichkeit? Gruß, Dirk.
müsste es ja mindestens > ne Warnung geben. Würde ich auch erwarten. Test: [pre] % cat foo.c char foo[4] = "Hello"; % cc -Os -Wall -Wextra -c foo.c foo.c:1: warning: initializer-string for array of chars is too long [/pre]
-
Thread
Uhrzeit aus RTC auf LCD ausgeben
lcd_init(); i2c_init(); while(1) { i2c_start(0b10100010); i2c_write(0x02); i2c_rep_start(0b10100011); i2c_readNak(); i2c_stop(); char Wert = TWDR; Wert = Wert & 0b01111111; lcd_string_xy
mir vorstellen kann. Wenn du sprintf, wie von PeDa vorgeschlagen benutzen kannst, dann zb so [c] unsigned char BCD; char string[20]; BCD = ((TWDR & 0x70) >> 4) + (TWDR & 0x0F); sprintf( string, "Sekunden: %02u", BCD ); lcd_string_xy(0, 0, string); [/c] Allerdings erhebt sich
-
Thread
Größe eines #define String mit sizeof ermitteln
string literal dagegen die bis zur letzten. Beispiele: [c] strlen("test"); // 4 sizeof("test"); // 5 strlen("test\0test"); // 4 sizeof("test\0test"); // 10 char *test = "test"; strlen(test); /
[c] #include <avr/io.h> #include <string.h> #define VERS_PROGRAMVERSION "V01.00.00" /* Programmversion */ int main() { PORTB = strlen(VERS_PROGRAMVERSION); return 0; } [/c] erzeugt
-
Thread
UART-String ins EEPROM schreiben
Variablen auch. Aber ich krieg das Ding nicht ins EEPROM. Hab dafür folgende Funktion geschrieben: [c] char ee_serial_number[20] EEMEM; char line[20]; int main() { ... string_to_eeprom(line, ee_serial_number); ... } void string_to_eeprom(char *input, char *destination) {
x = 0; &input[x] != '\0'; x++) { eeprom_write_byte(&destination[x], &input[x]); } } [/c] In dem Array "line[]" steht die eingelesene Zeichenkette. Und dann wollte ich das eben so machen, daß Element für Element ins EEPROM übertragen wird, mit Überprüfung auf das String-Endzeichen. Aber
-
Thread
Analogsignale am PC auslesen/ausgeben (C#/C++)
Temperaturwert abzuleiten und per ACSII-String dem Gerät zuzusenden(Sollwert). Umgekehrt genauso, also Parameter des Gerät dem ACSII-String entnehmen und daraus eine entsprechende Spannung ausgeben (ebenfalls +/-10V, Istwert) Ich brauch also
D-Wandler, den man per USB/PCI an den PC anschließen kann und wenn möglich über ein selbstentworfenes C++ oder C# Programm die Analogwerte auslesen bzw. ausgeben kann. Die RS232-Kommunikation ist dann auch kein Problem, da man dies entsprechend selber programmieren kann. Gesucht wird eine fertige Lösung
-
Thread
Variablen uint16_t hat falsche Werte
des Strings. Immer. Das ist die Art und Weise, wie in C Arrays übergeben werden. -> du brauchst ein C-Buch! > Zeiger auf das erste Element, da es mit const angegeben ist, sucht der > AVR im Flash-Speicher
Buchegger schrieb im Beitrag #3130967: >> Der Funktion wird ein char-Arrray übergeben, > > In C werden keine Arrays übergeben. Die Funktion kriegt einen Pointer > auf den Anfang des Strings. Immer. Das ist die Art und Weise, wie in C > Arrays übergeben werden. Tschuldigung, das ist mir klar
-
Thread
ATMega32 Absturz bei Zeicheneingang
Hallo, Bernhard: Ich habe es gerade mal geändert: [c] while ((sInBuffer[iTmpBufferPtr] != 0x00) && (sInBuffer[iTmpBufferPtr] != 0x20 && (iTmpBufferPtr <= (BUFFER_LENGHT-2)))) { // Command, max. String Länge aus ISR gesichert [/c] -> Gleicher
(ltoa(lCommandPar2, sOutString, 10)); UsartPuts (" -> "); UsartPuts("\n>>"); } } return 0; } [/c] langsam blick ich es wirklich nicht mehr. Gruß Andy
-
Thread
Hex-String einlesen und Binärwert laut Codetabelle zuweisen
Hans M. schrieb: > Wie kann ich das grundsätzlich machen? In welcher Programmiersprache? C? > Muss ich hier den String in ein > Array umwandeln mit 40 Zeichen? Wie hast du denn den String gespeichert? Der ist ja wahrscheinlich schon in einem Array gespeichert. > Wie kann ich dann
Programmiersprache C mit CCS-C Compiler Microchip MPLAB 8.36. Der String sieht folgendermaßen aus. Tippt man in LabVIEW die Nachricht "0123456789" ein, so wird der Hexadezimalstring "0000 000F 0033 003C 0055 005A 0066
-
Thread
TWI I²C Temperatursensor
false); // lesen von Bytewert Nr. 2 } MK3_TWI_STOP(); MK3_TWI_WAIT(10); lcd_string (itoa(wert1 , buffer , 2)); _delay_ms(5000); lcd_clear(); lcd_home(); } } } [/c]
Vielleicht ist es nur ein copy-paste-Problem, aber Dein MK3_TWI_START scheint auskommentiert zu sein? [c] //--------------------------------------------------------- ok=MK3_TWI_START(); [/c]
-
Thread
PIC HEX Code umschreiben - geht das?
Eine Frage hinterher: Ich kann den HEX nicht generieren wegen Fehler. Es ist möglich das 'string.h' fehlt. Im *.mcp steht ja: file_010=D:\Microchip\c18_v3_30\c18\h\string.h Ist das nun ein Teil vom C18 Compiler, oder gehört 'string.h' zur Source? In dem Fall ist dann hier erstmal Schluss
Schon mal geschaut, was in dem Verzeichnis D:\Microchip\c18_v3_30\c18\h so alles drin ist? Gibt es dort ein string.h? Gibt es irgendwo im Microchip-Verzeichnis ein string.h?
-
Thread
Gnu Assembler Macros
das obige eingefügt und stattdessen den String "test" ausgeben lassen über das Label .KLAUS Das ist als a.c und a.s (mit gcc aus a.c erzeugt, dann wie beschrieben geändert) im Anhang. Also sollten bei dir doch nur die Gänsefüßchen fehlen?
aber bei der Verwendung des Arguments Gänsefüßchen > dazu genommen): > [code] > .macro blabla string > .KLAUS: > .string "\string" > .endm > ... > blabla "test" > ... > [/code] > > Zum Testen habe ich ein kleines C-Programm gemacht, das mit puts() was > ausgibt. > Dann
-
Thread
problem mit 8051er
DPTR,#TXT_Ausgabe_Vorname lcall SP_OutString jmp dekrementieren VergleichNN: clr c cjne A,nachname,Eingabe mov DPTR,#TXT_Ausgabe_Nachname lcall SP_OutString dekrementieren: djnz
Sendet das Byte, auf das r0 zeigt (ergibt Char) ;SP_OutHexA: Sendet das Byte im Accu als Hex-String (z.B. FF) ;SP_OutByteHexR0: Sendet das Byte, auf das r0 zeigt, als Hex-String (z.B. FF) ;SP_OutWordHexR0: Sendet das Byte, auf das r0 zeigt, und das nächste Byte als ; Hex-String (z.B.
-
Thread
Atmel Studio 6.2 - sprintf() - Problem
Pyromaniac schrieb im Beitrag #3909287: > strcpy(buf, "Linie 2\0"); string.h eingebunden? Das \0 ist überflüssig, da der Compiler bei Stringliteralen automatisch ein '\0' anhängt. Wie sieht es bei [c]char buf[32] = "Linie 2";[/c]oder [c]send_string("Linie 2");[/c]aus
es bei [c] char buf[32] = "Linie 2"; [/c] > oder [c] send_string("Linie 2"); [/c] > aus? Beides führt zu dem immer selben Ergebnis wie auch schon bei sprintf().
-
Thread
LCD gibt keine String aus
lcd_clear ; Display löschen ldi ZL, LOW(text*2) ; Adresse des Strings in den ldi ZH, HIGH(text*2) ; Z-Pointer laden rcall lcd_flash_string ; Unterprogramm gibt String aus der ; durch den
konstanten Text aus dem Flash Speicher ; ausgeben. Der Text wird mit einer 0 beendet lcd_flash_string: push temp1 lcd_flash_string_1: lpm temp1, Z+ cpi temp1, 0 breq lcd_flash_string_2 rcall lcd_data rjmp lcd_flash_string
-
Thread
Speichermanagement
C - Grundkurs, 3. Tag: mit " werden C-strings eingeschlossen, also eine Sequenz von Zeichen die mit einem '\0' character endet. mit ' werden einzelne Zeichen eingeschlossen, also ein
(text); // ausgabe string pos(2,1); run(20); print("Servas Text") // ausgabe string run(20); for(;;){ } //endlosschleife } hier die lcd.c: #include<avr/io.h> #include
-
Thread
String automatisch verändern.
Vielleicht in Anlehnung and das hier? [c] sprintf (Dateiname, "%06d.CSV", zahl); [/c] und diesen Mist hier weglassen? [c] Dateiname [0] = '1'; Dateiname [1] = zahl; Dateiname [2] = '3'; Dateiname [3] = '4'; Dateiname [4] = '5'; Dateiname [5] = '6'; Dateiname [6] = '7'; [/c]
-
Thread
Konstanter String - zu lang!?
Hallo, in meinem µC möchte ich einen konstanten String ablegen, denn ich dann bei Bedarf über's Netzwerk rausschicken kann. Mein erster Versuch war Folgender (Pseudo-Code): [c] byte MyString = {... 0x65, 0x66, 0x67
(wie viel genau habe ich noch nicht analysiert). Mein zweiter Versuch: den String aufteilen: [c] byte MyString1 = {... 0x65, 0x66, 0x67 ...}; // Nur 1024 Bytes byte MyString2 = {... 0x65, 0x66, 0x67 ...}; // Nur 1024 Bytes byte MyString3 = {... 0x65, 0x66, 0x67 ...}; // Nur
-
Thread
Hex zahl auf richtigkeit überprüfen
Guten Morgen ich mache in den Ferien ein kleines Projekt mit einem Atmega in C. Nach der Eingabe wird der String in ein Char-Array gelegt. Nun suche ich nach einer Lösung wie ich einen Wert aus einem Char-Array am besten überprüfe, ob es sich um eine gültige Hex-Zahl handelt
kaum mehr eine > Rolle spielt: Wer garantiert dir, dass die Buchstaben hintereinander > kommen? Der C-Standard garantiert dir das nämlich nicht. Der Ansi und Ascii-Standard definiert das, und um den gehts ja bei der String-Auswertung :-) wollte nur zeigen, dass man so ein Problem auch effizient "
-
Thread
Umwandlung ASCII Charactr zu decimal in STM
dir einfach mal die C-Grundlagen zur String-Manipulation an.
#0 initialisiert (bis auf die ersten 2 Positionen - sort steht ja Deine Zahl). Damit hast Du Deinen C-String. Du übergibst atoi nur eine Referenz auf Deinen Puffer und gut ist. Du kannst auch über die Elemente des Puffers iterieren und jeden Wert umwandeln, so wie es hier mehrfach gezeigt wurde, und
-
Thread
Lib Roland Riegel, Dateinamen hochzählen lassen
Anna schrieb im Beitrag #2562759: > const char* file Das bedeutet nur, dass der Inhalt vom String, worauf /file/ zeigt, von der Funktion nicht geändert wird. > Ich programmiere in C. Und welchen Fehler bekommst du? Wie sieht deine Deklaration und wie sieht deine funktion aus?
Nachdem Dein Dateiname nicht konstant ist ("raufzählen"), darf er auch nicht const deklariert werden: [c]char* filename[11];[/c] Deine Lib erwartet allerdings einen konstanten String, also casten: [c]fat_create_file(&parent, (const char*) filename, &dir_entry);[/c] In diese Richtung char* --> const
-
Thread
SPI immer gleiche Antwort
Ich habe das jetzt mal so abgeändert das ich nach Übertragung CS wieder auf High ziehe: [c] if(rxc) { u8_spi_write_buffer[0] = receive_string[0]; u8_spi_write_buffer[1] = receive_string[1]; PORT_SPI &= ~(1<<DD_SS); SPI_Transmit(receive_string[2],u8_spi_write_buffer
[0] = 0x2c; u8_spi_write_buffer[1] = 0; u8_spi_write_buffer[2] = 0; SPI_Transmit(receive_string[2],u8_spi_write_buffer,3); acceleration_l = u8_spi_read_buffer[1]; acceleration_h = u8_spi_read_buffer
-
Thread
Schrittmotorsteuerung für primitive Astro-Nachführung
Ich werde mir vmtl. den ATmega8 zusammen mit Lochrasterplatine, sämtlichen Bauteilen (LED, R's, C's, Quarz, Spannungsregler,... ) und einem Programmer ordern. https://shop.myavr.de/index.php?sp=shoppingCart.sp.php&ses=I1RGTfCrCwCbyyCiB8CxCc2ChCrnB8CeCfhCmCpoCo0xB3CwaCxCgC8DhCjCaByBtDeC1BaC6DhDbC7B0BoC1tBdtCyDdDdCpg4CpCoikChB3CoB4CtB8ChCsCvdi
[j] = st[i-j-1]; } string[i] = '\0'; free(st); } [/c]
-
Thread
Prog. läuft auf Mega128 aber nicht auf Mega8!
Oje... den Code wollt ihr also sehen... aber nicht wundern, bin blutiger Anfänger ;) [c] // Display an PORTC // MAX6675 an PORTB // Taster an PORTD // Output Relais an PORTD #include <stdint.h> #include <stdlib.h> #include <string.h> #include <avr/io.h> #include <util/delay.h
MENU_DOWN)==1) { intOffset--; } itoa(intOffset, strOffset, 10); lcd_string(strOffset); long_delay(23); break;} } } [/c] Nochmal was im Nachhinein. Ich habe am Schaltausgang parallel zum Relais noch eine LED mit drangehängt. Das würde doch bedeuten
-
Thread
Programm zur Frequenzmessung
man fertige Funktionen itoa() bzw. ltoa(). Dazu braucht man natürlich eine Funktion, die einen String ausgeben kann. Die ist aber kein Problem: [C] void lcd_write_string( char* String ) { while( *String ) lcd_write( *String++ ); } [/C] Damit reduziert sich die auch sofort die Initialisierungssequenz
lcd_write_string( Buffer ); lcd_home(); flanke = 0; lcd_clear(); } } } [/C] Und dann würde ich mal hergehen und würde am µC mal ausprobieren, ob in diff vernünftige Werte rauskommen
-
Thread
atoi erzeugt Überlauf?
Satzes gehen while( *string && *string != '\n' ) string++; string++; *pos_ = string - initFile; } [/C] Ich weiß, am Anfang ist das nicht leicht. Aber du solltest dich schnellstens mit Pointern wenigstens
keine Zahl, sondern erstmal wieder Buchstaben, und die werden laut http://www.cppreference.com/wiki/string/c/atoi ignoriert.
-
Thread
AVR-GCC: Welcher Zeichensatz?
im Beitrag #3250212: > Nicolas S. schrieb im Beitrag #3250197: >> Ganz einfach: >> fprintf("\265C.net"); // geht >> fprintf("\xb5C.net"); // geht nicht. > > > oktal muss mit 0 einfangen! Nein. Ein Octal-Code in einem String ist ein Backslash mit drei Ziffern dahinter. \265 ist völlig korrekt
Stefan Ernst schrieb im Beitrag #3250219: > Nein. Ein Octal-Code in einem String ist ein Backslash mit drei Ziffern > dahinter. \265 ist völlig korrekt. oh stimmt, bei 3 stellen kann man es so schreiben. Aber dann sollte auch hex genauso gehen. > fprintf("\xb5C.net"); /
-
Thread
C char array Manipulation für atoi
schlimmeres, als Code in Prosa zu posten. Ich verstehe nur Bahnhof. Was ist denn so schwer an Ctrl-V, Ctrl-C?
Sicher funktioniert das als Workaround, aber es ist keine saubere Lösung. Würdest du das auch mit Strings machen, die mehrere Megabytes lang werden dürfen? Sicher nicht. Jede Funktion, die Strings verarbeitet, schließt entweder auch das terminierende null Zeichen ein oder liefert die Länge des Strings
-
Thread
cjson und Strings
Pressure_Akt= pressure->valuedouble; Visibility_Akt= visibility->valuedouble; uint16_t position_string=strstr(json_buffer,text); return 0; } [/c] Mit den Zahlen klappts super, jedoch fehlt mir die Erfahrung, wie ich die Texte aus dem JSON lede, wie die "description" etc. Kann mir jemand dies
mit [c] CJSON_PUBLIC(char *) cJSON_GetStringValue(const cJSON * const item) [/c] ? cJSON rein, char* raus. Und für die numerischen Werte gibts auch eine API Funktion: cJSON_GetNumberValue. Direkt in eine
-
Thread
Target mit SWD verbinden - "Vdd from Application" , GND?
HAL_Delay(100); ITM_SendString("LED\n"); } [/c] eingebaut und dann die Funktion ITM_SendString(*str) implementiert. [c] void ITM_SendString(char *str) { while(*str){ ITM_SendChar(*str); str++; } }
Machst du C oder C++? Bei C++ könnte es zwei verschiedene ITM_SendString geben (für const und nicht-const).
-
Thread
[AVR] compiler optimiert strings nicht richtig
> Was muss ich tun, damit der string nur einmal eingebunden wird? Mach eine globale Variable mit dem String: [c] char ERROR_SD_READ[] = "Error SD_read"; : lcd_puts_P( ERROR_SD_READ ); : [/c]
Worin liegt das Problem, den String nur einmal zu definieren, ihn aber mehrmals zu verwenden? [c]char ERROR_SD_READ[] PROGMEM = "Error SD_read"; ... lcd_puts_P( ERROR_SD_READ ); [/c] Und ja, der String ist dann nur einmal im
-
Thread
Alle Leerzeichen aus String entfernen
Am Ende der Routine fehlt noch [c] buff[j] = '\0'; [/c] bzw. [c] string_neu[j] = '\0'; [/c] um den neu erzeugten String abzuschließen. Fragt man das Stringende in der While-Schleife ab, kann man nich den strlen-Aufruf
*p = '\0'; // String mit Nullzeichen abschließen } [/c]
-
Thread
kommunikation zwischen 2 µC-Boards
hi habe follgendes problem - eines von vielen ;) ich habe ein eigenes µC board(atmega8-16pu) entwickelt und will mit diesem einen string an ein anderes µC board(ssc32 board atmega 168-20 Pu) schicken(über den usart). muss ich zwischen den 2 boards synchron oder asynchron
irgendwer von euch kennt. und ich will die positionen statt vom computer(was funktioniert) nun mit meinem µC board schicken. also mein µC board schickt auch den string( wenn ich mit hyperterminal teste kommt der string auch an) so noch eine frage: wenn ich synchron kommuniziere mit was muss ich dann
-
Thread
Kommunikation zwischen 2 MC
< sizeof(buffer)-1){ buffer[index++] = c; } } else{ buffer[index] = '\0'; // Beende den String mit einem Null-Byte index = 0; // Setze den Index zurück für die nächste Nachricht message_received
glaubst. Das wartet nicht nach jedem Zeichen, sondern nur einmal, nach dem kompletten Absenden des Strings "str". Um nach jedem Zeichen zu warten, müsste es so aussehen: [c] void uart_puts(const char *str) { while (*str) { uart_putchar(*str++); // dem Empfänger Zeit zur Verarbeitung
-
Thread
Problem mit UART beim empfangen
bleiben [C] void sendeString( char* text ) { while( *text ) sendenByte( *text++ ); } int main(void) { //UART initialisieren USART_Init(); sendeString( "Reset\n" ); //Interrupts
; return data; } void sendeString( char* text ) { while( *text ) sendenByte( *text++ ); } [/c]
-
Thread
Timerinterrupt und UART
; //Flag zurücksetzen } } } [/c] Die Interrupt Routinen [c] ISR(USART_RXC_vect) { uint8_t nextChar; // Daten aus dem Puffer lesen nextChar = UDR; if( uart_str_complete == 0 ) { // wenn uart_string gerade
] = nextChar; uart_str_count++; } else { uart_string[uart_str_count] = '\0'; uart_str_count = 0; uart_str_complete = 1; } } } ISR (TIMER1_COMPA_vect) { bSekunde=1; } [/c]
-
Thread
Macros ineinandergreifend
byte bereit ist. [c] ;Syntax: string_out_set Rb,Rb .MACRO string_out_set string_out_routine: pop @0 ; Oberes Byte der Adresse des 1. Datenbytes des Strings vom Stack holen mov @1,@0
out SREG,r16 pop r16 cbi UCSRB,UDRIE reti [/c] Die Macros werden dann folgendermaßen eingesetzt: [c] string_out_set r16,r17 loop: string_out r16,string_end .db "Test !",0x0A,0x0D,0 string_end: [/c] Das ganze hat ohne makros so funktioniert
-
Thread
Variable in string Funktion übergeben
); lcd_line2(); //cursor nach links in zeile 2 lcd_string( zeile2 ); } [/c] Noch hat sich nichts verändert. Aber die Dinge ändern sich. Denn um [c] lcd_text("Temperatur",temp); [/c] das hier zu tun, ist die Funktion lcd_text unbrauchbar. Die kann
zu bauen [c] void lcd_wert( const char* label, int wert ) { lcd_line1(); lcd_string( label ); lcd_line2(); lcd_int( wert ); } [/c] und damit kannst du dann im Hauptprogramm das hier machen
-
Thread
crc-Berechnung Codezeile Erklärung
mitgezählt wird 2: sizeof(), welches die Anzahl der Bytes von Argument schon beim Compilieren weis. [c] char variable[100]="Hallo"; [/c] strlen(variable) ist 5, weil der String 5 Zeichen lang ist. Tatsächlich sind 6 Zeichen belegt, wegen der abschließenden Null. sizeof(variable) ist 10, weil das
noch eine Frage: > wenn ich es richtig sehe, wird bei der crc Berechnung in der Funktion > mit String/Char-Array gearbeitet (berichtigt mich bitte wenn ich es > falsch interpretiere) > [c] > crc.setPolynome(0x1021); > crc.add((uint8_t*)str, 9); > Serial.println(crc.getCRC(), HEX); > [\c
-
Thread
vprintf: region rom overflowed by 6932 bytes
will lediglich einen Wrapper bauen für eine printf-Ausgabe. Dazu soll der das Argument fmt mein String sein, und anschließend eben die variablen Argumente. Alles andere Parameter werden "im Hintergrund" bereits eingefügt. Beispiel: [c] #define log_info(...) log_log(LOG_INFO, __FILE__, __LINE
; uart_puts(msg); uart_puts("\r\n"); } log_it("foo.c", "20", "mumble"); log_it("foo.c", "22", "doodle"); [/c] Dein numerisches Argument "Nummer der Zeile in der Datei" wurde also schon durch den Präprozessor in einen String umgewandelt, und alles
-
Thread
ADC mit ATMEGA8535
sprintf (string ,"%04d, ADCH"); SetLine (4 , string); }; } [/c] Wo fragst du den ADC ab?
(4, string); } [/C]
-
Thread
C soll einer verstehen...
folgenden Testcode kann man Zeile a und b (s. unten) variieren und es funzt immernoch. Entweder ist "C" nicht konsequent oder ich sollte lieber die Zeiger ner Uhr betrachten - die versteh ich nämlich. #include <stdio.h> #include "iostream.h" void print_char(char c){ cout<<c; } void print_string(char *c){ while (*c != 0) { /* Variante 1 */ print_char(*c); //Zeile a *c++; //Zeile b } } int main(void){ print_string("Hallo"); return 0; } /* Varinte 2
-
Thread
Codeschnipsel zusammenfassen (Übersichtlichkeit)
( text++ ) ); } } [/C] Diese Funktion holt sich den String direkt aus dem Flash, wobei sie der üblichen C-Konvention folgt, dass der String bei einem '\0' Zeichen endet (was anderes macht strcpy_P auch nicht). Aber: Sie
Zwischenspeicher und kann daher auch keinen Zwischenspeicher überlaufen! Auch benötigt sie die tatsächliche String Länge nicht, ist daher schneller, als wenn vorher mittels strlen_P die Länge festgestellt werden muss. Dein Aufruf [C] strcpy_P ( &au8TempStr[0], AU8TXT_MAIN1 ); lcd4x20_show ( /* u8Line