-
Thread
Atmel SAM25W I2C und WIFI
switch (u8MsgType) { case M2M_WIFI_RESP_CON_STATE_CHANGED: { tstrM2mWifiStateChanged *pstrWifiState = (tstrM2mWifiStateChanged *)pvMsg; if (pstrWifiState->u8CurrState == M2M_WIFI_CONNECTED) { } else if (pstrWifiState->u8CurrState == M2M_WIFI_DISCONNECTED) { printf
-
Thread
3310 Software will nicht char* nehmen
LcdImage(waitImage); //Bild LcdGotoXYFont(1,6); //Zeile LcdFStr(FONT_1X,(unsigned char*)PSTR("MPC Startet...")); //Startet LcdUpdate();// Auf Display _delay_ms(1000); LcdClear(); //Bildschirm räumen LcdUpdate();// Auf Display LcdGotoXYFont(1,1); //Zeile LcdFStr(FONT
[c] LcdFStr(FONT_1X,(unsigned char*)PSTR("MPC Startet...")); //Startet [/c] und kurz danach ... [c] LcdFStr(FONT_1X,(unsigned char*)Text); [/c] wobei „Text“ eine (falsch deklarierte, aber jedenfalls) Variable im SRAM ist. Also wird
-
Thread
sketch stört webserver - wer kann helfen?
ist mir noch aufgefallen, dass du viele relativ grosse Zeichenketten im RAM hast. Benutze PROGMEM, PSTR() und F() damit die Strings nur im Flash Speicher liegen, nicht im RAM. https://arduino-esp8266.readthedocs.io/en/latest/PROGMEM.html
mir noch aufgefallen, dass du viele relativ grosse > Zeichenketten im RAM hast. Benutze PROGMEM, PSTR() und F() damit die > Strings nur im Flash Speicher liegen, nicht im RAM. > https://arduino-esp8266.readthedocs.io/en/latest/PROGMEM.html Das sollte beim ESP32 doch eigentlich egal sein, da dieser
-
Thread
sehr viele printfs -> probleme mit ram (?)
Ohne pgm_read_byte() Einfach printf_P(PSTR("xyz"),...) verwenden.
Jezt siehts gleich vieeel besser aus :D Ich hatte nur printf_P("text"); versucht ohne das PSTR... Das brachte null,nix ;) Danke !
-
Thread
ENC28J60 myEthernet mit NeMo Stack Probleme
if(ind != 255) { if(debugLevel & DEBUGLVL_STACK_TCP_ERROR) { usart_send_line_P(PSTR("tcpOpen: conn already exists")); } return ind; } // Suche nach freiem Eintrag in TCP-Verbindungsliste ind = tcpGetFreeConnEntry(); // Kein freier Eintrag mehr vorhanden if(ind == 255) { if(debugLevel & DEBUGLVL_STACK_TCP_ERROR) { usart_send_line_P(PSTR("tcpOpen: connList full")); } return 255; } else { // MAC-Adresse zu IP-Adresse ermitteln mac = arpGetMac(ipAddr); tcpConnList[ind].handler = handler; tcpConnList
-
Thread
Debug-Funktionen wegdefinieren
> oder bei AVR für Text im ROM Oder [c] #if DEBUG # define trace(s,...) printf_P (PSTR(s) , ##z) #else # define trace(...) (void) 0 #endif [/c] Um Warnungen etc zu vermeiden bei [c] if (x) trace (a, b); else ... [/c] Die Leerzeichen um
Johann L. wrote: > # define trace(s,...) printf_P (PSTR(s) , ##z) Lag nahe, funktioniert(e) aber bei C++ nicht. Daher die andere Version.
-
Thread
Fallende Flanke von Variable nach MC neustart
dann vor der Routine eingefügt, [c] if (MC_hochgefahren && R_TRIG(!licht_status[9])) {DimmenAus (PSTR("89|11|02|00\r"),PSTR("98|11|02|00\n\r"),9);} [/c] Trozdem wird die "Iffe" nach 5 Sek einmal Wahr. Ich habe da irgendeinen Denkfehler, kann mir dort bitte jemand helfen? Danke!
-
Thread
ATXMega128A1: 32-bit quadrature decoder mit compare match ?
printf_P(PSTR("up OV: %i\n"), TCC0.CNT); // send an increment event, see Table 6-2 EVSYS.DATA |= (1<<1); EVSYS.STROBE |= (1<<1); } } // otherwise we're counting down else { if (TCC0.CNT>0) { printf_P(PSTR("dn OV: %i\n"), TCC0.CNT); // send a decrement event EVSYS.DATA &= ~(1<<1); EVSYS.STROBE |= (1<<1); } } } [/c]
-
Thread
Fehlerhafte Adressierung von lokalen Arrays bei tinyAVR(R) 0-series
--------------------------------------------------- */ #define puts_rom(str) (uart_puts_rom(PSTR(str))) void uart_puts_rom(const uint8_t *dataPtr) { uint8_t c; for (c=pgm_read_byte(dataPtr); c; ++dataPtr, c=pgm_read_byte(dataPtr)) uart_putchar(c); } /* -----------------------
*********************************************************/ #define putString_P(__s) puts_p(PSTR(__s)) void puts_p(const char *progmem_s ) { volatile char c {0}; while ( (c = pgm_read_byte(progmem_s++)) ) putChar(c); } [/c]
-
Thread
AVR String-Array
Hi, schon mal mit "PSTR()" im Array versucht? Hab gerade keine Möglichkeit dies zu testen, aber da es beim printf auch so geht sollte es möglich sein. Stephan
übersichtlicher und schnell erweiterbar. @Stephan dies funktioniert leider nicht, da [c] # define PSTR(s) (__extension__({static char __c[] PROGMEM = (s); &__c[0];})) [/c] aus 2 Codezeilen besteht, welche natürlich nicht im Array verwendet werden können. Wahrscheinlich wirds drauf hinaußlaufen,
-
Thread
AVR-GCC: const __flash struct mydata_t *[4]
kleines Mock-up gemacht: [c] // Struct und seine Inhalte void dummyfkt(void) { glcd_putstr_P(PSTR("Ich schreibe also bin ich")); glcd_drawnow(); } int16_t dummyvar = 0; const __flash char TEXT1[] = "Hallo"; const __flash char TEXTN[] = {'\0'}; typedef struct { const __flash
}; // Test void test(const __flash mydata_t *(data[])) { snprintf_P(glstr_Buf,N_TEXTBUF,PSTR("hallo")); glcd_putstr(glstr_Buf); glcd_drawnow(); voidFcn_t fkt; fkt = data[1]->fktpointer; fkt(); // Geht schief snprintf_P(glstr_Buf,N_TEXTBUF,&(data[1]->text)); // Geht auch
-
Thread
KS0108 GLCD Routinen
> #include "ks0108.h" [...] void meinBeispielFunktion(void) { [...] ks0108Puts_P(PSTR("Ein String im Flash")); [...] } Die Width-Funktionen geben jeweils (wie der Name schon sagt) die Breite eines einzelnen Zeichens, eines Strings im SRAM und eines Strings im Flash an. Die Breite
einen String mittig auf dem Display platzieren möchte kann man einfach schreiben: PGM_P string = PSTR("Mittiger Text"); uint8_t w = ks0108StringWidth_P(string); ks0108GotoXY(64-(w<<1), 24); ks0108Puts_P(string); Das ganze kann man natürlich auch durch probieren erreichen und würde dann sogar schneller
-
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
Sonderzeichen LCD HD44780 kompatibel
So, nun zum Generieren anonymer Zeichenketten im Flash. Ein Blick in <avr/pgmspace.h>, Makro *PSTR*, zeigt wie es geht: #define P00(s) (__extension__({static const PROGMEM hd44780::a00::str<sizeof L##s/2> c(L##s); c.a;})) Es ist tatsächlich ein weiteres Makro erforderlich. A00 und P00 können
nicht zusammengelegt werden. Der Typecast-Operator ist dazu überflüssig. Die Anwendung ist wie bei PSTR: lcd_puts_P(P00("Test ÄÖÜäöüß °C kΩ")); Das erscheint erst mal komfortabel genug. Lästig ist, dass man beim AVR immer die beiden Adressräume, RAM und Flash, im Hinterkopf behalten muss.
-
Thread
Probleme bei der Ansteuerung MAX7219 mit 8x8 Dot Matrix
display.stopTransfer(); sendMessage_p ( ADDR_BROADCAST, rx.myAddress, PSTR ( "led" ) ); uartPuts ( uint8ToAh ( ( char* ) buffer, displayData ) ); uartPuts_p ( PSTR ( "\r" ) ); uartWaitTXEmpty(); [/code] Besten Dank shcon mal für die Bemühungen.
-
Thread
AVR, Heap - Variablen jenseits RAM-Grenze?
counter = 0; uint8_t buf[60]; [... versch. Initialisierungsgeschichten, unwichtig ...] uart_puts(PSTR("\n\rAdresse von cluster: ")); uart_puts_R(ltoa(&cluster, buf, 10)); uart_puts(PSTR("\n\r\n\r")); [... usw. usf. ...] } [/c] jetzt liefert mir dieses kleine Programmcodebeispiel ein [c]
-
Thread
Strings im Flash ablegen, oder nicht?
[c] uart_output("Dies ist eine Test-Ausgabe aus dem RAM"); [/c] vs. [c] uart_output_P(PSTR("Dies ist eine Test-Ausgabe aus dem Flash")); [/c] Option #2 braucht letztendlich sogar mehr Flash, wenn man es kompiliert. Das macht vermutlich auch Sinn, weil der String ja in beiden Fällen im
das Flash im RAM-Adressbereich sichbar ist. Auf diesen Devices kann man auf __flash und PROGMEM / PSTR etc. ohne Overhead verzichten. [c]const int i = 2; __attribute((noinline,noclone)) int readi (const int *pi) { return *pi; } int main (void) { return readi (&i); }[/c] Zunächst
-
Thread
1. Funktionsaufruf alles wunderbar 2. Funktionsaufruf => Absturz
Ohne den Rest-Code gesehen zu haben: Ram/Stack-Problem? pgmspace.h und dessen PSTR-Makro helfen.
Ich habe nun alle strings mit PSTR übergeben. Das löst das Problem allerdings auch nicht. Nach etwas herumprobieren und auskommentieren, habe ich herausgefunden, dass der eigentlich Knackpunkt wohl die spi_send_byte() Funktion ist. Warum
-
Thread
ATmega resettet dauernd
Beitrag #3602947: > uart_puts_P("Hallo\n"); Wahrscheinlich sollte das uart_puts_P(PSTR("Hallo\n")); lauten, oder täusch ich mich?
dafür gibts ja #define uart_puts_P(__s) uart_puts_p(PSTR(__s)) im header.
-
Thread
Arduino Uno R4: Besonderheiten und Abhilfen
Beim STM32 Core ist Progmem einfach als gar nichts definiert, PGM_P ist ein normaler const char* und PSTR(von x) ist auch ein dummy, nämlich x.
STM32 Core ist Progmem einfach als gar nichts definiert, > PGM_P ist ein normaler const char* und PSTR(von x) ist auch ein dummy, > nämlich x. Hallo Nemopuk, wie bekomme ich die Daten in den Flash bzw. wie und welche eindeutigen Adress-Bereiche muss ich angeben um beispielsweise: const int
-
Thread
Arbeitsspeicher sparen
www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Array_aus_Strings_im_Flash-Speicher PROGMEM und PSTR sind die Zauberwörter. Servus Michael
Code. Da gibt es einen kompletten Abschnitt drüber im AVR-GCC-Tutorial. Such mal nach PROGMEM und PSTR... In der Artikelsammlung sind auch Projekte beschrieben, die mit einer Menüführung auf einem LCD arbeiten. Da ist wahrscheinlichst auch entsprechender Code zu sehen.
-
Thread
Problem mit AVR NEt IO und Eingänge
break; } if(b) { strcpy_P(var_conversion_buffer, PSTR("ledon.gif")); } else { strcpy_P(var_conversion_buffer, PSTR("ledoff.gif")); } str_len = strnlen(var_conversion_buffer,CONVERSION_BUFFER_LEN);
-
Thread
WLAN Steckdosen Unterschiede?
CR":"372/699"}} tasmota/support.ino- if (is_8285) { tasmota/support.ino- strcpy_P(buff, PSTR("ESP8285")); tasmota/support.ino- } else { tasmota/support.ino: strcpy_P(buff, PSTR("ESP8266EX")); tasmota/support.ino- }
-
Thread
USART Sende Problem - 168
// 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); } }
-
Thread
Webserver mit UIP Stack und NTP-Client
/ 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,
u16_t *ntpserver) { if(ntp_conn != NULL) { uip_udp_remove(ntp_conn); } printf_P(PSTR("NTP uses Server %d.%d.%d.%d\r\n"), ntpserver[0] & 0xFF, ntpserver[0] >> 8, ntpserver[1] & 0xFF, ntpserver[1] >> 8); ntp_conn = uip_udp_new(ntpserver, 123); } /*----
-
Thread
[AVR-GCC] struct-Initialisierung. PROGMEM und Strings
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?
-
Thread
Probleme bei Programmausführung
nicht... Mit wenig Aufwand könnte er z.B. alle String-Konstanten vom Ram in den Flash verbannen... PSTR(), lcd_string_P ()...
nicht... Mit wenig Aufwand könnte er z.B. alle > String-Konstanten vom Ram in den Flash verbannen... PSTR(), lcd_string_P > ()... AVR Memory Usage ---------------- Device: atmega16 Program: 5670 bytes (34.6% Full) (.text + .data + .bootloader) Data: 426 bytes (41.6% Full) (.data
-
Thread
sprintf_P Vor und Nachteile
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
-
Thread
RFM12 an XMEGA
temp = RFM12_rxfinish( RFMpacket ); if ( temp != 255 && temp != 254 ) { printf_P( PSTR("RFM12 %d Bytes recieve."), temp ); for ( i = 0 ; i < RFM_PACKET_SIZE ; i++) printf_P( PSTR("%02x ") , RFMpacket[ i ] ); if ( RFM12_rxstart() != 0 ) printf_P( PSTR("RFM12 error")); printf_P( PSTR("\r\n")); } } //interrupt service routine void RFM12_isr( void ) { LED_off(7); if(RFM12_status.Rx) { if(RFM12_Index < RFM12_DataLength) { //no complete packet
-
Thread
PIC µC: PWM-aus & Port aus -> manchmal bleibt Port-Bit auf high hängen?
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 ...
-
Thread
Die andere Firmware für AVR-NET IO
void init_cmd_livedata( void ) { #if defined(HTTPSERVER_ONEWIRE) cgi_RegisterCGI( cgi_livedata, PSTR("livedata.cgi")); #endif } void cgi_livedata( void * pStruct ) { struct TIME nowtime; int i; char TEMPSTRING[10]="\0"; for ( i = 0 ; i < 1 ; i ++ ) // TEMP_MAX_SENSORS {
1900), correction for unixtime TEMP_Sensor2String(i, TEMPSTRING); printf_P(PSTR("[%lu000,%s]"), nowtime.time, TEMPSTRING); } }[/c]
-
Thread
const prog_char in AVR Studio 6.2
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
-
Thread
Probleme mit AVR ADC
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)...
-
Thread
PID-Regler: Wie schnell ist schnell genug?
itoa(OCR0B,valueToPrint,10); sendString(valueToPrint); sendString_p(PSTR(",")); dtostrf(voltage, 6, 4, valueToPrint); TCCR1B &= ~(1 << CS10); sendString(valueToPrint); sendString_p(PSTR(
-
Thread
DS18B20 Temperaturberechnung
if (diff == PRESENCE_ERR) { // No Sensor found # if DEBUG uart_puts_P(PSTR("No Sensor" CR)); # endif return 87; break; } if (diff == DATA_ERR) { // Bus Error # if DEBUG uart_puts_P(PSTR("Bus Error" CR)); # endif
-
Thread
Mikrocontroller über Ethernet verbinden
timer = millis() + 5000; Serial.println(); Serial.print("<<< REQ "); ether.browseUrl(PSTR("/foo/"), "bar", website, my_callback); Serial.println(); Serial.print(ether.browseUrl(PSTR("/foo/"), "bar", website, my_callback)); } }[/c] Das mit IOBroker schau ich mir aufjedenfall
-
Thread
Minimal UART für Attiny gesucht
(ch)) return -1; s++; } return 0; } #define dbg_serial_print_P(__s) dbg_serial_print_p(PSTR(__s)) #define dbg_serial_print_P_nonblock(__s) dbg_serial_print_p_nonblock(PSTR(__s)) void dbg_serial_print_maxlen (char * s, unsigned int maxl) { unsigned char ch; //unsigned int ii; //while
-
Thread
Unterschiede zwischen ARM und ATmega in der Programmierung
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 :)
-
Thread
STM32 I2C mit EEPROM - funktioniert nur zuverlässig mit Bus-Sniffer
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
-
Thread
Variablen eindeutig benennen damit der Typ eindeutig ist
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
-
Thread
Arduino SD Card Modul
// 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
-
Thread
Gibt es Pflanzenlicht-Einzel-LEDs?
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.
-
Thread
Einstieg in die µC-Welt
foundDate) { display.scroll_up(8,20); display.draw_string_P(0,24,PSTR("No date received")); display.display(); } } else { display.scroll_up(8,20); display.draw_string_P(0,24,PSTR("Connect failed")); display.display
-
Thread
Kommerzieller AVR C Compiler
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
-
Thread
Uhrzeit formatieren...
Mit WinAVR aktuelle Version von avrLibC snprintf_P(buffer, 20, PSTR(" %02d:%02d:%02d %-6S"), tm.tm_hour, tm.tm_minute, tm.tm_second, dst); NULL problemo
-
Thread
LC 7981 Grafikdysplay Ansteuerung
PSTR() und PROGMEM sind wohl auch nicht so angebracht. Da fehlt allerdings noch einiges! (diverse Header-Dateien, LCD-Routinen)
-
Thread
WinApi CreateThread
des Api Mains: int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { HWND hWnd; MSG msg; WNDCLASSEX wc; HANDLE hHandle1; DWORD ThreadId1=0; .... dann mache ich irgentwann das: hHandle1
-
Thread
Stackbelastung durch printf()
Probier mal sprintf_P (cString,PSTR("init Bluetooth")); Da kann man oft ne Menge RAM mit freischaufeln.
-
Thread
Probleme mit meinem LCD-Display
(LCD_DISPLAYON | LCD_CURSORON | LCD_BLINKINGON); lcd_light(true); lcd_printlc_P(1, 1, PSTR("Hello World")); } [/c] Die Lib ist angehängt Ein I2C Scanner sagt, es ist 0x3F, aber es funktioniert nicht Durch die Verschiebung um 1 Bit vermute ich mal 0x7E, aber das funktioniert auch
-
Thread
ATMega328, komisches Verhalten bei fast vollem Speicher
[c] //fuer den Zugriff auf den Flashspeicher #include <avr/pgmspace.h> ... screen_print_p(PSTR("(Speed restored)"); ... //funktion zum Schreiben von Strings aus dem Flash void screen_print_p(const char* stringFromFlash) { register char zeichen; while( zeichen = pgm_read_byte(stringFromFlash
Hmmm, mit screen_locate(1, 2); screen_print_p(PSTR("(Speed restored)")); funktioniert das Ding wiederum. Krank! Gruß, Sebastian