Embedded Systems - My Zen Area of Hardware and Software

OK...maybe not Zen for a lot of people at UT who REALLY got pissed off at that lab that requires the sending of data between two boards because of poor lab instructions, confusion on how to clear interrupt flags, and anything else that is just aggravating.  But when I took the class semester, despite having moments of frustration I felt that the class was a valuable bridge to ram home the fact that hardware and software are mutually dependent.  Without well written software, the hardware or user interface doesn't behave well and has the possibility of frustrating an end user, and without good hardware, your software might as well be that guy that has a good idea but never follows through.

I guess my main point here is, from my experience, success in an embedded systems class requires good knowledge of both hardware and software.  For instance, lets take a LCD screen.  Simple enough and to most people not an impressive device considering there are far more advanced displays out there, but there is a learning curve in getting the hardware to work properly.  When dealing with new hardware you should ask several questions.  Some of the ones I think of are:

1. Have I done an over-view of the documentation?
2. How do I interface with the new hardware?  Is there more than one way to do this?
3. What are the timing constraints?  For instance, what is the proper set-up and hold time to get data and commands in and out?
4. If I am dealing with a hardware driver is the interface simple enough to write in the embedded processors assembly language (ARM, CPU12, etc.), or is the interface so complex that the added abstraction of a higher level programming language such as C will help managing the project better and in a more timely manner?
5. What assembly level instructions would be helpful in communication.?

Not all the questions that should be asked, but enough to get some research going and to help plan out to make tasks easier and less prone to simple errors.