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

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!!

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!!

Microprocessors 10/1/09 -> 10/7/2009

Here are the in class examples that we've covered in class since the 28th

Revised Blink LED's

Branch And Link

Fibonacci using Stacks

Good luck and let me know if you have any questions!

Microprocessors 9-28-09

In class today we reviewed the LED problem from last class, then we moved on to rs232 programming.
The updated and working LED program Dr. Pollard wrote is located here: the only difference is nop's

The link to the in class exercise is here:

Basically what we reviewed was receiving data in the RX FIFO, as well as spitting that data back out in the TX FIFO

Microprocessors 9-24-2009

I've got the in class posted here:

Things to remember:
a 1 written to the offset of 4 to the memory location of the LED's tells the DDR it's in "input mode" a 0 written tells it its in output mode.

Writing to the DREG will turn the LED's On or Off once you put the register in output mode.

Note: the above program wasn't working in class, I'll be posting an updated version tonight that works (somewhat different then the version we did in class)

Here is the updated file that works, here:

One thing to note is that you'll want to copy and paste the contents of these files into a new file, I had issues getting it to compile until I just copied over.

DDR means Data Direction Register.
DREG means Data Register.

Microprocessors 9-17-2009

The ECE 344 Microprocessors in class examples will be posted here:
The example below takes a list of 1000 numbers generated from a random number generator from 0-10,000, then in groups of 0-999, 1000,-1999, 2000....

# in class 9_17
# work on comparison and branch commands
.org 0x100
# clear out registers
li r1, 0
li r2, 0
li r3, 0
li r4, 0
li r5, 0
li r6, 0
li r7, 0
li r8, 0
li r9, 0
li r10, 0
li r11, 0x200
li r12, 1000
mtctr r12
loop: lhz r13, 0(r11)
cmpi 3, 0, r13, 999 # P303 for cmpi
bt 13, chk2 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r1, r1, 1
b nextv
chk2: cmpi 3, 0, r13, 1999
bt 13, chk3 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r2, r2, 1
b nextv
chk3: cmpi 3, 0, r13, 2999
bt 13, chk4 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r3, r3, 1
b nextv
chk4: cmpi 3, 0, r13, 3999
bt 13, chk5 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r4, r4, 1
b nextv
chk5: cmpi 3, 0, r13, 4999
bt 13, chk6 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r5, r5, 1
b nextv
chk6: cmpi 3, 0, r13, 5999
bt 13, chk7 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r6, r6, 1
b nextv
chk7: cmpi 3, 0, r13, 6999
bt 13, chk8 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r7, r7, 1
b nextv
chk8: cmpi 3, 0, r13, 7999
bt 13, chk9 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r8, r8, 1
b nextv
chk9: cmpi 3, 0, r13, 8999
bt 13, chk10 # bit 12 is less then, 13 is greater then, bit 14 is equal, 15 summary overflow
addi r9, r9, 1
b nextv
chk10: addi r10, r10, 1
b nextv

nextv: addi r11, 0x2
bdnz loop
nop
here: b here

Oddly enough, the spacing on the blog doesn't take so all the lines are left aligned, sorry.

ECE 344: Microprocessors

Microprocessors 9/17

The example below takes a list of 1000 numbers generated from a random number generator from 0-10,000, then in groups of 0-999, 1000,-1999, 2000....

Microprocessors 9/24

Things to remember:
a 1 written to the offset of 4 to the memory location of the LED's tells the DDR it's in "input mode" a 0 written tells it its in output mode.

Microprocessors 9/28

In class today we reviewed the LED problem from last class, then we moved on to rs232 programming.

Microprocessors 10/1-10/7

Here are the in class examples that we've covered in class since the 28th

How to Microprocessor

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.

Design and Programming..a Love affair

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!

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.

Syntax

Syntax doesn't require a whole lot of explaining. Mainly get a good source of information that you can understand

Troubleshooting

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