I believe that the most important thing that I learned from this class 
was the importance of properly adapting myself to the different problems 
that present themselves in hardware and software design. Through the 
duration of this project, 
I have worked on parts of it that were on completely different sides of 
the hardware/software spectrum. When I first started off, I was working 
exclusively on wiring up the board. 
Since I had no experience working with hardware bugs like this in the past, 
this made 
for a lot of ineffective debugging, because trying to fix random things 
on the board based on hunches is not very useful if you do not know 
exactly what the root of the problem is. After a while, though, I saw
the error of my ways and started 
using the logic probe and checking to see exactly where I had my problems. 
This, of course, was much more effective than making random stabs in the 
dark. 

After I finished wiring up the board and testing to see if it worked, I 
switched to converting functions from the MP3 to hardware. 
Due to my lack of previous experience in tasks like this, instead of 
trying to fully understand the problem first, I decided that I would 
dive right into the problem and 
start by using the original im_dct function as my framework to work with. 
Unfortunately, I did not stop to think things over as I should have. 
If I had just looked at what the code was doing more carefully, I would 
have seen that over half the original im_dct code was dedicated to
initializing a table 
using constants. In other words, it was a simple matter to just 
pre-generate the entire table and simply use this table later on. Instead, 
I spent a good week or two hacking at something that just seemed to get 
more and more complicated by the minute.

By now, it became apparent to us that before we could do anything, we 
needed to take floating point out of the code as soon as possible, so I 
volunteered to drop my work on im_dct and do so. This time, I had 
learned from my previous 
experiences in adaptivity. Instead of diving into the problem, I took a 
lot of time thInking about the problem and asking people for advice about 
so of the confusions I had. 
Also, when I finally started to attack the problem, I 
used a completely step-by-step method of implementation, starting from 
the very end of the code and slowly converting the code to fixed point, 
leaving the code before it as floating point. Although it still took me 
quite a bit of work to get floating point fully ripped out of the code 
from here, my previous experiences had taught me enough so that I was 
at least applying my efforts in an effective manner to expedite my 
progress as much as I could. Unfortunately, by the time I got the 
floating point ripped out, it was already too late for us. Even though the
deletion of the floating point code cut the code down enough to fit it on 
the board, we had simply decided to do attack the floating point problem too 
late in the game. 

I believe that learning the importance of using different approaches to 
adapt to different problems is the single most important lesson that I 
took from this class. I have never taken a class that has thrown me into 
the complete different ends of the hardware/software pools, so I have 
never seen for myself how different design and debugging for these two 
ends of the spectrum are. This class has allowed me to gain a 
lot of hands-on experience in implementing a system while 
working on both sides of this spectrum. In retrospect, 
I can see how the many issues that I faced could have been fixed or 
alleviated so much more easily if I had taken a more effective approach 
to designing and or debugging it. I feel rather sheepish for not doing 
things the right way the first time, but I believe that I have learned 
from my experiences in 545 and that I will be much more likely to take 
time to rethink my problems in the future and do a better job of finding 
a better method of adapting to it.