-
Thread
Binäre Konstanten in C
Ergebnisse die folgenden, für klassische C-Arrays wohldefinierten Ausdrücke liefern sollten: [c] sizeof Tout[0] Tout + 1 [/c]
auch machbar sein. Man wird aber eben auf bestimmte Funktionalitäten verzichten müssen, wie eben sizeof oder z.B. Zeiger auf die Elemente.
-
Thread
Pointer als parameter von Funktion zurück
t numOfDoubled = 0; for(uint8_t x=0; x<4; x++) { a[x] = 0x10; } work(&a[0], sizeof(a), c, &numOfDoubled); for(uint8_t x=0; x<numOfDoubled; x++) { printf("%02X ", c[x]); } return EXIT_SUCCESS; } static void work(uint8_t* a, uint8_t numOfA, uint8_t* resArray
Johannes schrieb im Beitrag #6443160: > work(&a[0], sizeof(a), c, &numOfDoubled); &a[0] ist quatsch, da a[0] bereits die Adresse ist.
-
Thread
for-schleife rückwärts bis auf 0 laufen lassen probleme
subtil, denn bei for (ushort_t ...) kann das Verhalten solcher Spielchen davon abhängen, ob sizeof(short) < sizeof(int).
-
Thread
STM32 HAL_SPI_Transmit() richtig?
HAL_SPI_Transmit(&hspi1, data, sizeof(data), HAL_MAX_DELAY);
-
Thread
struct aus rohbytes initialisieren
// jetzt will ich "sensordaten" befüllen // mit memcpy geht es,statt laenge geht // auch sizeof(sensordaten) memcpy(&sensordaten, data, laenge); // geht das auch mit einer Zuweisung und Typumwandlung // des uint8_t *daten? // wie muss ich hier casten? sensordaten = (??? ) daten
jetzt will ich "sensordaten" befüllen > // mit memcpy geht es,statt laenge geht > // auch sizeof(sensordaten) > memcpy(&sensordaten, data, laenge); > > // geht das auch mit einer Zuweisung und Typumwandlung > // des uint8_t *daten? > // wie muss ich hier casten? > sensordaten
-
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
Initialisierung: pointer array
ohne das ich immer nachzählen muss? :D z.b. sowas: {.buffer = (unsigned char*)"abcdefz", .len = sizeof(.buffer)}
struct schrieb im Beitrag #6420442: > z.b. sowas: > {.buffer = (unsigned char*)"abcdefz", .len = sizeof(.buffer)} Das sizeof bezöge sich hier die Größe des Zeigers auf den Buffer, also z.B. 4 Bytes auf einer Plattform mit 32 Bit, oder 8 Bytes auf 64 Bit - und nicht auf die Größe des Buffers selber
-
Thread
STM32G071G8 I2C schickt keine Bytes?
[c] buffer[0] = 0x40; buffer[1] = 0x06; HAL_I2C_Master_Transmit(&hi2c1, 0x7C<<1, buffer, sizeof(buffer), 1) [/c] Im Anhang ist zu sehen wie das ganze dann auf der Leitung aussieht. Weiß jemand eventuell weiter und hat eine Idee was schieflaufen könnte? Das Versenden über I2C mit der
-
Thread
Probleme bei Pointer in C. Code crasht
Wie schon geschrieben wurde, gibt es einen Array-Überlauf, wenn sizeof(table_T) > sizeof(uint32) ist. Die Zeile [c] resp_table = (table_t)(init_s->table); [/c] verstößt gegen die strict aliasing Rule, d.h. selbst wenn es keinen Array-Überlauf gibt, ist
-
Thread
Bitdekodierung aus Bytepuffer
*p; for(p=Dsc; p->z; p++) { signed long i; memcpy(i, data + p->s/8, sizeof(i)); i<<=sizeof(i)-p->n-p->s%8; i>>=sizeof(i)-p->n; p->z=(int16) i; } [/c] Nur für int16 als Ziel und wohl weder lauffähig noch kompatibel sondern so runtergetippt. Ich
müsste selbst erst googeln wie es richtig gemacht wird :D [c] int datatemp[10]; while (i < sizeof(datatp)) { datatemp[cnt] = int((unsigned char)(datapt++) << 24 | (unsigned char)(datapt++) << 16 | (unsigned char)(datapt++) << 8 | (unsigned char)(datatp));
-
Thread
FATFS f_lseek für den schnellen Zugriff beim lesen
) | e_Result; else { nbytes = sizeof(u8a_SrcBuf); // max. byte anzahl im localen puffer, letztes byte ist '\0' u32_BytesToRead = (uint32_t)fileSize; // anzahl der insgesamt zu lesender bytes
nbytes = (size_t)u32_BytesToRead; // anzahl der restlichen zu übetragenden bytes wenn nbytes < als sizeof(Src_Buf) s32_ReadBytes = SYS_FS_FileRead(handle, u8a_SrcBuf, nbytes); if ( (e_Result != SYS_FS_RES_SUCCESS) || (s32_ReadBytes == -1) ) u32_
-
Thread
AT32UC3C beide DAC Kanäle A und B laufen nicht gleichzeitig
/* Assign and enable GPIO pins to the DAC function. */ gpio_enable_module(DACIFB_GPIO_MAP, sizeof(DACIFB_GPIO_MAP) / sizeof(DACIFB_GPIO_MAP[0])); dacifb_get_calibration_data(&AVR32_DACIFB0, &dacifb_opt, DACIFB0_INSTANCE); dacifb_configure(&AVR32_DACIFB0, &dacifb_opt, FOSC0); // Configure
-
Thread
memcpy stürtzt immer ab
uint32 *data_pu32) { sint32 err_s32; err_s32 = dataInput(&addr_u32, (uint8*) data_pu32, sizeof(uint32)); return err_s32; } [/c] file 3 [c] uint8 data[2000] = {0}; sint32 dataInput(uint32 *src, uint8 *dest, uint16 bytes_u16) { memcpy( dest, &data[*src], bytes_u16);
-
Thread
Pthreads: Pointer ausgeben und wieder als Parameter übergeben
dürfte dort auch nicht deallokiert werden. In main(): [C] int *arr = (int*) malloc(nbValues * sizeof(int)); pthread_join(tid1, (void**)&arr); printf("array: %d\n", arr[0]); [/C] Zuerst allokierst du mit malloc nochmal einen weiteren Speicherblock und speicherst dessen Adresse im Zeiger
-
Thread
Pyfda und die Amplitude
(argv[2]) { w = strtod(argv[2], NULL); } } coeff = calloc((n+1),sizeof(double)); if (!coeff) { printf("phuc!\n"); return -1; } fir(n, w, coeff); /* normalize + print coefficients */ for (i=0;i<=n;i++) { sum += coeff[
-
Thread
Linux socketCan Interrupthandler mehrere CANs
strcpy(ifr.ifr_name, ifname ); ioctl(s, SIOCGIFINDEX, &ifr); memset(&addr, 0, sizeof(addr)); addr.can_family = AF_CAN; addr.can_ifindex = ifr.ifr_ifindex; if (bind(s, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("Bind"); return 1; } while(1) { nbytes = read(s, &frame, sizeof(struct can_frame)); printf("vcan1: "); fflush(stdout); if (nbytes < 0) { perror("Read"); return 1; } printf("0x%03X [%d]
-
Thread
Integer-Berechnungen mit grossen Zwischenwerten
sicher? dieser Code liefert bei mir für: [c] long long int n = LLONG_MAX; printf("sizeof(long long int) = %d, n=%lld\n", sizeof(n), n); [/c] den korrekten Output: [code] sizeof(long long int) = 8, n=9223372036854775807 [/code] sowohl auf einem CM4 als auch auf dem PC in VS2019
drin. unsigned geht natürlich auch: [c] unsigned long long m = ULLONG_MAX; printf("sizeof(unsigned long long) = %d, m=%llu\n", sizeof(m), m); [/c] [code] sizeof(unsigned long long) = 8, m=18446744073709551615 [/code] aber keine 128 Bit, auch nicht auf dem 64 Bit Core-irgendwas.
-
Thread
Nachkommastellen Arduino
ja mal den Compiler anzeigen lassen, da sollte auch 4/8/8 rauskommen: [c] Serial.println( sizeof(float) ); Serial.println( sizeof(double) ); Serial.println( sizeof(1.20658453) ); [/c] Wenn nicht, dann ist irgendwo versteckt etwas verbogen. Per default rechnet der gcc mit ARM eabi mit
gegenüber dem was das Programm berechnet. Das Programm rechnet also korrekt mit 64 Bit FP. [code] sizeof(float) = 4 sizeof(double) = 8 sizeof(1.20658453) = 8 ta = 1.206584530000000 eps = 43717.667965170294337 Los geht's! JD von: 29 8 2020 2459090 obli 23.436605537634907 ta= 1.206584531143053
-
Thread
uint16_t als ASCII mit HAL_UART_Transmit
32bit-Prozessor handelt, und die struct nicht "gepacked" wurde. Für sowas gibt es dann aber auch "sizeof()"... Harry L. schrieb im Beitrag #6390355: > Du kennst den Unterschied zwischen Binär-Daten und > human-readable-Strings? Dem sollte man kennen.
printf("Size is %ld ", sizeof(bhy_data_quaternion_t)); 64 Bit Linux auf X86 12 32 Bit Linux auf Raspi 12
-
Thread
HAL UART Fragen zum Grundverständnis
im Beitrag #6390312: > strlen(sensor_data->data_quaternion.x) Das ist Mist! Versuchs mal mit sizeof!
-
Thread
uC bleibt hängen - Ursache unklar - Fehler nicht reproduzierbar
} /* Daten übertragen */ inline void daten_senden() { senden( (char*)&Data , (uint8_t)sizeof(Daten) ); } /* Grundeinstellung vom LED laden */ inline void init_default_led() { pinMode( PORT_LED , OUTPUT ); set_port( PORT_LED , false ); LED.setOutput(PORT_LED); set_led(NO_COLOR
void konfig_senden() { /// die Konfiguration dem PC mitteilen senden( (char*)&Conf , (uint8_t)sizeof(Configuration) ); } /* Daten über USB senden und dabei den * Eingangspuffer leeren, * Daten byte-weise übertragen und * Ausgangspuffer leeren */ inline void senden(char *structPointer,
-
Thread
unions structs bildfields
von floats, 8 oder 9 Bit pro char/Byte, Es ist aber explizit erlaubt, mit einem byteptr und sizeof(Struktur) die komplette Struktur in Bytes zu zerlegen.
int8_t kann es auf einer Platform zwar geben, > muss es aber nicht. Wenn es sie gibt, dann ist sizeof(char) == 1 Byte. sizeof(char) ist immer 1 Byte, egal ob es uint8_t gibt oder nicht. Ansonsten soweit richtig. > Tja, damit ist jeder Code, der uint8_t benutzt "implemantation defined". Wenn
-
Thread
Arduino: if(String == "ein") funktioniert nicht
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))
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
Warum funktioniert dieser code nicht [C]
size = (int) sprintf(buffer, "%d", inputvalue); outpointer = (int *) malloc((size + 1) * sizeof(int)); for (i=0;i<size;i++) outpointer[i] = atoi(buffer[i]); return outpointer; } int main() { int testvalue = 8392, *pointer , size = 4, i; pointer = splitToDigits
Da M. schrieb im Beitrag #6368767: > outpointer = (int *) malloc((size + 1) * sizeof(int)); das +1 brauchst du nicht. Üblicherweise macht man so eine Zerlegung übrigens über Ganzzahldivision und Modulo-Operator. Die Rückgabe des Pointers ist auch keine gute Lösung, weil du außerhalb
-
Thread
[C] uint8_t und spriftf()
macht sinn. Wie würdest du dann casten? char s[] ="Hallo \r\n"; tx_com( (uint8_t*)s, sizeof(s)); so ?
sinn. > Wie würdest du dann casten? > char s[] ="Hallo \r\n"; > tx_com( (uint8_t*)s, sizeof(s)); > > so ? Der cast ist richtig, statt sizeof() aber strlen() oder sizeof()-1 wenn die Größe zur Compilezeit bekannt ist. Das Nullbyte wirst du im Allgemeinen nicht mitübertragen wollen.
-
Thread
STM32 SDMMC FATFS ließt Volumengröße falsch
finden kann, dann die nächste Idee: Erzeugen wir halt eins. f_mkfs ( SDPath, FM_FAT32, 0, work, sizeof work); wird mit “einem Fehler” beendet. Wenn man reindebuggt findet man, dass die Volumengröße falsch berechnet wird. Wenn man sich in der ff.c einen BreakPoint in Zeile 5564 stellt und dort anhält
-
Thread
Mikrocontroller Klausur Aufgabe Speichertest
zurückgeben else begin+=uint8_t umeinserhoehen; //nächste Adresse also um sizeof(uint32_t)erhöhen } return 0; } [/c]
auf uint8_t, uint16_t, uint64_t etc genauso analog. Vollautomatisch. Also: Du brauchst kein Sizeof-Gewurschtel, das kann der Compiler alles selber. Pfusch ihm da nicht rein, er kann das nämlich nicht nur selbst, sondern auch besser als du mit deinem aktuellen Kenntnisstand.
-
Thread
AVR Inline Optimierung kaputt?
auch 2 Byte! Ach nee.... Und das Byte hat dann irgendwas zwischen 5 und 36 Bit. Oder? Tipp: sizeof(char) liefert immer 1 IMMER Egal auf welchem Bügelbrett der Code läuft.
Arduino Fanboy D. schrieb im Beitrag #6339669: > Tipp: > sizeof(char) liefert immer 1 Tipp: Standard lesen. sizeof(char) liefert zwar immer 1, das aber bedeutet nicht das, was du meinst. Denn, wie schon geschrieben wurde, kann ein char auch mehrer Byte groß
-
Thread
8 Array Bytes to float64
übertragen. [c] uint64 tempVar = 0; uint8 eightBitsProByte = 8; for(uint8 i = 0; i < ((sizeof(uint64))); i++) { tempVar |= (dataArray[i] << (eightBitsProByte * ((sizeof(uint64) - 1) - i))); } finalVar = (float64)(tempVar / 10000); //<-- ich glaube hier laufe
richtige Schritt. Über die Signatur, char oder void Pointer lässt sich allerdings streiten. Ein sizeof hinter einem Makro verstecken ist allerdings keine gute Idee.