-
Thread
LCD Userinterface
Diese vielen konstanten String brauchen so doppelt Speicher, im Flash und im RAM. Mit der Funktion PSTR() un eine kleine Anpassung von lcd_puts() kann man die konstanten Strings in den Flash verschieben, siehe Doku der libc zum Themas sprintf(). > lcd_gotoxy(0,1); > lcd_puts(">"); >
Diese vielen konstanten String brauchen so doppelt Speicher, im Flash > und im RAM. Mit der Funktion PSTR() un eine kleine Anpassung von > lcd_puts() kann man die konstanten Strings in den Flash verschieben, > siehe Doku der libc zum Themas sprintf(). Stimmt, daran hatte ich garnicht gedacht. Danke
-
Thread
Array mit printf_P als Hexzahlen ausgeben
f16_open(EIBlogStatus.log_datei,"a"); if (logfile) { f16_printf_P(logfile,PSTR("%2i.%2i.%2i;%2i:%2i:%2i;"), TM_DD, TM_MM, TM_YY, TM_hh, TM_mm, TM_ss, Telegramm); for(i=0;i<Length_save+8;i++) f16_printf_P(logfile,PSTR("%x;"),Telegramm[i]); f16_printf_P(logfile,PSTR("\r\n")); f16_close(logfile); } } } [/c]
-
Thread
stringkonstanten aus dem rom lesen
Was du suchst, ist dieses: [c]uart_puts(PSTR("blabla"));[/c] Aber weder diese Kurzform, noch deine lange Version, werden funktionieren, wenn uart_puts einen "normalen" String erwartet (also einen, der im RAM steht).
-
Thread
Stackproblem ATMEGA128 und GCC
// hier die EIGENTLICHE Funktion, ist aber auskommentiert sprintf_P(cString,PSTR("\n%d Zeichen gelesen"),uiCounter); LCD240_PutString (cString); sn=SP; // Stackpointer nachher merken sprintf_P (cString,PSTR("\nStackDiff: %d Byte"),sn-sv
wieder reinnehmen sn=SP; // Stackpointer nachher merken sprintf_P(cString,PSTR("\n%d Zeichen gelesen"),uiCounter); LCD240_PutString (cString); sprintf_P (cString,PSTR("\nStackDiff: %d Byte"),sn-sv); LCD240_PutString (cString); } break
-
Thread
RX Complete Interrupt wird nicht ausgelöst
void usart_write_P (const char *Buffer,...); #define usart_write(format, args...) usart_write_P(PSTR(format) , ## args) //---------------------------------------------------------------------------- #endif //_UART_H [/c]
-
Thread
uart problem aufm atmega32
implementiert hab laeufts auch mit 18 MHz. uart_puts_P [c] #define uart_puts_P(__s) uart_puts_p(PSTR(__s)) [/c] Wie gesagt im Endeffeckt hab ich nur von Peter Fleury[1] die uart-lib um die ganzen anderen Controller erleichtert. Bei ihm steht nicht drin das man erst nen char im PROGMEM anlegen muss
-
Thread
va_list an vsprintf() weiterreichen
0' == c) return; if ('%' == c) { ... } void put_PSTR (const char * fmt, ...) { va_list vlist; va_start (vlist, fmt); put_va (fmt, vlist); va_end (vlist); } [/c] Die Format-String muss im Flash liegen. Um nicht jedesmal PSTR
c] #include <avr/pgmspace.h> // mind the blank before the colon! #define put_P(y,z...) put_PSTR (PSTR(y) , ##z) extern void put_PSTR (const char *, ...); [/c]
-
Thread
AVR für wenig Geld im LAN
weiterzuverfolgen. Suche mal nach: char* nPos=strstr_P((char*)ð_buffer[TCP_DATA_START], PSTR("IMES=")); Anbei die Korrekturen für das 1-Wire-Problem Grüße RoBue
weiterzuverfolgen. > > Suche mal nach: > char* nPos=strstr_P((char*)ð_buffer[TCP_DATA_START], > PSTR("IMES=")); Hi RoBue und dann weiter? In etwa so: [c] char* nPos=strstr_P((char*)ð_buffer[TCP_DATA_START], PSTR("SWC0=")); [/c] Wobei SWC0 der Name des Formular-Feldes ist? Gruß Christian
-
Thread
Blutzucker-Messgerät Hardware OLED Display
das PROGMEM void printstr_P(PGM_P s) { // gib den Text aus } printstr_P(s); printstr_P(PSTR("Hallo")); [/c] Man muß also die Parameterübergabe an die print-Funktionen anders machen und in den Funktionen auch anders auf die Strings zugreifen. Da ja bei den kleinen Display nicht soviele
-
Thread
SRAM voll, RAM fast leer, printf und Array
Debug-Strings müssen nicht ins RAM. Mit printf_P(PSTR("Hallo")); landen sie nur im ROM. Und mit [c] #if DEBUG #include <stdio.h> #define PRINTF(s, ...) do{ static char __s[] PROGMEM = (s); \ printf_P(__s, ## __VA_ARGS__); }while(0
verwende ich immer folgendes Macro: [c] #ifdef DEBUG #define DbgPrintf(format, ...) printf_P(PSTR(format), ##__VA_ARGS__) #else #define DbgPrintf(format, ...) #endif [/c]
-
Thread
Hilfe zu DS18S20
LCD die Texte aus, kannst Du erstmal auskommentieren: [c] #if 1 # define TRACE(x) Trace_LCD_P(PSTR(x)) #else # define TRACE(x) #endif [/c] gruß, jetzt geht es an die Daten...
-
Thread
GLCD Routinen ( KS0108, HD61202 )
Wert oder unsigned char direkt auf dem display schreiben lassen. Beispiel: lcd_puts_p(small_font,PSTR("1")); schreibt eine 1 auf dem Display. Wie mache ich das, wenn ich jetzt eine unsigned char Variable habe, die den Wert 0x01 -0xff hat um das dynamisch auszugeben? vielen Dank für eure Hilfe,
-
Thread
Linux Uart AVR
"); [/c] oder bessere Lösung (verbraucht weniger Ram, da Konstante im Flash) [c] uart_puts_P(PSTR("Hallo Linux\n")); [/c] (Weitere Infos stehen irgendwo im Tutorial zu Konstanten im Flash) 2. Fehlerquelle: Sind die Fuses richtig gesetzt? Falls du da noch nix dran geändert hast, stehen die
pfleury__uart.html#ga18 stimmt, hier ist "uart_puts_P(...)" (großes P) ein Makro das "uart_puts_p(PSTR(...))" (kleines p) ausführt und hier ist dann auch das von mir erwähnte PSTR drin. übrigens mit lsof -n | grep tty sieht man schnell, welche Prozesse ein tty geöffnet haben Gruß Roland
-
Thread
gets problem
(zeittemp[4]-'0'); sek=(zeittemp[6]-'0')*10+(zeittemp[7]-'0'); sek--; sprintf_P(zeittemp,PSTR("%2i:%2i:%2i"),h,min,sek); myprintf("%s",zeittemp); myprintf("\n\n"); } [/c] zeittemp ist 19 Byte groß. Epmpfang ist auch aktiviert: #define UART0_CONFIGURE1 UCSRB= (1<<RXCIE
-
Thread
sprintf_P & PSTR
mehreren Beispielprogrammen habe ich folgendes Konstrukt gefunden: [c]sprintf_P( tctpbuffer , PSTR("Testnachricht"));[/c] Was genau macht die Funktion sprintf_P und wofür ist die Funktion PSTR? Habe schon ein wenig gegoogled aber leider bin ich nicht recht fündig geworden... Vielen Dank
Den Speicher im Flash brauchts beide Male, nur das RAM wird durch den Progmem-Kram (..._P und PSTR) nicht so sehr belastet.
-
Thread
Datum & Zeit (GCC, AVR)
p.s.: [c]PGM_P s = PSTR(__DATE__);[/c]
-
Thread
Ulrich Radigs LCD Ansteuerung
die Funktion einen String im Flash erwartet. Deiner liegt aber im RAM. Du kannst den String mit PSTR ins Flash verfrachten, also z.B. so: PSTR("Hallo") http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Vereinfachung_f.C3.BCr_Zeichenketten_.28Strings.29_im_Flash
was ich genau ändern müsste? Ich dachte eigentlich, das hätte ich bereits. lcd_print_P(0,0,PSTR("Time: %2i:%2i:%2i"),hh,mm,ss);
-
Thread
Variablenausgabe auf GLCD
schon probiert: ks0108Init(); ks0108GotoXY(0,4); fdevopen(ks0108PutChar,Null, 0); printf_P(PSTR("Variable: %d"), z); habe ich hier ausm forum aber er meckert an den 3 parametern rum und will nur 2 haben.
-
Thread
Menüstruktur mit Text im Atmel
kann ich diese Strings in den Flash bringen? Für Strings gibt es ein Makro: [c] usb_puts_P(PSTR("Menu active"))); [/c] Das PSTR sorgt automatisch dafür, dass der String dahinter im Flash abgelegt wird, ABER ACHTUNG: die Funktion usb_puts kannst du dann nicht mehr wie sie jetzt ist verwenden
Ich habe mal mit dem PSTR experimentiert. Wenn ich das vor eine Variable schreibe, dann verringert sich der "Data" Bereich bei Memory Usage. Also Data bezeichnet den RAM, richtig? D.h. dass die Variable nun nur noch im Flash
-
Thread
zu wenig RAM ?
#include <avr/pgmspace.h> Statt sprintf() nimmst du dann sprintf_P() sprintf_P(zeit,PSTR("%2i.%2i.%2i %2i:%2i:%2i\t"),y,m,d,h,min,sek); Texte dann mit PSTR("text") umgeben.
-
Thread
Progmem Funktionen
return strcpy_P((char *)str_FtoR,str); } [/c] weg? aufruf der funktion: [c] strings(PSTR("blabla")); [/c]
-
Thread
Zwei gleiche Codeschnipsel = volkommen verschiedene Ergebnisse
Vollständigkeit halber hier noch den Sollbyte-Manipulator [c] else if (strncmp_P(auswertstring,PSTR("east"),4)==0) {volatile extern unsigned char motorsollbyte; setbit(motorsollbyte,0); clearbit(motorsollbyte,1); ausgabefehler = 0;} else if (strncmp_P(auswertstring,PSTR("west"),4)==0) {volatile
motorsollbyte,1); clearbit(motorsollbyte,0); ausgabefehler = 0;} else if (strncmp_P(auswertstring,PSTR("stop"),4)==0) {volatile extern unsigned char motorsollbyte; motorsollbyte = 0x00; ausgabefehler = 0;} else if (strncmp_P(auswertstring,PSTR("up"),2)==0) {volatile extern unsigned char motorsollbyte
-
Thread
Stackbelastung durch printf()
Probier mal sprintf_P (cString,PSTR("init Bluetooth")); Da kann man oft ne Menge RAM mit freischaufeln.
-
Thread
AVR - USART RX via Interrupt, funktioniert nicht
{ intflags.rx_int = 0; switch (rxbuff) { case 'h': printstr_p(PSTR("\nHelp Please help me Please")); break; } } } }
-
Thread
Grafikfähiger LCD Controller für 320x240 LCD mit 4 Graustufen
); lcd_block(180,40,219,75,128,128); lcd_block(200,20,239,50,255,255); lcd_string(10,120,PSTR("320x240 LCD Controller"),255,0); lcd_string(15,140,PSTR("\xB8"" by Benedikt"),255,0); wdt_enable(WDTO_250MS); ENABLE_VLCD=1; }
-
Thread
Seltsames Verhalten von USB-Seriell-Adaptern
in main(): stdout = stderr = &uart1_str; // standard output to UART1 printf_P (PSTR("*** Klapptriebwerks-Controller Version 0.0 ***\r\n")); [/c] Gruß, Peter
-
Thread
Kompilieren in Abhängigkeit vom Target-System
unterschiedlich deklarierst. So ala #ifdef PC #define usart_write(format, args) usart_write_PC(PSTR(format) , ## args) #eldeif #define usart_write(format, args) usart_write_UC(PSTR(format) , ## args) #endif Damit brauchst du keine ifdef Orgie im code machen...
verstanden, dann kommt eine Funktionmit zwei Parametern, diese wird im Code ersetzt durch usart_write_PC(PSTR(format) , ##args), aber was machen die ##?
-
Thread
PSTR - Problem
date",4)==0) { ... } funktioniert problemlos aber wenn man es ändert zu if(strncmp(command,PSTR("time"),4)==0) { ... } else if(strncmp(command,PSTR("date"),4)==0) { ... } wird es zwar anstandslos kompiliert, jedoch funktioniert der Vergleich nicht mehr, es wird immer nur die Zeit verändert
Nein, nur die AVR-LibC Doku nicht gelesen. Überall ein _P dranhängen... strncmp_P(command,PSTR("date"),4);
-
Thread
Kann keine datei auf sd card estellen
); if(!partition) { uart_puts_p(PSTR("opening partition failed\n")); return(0); } else { uart_puts_p(PSTR("opening partition OK\n")); } } struct fat16_fs_struct* fs = fat16_open(partition); if(!fs) { uart_puts_p(PSTR("opening filesystem failed\n")); } else { uart_puts_p(PSTR("opening filesystem OK\n")); } /* open root directory */ struct fat16_dir_entry_struct directory;
-
Thread
einzelne Zeichen aus String auslesen in C
; Dann diese Funktion implementieren: void lcdPutString( char * dat ) { char * pStr; pStr = dat; for(;*pStr!=0;pStr++) { lcdPutchar( *pStr ); } } Und rufe dann auf: lcdPutString( beispielArray ); Sollte eigentlich Funktionieren ;-) Alternativ, kann man auch ohne
-
Thread
Ist mein Ram bereits voll?
am Programm >möglich sein So groß ist der Aufwand für die Strings doch gar nicht. Überall ein PSTR mit den zugehörigen Klammern eingefügt, dazu per replace die entsprechenden Funktionen durch ihre _P-Version ersetzt. Ist halt mal eine Stunde Fleißarbeit. Was ich nicht nachvollziehen kann, ist,
-
Thread
Riesige Änderungen zwischen WinAVR 030913 und der aktuellen Version? Gesperrt
einer 2007er und einer 2008er Version nicht mehr funktioniert. Bei der 2007er habe ich zB. keine PSTR verwenden können. Da wurde wild im Speicher herumgelesen. Bei der 2008er funktionieren die PSTR zwar wieder, aber dafür habe ich das Problem auf ungerade Adressen im EEProm zuzugreifen. Heute Mittag
durcheinander geht, aber prinzipiell funktioniert der Code. >Bei der 2007er habe ich zB. keine PSTR >verwenden können. Da wurde wild im Speicher herumgelesen. Gibt es dafür auch ein Beispiel? Oliver
-
Thread
AVR-Bootloader mit Verschlüsselung
[c] // in Firmware void uart_handlemsg(const char* msg) { ... if (0 == strcmp_P(msg, PSTR("<rest>")) { cli(); wdt_enable(WDTO_15MS); while (1) { } } ... } // in AVRootloader.asm BootSign: .db "<rest>" [/c]
-
Thread
Flash Speicher wird eng HILFE?
Hi, ich verwende hier ein [c] lcd_puttext(strcpy_P(string20, PSTR("Hello world !"))); [/c] Welches nur Flash-Platz benötigt. Der string20 ist ein "Unversalstring", den ich nach Bedarf nutze ... Damit habe ich gute Erfahrungen gemacht ... Gruß Andreas
lcd_puts_S(prog_char *)" gleichzeitig zur Verfügung zu haben, dann entfällt z.B. bei [c]lcd_puts_S(PSTR("blub"))[/c] die Initialisierung des Strings im RAM. Das wirkt sich üblicherweise positiv auf den RAM- und den Flash-Verbrauch aus. Vierter Punkt: Solche unnötigen Animationen sind doch einfach