Troubleshooting

One of the biggest challenges in ECE 344 is troubleshooting on the system.

I mean walking through typing stp, then rrd when you want to read the registers.

In comes typical troubleshooting without a debugger, normally you stick some print statements in there and wait for the print fest to begin.

This bothered me because we can't really do this in our architecture very easy. The nice thing is that we learned about sub routines, and you can treat sub routines as functions if you do it right, so what did I do?

I wrote a sub routine that will print the register values at the time you branch and link, the main limitation, is that interrupts can change your register values once you've entered into the subroutine. This is where the mailbox architecture comes in, if you design your system so that the interrupts do as little as possible and leave everything as untouched as possible, you can then go into your print subroutine and it will print the register's last value.

There are probably plenty of other uses you can find for this routine, and maybe even better ways to use it, for example when you enter this subroutine it waits for a key press before you can exit. Once that happens you can return from your branch and link, this is great because now you don't just blow through your whole program before even really seeing anything.

This is untested code as I am unable to make it to the school until Monday at the earliest, but if you want to give it a try I'll link to it at the bottom.

Changes you'll want to make to allow this to integrate with your program is finding your location in memory you can stick the long ascii string I've built.

Additionally you'll need a 32 bit to ascii converting branch and link, which i haven't written, but we have written for our latest program. This will convert the actual register values to a printable value, as well as you'll need a push and pop routine at the beginning and end, with the pointer jumping by 40 each time, if you don't have this you'll have to find a way to get the data from the register's instead of memory as I'm doing.

As I have time I'll upload more files and a more complete solution but this is very far along and should only require small amounts of modification.

NOTE: As with any file you download from google documents, unfortunately just directly downloading it will have format issues. Copy and paste the contents to a new file and save as a .s file, otherwise you'll be chasing your tail trying to find problems that really don't exist.

Check out the code here: Print Function

Thoughts on OS's

So here are my thoughts on os's these days.

I just recently got my new HP netbook. It's a great little device, but here's my worry, it's not very powerful and it's running windows, My old laptop is running windows as well and is slowing to a crawl.

What are some common causes of slowed down computers?
From Computer Hope:

Hard disk drive is short on available disk space.
Several software programs have been installed/uninstalled leaving behind bad files and/or confusing the software.
Data Corruption.
Outdated drivers
Computer is overheating.
Corrupt OS.
Bad Hardware.

It would appear there are two common causes here.
1. The hardware capability is declining.
2. Operating System related errors.

Hold up before you start getting all upset and claiming that if the people who wrote the programs cleaned them up right then you wouldn't have these problems.

What I want to know is why these programs are becoming so integrated with the OS that the OS can't simply clean itself up?

I was watching the Google OS talk as well as reading a little on it. One of the things I noticed and it's becoming a bit of a theme across OS developer's now a day's.

Let's build OS's that are designed for specific hardware and really only market for that.

What I'd really rather see is OS's that when you load them up will look at all hardware connected and self configures itself to be the most optimal OS for that hardware. What this means is now instead of having 300 print drivers loaded into your system and 45 wireless network card configurations, the OS looks at what you have and decides what's best and get's rid of the rest. Typically true hardware to the system should have only those drivers loaded, no more, no less.

I know this sounds crazy and in some ways it is, but what happens next is the OS is also linked up with the web, so let's say you plug in a new hardware item a new sound card, a new stick of ram or something. Things might be a little hokey but with a basic set of drivers that will control (in a limited way) most hardware, you now tell the computer to rescan for system updates, at which point you can optionally load the new driver's for this new device onto your system, and again it re-configures itself to run as optimally as it can with this system.

What can this mean for boot up times? Well if the OS doesn't have to constantly be verifying what equipment you have and assume you just plain have it and go forward from there. If/When it runs into a hiccup such as it expected a stick of ram somewhere and didn't see it, it jumps to the degraded mode until you either update and "auto" re-configure the system or repair the problem.

I think if you can resolve hardware checks as well as re-design the bootup to start simultaneously kick off processes that will help considerably.

Once more, you won't have to constantly be pinging the devices (wasting power) just verifying that the components are there.

Syntax

Syntax doesn't require a whole lot of explaining. Mainly get a good source of information that you can understand, in this case we really only get a .pdf file with the reference manual so you really need to make the best of it.

In our "compiler" the system converts the assembly code that you wrote to a 32bit instruction.
This instruction can be analyzed by the student by breaking it down into opcode, from there that will tell you what kind of data can reside in the rest of the instruction.

One thing I'd like to do is write a syntax checker for the PPC 403 that we're using. This would be particularly helpful in writing code off site, and then making sure the syntax is right.

Once you can sucessfully "compile" then you're on to the testing, and possibly will return to this section.

Let me know what you think!!

Google Voice Screwups

This is a pretty hilarious site, they allow anyone to post google voice to text translations which many times turn out to be quite hilarious.

http://gvscrewups.blogspot.com/

Now here's my question some people post the "before" and after versions, is it possible to improve the translator's capabilities knowing this information?

