-
Thread
Frage zu delay (wie bekomme ich genau 1 Sekunde)
(1,10, "setze Ausgaenge......"); // _delay_ms(1500); g_draw_string(1,10, "setze Ausgaenge......ok"); _delay_ms(1500); g_draw_string(1,20, "hole Sensoren.."); // _delay_ms(1500); g_draw_string(1,20, "hole Sensoren...."); // _delay_ms(1500); g_draw_string(1,20, "hole Sensoren....ok"); _delay_ms(1500); g_draw_string(1,30, "starte Menue.."); // _delay_ms(1500); g_draw_string(1,30, "starte Menue...."); // _delay_ms(1500); g_draw_string(1,30, "starte Menue......"); // _delay_ms(1500); g_draw_string
-
Thread
lcd string "ü" darstellen.
braucht man an der verwendenden Stelle überhaupt nichts tun, der 'LCD-String-Treiber' erledigt die Anpassung [C] void lcd_string( const char* text ) { char c; while( ( c = *text++ ) ) { if( c == 'ü' ) lcd_data( 0x5F ); else lcd_data( c )
"); lcd_string( Out ); lcd_string( "Belüftung ist ein" ); [/C]
-
Thread
GSM Modem AT-Befehl
" vom Modem quittiert. "\x0d" ist eine Schreibweise, um das Steuerzeichen 0x0d gleich in den String mit einzupacken. Wenn ich also schreibe unsigned char string[]="ATZ\x0d"; dann enthält "string" insgesamt 5 Zeichen: A,T,Z,das Steuerzeichen 0x0d, und die 0-Terminierung. > ISR(USART_UDRE_vect
eigentlich nciht liegen, ich stecke ab und zu mal wieder den Hyperterminal an im zu sehen was der µC macht, und der schickt fein den String und wenn ich dann Antworte (über Hyperterminal) sehe ich das auch im Programm "glob_USART_gesendet" ist nur ne vari damit der während ich auf die ISR warte kein
-
Thread
Projekt: Pascal-Compiler für AVR Gesperrt
Hi >1) Pascal-to-C converter > Also Pascal-source nach C/C++ konvertieren und dann mit gcc-avr >fertigstellen (lassen). Ich halte Pascal als durchweg gleichwertige Sprache zu C. Also wozu? MfG Spess
Rudolf Grobe schrieb: > 1) Pascal-to-C converter p2c
-
Thread
Suche Software oder Programmierer
Sowas hier, über die serielle Schnittstelle? 3C 49 44 30 30 3E 3C 42 45 3E 30 35 3C 45 3E 3C <ID00><BE>05<E>< 49 44 30 30 3E 3C 4C 31 3E 3C 50 41 3E 3C 46 41 ID00><L1><PA><FA 3E 3C 4D 41 3E 3C 57 43 3E 3C 46 4B 3E 3C 47 47 ><MA><WC><FK><
30 3E 3C 42 45 3E 30 35 3C 45 3E 3C <ID00><BE>05<E>< 49 44 30 30 3E 3C 4C 31 3E 3C 50 4F 3E 3C 46 45 ID00><L1><PO><FE 3E 3C 4D 41 3E 3C 57 41 3E 3C 46 45 3E 48 69 20 ><MA><WA><FE>Hi 48 6F 21 21 21
-
Thread
lcd_write Fehlersuche
habe jetzt auf [c] u8 tst[]="wzb vl rl t0 t1 thm elt az "; lcd_goto(25,1);lcd_write(tst); [/c] geändert. Der im Ram abgelegte String wird korrekt geschrieben. Es ist also kein Problem mit der Funktion
0 ); Das Problem mit dem Leerstring lässt sich leicht lösen, indem man stattdessen schreibt: [c] while ( *str != '\0' ) { .... } [/c] Man sollte beim "Durchwandern" eines C-Strings *immer* eine while- und keine do-while-Schleife nehmen.
-
Thread
Zufallsgenerator Visual Basics
Imports Microsoft.Office.Interop Public Class Form1 Private Structure ExcelRows Dim C1 As String Dim C2 As String Dim C3 As String Dim C4 As String Dim C5 As String Dim C6 As String Dim C7 As String Dim C8 As String
Dim lvitem As ListViewItem lvitem = Me.ListView1.Items.Add(xitem.C1) lvitem.SubItems.AddRange(New String() {xitem.C2, xitem.C3, xitem.C4, xitem.C5, xitem.C6, xitem.C7, xitem.C8, xitem.C9}) Next End If End Sub Private
-
Thread
Hargassner Pelletheizung Betriebsdatenerfassung
nur" die elektrische Steuerung. Wenn ich das richtig gesehen habe ist oben ein 8051 verbaut (TS80C32X2-MCB), und das EPROM ist ein 290F010. Ich habe das ROM gelesen, es gibt wohl 4x32KB Blöcke, der erste Block sind wohl die Daten (Strings usw.), die anderen 3 Blöcke sind wohl der Code. (Evtl. sind
Stringanfang "pm" bei der Auswertung der Daten, sobald auf der UART Schnittstelle Daten empfangen werden. [c]std::string str(bytes.begin(), bytes.end()); if (str.rfind("pm ", 0) == 0) { ... }[/c] Der Rest ist dann eigentlich nur Zuweisung der Werte und Statusbits zu den Variablen und Bereitstellung als
-
Thread
STM32L051 UART transmit
gefunden --> Text wurde vollstaendig ausgegeben { outString = saveString; // Neu: Urspruenglichen Text wiederherstellen USART2->CR1 &= ~USART_CR1_TXEIE; } } }
C) anbietet, wo dann je nach Bedarf ein > String_Out(...) oder ein Long_Out(...) oder ein Float_Out(...) aufsetzen > können. Eben je nachdem, was man tatsächlich braucht. Mit dem Ansatz gehe ich
-
Thread
system_clock::now() liefert UTZ, benötige GMT + 1
tz_private.h und tz.cpp von Howard Hinnant geht es auch out-of-the-box und standardkonform so: [c] #include <ctime> std::string getDate() { time_t t = time(NULL); char buffer[30]; strftime(buffer, sizeof buffer, "%FT%TZ", localtime(&t)); return std::string(buffer); } [/c] Das
in Ordnung. Wenn man aber in einem C++-Programm das Ergebnis > als std::string haben möchte, erscheint mir der Umweg über den C-String > etwas holprig, zumal man bei einer Änderung des Formatstrings evtl. auch > die Größe des Ergebnispuffers
-
Thread
1Wire-Bus SEARCH ROM missverstanden?
Raw-Wert zurückliefern. Diesen rechne ich dann per Integer-Arithmetik in eine Fliesskommazahl um. [c]while (1) { dcount = scan_bus(roms, ONEWIRE_SEARCH_ROM); if (dcount == 255) { uart_string_P(PSTR("Error, no device found!" CR)); uart_string(CR); } else { uart_string_P(PSTR
} Nach = Temp / 1000; // int8_t uart_int(Vor); uart_string_P(PSTR(".")); uart_int(Nach); uart_string_P(PSTR(" °C" CR)); } } } uart_string(CR); } [/c] Das gesamte Programm benötigt 2342 Byte. Es gibt folgendes aus
-
Thread
Problem bei konvertiren eines char[] in einen integer
(usart_string[2] - '0') * 100); recived_time_ticks += ((usart_string[3] - '0') * 10); recived_time_ticks += (usart_string[4] - '0'); [/c] ich habe vom PC aus 72000 an den µC gesendet angekommen is aber: 64640
Verscuhe mal [c]recived_time_ticks += (((uint32_t)usart_string[0] - (uint32_t)'0') * (uint32_t)10000); //1[/c] Cast heißt das Zauberwort
-
Thread
LabView mit µC synchronisieren
Thomas schrieb im Beitrag #2603401: > Der µC misst die Temperaturen und sendet nach Deendigung der Messung > erst das Startbyte und dann die Daten: > put_string(ok); > put_string(daten); Hallo Thomas , vielleicht mal nur so als Test -
, Baud 9600) dauert 1,04 ms. Meine Zeichenkette ist 15 Bytes lang. Es dauert also 15,6 ms bis der µC die Bytes gesendet hat und 15,6 ms bis LV sie gelesen hat, anschließende nach ca. 32 ms wird dann die Antwort gesendet, die der µC lesen soll. Im µC habe ich das so realisiert put_string(daten);
-
Thread
spi string empfangen
Hallo, ich versuche einen String den ich über einen Mega32 sende mit einem mega8 zu einem display zu senden. Leider hab ich absolut keine Ahnung was mein Denkfehler in der Empfangsroutine ist. [c] // sende routine atmega 32 void
Hallo, du willst ins nichts den String zwischen speichern: [C] char* text=""; [/C] Ich würde mir dazu ein Feld definieren: [C] char cBuffer[20+1]; char* text = cBuffer; [/C] Ich habe das so hingeschrieben um dir den Unterschied
-
Thread
c++ new und delete
147: undefined reference to `twi_transmit' Wire.cpp sollte normalerweise die Funktionen aus twi.c benutzen. Ganz am Anfang von Wire.cpp steht: extern "C" { #include <stdlib.h> #include <string.h> #include <inttypes.h> #include "twi.h" } Damit sollte doch eigentlich die Funktionen
der Compilerentwickler eine Idee: [code] //Wire.cpp sollte normalerweise die Funktionen aus twi.c benutzen. Ganz am //Anfang von Wire.cpp steht: extern "C" { #include <stdlib.h> #include <string.h> #include <inttypes.h> #include "twi.h" } [/code] Wenn über das extern "C" ...
-
Thread
Variablen eindeutig benennen damit der Typ eindeutig ist
im Flash abgelegt werden muss. Mit #define wird irgendetwas definiert, ob das ein Ausdruck, String oder schlicht ein Wert ist, ist absolut egal. > Marc V. schrieb: >> So etwas kann man aber mit const nicht machen: >> const uint8_t c_DatBlkLen = 0x3F; // 63 Byt max >> uint8_t DatBlk[c_DatBlkLen
Array schon mal was ganz anderes, zweitens hast du auch hier zumindest bei einer recht prominenten µC-Architektur unrecht: da der AVR für Operationen aus dem Flash andere Befehle braucht als für Operationen aus dem RAM, werden selbst string literals (die schon seit C89 "immutable" waren) dort im RAM
-
Thread
C++ Startadresse: char Array vs int Array
Unnötigerweise erstreckt sich die Überladung dabei gleich über sämtliche char-Pointer-Typen, nämlich [c] char * signed char * unsigned char * const char * const signed char * const unsigned char * [/c] Um C-Strings komfortabel ausgeben zu können, hätten eigentlich char * und const char * genügt
Falls das bis jetzt alles verwirrend klingt und weil der TO von C kommt: In C++ sollte man die richtigen Typen für seine Aufgaben verwenden. Das heisst in diesem Fall std::string anstatt char[]. Das Arbeiten mit einfachen Pointern sollte man sich abgewöhnen, damit
-
Thread
µC+gsm -> Problem
nicht; Hyperterminal übersetzt Steuercodes nicht in Klartext und kann auch nicht zwei Datenkanäle (µC->GSM + GSM->µC) gleichzeitig auslesen.
Schleife länger als der String ist kommt öfters im Quelltext vor.
-
Thread
String zerlegen funktioniert nicht richtig, 2-dimensionales Array
einen Pointer auf die Anfangsadresse des ermittelten Strings zurück. Daher funktioniert das Speichern in meinen 2D-Array nicht. Vielmehr müsste ich manuell mit strncpy arbeiten... In etwa so: [c] void store_nmea (unsigned char nmea_msg_id, char* ptr_source
Mir gehts darum ,dass mit der [c] char* ptr_Datafield[20][/c]-Methode die einzelnen Strings irgendwo im Speicher des µC stehn und evtl. andere Daten überschrieben werden könnten. Oder legt mir strtok bei jedem Aufruf reservierte Speicherbereiche
-
Thread
C# mehrdimensionale Listen in Excel übertragen
private void BtnOpen_Click(object sender, RoutedEventArgs e) { var fileContent = string.Empty; var filePath = string.Empty; OpenFileDialog openFileDialog = new OpenFileDialog(); openFileDialog.InitialDirectory = "c:\\"; openFileDialog.Filter
(XmlNode table in cTables) { // tableType in Variable speichern string tableType = table.Attributes["TableType"].Value;
-
Thread
Kommunikation Labview zu PIC32 via Ethernet
Falls Du vom uP zum Computer einen String übertragen willst, musst Du am uC einen Server starten. Schau einmal in LabVIEW zwei Dateien an: C:\Program Files\National Instruments\LabVIEW 2009\examples\comm\TCP und da Simple Data
gebe ich ein Telnet 169.254.1.1 9760 und es öffnet sich > ein Telnet Fenster. > Hier gebe ich Strings ein und empfange die Echos.. genau. Funktioniert also. > Die Übertragung funktioniert immer noch nicht:( > > Wie verschicke ich denn einen String? > Ich nehme an im GenericTCOServer.c
-
Thread
Powermessung mit INA219
(tempe); //Serial.print(temperature); String C = "*C"; // int buf[318]; int x, x2; int y, y2; int r; // Clear the screen and draw the frame // myGLCD.clrScr(); myGLCD.setColor(255, 0, 0);// oberes Rechteck myGLCD.fillRect
myGLCD.printNumF(temperature[3], 0, 260, 190); myGLCD.setColor(255, 255, 0); //String C="*C"; wurde schon weiter oben erklärt myGLCD.print(C, 60, 190); myGLCD.print(C, 140, 190); myGLCD.print(C, 220, 190); myGLCD.print(C, 300, 190); myGLCD.setColor(255, 255, 0);
-
Thread
Wird diese if-Schleife jemals ausgeführt?
wusste ich nicht. Da kommt dann die Warnung mit dem "=". Es kam auch noch eine Meldung zu [c]char File_Name[15] = "beelogger_Lukas_1.csv";[/c] Die String-Länge sei zu kurz. Reicht es da einfach eine 22 aus der 15 zu machen? Vielen Dank!
Paul-Gerhard S. schrieb im Beitrag #6686484: > Es kam auch noch eine Meldung zu [c] char File_Name[15] = "beelogger_Lukas_1.csv"; [/c] > Die String-Länge sei zu kurz. > > Reicht es da einfach eine 22 aus der 15 zu machen? Wegen dieser Zeilen wohl nicht: [c] File_Name
-
Thread
C++ Klassendeklaration
In dieser C++ Klassendeklaration, was bedeutet das zwischen "class GraphWindow:" und der ersten "{"? Das sind andere Klassen, aus denen die gelisteten virtual Funktionen kommen. Aber "class GraphWindow" ist damit
Lothar schrieb im Beitrag #6587401: > In dieser C++ Klassendeklaration, Es handelt sich um eine Klassendefinition. > was bedeutet das zwischen "class GraphWindow:" und der ersten "{"? Das sind die Basisklassen, von denen GraphWindow abgeleitet
-
Thread
c-Programm - erster Versuch
hallo, ich habe dabei, mich in C etwas einzuarbeiten...echt faszinierend. Hab mir so ein Programm zum Einlesen von GPIOs auf meinem BeagleBoneBlack gesucht. [c] #include <stdio.h> #include <stdlib.h> #include <string.h> #include
the key press event printf ("Code[%d]n", (ev[1].code)); } } return 0; } [/c] Auf dem BBB compiliere ich mit [c] gcc C_Key_test.c -o C_Key_test [/c] Mein Problem ist, dass es mir so vorkommt, dass die Zeile nach "//Open Device.1" nicht ausgeführt wird. Jedenfalls zeigt
-
Thread
ATmega8 und UART => Code bringt Einsteiger zum Verzweifeln
, Null wird. > Wenn ich aber > [c] > putstring("ADCW"); > [/c] > eingebe, wird nicht der ADC-Wert, sondern der String ADCW übertragen. Natürlich. Computer machen nicht, was man will, sondern was man ihnen sagt. Du mußt den integer
, UDRE)); > UDR = data; //data ausgeben > } [/c] IMO OK. [c] > > //sendet einen String über das Uart > void uart_puts(char *s) > { > while (*s != 0) > { > UART_SendByte=*s++; [/c] Mööp. Das kompiliert nicht. So muß das sein
-
Thread
Giesomat 16 Sensoren
Beitrag #6664383: > Habe ich geändert das ich von 1 -16 zähle Nein, jetzt zählst du von 1 bis 15: [c] for (CurrSensor = 1; CurrSensor < 16; CurrSensor++) [/c] Aber deine Funktion SelectSensor benötigt Werte von 0-15: [c] void SelectSensor(byte SensorToSelect) { SensorToSelect--; digitalWrite
SensorToSelect, 0))); digitalWrite(MultiplexPinB, (bitRead(SensorToSelect, 1))); digitalWrite(MultiplexPinC, (bitRead(SensorToSelect, 2))); digitalWrite(MultiplexPinD, (bitRead(SensorToSelect, 3))); } [/c] Und dein Zugriff auf das Array benötigt Werte von 1-16: [c] void AssignToSensor(int SelectedSensor
-
Thread
Funktionsparameter Gesperrt
screenX == 1) { //lcdClear(); xpos = 0; lcdSetPos(xpos,8); lcdString8("Neonröhre 1"); } } [/c] Beim Starten des Programms wird lcdScreen(0) aufgerufen und wie gewünscht die erste if-Anweisung erfolgreich abgearbeitet (und eine Grafik auf das LCD gezeichnet
String-Funktion... [c] void lcdChar8(int c) // c ist hier der jeweilige ASCII-Wert (z.B.: "A">65) des gesendeten Charakters { for(uint8_t nColumn=1; nColumn<=7; nColumn++) { lcdSendData
-
Thread
LCD wird immer aktualisiert
brne lcd_ok_1 ldi r19, 20 rjmp main lcd_ok_1: ldi ZL, LOW(text_ok*2) ; Adresse des Strings in den ldi ZH, HIGH(text_ok*2) ; Z-Pointer laden rcall lcd_flash_string ; Unterprogramm gibt String aus der text_ok: .db "OK",0 ; Ausgabe bei keinen fehler [/avrasm]
Immer noch falsch [C] lcd_ok_ja: ldi r25, 11 ldi ZL, LOW(text_ok*2) ; Adresse des Strings in den ldi ZH, HIGH(text_ok*2) ; Z-Pointer laden rcall lcd_flash_string ; Unterprogramm gibt String aus der rjmp main
-
Thread
GPS String auswerten wiedermal
buffer[StringLen] = NextChar; StringLen++; } NextChar = getch1(); } while( NextChar != '\n' ); buffer[StringLen] = '\0'; } [/C]
Warum hast du hier [C] void StringHolen(void) [/C] die Argmuente entfernt, die da ursprünglich mal waren? [C] void getstr1( char* Buffer, uint8_t MaxLen ) { [/C] Du arbeitest im Moment in die genaue Gegenrichtung
-
Thread
Umsetzung: String in Befehl
ATmega2561, der über die serielle Schnittstelle mit mein PC Interruptgetriggert kommmuniziert. Gibt es in C irgendeine Möglichkeit wie man einen String, z.B. "SetPortA(0xaf);" in einen direkten Befehl an den Mikrocontroller umwandeln kann. Bisher ist mir nur eingefallen beim Empfang eines Strings, diesen
@Hans So ungefähr habe ich das gemeint. Der Unterschied ist nur, dass der String(also der Befehl), den ich an den µC sende, genau so aussehen soll, wie die auszuführende Funktion im µC, z.B. SetPort(A, 0xF3); Aber du hast wohl Recht. Ich werde vermutlich decodieren müssen
-
Thread
Serielle Verarbeitung von Strings mit Python
, ich arbeite gerade an einer Kombination aus Pythonskript und Mikrocontrollerprogrammierung in C bei der ich einen ARM Cortex-M3 vom Typ ADuCM301 über UART ansteuern möchte. In diesem Skript soll erstmal ein String, später mehrere Strings, seriell an den µC gesendet werden. Hierzu verwende ich
wichtigste erst mal hier nachlesen: [[String-Verarbeitung in C]]
-
Thread
Parsing expression grammar mit peglib
Unicode" im wxWidgets, bzw gibt es da noch ein paar Fallstricke. Das Problem war versteckt in: [c] const auto db = parser.parse(LoadFile(filename).ToStdString()); [/c] ToStdString() konvertiert in das Systemspezifische Format. Damit parser.parse() richtig funktioniert muss es aber mit UTF8 gefüttert werden. Der saubere Weg ist nun den wxString vor dem ToStdString in UTF8 zu Konvertieren (wxString basiert auf 32bit bzw UTF32): [c] wxString tmCanDatabaseFile::LoadFile(const wxString& filename) { wxString str; do {
-
Thread
DS1307 Lib für Fleury's I2C
); i2c_write(SQW_CONTROL_REG); i2c_write(_BV(SQW_SQWE) | SQW_RS1_RS0_1Hz); } i2c_stop(); return true; } void set_time_string(char *time_str2) { /* Function will use a formatted
Convert year to ASCII strncat (date_str2,date_str1,2); // Append year string to output string return date_str2; // Return output string } #endif /* _ds1307_H_ */ [/c]
-
Thread
AVR-GCC 4.8.1: unrecognizable insn
abbricht. Zurückführen konnte ich alles auf die folgende Zeile (von deren Typ es mehrere gibt): [c] snprintf_P(glstr_Buf,N_TEXTBUF,menudata[item].menutext,\ *menudata[item].puint8); [/c] Nicht zum Fehler führt die folgende Abwandlung mit einem konstanten String im Flash: [c] snprintf_P
is a GCC extension [enabled by default] #warning "GCC 4.8.1 needs workaround for flash strings" ^ C:\Users\Nicolas\Desktop\SVN\2015_Rotorsteuerung\Firmware_AVR\Pulsgenerator04\common\src_menu\menu.c(177,6): warning: #warning "GCC 4.8.1 needs workaround for flash strings" [-Wcpp]
-
Thread
String zu Integer (Wer findet den Fehler?)
Karl heinz Buchegger wrote: [C] if( *string == '-' ) is_neg = 1; [/C] -> [C] if( *string == '-' ) { is_neg = 1; string++; } [/C]
Stefan Ernst wrote: > Karl heinz Buchegger wrote: > [C] > if( *string == '-' ) > is_neg = 1; > [/C] > > -> > > > [C] > if( *string == '-' ) { > is_neg = 1; > string++; > } > [/C] und wieder mal die alte Weisheit
-
Thread
AtMega ehwiges Fuse Thema 16 Mhz Quarz
*progmem_s ) { register char c; while ( (c = pgm_read_byte(progmem_s++)) ) uart_putc(c); }/* uart_puts_p */ /* * these functions are only for ATmegas with two USART */ #if defined( ATMEGA_USART1 )
char *progmem_s ) { register char c; while ( (c = pgm_read_byte(progmem_s++)) ) uart1_putc(c); }/* uart1_puts_p */ #endif [/code] [code] #ifndef UART_H #define UART_H /*******************************
-
Thread
Registernamen/Variablennamen erstellen
bleibt dir da nur übrig, diese in Abhängigkeit des übergebenen Namens zuzuweisen. Dazu kommt: [c] char* test = "DDR"; char* append = port[4]; volatile char* data_direction = strcat(test,append); [/c] ist ein klassischer Fehler bei der String-Behandlung. Wie schreibt wikipedia so schön:
>Heißt das, dass ich jetzt abfragen einbauen muss? Nein. [c] if (*port == PORTD) DDR = &DDRD; [/c] Ich habe Dir doch auch geschrieben, das ein String nichts unmittelbar mit der Identifikation, zu der hier eine numerische Konstante dient, zu tun hat
-
Thread
ATMega644 UART
Beitrag #4514886: > muss ich die Baudrate neu berechnen? Nein. Aber diese Einstellungen: [c] UCSR0B = (1<<RXEN0)|(1<<TXEN0); [/c] werden in UCSR0A gemacht.
// ADC_Init(); ADCWert = 123; while(1) { //ADCWert = ADC_Read(4); sprintf(String,"Test: %i\n", ADCWert); uart_puts(String); //USART_Transmit(S); _delay_ms(1000); } } [/c] Wenn dann was kommt stimmt mit deinem ADC Teil was nicht
-
Thread
String Array "indexieren" wie geht das?
Spannungsteiler schrieb im Beitrag #4719510: > String Worte[5][10] = {"Uhr","Bot","Traktor","Haus","Zange" }; ich kenne jetzt Arduino nicht, aber du willst bestimmt nicht 50 Strings haben. [c] String Worte[5] = {"Uhr","Bot","Traktor","Haus","Zange
die string-Schreibweise nimmst. [c] String Worte[5] = {"Uhr","Bot","Traktor","Haus","Zange" }; [/c]
-
Thread
Programmoptimierung
DDRB, temp1 ldi temp1, 0xFF out DDRD, temp1 ;Vorbelegung auf Multi Kanal 0 -> String bei Temperatursenden ldi multinr, '0' ; Beginn des Strings ; Baudrate einstellen ldi temp1, HIGH(UBRR_VAL) out UBRRH, temp1 ldi
nicht mehr ??????? warum verläßt er mich, er war doch noch so jung????? --> das war der befehl: C:\WinAVR-20100110\bin\avrdude.exe -C C:\WinAVR-20100110\bin\avrdude.conf -p m8 -P lpt1 -c alex -u -U hfuse:w:0xD9:m -U lfuse:w:0xE7:m hier der Programmer im Conf: programmer id = "alex";
-
Thread
Entprellung nach Peter Dannegger funktioniert nicht wie sie soll?!
PORTA // #define LED0 0 // #define LED1 1 // #define LED2 2 [/c] taster.c [c] #include <stdint.h> #include <avr/io.h> #include <avr/interrupt.h> #include "taster.h" #include "delay.h" rest wie im Beispiel [/c] [c] [/c] in der main.c [c] #include
( 0, 0 ); if( KEY_PIN & (1<<KEY0) ) lcd_string( "Pin auf >> 1 <<" ); else lcd_string( "Pin auf >> 0 <<" ); } return 0; } [/C] Ist die Anzeige wie erwartet? Normal steht [code] Pin auf >> 1 << [/code] auf dem LCD.
-
Thread
i²c kein ACK vom SLAVE
modifizierten i2c_start() [c] TWCR = (1 << TWEN) | (1 << TWINT) | (1 << TWSTA); // send start condition i2c_wait_flag_to_be_set(); // wait until transmission completed if(i2c_check_status_register(0x08
(); char buf[8]; itoa(TWDR, buf, 10); lcd_string(buf); lcd_string(": "); itoa(TWSR & 0xF8, buf, 10); lcd_string(buf); _delay_ms(500); lcd_clear(); [/c] Mein LCD zeigt mir nun bei dem TWDR-Inhalt von "0x80" ein "0x18" (aus
-
Thread
Programm zum Setzen von einzelnen Bits in C
Holzweg. Der Punkt hat auch bei den Inte- gerformaten eine Bedeutung. Welche, das verrät jedes bessere C-Buch ;-)
digits for g and G conversions, or the maximum number of characters to be printed from a string for s and S conversions. [/pre]
-
Thread
Bascom Variablen
Ich mach das gerne durch Overlay. Da kann ich als Byte einlesen und hab am Schluss einfach nen String, oder umgekehrt. Also z.B. so. [code] Dim Eeprom_data As String * 9 ' Daten als String Dim Eeprom_data_array(9) As Byte At Eeprom_data Overlay ' Daten als Array Eeprom_data
des unteren Bytes. Mit 3 Byte geht das natürlich nicht. Irgendwie vermisse ich auch "$lib "i2c_twi.lbx", sonst geht I2C eigentlich nicht per Bascom. Da Du ja wohl Ambitionen hast: Mach bitte viel kleinere Schritte und verstehe jeden Schritt. µC ist nicht wie PC "hab rumprobiert und so geht
-
Thread
UART Problem mit Fleury Lib
[c] /* * Transmit string from program memory to UART */ uart_puts_P(PSTR ("String stored in FLASH\n")); [/c] ^^^^^^ ^ Gruß Carsten
Zwischenzeit kannst du hier mal die absoluten Grundlagen über Strings in C nachlesen. Das ist allerdings kein Ersatz für ein C-Buch! http://www.mikrocontroller.net/articles/FAQ#Wie_funktioniert_String-Verarbeitung_in_C.3F
-
Thread
STM32L152C-Discovery debuggen
Hallo Entwickler, ich bin ein STM32-Beginner und habe das Board STM32L152C-Discovery-Board, einen ST-LINK-V2-Adapter und Debian (Linux) als Betriebssystem auf meinem Rechner installiert. Als IDE benutze ich STM32CubeIDE. Ich habe damit mein erstes Projekt mit der automatisierten
mehrfach probiert habe). Im Anhang sind Bilder. Ich habe auch mal den GBD-Server zum Debuggen von C/C++-Projekten probiert, jedoch bekomme ich da den Fehler, daß kein Board erkannt werden konnte, weil Timeout erfolgte. Mittlerweile habe ich alle möglichen Debugger und Einstellungen/Konfigurationen
-
Thread
Attiny 4313 zu 'klein'
zu 70% verwendet. Die Fehlermeldung, dass das RAM nicht reicht, kommt wenn ich die gewünschten Strings deklariere. Heisst: erstmal alles was nicht sein muss rauslöschen und dann schauen wie das mit Mehrfachverwendung einiger/weniger String's gehen könnte. Kurt
, ich bin nur mit C auf den AVRs unterwegs.
-
Thread
Rückgabewert von Funktion ausgeben
http://www.mikrocontroller.net/articles/String-Verarbeitung_in_C#wie_schreibt_man_eine_Funktion.2C_die_einen_String_liefert.3F
sich sowieso besser an den bereits weiter oben verlinkten http://www.mikrocontroller.net/articles/String-Verarbeitung_in_C#wie_schreibt_man_eine_Funktion.2C_die_einen_String_liefert.3F halten, als an ein Codebeispiel eines 'C++ - Programmierers', dem nicht klar ist, was an char line[]; das Problem
-
Thread
Uart String empfangen Interrupt
) != '\0') { rec[j++] = n_char; tx_char(p, n_char); } rec[j] = '\0' ; tx_string(p, rec); } /**************************/ void UART2_IRQHandler( void ) { (void)UART2_S1; rx_echo_string( UART2 ); } [/c] Gruß Marco
Zeichen abholen */ extern void V24TxDone (void); /* warten bis Sendepuffer geleert ist */ [/c] Und auf diesem Interface dürfen dann alle anderen Funktionen aufbauen, also Senden von Strings oder Ausgabe von Zahlen im Klartext und so weiter. Der Interrupt dient IMMER nur zum Bedienen der Hardware