W.S. schrieb:
> Ich geb dir mal ein Beispiel von nem STM32F103ZET6 im Anhang.
Warum, W.S., warum...
1 | #define integer short int // d.h. "integer" ist 16bit und "int" 32bit? Aha, intuitiv
|
2 | #define word unsigned short int // Auf ARM ist ein word 32bit.
|
3 | #define byte unsigned char
|
4 | #define dword unsigned long
|
5 | #define qword unsigned long long
|
6 | #define int64 long long // aha int64 ist die signed variante von qword - macht natürlich sinn - warum jetzt aber kein int32, int16...?
|
7 | #define cardinal unsigned long //wollten wir den nicht dword nennen?
|
8 |
|
9 | // Wieso nicht einfach #include <stdbool.h>?
|
10 | #define bool unsigned char
|
11 |
|
12 | #define TRUE 1
|
13 | #define FALSE 0
|
14 | #define true 1
|
15 | #define false 0
|
16 |
|
17 |
|
18 | // warum nicht einfach das vordefinierte "and", "or", "xor" nehmen?
|
19 | #define MOD %
|
20 | #define XOR ^
|
21 | #define NOT ~
|
22 | #define AND &
|
23 | #define OR |
|
24 |
|
25 | #define POINT struct TPoint
|
26 | #define RECT struct TRect
|
Warum um alles in der Welt überall #define? Bist du noch in der
Macroassembler Zeit verhaftet? Warum nicht "typedef", was einen
richtigen, gescopten C-Bezeichner erzeugt und keine ulkigen Syntaxerror
produziert? Warum nicht die vordefinierten typen (u)int8_t, (u)int16_t,
..., (u)int64_t aus der <stdint.h> verwenden und sich selber einen
Haufen inkonsistenter Typen definieren?
Es ist ja verständlich, die Beispiele und Libraries von ST nicht zu
verwenden. Aber dann stattdessen so etwas zu produzieren? Da doch
lieber die "etablierte" StdPeripheral Libary, ST Clock Setups etc.
verwenden.