Check it out and let me know what you think.

Google Voice

I just ran into another situation where Google can integrate their google voice application into, Google Maps!

I was searching for my doctor's office, it brought up an address and phone number, why not have a clickable link for those logged in that have GV, and they can click call this number and select which phone to ring, OR even text message address/directions to myself....

Just another little idea for the wide world of google voice

Concepts, the Leonardo of Programming

If you don't understand "what" you're trying to do, it's going to be very difficult to write code and/or tests for it.

Learning concepts can be difficult, some of the main things you need to think about "conceptually" is breaking any task down into 3 parts,

1. Initialization
2. Code that does the actual work (algorithm)
   
3. Exiting

For initialization you can look most of the things up in the user's manual, once you know how to setup the actions you will be using, you can then begin to look at what you're actually wanting to do, which brings us to algorithms.

Algorithms are "how" you're going to accomplish the task you're attempting to complete. My favorite method is drawing it out in a flowchart design. But I have to "see" what I'm doing and that's one way of doing it, once you've managed to really nail this idea down, you can frequently just do it in your head, and reserve doing flow chart's for the more difficult designs that you really can't wrap your head around.

If you don't know your algorithm it's much like trying to write a paragraph about a subject that hasn't been given to you, you'll keep writing and rewriting your paragraph until you finally get the subject, but that doesn't seem very efficient now does it? Figure out your subject (or what you're trying to do) and THEN write the paragraph, much like figuring out your algorithm FIRST then code up the solution, this prevents large quantities of re-writing code.

Finally when you've finished your task, are there any "clean up tasks" that you need to complete? Do you need to return the register's to their original values? Do you need to clear out memory so that another operation doesn't accidentally use data you've shoved out there? Do you need to pop the stack? These are all things you need to answer when you've finished the task your algorithm is attempting to complete.

School Reports

What's wrong with School reports today?

Frequently we are told you need X number of pages, so you push and pull at your words to try to force as many as you can out, many times rather then a clear and concise report you end up sometimes obfuscating ( to be evasive, unclear, or confusing) things.

When will it become clear that writing shorter reports that convey the information required are better then long drawn out reports that are 90% bloat and 10% real information?

Looking at Needless words I started thinking about this, I don't know how many reports this semester alone I've written that are really just bloated with meaningless information, in a simple attempt to pass as a "useful" paper.

When will engineering students write reports as clear and concise as the work we will need to produce?

I have read requirements documents that are so indirect that it's a wonder how people can implement them, and in fact I was once told that if they didn't understand the requirements they were writing that well, they would write it more then once in a couple different ways, so as to give them an "out" when the software comes that they can say "this isn't what I meant" and force you to change it.

That's a tough paragraph to read. Re-Worded: If you don't understand the material you're writing about, make it so the people that are reading it can't understand it.

Start writing what you MEAN. Stop writing bloat into your reports. I'm going to give this a try on my next Microprocessors report, I'll let you know what kind of score I get.

No one likes bloat. Me least of all.

Designing Learning

In today's day and age, is the current methodology of teaching the best approach?

Here's my hypothesis, Changing HOW we are taught can net greater results on a broader spectrum of students.

It's a well known fact that there are different types of learning

from: LD Pride

These Learning styles are, Auditory, Tactile, and Visual.

How can we improve each of these area's in today's classroom?

I believe that if a student doesn't "care" about what they're learning, it's like trying to force oil to mix with water, it doesn't work.

What we need is something that will be the go-between from the oil (the student) and the water (the material). One way to do this is by not stifling creativity, and in fact fostering it, the best engineers in my opinion are the ones who find the most creative solutions!

Point in case, I'm working on my microprocessors class. Right now we are learning how to handle interrupts, using timer's, buttons, led's and various other things. Individually these projects are dry and don't inspire creativity.

My solution suggests that the student attempts to create a game in one case. For example, Simon Say's, a great game, could be a pretty easy one to build, but in building that you learn a lot of things, here are many of them I can think of:

1. LED Outputs
2. Pointers
3. Timer's
4. Interrupts
5. Button Presses
6. LCD (maybe give the user a score?)
7. Stack
8. Algorithms

So I could manage to learn all those things and actually have fun doing it.

I am so far having a blast with the class because I can SEE the potential I'm given while learning this information, but many people see it using blinders, where they can only see what's directly ahead of them, and not see the potential, I believe that letting student's pick projects force them to learn how to design a project, work through the team building details, and the final implementation. I don't think this should be a one time project that is part of graduating, but shoot find a project that the student needs to complete that takes each piece, and as you learn, you can build more and more.

