-
Thread
Atmel ARM: USB Communication Device Class
beiden Data Endpoints: [c] #define UDI_CDC_DATA_DESC_COMMON \ .iface.bLength = sizeof(usb_iface_desc_t),\ .iface.bDescriptorType = USB_DT_INTERFACE,\ .iface.bAlternateSetting = 0,\ .iface.bNumEndpoints = 2,\ .iface.bInterfaceClass = CDC_CLASS_DATA
= sizeof(usb_ep_desc_t),\ .ep_out.bDescriptorType = USB_DT_ENDPOINT,\ .ep_out.bmAttributes = USB_EP_TYPE_BULK,\ .ep_out.bInterval = 0, [/c] Das Ganze ist sehr verschachtelt
-
Thread
Pointer übergabe führt zum Absturz?
Speicher reserviere, klappt es! [C] int main(int argc, char *argv[]){ char *inBuff = malloc(sizeof(char)*50); strcpy(inBuff,"+ADDR:1234:56:abcdef"); printf("Function Result.: %d\r\n",srchCmd(inBuff,"+ADDR:xxxxxxxxxxxxxx")); printf(getBlthAddr(inBuff)); return 0; } [/C]
Steffen W. schrieb im Beitrag #5224221: > char *cmdBeginn_ = malloc(sizeof(char)*cmdStrLen); > strcpy(cmdBeginn_,srchCmd); Da ist kein Platz für die 0-Terminierung ... Du brauchst 1 Byte mehr als der String lang ist. Sicherheitshalber sollte man eh kein strcpy verwenden
-
Thread
UART char Array senden?
); s++; z++; /* P.S: was ist z???? */ } } //main... uart_put_n (initTx1, sizeof(initTx1)); uart_put_n (initTx2, sizeof(initTx2)); uart_put_n (initTx3, sizeof(initTx3)); ;)
-
Thread
[C,WinAPI] Fenster eines anderen (eigenen) Programms verschieben
StartupInfo; PROCESS_INFORMATION ProcInfo; HWND window[10]; memset(&ProcInfo, 0, sizeof(ProcInfo)); memset(&StartupInfo, 0 , sizeof(StartupInfo)); StartupInfo.cb = sizeof(StartupInfo); // Set structure size StartupInfo.dwX = 100 ; StartupInfo.dwY = 300 ; StartupInfo.wShowWindow
-
Thread
AD7793 an ARM9
spi_ioc_transfer xfer[2]; unsigned char buf[32], *bp; int status; memset(xfer, 0, sizeof xfer); memset(buf, 0, sizeof buf); // 32 Bit high = 4x 8 bit = 4 Byte buf[0] = 0xFF; // 0xFF = 0b1111 buf[1] = 0xFF; // 0xFF = 0b1111 buf
spi_ioc_transfer xfer[2]; unsigned char buf[32], *bp; int status; memset(xfer, 0, sizeof xfer); memset(buf, 0, sizeof buf); buf[0] = 0x60; // 0x60 = 0b(0)1100000 ID-Register lesen xfer[0].tx_buf = (__u64) buf; xfer[0].len = 1; // 1 Byte = 8 Bit xfer[1].rx_buf =
-
Thread
VUSB Long Transfers Test
is in the bRequest field case USB_PC_IN: // send data to PC { usbMsgLen_t len = sizeof(buf); // we return up to 1024 bytes if(len > rq->wLength.word) // if the host requests less than we have len = rq->wLength.word; // return only the
dataLength = (uchar)rq->wLength.word; dataReceived = 0; if(dataLength > sizeof(buf)) // limit to buffer size dataLength = sizeof(buf); return USB_NO_MSG; // usbFunctionWrite will be called now } return 0; // should not
-
Thread
Konzept Zugriff auf Variablen und Modbus
float b; uint16_t c; }; union store { struct abc data; uint16_t data_mod[ sizeof( struct abc )/sizeof(uint16_t) ]; }; union store storage; [/C] Auf deine Daten kannst du auf die 'schöne' Art mit sprechenden Namen zugreifen [C] storage.data.b = 5.0; [/C] und
Prozessorarchitektur ab und welche Speicherzugriffsrestriktionen sie mitbringt. Man merkt es daran, dass zb sizeof( struct x ) eine 4 ergibt und keine 2, wie man eigentlich anhand der beiden 1-Byte Variablen annehmen würde.
-
Thread
eeprom_read_block Problem
] und so lese ich: [c] eeprom_read_block( (void*)&colors[0], (const void*)&colortable[0], sizeof( colorproc ) ); [/c] Wäre für den entscheidenden Tip dankbar. Gruß Frank
Hallo Werner, ich denke, das Problem liegt an sizeof( colorproc ). Ich hatte mir den Wert mal per UART ausgeben lassen und erhalte hier den Wert 0x20 an Stelle von 0x14. In der Simulation läuft die Anwendung einwandfrei. Also liegt die Vermutung
-
Thread
Warum ist mein int8_t 4 Bytes groß? 0xFF != 0xFFFFFFFF
; int8_t offset = EEPROM.read(0x08); Serial.print("Size of offset: "); Serial.println(sizeof(offset)); Serial.println(EEPROM.read(0x08), HEX); Serial.println(EEPROM.read(0x08), DEC); Serial.println(eeprom_read_byte((uint8_t*)0x08), HEX); Serial.println(offset, HEX); Serial.println
_t test1 = -127; int8_t test2 = -1; void setup() { Serial.begin(9600); Serial.println(sizeof(test1)); Serial.println(test1); Serial.println(test2); } void loop(){} [/c] Result: [c]1 -127 -1 [/c]
-
Thread
STM32 RF24 Kommunikation
printf("%d\r\n",radio.available()); while(radio.available()){ radio.read(&data,sizeof(data)); serial0.printf("Daten \n"); counter++; } } radio.startListening(); t.stop(); } [/c]
radio.enableDynamicPayloads(); // Dynamische Payload Size aktivieren //radio.setPayloadSize(sizeof(data)); radio.setRetries(15,15); // 4ms Pause, 5 Wiederholungen radio.setCRCLength(RF24_CRC_16); // 16 Bit CRC radio.openWritingPipe(TXADDRESS); set_wdt_isr(); /* Struct
-
Thread
pic32 +cc1101
uint8_t status[2]; SYS_DEBUG_PRINT(SYS_ERROR_DEBUG, " packetLength = 0x%2x\r\n", sizeof (NoMo4_Packet_t)); SYS_DEBUG_PRINT(SYS_ERROR_DEBUG, " RXBYTES = 0x%2x\r\n", CC1101_RXBYTES); //////RXBYTES--->Number of bytes in RX FIFO if (_CCRadio_SpiReadStatusReg(CC1101_RXBYTES
RXBYTES, &RxBytes); /////if (RxBytes & BYTES_IN_RXFIFO) { size = sizeof (NoMo4_Packet_t); SYS_DEBUG_PRINT(SYS_ERROR_DEBUG, " size1 = 0x%2x\r\n", size); _CCRadio_SpiReadBurstReg(CC1101_RXFIFO, rxBuffer, size); SYS_DEBUG_PRINT
-
Thread
UART array auslesen
, wenn dieser 100 oder 1000000 ist. uint8_t aaa='z'; HAL_UART_Transmit(&huart2, &aaa, sizeof(aaa),100); zudem würde ich gerne wissen, warum ich so Zeichen senden kann, aber folgendes nicht funktioniert uint8_t array[] = {1, 2, 3, 6, 5, 4}; HAL_UART_Transmit(&huart2, &array, sizeof
array[] = {'m', 'a', 'x', 'd', 'e', 'n', 'g', 'e', 'r'}; HAL_UART_Transmit(&huart2, &array[0], sizeof(array), 100); [/c] Jedoch würde ich trotzdem gerne wissen, wofür die Timeout ist. Das habe ich leider nicht gefunden. [c] HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8
-
Thread
Serial Communiction uint8_t* Arduino
mqtt_connect_configuration mqtt_connect_configuration) { char *msg_mqtt_clean = (char*) malloc(sizeof(char)*21); if(msg_mqtt_clean == NULL) { return EXIT_ERROR; } sprintf(msg_mqtt_clean,"AT+MQTTCLEAN=%d\r\n",mqtt_connect_configuration.LinkID); HAL_UART_Transmit(&huart1, (uint8
findender Fehler, da man sich sicher ist, dass das schon mal so (oder so ähnlich) geklappt hat. sizeof() strlen() mblen() Ich rate da zu ein klein wenig Aufmerksamkeit/Sorgfalt. Émile schrieb im Beitrag #7268048: > Ob char selbst wiederum signed oder unsigned ist, ist nicht festgelegt
-
Thread
MSP430F5529 Flashpointer zu klein
Zur Kontrolle: lass Dir mal im Debugger das Ergebnis von sizeof (int *) anzeigen. Da muss was anderes als zwei ("2") rauskommen.
Rufus Τ. Firefly schrieb im Beitrag #2468943: > sizeof (int *) > > Da muss was anderes als zwei ("2") rauskommen. Warum? 16 Bit Core, also 2 Byte pro Integer.
-
Thread
ANSI C: uint8_t* Länge der gespeicherten Daten bestimmen
Hi, leider so nicht. Du müsstest schon z.B. st_Data data1 = {0, sizeof(data), data}; initialisieren, um eine Längeninfo zu haben. Grüsse
seine Länge: [c] #include <stdio.h> int main() { char c[500]; printf("%zu\n", sizeof c); return 0; } [/c] Die Array-Länge ist allerdings nicht Teil des einzelnen Arrays, sondern seines Typs. Die Probleme fangen dann bei Zeigern an, weil ein: toto schrieb im Beitrag #7123127
-
Thread
BMP aus PIC Speicher auf MI0283QT9 anzeigen
OpenBMPFile(const char *file, int16_t x, int16_t y) { uint8_t buf[40]; //read buf (min. size = sizeof(BMP_DIPHeader)) BMP_Header *bmp_hd; BMP_DIPHeader *bmp_dip; int16_t width, height, w, h; FILE * fd; fd = fopen(file, "rb"); if(fd == NULL) { lcd.drawText(x, y,"File not found
*)&buf[0]; fread(&buf, sizeof(BMP_DIPHeader), 1, fd); if ( (bmp_dip->size == sizeof(BMP_DIPHeader)) && (bmp_dip->bitspp == 24) && (bmp_dip->compress == 0)) { //BMP data (1. pixel = bottom left) width
-
Thread
Pointer in Funktion..
[lvalue] Wie jede andere Variable hat ein Pointer eine Adresse (&-operator) und eine Größe (sizeof-operator). Axel S. schrieb im Beitrag #5052529: > Wenn du schon den Standard zur Hand hast: schlag doch mal die Definition > des Konzepts "Pointer" nach. Und dann zeig mir, wo der Standard das
hat. > Wie jede andere Variable hat ein Pointer eine Adresse (&-operator) und > eine Größe (sizeof-operator). Und wie jede andere Variable hat ein Pointer einen Wert. Im Falle eines Pointers ist dieser Wert eine Adresse.
-
Thread
Terratec (NEC) Fernbedienung mit IRMP
Anwendung RepeatCounter *immer* größer als 0? Weiter unten sehe ich: memcpy(buf, &myIRData, sizeof(myIRData)); USB_HID_SendData(REPORT_ID_IR, buf, sizeof(myIRData)); Die Datenstruktur wird also in einen buffer "buf" kopiert und anschließend die Funktion USB_HID_SendData() aufgerufen, bei der
check_reboot(&myIRData); } /* send IR-data */ memcpy(buf, &myIRData, sizeof(myIRData)); USB_HID_SendData(REPORT_ID_IR, buf, sizeof(myIRData)); }[/c] Dabei ist learn_wakeup irrelevant, da schon vorhanden, macros sind nicht vorhanden, resets auch nicht, wakeups
-
Thread
char * Verkettung von Arrays Chars
folgenden Code: adrIP++; for (int iP=0; iP<anzCMD; iP++) { for (unsigned int t=0; t<sizeof(cmdP); t++) { *((char*)&CMD[iP] + t) = EEPROM.read(adrIP + (iP * sizeof(cmdP)) +t); } //char *p1; //itoa(CMD[iP].param1,p1,10); char *strTemp;
Andreas Frauenstein schrieb im Beitrag #2718489: > *((char*)&CMD[iP] + t) = EEPROM.read(adrIP + (iP * sizeof(cmdP)) Eine read Funktion liefert normalerweise nur einen Pointer, d.h. der Compiler kann die Daten nicht automatisch an das Struct übergeben. Über ein memcpy() wäre es aber möglich. Wer mit
-
Thread
Woher Infos zum kleinsten impliziten Datentyp?
Ausgabemöglichkeit hat, evtuell am Programmanfang zu testen oder ein assert einzubauen assert( sizeof(int) > 2 ) letzteres geht nur dann vernünftig, wenn sizeof(char) tatsächlich Bytegröße hat. sizeof(char) ist per Def immer 1. Aber das muss nicht bedeuten, dass es sich dabei um 1 Byte handelt.
-
Thread
Look-up Tabelle wird nicht anständig gelesen
werden: > > Array Adresse + (Index * Datenbreite) nein nicht ganz: Array Adresse + (Index * sizeof( Datentype ) )
Peter II schrieb im Beitrag #3467744: > nein nicht ganz: > > Array Adresse + (Index * sizeof( Datentype ) ) Eben, hast es nur anders ausedrueckt ;) Wenn dieser C Dialekt auf dieser HW aber doch 8 Bit Bytes unterstuetzt, dann sollte man auch ein Byte als Index verwenden, das war es worauf
-
Thread
buffer in variabel speichern aber wie?
// read up to 128 byte int c = stream->readBytes(buff, ((size > sizeof(buff)) ? sizeof(buff) : size)); // write it to Serial USE_SERIAL.write(buff, c); test = buff;
delay(10000); } [/c] es geht um folgenden bereich [c] int c = stream->readBytes(buff, ((size > sizeof(buff)) ? sizeof(buff) : size)); // write it to Serial USE_SERIAL.write(buff, c); test = buff; [/c] wie bekomme ich buff
-
Thread
Problem mit Zeigern auf Structe
Zahlen kümmert [C] void autopilot_init(autopilot * const _this) { for(unsigned char i=0; i<sizeof(_this->wp)/sizeof(*_this->wp); i++) { _this->wp[i].lon = 0; _this->wp[i].lat = 0; _this->wp[i].course = 0; _this->wp[i].distance = 0; } _this->wp_id = 0; } [/C] dann passiert dir sowas nicht. Ein Makro [C] #define ARRAY_SIZE(x) (sizeof(x)/sizeof(*x)) [/C] macht die Sache dann noch besser lesbar [C] void autopilot_init(autopilot * const _this) { for(unsigned char i=0; i<ARRAY_SIZE(_this->wp); i++) { _this->
-
Thread
[ARM] U-Boot: Probleme mit Code-Portierung
Und was spricht gegen ein initiales [c]memset( golayEncodedSecret, 0x00, sizeof(golayEncodedSecret));[/c] ?
Beitrag #3295167: > Und was spricht gegen ein initiales > [c]memset( golayEncodedSecret, 0x00, sizeof(golayEncodedSecret));[/c] > ? Ist dies gute Praxis für jegliche globale Arrays?
-
Thread
Float ins Externe EEPROM schreiben. Funkt. nicht so ganz
I2C_Device_Address + I2C_WRITE); i2c_write(eepromaddress & 0xFF); i2c_writeBlock((uint8_t*) &data, sizeof(data)); i2c_stop(); _delay_ms(5); } [/c] Gruß, Stefan
readEEPROM_Float): [c] float floatData; ... i2c_writeBlock((unsigned char*) &floatData, sizeof(data)); ... i2c_readBlockNak((unsigned char*) &floatData, sizeof(data)); ... [/c] Alles aus dem Stegreif geschrieben und ungetestet! Gruß, Stefan
-
Thread
stack frame too large (EEPROM)
übergibt man keine riesen Monsterstrings, sondern nur den Pointer darauf. Und da geht dann kein sizeof, man übergibt einfach die Anzahl als 2. Argument. Peter
) und es findet keine Übergabe per Array sondern per Pointer statt. Aus diesem Grund ist auch sizeof(data1[]) erstens sinnlos, zweitens syntaktisch merkwürdig. Ich kann in diesem Schnipsel also kein Problem erkennen. Es sei denn der Hersteller des Compilers hat die Sprache C neu definiert.
-
Thread
EEPROM wird nicht korrekt ausgelesen
EEPROM [c] // String ins EEPROM abspeichern eeprom_write_block (&uart_string, &eeFooNummer,sizeof(uart_string)); // Nummer ins EEPROM abspeichern //Länge des Strings extra abspeichern NummerLaenge = strlen(uart_string); eeprom_write_byte(&eeFooLaengeNummer,NummerLaenge); // Länge
[c] eeprom_read_block( &uart_string, eeFooNummer, sizeof(uart_string)); // Nummer aus dem EEPROM lesen [/c] oder so [c] eeprom_read_block( &EepromNummerAusgelesen, eeFooNummer, NummerLaenge+1 ); // Nummer aus dem EEPROM lesen [/c] oder so
-
Thread
C++: Interessanter Effekt bei constexpr Arrays
durchkompiliert arm-none-eabi-gcc GNU Tools ARM Embedded 4.9 2015q3 für cortex m-3 mit offset = 0 ist sizeof(main) == 0x30 mit offset = 1 ist sizeof(main) == 0x3C In beiden Fällen ist sizeof(data) == 0
-
Thread
zeilenweise lesen aus einer Textdatei
line[256]; int x; if ((txtfile = fopen( "Dateiname", "r" )) != NULL) { if( fgets( line, sizeof( line ), txtfile ) ) { sscanf( line, "%d", &x ); } } fclose(txtfile); [/C] So kann man seit 30 Jahren aus einem String eine Zahl herausholen. Und ev. solltest du das auch tun.
hat, dann hast du zunächst mal einfach nur einen String in einem Array. if( fgets( line, sizeof( line ), txtfile ) ) ist die kürzere Schreibweise von if( fgets( line, sizeof( line ), txtfile ) != NULL ) Und diesen String (der jetzt im Character Array namens 'line' abgelegt ist)
-
Thread
AVR-GCC: Variable wird im Interrupt gekillt / Math.h-Frage
Parameter tabu sein. Im gegenständlichen Fall: snprintf verwenden! [C] snprintf( Numout, sizeof( Numout), "%02d", Stunde ); [/C] > > Bleibt noch die Frage nach der schlechten Genauigkeit im > Fließkommabereich. Erwarte ich da zuviel? Ja. Aus 4 Byte ist nunmal nicht mehr herauszuholen
double? Dann brauche ich mich ja nicht zu wundern. > Dann ist hier wohl Handarbeit angesagt. Jep, sizeof(float) == sizeof(double) == 4 beim avr-gcc.
-
Thread
C sorgt oft für Verwirrungen
; Width = malloc(sizeof(int)); *Width = 34; return 0; } [/c] Soll das echt Lernmaterial sein? Das ist ja echt schrecklich!
schon so eine Frage in Foren und Newsgroups gelesen habe: "Ich wollte die Größe des Arrays mit sizeof ermitteln, aber bekomme immer 4 raus, obwohl das Array 100 Elemente hat: [C] void func(int arr[]) { printf("%d\n", (int)sizeof(arr)); } [/C] ". Gefühlt gehört sie zu den Top-Fragen von C-Anfängern
-
Thread
C++ : Mit for-Schleife über Objekte verschiedener Klassen iterieren
hat es auch entsprechenden overhead. DU kannst deine Klasse auch [[gnu::packed]] machen und dann sizeof(...) vergleichen. https://en.wikipedia.org/wiki/Virtual_method_table#cite_note-4 https://en.cppreference.com/w/cpp/language/virtual
gepackt werden können, denn wie soll die Adresse von Element X berechnet werden, wenn nicht mit X*sizeof(T) ? Daher der Trick, dass im Array nur der Zeiger steht, denn alle Zeiger sind gleich groß. Das impliziert aber, dass die eigentlichen Objekte noch irgendwo anders abgelegt sind, wo der Zeiger dann
-
Thread
Differenzen auswerten: Geht das eleganter?
float temperature_range_limits[] = {-2,-1,-0.5, 0, 2.5, 3.0}; const size_t num_temperature_ranges = sizeof(temperature_range_limits) / sizeof(temperature_range_limits[0]); const unsigned char leds[] = {0,1,2,3,4,5,6}; // irgendwelche Bitmuster. size_t get_temperature_range(float t) { for (size_t
. Dadurch war das mit der Schleife oben einfach lösbar. const size_t num_temperature_ranges = sizeof(temperature_range_limits) / sizeof(temperature_range_limits[0]); Auch noch nicht gesehen .... ich habe einfach 12 reingeschrieben.
-
Thread
RS232-Frameprotokoll transmitt Problem
,'l','l','o',' ','w','e','l','t'}; // Gibt als Parameter "hallo welt" aus int Num_bytes = (sizeof(array)/sizeof(array[0])); // Arrayplätze berechnen UART_Transmit(Num_bytes, array); [/c] ausserhalb des Protokoll kommt am PC das an: Number of Bytes Parameter 1 ... Parameter n Checksum
[]={'T','i','m','e','o','u','t'}; // Gibt als Parameter "Timeout" aus int Num_bytes = (sizeof(array)/sizeof(array[0])); // Arrayplätze berechnen UART_Transmit(Num_bytes, array); [/c] gast schrieb: >dann solltest du DAS >ENQ -> ><- ACK >-> Request ><- ACK ><- Response
-
Thread
C - libpng unter Windows verwenden
will just use the constant 14 we know we have fwrite(&bfh, 1, 14, image); fwrite(&bih, 1, sizeof(bih), image); // write out pixel data, one last important this to know is the ordering is backwards // we have to go BGR as opposed to RGB int i = 0; for(unsigned y = 0; y < height; y
buffer[i * 3 + 2] / samples); char color[] = {b,g,r}; fwrite(color, 1, sizeof(color), image); i++; } fclose(image); } [/c]
-
Thread
Unions in C
Du könntest sizeof(head) verwenden um ein Array anzulegen das genauso groß ist wie deine struct.
char many[9]; } head; [/c] Nochmal zurück zu den DSPs: Ich hatte mal einen, da war sizeof (double) == 1 Das hat mich zunächst arg gewundert, denn die berechneten Ergebnisse waren etwa 7 Stellen genau =8-O, bis es mir dann wie Schuppen von den Augen fiel (s. o.).
-
Thread
128 Bit Risc
immernoch 32bit breit ist, bei der 64bit Version dann aber doch 64bit! [code] printf("\nsi=%u", sizeof(short int)); printf("\ni=%u", sizeof(int)); printf("\nli=%u", sizeof(long int)); printf("\nlli=%u", sizeof(long long int)); printf("\nf=%u", sizeof(float)); printf("\nd=%u", sizeof(double)); printf("\nld=%u", sizeof(long double)); mgw32: si=2 i=4 li=4 lli=8 f=4 d=8 ld=12 mgw64: si=2 i=4 li=4 lli=8 f=4 d=8 ld=16 [/code] Ich weiß jetzt nicht, wie das beim GCC unter Linux ausschaut, wenn
-
Thread
STM32 Uart Float Bytes senden
exceptions and examples. D.h. du solltest es eher so machen: [c]float f = 1.0; uint8_t foo[sizeof(f)]; memcpy(foo, &f, sizeof(foo)); HAL_UART_Transmit(&huart2, foo, sizeof(foo), HAL_MAX_DELAY);[/c] Der compiler erkennt dann, dass du float nach uint8_t array casten möchtest und optimiert das
-
Thread
CMD: drucker druckt nicht
di; hDC= CreateDC("WINSPOOL","Microsoft XPS Document Writer",NULL,NULL); memset(&di,0,sizeof(DOCINFO)); di.cbSize= sizeof(DOCINFO); di.lpszDocName= "Sample Document"; if(StartDoc(hDC,&di)>0) { char buffer1[]= "This is output to the printer"; StartPage(hDC); TextOut(hDC,10,10,buffer1,sizeof(buffer1)-1); EndPage(hDC); EndDoc(hDC); } DeleteDC(hDC); return 0; } [/c]
-
Thread
Effiziente string replace Funktion
); tempString = (char*)malloc( ( strlen(string_in) - strlen(search) + strlen(replace) ) * sizeof(char)); if(tempString == NULL) { return NULL; } strcpy(tempString, string_in); len = (tok - string_in); string_in[len] = '\0'; strcat(string_in, replace); len = len + strlen
size > 11 ) strcpy( pMem, "Hallo World" ); } int main() { char str[3]; foo( str, sizeof( str ) ); } [/C]
-
Thread
[C] Programm hängt sich beim Aufruf von malloc() auf
Wer per malloc Speicher alloziiiert, bekommt einen Zeiger zurück, zB so: int *ptr = malloc(10 * sizeof (int)); Vom Zeiger ausgehend bis zum Ende von 10 * sizeof(int) ist der Speicher belegt. Was ich vermute, ist, dass sich das Malloc in Zusammenarbeit mit den OS verheddert, und mit einer Speicherbelegung
Code //Platz für DB reservieren usw... //viel Code Feldertmp=realloc(Data[i].Felder,NbFelder*sizeof(InfoFeld_t)); //viel Code Data[i].Felder[NbFelder].Index=j; [/c] Mit der IDE von MS komme ich überhaupt nicht klar, bevor man da das Programm zum Compilieren gebracht hat hat man schon die Schnauze
-
Thread
Motordrehzahl eingeben Arduino
] = '\0'; strcpy(serial_in_command, serial_in_buff); memset(&serial_in_buff[0], 0, sizeof(serial_in_buff)); chr_cnt = 0; stringComplete = true; } else // Falls kein Enter kommt muss der Text gespeichert werden in dem inText Array { if(isprint(incomingByte))
else { Serial.println(F("serBUF ov-> DEL")); memset(&serial_in_buff[0], 0, sizeof(serial_in_buff)); memset(&serial_in_command[0], 0, sizeof(serial_in_command)); chr_cnt=0; } // if(chr_cnt<(MAXBUFFER-2)) } // if(isprint(incomingByte)) }
-
Thread
STM32: HAL_SPI_Receive: auch Daten ausgeben?
dem Wert füllen, was er grad möchte. Probier es einfach mal aus: [c] memset(caArrayRx, 0x00, sizeof(caArrayRx)); HAL_SPI_Receive(&hspi1, caArrayRx, 123, 1000); // oder memset(caArrayRx, 0xFF, sizeof(caArrayRx)); HAL_SPI_Receive(&hspi1, caArrayRx, 123, 1000); // oder memset(caArrayRx, 0xAB, sizeof(caArrayRx)); HAL_SPI_Receive(&hspi1, caArrayRx, 123, 1000); [/c] Vllt. hast noch nen LogicAnalyser, dann würdest es direkt sehen ob das Auswirkung hat.
-
Thread
ESP32 und die "String" Funktion: Finger weg!
eben. Ich muss mich da nicht anpassen, ich drehe mich um und gehe. [c] memset(msg, 0, sizeof(msg)); /* Wichtig, msg wieder löschen! */ /* Document Header */ strcat(msg, "<!DOCTYPE html>\ <html lang=\"de\">\ <head>\ <title>ESP Solar Debug</title>\ <style>\
Thorsten M. schrieb im Beitrag #7815876: > memset(msg, 0, sizeof(msg)); /* Wichtig, msg wieder löschen! */ Es reicht völlig aus, nur das 1. Byte zu leeren: [c] msg[0] = 0; [/c] Thorsten M. schrieb im Beitrag #7815876: prozent = (int)(((Data.UBatterie
-
Thread
Struktur Byteweise in EEPROM speichern bzw. von dort laden
nicht um die einzelnen Variablen kümmern muss? Also im wesentlich so etwas: for (n = 0; n < sizeof (struct FunctionVar); n++) { pZieladresse = EEPROM_Read_CHAR(EEPROMAdresse); pZieladresse++; EEPROMAdresse++; } Anbei mein Lösungsansatz etwas ausführlicher im Anhang
eine Union deiner Struktur mit einem Byte Array, was genau so groß ist, wie die Struktur selbst. (sizeof (struct FunctionVar)) Du kannst dann auf einzelne Bytes auf Byte Array in einem Loop zugreifen, so wie es vor hattest.
-
Thread
c write RS232
hat einen Wert. Funktionen wie open() geben einen Wert zurück. ein [c] n = write(fd,Port_LED, sizeof(Port_LED));[/c] sollte reichen.
DirkB schrieb im Beitrag #2157774: > ein n = write(fd,Port_LED, sizeof(Port_LED));sollte reichen. yo stimmt ! ich kann das ganze array raushauen ! super danke euch mfg marco