Im Forum und im Wiki
-
Thread
Empfehlungen für PIC-Programmierer und Debugger gesucht (bin kein µC anfänger mehr!)
6800, 6809, 68000/Coldfire, 8032, 80x86, Sparc (v7, v8, v9), MIPS, 56002, 96002, DSP32C, 21xx, TMS320C40, TMS320C80, TMS320C6xxx, ARM (7,9,M0,M3,XScale), PowerPC, AVR, AVR32, PIC12/16/18/24/32,... irgendwas werde ich sicher noch vergessen haben. In 30 Jahren kommt eben einiges zusammen, und der Überraschungseffekt
6800, 6809, 68000/Coldfire, 8032, 80x86, Sparc >(v7, v8, v9), MIPS, 56002, 96002, DSP32C, 21xx, TMS320C40, TMS320C80, >TMS320C6xxx, ARM (7,9,M0,M3,XScale), PowerPC, AVR, AVR32, >PIC12/16/18/24/32,... Achsooooooo, die sind alle gleich? wusste ich nicht.
-
Thread
Das alte Problem: Datentypen
Bit > sizeof(char) = 1 , also 16 Bit > sizeof(long) = 2 , also 32 Bit. Beim TMS320C40 (32-Bit-FP-DSP) war [pre] sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long) == sizeof(float) == sizeof(double) == 1 [/pre] :)
-
Thread
Controller mit FPU
Wär nicht erstaunt, wenn man den für Newton-Raphson verwenden kann. So wurde das u.a. auf dem TMS320C40 gemacht. Der hatte einen Befehl, der mit Hilfe einer Lookuptabelle einen 8 Bit genauen Näherungswert für den Kehrwert einer Zahl ermittelt hat. Das Newton-Raphson-Verfahren verdoppelt mit jedem
-
Thread
Basic und/bzw. vs - C Erfahrungsumfrage
dem gerechnet wird. Ich bin das erste Mal auf diesen Sachverhalt gestoßen, als ich mit einem TMS320C40 (Floatingpoint-DSP) herumhantierte. Weil ich mir anfangs nicht sicher war, ob man mit double eine höhere Genauigkeit erreicht als mit float, habe ich in einem Testprogramm sizeof(double) ausgegeben