// Same function as printf() but the format string resides in flash // printf_P(PSTR("Type text in TX window, then press ENTER\r\n")); while(scanf("%s",s) == 0); // Get text printf_P(PSTR("\r\nYou entered '%s'\r\n"),s); } }
/ UTC +1h conv_time(timestamp, ¤t_time); // in struct time umrechnen printf_P(PSTR("NTP: Time is %02d.%02d.%04d %02d:%02d:%02d Day=%d\r\n"), current_time.day, current_time.month, current_time.year, current_time.hour, current_time.minute,
unuebersichtlich ist. Viel lieber waere mir sowas in der Art: [c] struct foo PROGMEM mystruct = { 42, PSTR("foobar") }; [/c] Leider funktioniert das PSTR-Makro nicht bei Initialisierungen. Hat jemand eine Idee?
kann mir jemand erläutern wo die Vor und Nachteile dieser Varianten liegen. [c] sprintf_P(temp,PSTR("%d"),value); sprintf(temp,"%d",value); [/c] Ich weiß daß die erste Variante die Daten in den Programm-Flash legt. Und man spart RAM. Ist daher die erste Variante uneingeschränkt besser?
sprintf() nicht viel interessieren... Außerdem werden (hatten wir neulich gerade) mehrere gleiche PSTR- Literale nicht automatisch zu einem zusammengefasst, wenn man also 5x den gleichen Formatstring hat, den aber nicht in einer eigenen separaten Variablen (eigentlich natürlich Konstanten) verwaltet
buffer, 5); // Daten abholen if (!(TWI_LastTransOK())) // dieser Test kann auch entfallen { puts_p(PSTR("TWI-Read-Error")); put_c(13); return; } if (buffer[1] & 0b11000000) // Bit.7/6 des ersten Datenbytes testen, { // wenn gesetzt, dann ist der Sensor noch busy i--; put_c('+'); put_c(' '); // wenn diese
jemand so etwas schon mal gehabt oder eine idee?????????? Relais einschalten: ... STR1A=1; //PSTR1CON Register RELAIS_K1=1; //RC2 ... Relais ausschalten: ... STR1A=1; //PSTR1CON Register RELAIS_K1=1; //RC2 ...
Aufruf aus der main.c [c] lcd_init(); lcd_clear(); sei(); set_cursor(0,1); lcd_string_P( PSTR("Wetterstation") ); [/c]
Und ich habe auch noch Probleme mit Deiner Problembeschreibung. Der Aufruf von "lcd_string_P( PSTR("Wetterstation") );" funktioniert völlig einwandfrei. Die Funktion "void lcd_string_P( PGM_P data )" läßt sich einwandfrei kompilieren, auch mit neuen Compilerversionen. In dieser Funktion ist ein
ks0108ReadFontData, BLACK); // Set a position ks0108GotoXY(20,7); // Print some text ks0108Puts_P(PSTR("PV-Controller")); ks0108GotoXY(29,27); ks0108Puts_P(PSTR("Version 1.0")); // a nice little round rect ks0108DrawRoundRect(5, 4, 117, 37, 8, BLACK); ks0108SelectFont(Corsiva_12, ks0108ReadFontData, BLACK); ks0108GotoXY(1,48); ks0108Puts_P(PSTR("programmed by kumschier")); //ganze Breite des Bildschirms 23 Zeichen backlight_on; _delay_ms(5000); ks0108ClearScreen(); ks0108PutChar(a);//------------------geht nicht while(1) { } //Ende Endlosschleife
verwendet wird. In meinem main habe ich folgendes: [c] if (strncmp_P((const char*) uart_rx_buf, PSTR("meas_bg\n"), 8) == 0) { get_adc_val(30); printf_P(PSTR("BG = %d\n"), get_adc_val(30)); } [/c] Laut datasheet sollte kanal 30 ja die interne BG Spannung von 1,1 V sein (Seite 288)...
- BAS ? Return PSBAS Status PSBAS ?<CR> ○ ○ ○ ○ ○ ○ TRE UP TREBLE UP/DOWN , direct change to **dB PSTRE UP<CR> PSTRE 50<CR> ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ TRE DOWN **:00 to 99 by ASCII , 50=0dB PSTRE DOWN<CR> PSTRE 50<CR> TRE ** ---AVR can be operated from -6 to +6(44 to 56) PSTRE 50<CR> <- ○ ○ ○ ○ ○ ○ TRE
RAM. Und die bei AVR bekannten Methoden, die das Kopieren verhindern, entfallen ebenfalls: PROGMEM, PSTR, und die ganzen "_P" Funktionen wie printf_P().
des C-Compilers und dessen Library. Der tut es > halt, sofern du nicht ausdrücklich PROGMEM oder PSTR benutzt. Oh Entschuldigung. Diese Einschränkung des C-Programmierens war mir nicht bewusst. Kannte ich als ein Asm-Programmierer mit allen Freiheiten noch nicht :)
das Warten auf das Busyflag vor dem Senden der Startbedingung ausgelagert wurde. "printf_P" und "PSTR" sind nur definiert, um Kompatibilität mit einem AVR zu behalten und sind definiert als: [c] #define PSTR(a) (a) #define printf_P printf [/c]. Die Funktion key_getstroke() wartet auf einen Tastendruck
meine_variable_ist_schoen Ersteres mit der ungarischen Konvention gepaart kann dann so aussehen: [c] pstrMeineVariableIstSchoen = "Bla"; dwMeineVariableIstSchoen = 0xFFEEDDCC; iMeineVariableIstSchoen = 6; dblMeineVariableIstSchoen = 12.34E4; [/c] Wie gesagt, das liegt im Auge des Betrachters.
Rufus Τ. F. schrieb im Beitrag #5679872: > pstrMeineVariableIstSchoen = "Bla"; > dwMeineVariableIstSchoen = 0xFFEEDDCC; > iMeineVariableIstSchoen = 6; > dblMeineVariableIstSchoen = 12.34E4; Schöne Beispiel :) Meine Erfahrungen: Falls Konventionen
// use uppercase in hex and use 0X base prefix cout << uppercase << showbase << endl; // pstr stores strings in flash to save RAM cout << F("SdFat version: ") << SD_FAT_VERSION << endl; if (DISABLE_CHIP_SELECT < 0) { cout << F( "\nAssuming the SD is the only SPI device
----- void loop() { // read any existing Serial data while (Serial.read() >= 0) {} // pstr stores strings in flash to save RAM cout << F("\ntype any character to start\n"); while (Serial.read() <= 0) {} delay(400); // catch Due reset problem uint32_t t = millis(); // initialize
ja schon exakt von dem physikalischen Wirkungsgrad und nichts anderem. Und ja, natürlich ist Pel - Pstr = PHeiz, wobei Pstr = Pel* η ist. Und η = L/LER, mit L der Lichtausbeute in lm/W.
value .endmacro .macro pmsg ;print message at @0 using z ldi zl,low(@0<<1) ldi zh,high(@0<<1) rcall pstr .endmacro .macro outw ;output word @1 to @0 using z ldi zl,low(@1) ldi zh,high(@1) out @0h,zh ;word order high first out @0l,zl .endmacro ; reset and interrupt vectors ; jmp reset ; Reset handler jmp
die Tonne. Wenn man nicht einmal die Speicherzugriffe richtig im Griff hat. Ich sage nur printf_P(PSTR... und dieser ganze Schwachsinn. Ich war irgendwann davon so genervt dass ich Geld in die Hand genommen habe und mir eine IAR Workbench gekauft habe. Damit bin ich voll und ganz zufrieden.
Tonne. Wenn man nicht einmal die Speicherzugriffe richtig im > Griff hat. Ich sage nur printf_P(PSTR... und dieser ganze Schwachsinn. Das ist natürlich kompletter Schwachsinn. Das liegt nicht am gcc, sondern an der für C-Programmierung ungeeigneten Harvard-Architektur der AVRs. Wenn IAR das verbirgt
