I finally broke down and bought the student version of MATLAB. Even though I feel that Mathematica is superior to MATLAB, especially when it comes to data visualization and symbolic math, the fact that my linear circuit analysis class requires that you use MATLAB was enough to push me to the dark side. I’ve made a special plot using MATLAB to break it in. This is a plot of the output voltage of a boost regulator that I made using some spare parts. It takes 5V and outputs up to 30V. The output voltage is measured using a voltage divider and an ADC on an ATMega168. This reading is printed to the UART (for logging, this is how I produced the plot) and it also adjusts the duty cycle of a PWM on the AVR to regulate the output to the desired voltage. From the plot you can see that using a bigger capacitor helps minimize the voltage ripple but it also seems to let the duty cycle vary a lot. Perhaps some simple averaging or rate limiting could help lower the ripple even more. I was shooting for 20V output, but it keeps wanting to output a bit higher. Maybe I need more precise measurements of the ratio in my voltage divider. Regardless, the precision and accuracy of the output voltage isn’t too important, it gets regulated down to an accurate voltage up to 16.5V using an op-amp. Why go to all this trouble? I’ll explain in a later posting…
Archive for the 'Programming' Category
Ever have those demons inside your computer that you swear are messing with your bits and producing random errors? Me too. During one of these bug chasing marathons, I wrote a FPU dumper that prints out the state of the x87 FPU whenever it is called. The program that I was working on was getting random numerical corruption on an older version of Cygwin’s GCC. I traced the corruption to a single line that had a floating point divide. The value was fine before the line was run and clobbered to a NaN after the line was run. Great, demons. The FPU dumper helped me realize what was going on. Long story short, there was a bug in newlib (Cygwin’s standard C library) which caused it to not conform to C99. The bug didn’t show up in my newer version of GCC because GCC provided a builtin for the missing C99 math function. I sent off a description to the bug to the newlib mailing list and Jeff Johnston had a patch within an hour. Thanks Jeff!
Regarding the FPU dumper, it is a header file that you include in whatever code you want to check the FPU from. If you uncomment the #define FPU_DUMP_VERBOSE line in the header or define it in the compile line (-DFPU_DUMP_VERBOSE), it prints off a bit more info on the status registers. To do the actual dumping, simply call FPUDUMP from anywhere in your code. The FPU state is saved into a struct, parsed, printed, and the FPU state is restored from the struct lest something like printf messes with the FPU in some way.
The code is licensed under the zlib license. The output format is borrowed from the excellent OllyDbg, my favorite Windows debugger. Feel free to comment/criticize my code!
Here is the code!
Example code calling the dumper:
#include "fpu_dump.h"
double x = 243;
FPUDUMP;
x = x / 3.14;
FPUDUMP;
An example of the verbose output:
================== MAGICAL FPU INSPECTOR ==================
From fpu_dump.c line 20:
Status: 0x0020
Invalid: 0, Denorm: 0, Zero Div: 0
Overflow: 0, Underflow: 0, Precision: 1
Stack fault: 0, Error summary: 0, TOP: 0
C3: 0, C2: 0, C1: 0, C0: 0
Control: 0x037F
Invalid Mask: 1, Denorm Mask: 1, Zero Div Mask: 1
Overflow Mask: 1, Underflow Mask: 1, Precision Mask: 1
Rounding: NEAR, Precision: 64, Infinity: 0
3 2 1 0 E S P U O Z D I
FST 0020 Cond 0 0 0 0 Err 0 0 1 0 0 0 0 0 (GT)
FCW 037F Prec NEAR,64 Mask 1 1 1 1 1 1
ST0 EMPTY NAN REG0
FFFF 00000000 00000000
ST1 EMPTY 0 REG1
0000 00000000 00000000
ST2 EMPTY 0 REG2
0000 00000000 00000000
ST3 EMPTY 0 REG3
0000 00000000 00000000
ST4 EMPTY 0 REG4
0000 00000000 00000000
ST5 EMPTY 0 REG5
0000 00000000 00000000
ST6 EMPTY 16045690984229361664 REG6
403E DEADBEEF BAADD800
ST7 EMPTY 16045690984229355520 REG7
403E DEADBEEF BAADC0DF
========================= GOODBYE =========================
About half an hour after my last post, I realized that I was exporting the triangles as vertex1, vertex2, vertex2 instead of vertex1, vertex2, vertex3. Amazing what a one character typo can do… I feel awesome.
Edit: Looks like the I got the texture coordinates right - I was able to add the texture without any trouble!
Last night I took a big step in my reversing of the Guitar Hero mesh format. For a while now I have been trying to decode the meshes so that I can import them into StepMania for a Guitar Hero-ized version. I have all the vertices, their normals, their colors and their texture locations decoded. The triangles look decoded correctly for the most part but it looks like it is missing a few. The only left is the correct interpretation of the normals - right now MilkShape doesn’t want to display a solid of the mesh, just the wireframe. I’ll post more on the development as I continue. Once I get the decoder in working order, I’ll release the source code.
