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.

Program Musings - The Power of Finite State Machines

As I sit here writing a program for my Intro to Programming class, I feel the urge to blog about a topic that has become ever so important to handle dealing with strings.  I know, it's such a fun topic and everyone is waiting to hear about working with strings and such, but the main point of this blog right now is to talk about the power of the finite state machine.

For those of you who do not know what a finite state machine is, you can search for it on Google or get the basics at Wikipedia.  I will not be talking about what a finite state is, but how powerful they are as a tool to solving engineering problems.

The power of finite state machines, or FSMs (not to be confused with the Flying Spaghetti Monster, the diety of Pastafarianism), is that they can encapsulate output behavior based upon previous actions.  This gives the ability to make decisions in the present based upon past actions.  In terms of robotics, this is a powerful tool since we can encapsulate chains of actions and behaviors that can appear to do jobs on their own.  In computers, it allows for dynamic chaining of events based upon user input, etc.

If you haven't studied too much on FSMs and you are an engineer, please consider touching this topic as it appears to have many practical applications in problem solving, and for the non-engineer, I would recommend it as well since FSMs are so abstract that they can apply to anything from economics to sociology to business, or anything that has different states that encapsulate behavior and next states are dependent on previous actions.

The Beginning of a Causal Blog

So I decided to make this blog as a way to journal my education in signal processing, robotics and automation, my focus areas of study as an undergrad in Electrical Engineering at the University of Texas at Austin.  Right now I am in a class called EE 313 called Linear Systems and Signals and this is by far one of the most interesting classes that I have taken at UT, so much to the point of where I have actually started to read the book for enjoyment to learn a little bit more.  Right now I am getting ahead in 313, covering such topics such as properties of the Fourier Transform, filer design, and design of receivers that not only do not distort the signal, but are able to amplify the signal as well.  All this stuff has practical application in regards to design of sound systems, television screens, cell phones, optical materials, etc.  In other words,  systems and signals affect us in almost all aspects of our life.  I'm not sure where this will take me, but I am reminded by this clip...

I thank the website Coding Horror for finding this gem of a 1980's movie clip.