For example, let's say you're given a project as a freshman, some of the techniques to build this project may require math level x (doesn't have to be overly difficult), as you push through each semester you can learn more and then literally apply it to a project as you go along, so when you finish your degree you can say...Look I completed this project and it required knowledge and skills in all these area's.

How do you think learning should be implemented in today's day and age? And do you have any ideas for programming that may induce learning indirectly?

Design and Programming..a Love affair

Let's take a look at design.

If you design your project well, looking at all possibilities up front without coding a single thing you can catch some problems up front that you may run into. One of those may cause messy or unneeded code! That's again the beauty of the artist they can choose whether they want to keep repainting the exact same thing or really go out there and paint something new!

What all can be designed?
For Microprocessors where you have a limited number of register's to use, defining a personal/project standard allows greater code re-use, as well as less code and easier to understand code.

If you define a register as the UART pointer from the beginning and make sure not to change it, you won't have to constantly be re-writing the code to setup a pointer. How many times does that have to happen? Well if everytime you have to drop into your interrupt service routine and determine whether it was a RX or TX bit that sent you running, that's 2 times for every "interrupt". I know it doesn't sound like alot of time, but when you run into a situation where your time is critical, 2 instructions can make that difference.

The short time that it takes to design your project, can multiply the rewards exponentially.

Deciding how you want to setup each module is part of design, would you rather setup the entire initialization in your main routine for each module, and let that handle everything OR modularize everything and put ALL uart related items in the UART section.

This brings up the good point of .include files, by putting all your setup into a .include file, you can now start using that file in new projects and rather then constantly having to re-write a subroutine you just write it once, and any improvements you make are better for all programs, (provided they are in fact better). Writing this I already see a flaw in the design of the program we made in our latest lab!

Guess what? Looking back on it, I realize we have a file called variables that contains the ".set" items that point to the UART and all other associated names, this means that every file that I try to .include the UART routine into has to have the entire variables file included, Guess what we did that with a "register setup file too!!!".

How can this be improved?

I can put all registers that the UART EXPECTS to use in it's .include file as part of the initialization, and make sure that any time I use that file those particular register's are in that state before the subroutine is used, this can occur by pushing the register settings to the stack before any updates to them, then reverting them back, will allow the subroutine to keep using them as expected.

If there is one thing I'll stress, Try to make your code as uncomplicated and easy to understand for yourself and others, Implementing a design can aide in that.

Let me know how you design!!

How to Microprocessor

Recently we were given a lab in microprocessors that requires us to handle alot of interrupts somewhat simultaneously.

For someone that walks into this lab unprepared it can look like a lot, but for some that's a challenge and for other's that's an active barrier, rather then choosing to be prepared for it, you just walk through and hope for the best.

Reading manuals on the syntax or basic tools to use while programming the microprocessor can be boring, and often time's it's easy to forget about what you just learned.

How do you approach a problem like our latest lab (or any other programming project for that matter)

1. Design --You need to know the "picture" you want to paint with your code.
2. Concepts -- You need to know "how" painting that picture can be accomplished
3. Syntax -- You need to know how to "paint" that picture.
4. Testing -- You need to know how to tell if the picture "looks" like you want it to?

I think those are the 4 most important concepts of programming that really need to be understood.

I'm going to post a series of posts about these particular topics!!

Defining Moment

What's your defining moment?

At what point in your life did you decide, enough talking about doing something and literally start doing it?

What pushed you over that edge?

I feel like many times I talk and talk about doing something but never end up really doing it, which is why in some deep recesses of my heart and mind I started this blog. I got tired of talking about all the stuff I "want to do" and started doing them. Don't get me wrong, I've got along way to go before I feel like I've had that "defining moment".

I've done a few things in my life and when I talk about things I'd like/am doing, I suprise other classmates, they're amazed that I do some of the things I do, but then again I talk to classmates and I'm amazed at the things they're doing, it's because when you get into that "routine" of it's just what you do, you forget how special those qualities are.

Keep pushing yourself to your limits and it'll payoff, everyone's defining moment is different, one man's trash is another's gold. Just because the things you do don't sound interesting to you anymore, or 'special', don't forget that it's someone else's gold.

If you have the opportunity to really connect with people and you can mentor someone else interested in what you're doing, do it by all means, you might be that person that pushes someone just that much closer to a defining moment.

Sometimes I think that my Mountain talks with Phil helped push me over that edge, when I came upon the epiphany of the Guitar Hero Challenge, That's when I realized I can do so much more when I push myself to that limit, and I'm fully capable of it too, I just have to realize that excuses are what sometimes consumes us. Being able to understand the difference between an active and passive barriar and how to hurdle it is the biggest part in learning who you are.

Good luck finding that defining moment, and I encourage you to keep pushing on towards it, you may one day look back and realize that your moment occurred and you didn't even notice it.

Google Calendar

Short "rant/post" today about GCal

Google really needs to add a feature you can say that the weekend after date x is the weekend event x occurs.

For example my wife and I went to volleyball on our first date, it was the 7th, so I would be interested in setting an event reminder that will remind me to look up the schedule on the weekend before (or after) the 7th and see if there are any games we can attend.

I think it would be nice to allow not date specific (or day specific) recurring events, but rather recurring events that can be determined easily based on the calendar date of that year....

Just and idea. Let me know what other features Google Calendar should add to their Gcal