jamius.com

There is a difference between #include <io.h> and #include "io.h". I hope I am remembering the syntax correctly. One is for basically the compiler utilities and the other is for yours. You should be able to put your includes in your source directory or with a relative path in a sub-directory.

The reason for not using absolute paths is just what you said, although I have worked at a place for a short time that wanted absolute paths, but it causes problems. That is one of the cool things about working as a contractor. I got to see people do a lot of unique things. In this case, I discovered a bug where to copies of the same file were being used, one in one place, the other in another. You haven't got into showing structures, but the big difference was the structures were slightly difference, which was something the compiler didn't catch because it compiled using the other header file.

By the way, that is another thing to remember. Always include your header file in the source file for the method. For instance display.h should be included in display.c. This way the compiler will verify that the function prototype in the header matches the function definition in the source file.

I don't want to get into to much of this because you intend this for beginners. Keeping things simple is a priority. Learning coding standards and the difference between what you can and what you should do are for future threads. As I say, C will let you do whatever you want, whether you want to or not.

I tried putting functions into another .c file then putting the function prototypes in a header file but for some reason the compiler didn't like it... so I'm sticking to my working, albeit wrong, way for now.

Anyway, I've uploaded a couple more vids... here ya go
Timers "theory" if you will Part 1.

Part 2

Sample program

Very good videos. There is something you can do to make the math work out better. You can start the counter at a value other than zero so that it counts a more manageable number of times, like 100 by starting that count at 155, or at 200 by starting the count at 55. That will make your math work out cleaner on your spreadsheet.

Programmers do use interrupts, but they can be tricky. Keeping them as short as possible is best and the first thing to do in an interrupt is to check a flag to see if you are already in the interrupt. Basically it is possible for an interrupt to get called while you are already processing the interrupt. If that happens you can run into an endless nesting of interrupts that will eventually cause a crash. Usually you just use a static variable that you set every time you enter your interrupt routine and clear as you exit. Of course, you check to see if it is set already before you enter.

Then inside the interrupt you can do the stuff like restarting the timer, re-initializing the count, and possibly doing a manual counter to get an event slower count.

Just a few thoughts, but good stuff. You are bringing back a lot of memories.

P.S. As a next step, maybe reading inputs would work. Debouncing inputs is usually something done that takes more time than setting outputs. Momentary switches are cool. You could do something like change the speed based upon how many times a momentary was pressed or counting up with a seven segment display.

Thanks! I actually DO use interrupts, especially for important things like... oh I don't know... sensors to make sure your robot doesn't fall off an edge? But it was easier to explain the other way around. Also, I've read that when you're in an interrupt all other interrupts are put on hold until you are out? I'm actually not sure as I've never tried myself.

I totally forgot that you could start the counting number at a different number. I actually did mention it in the video, but never expanded on it. Hmmm, that's a really easy way to get pretty much whatever number you wanted. I can't believe I've never thought of that before.

Also, I honestly don't know how to use a normal momentary switch. The only way I know to input something is to use the ADC. I was literally just thinking of this yesterday. I'm going to look some stuff up today. It's gotta be easy, just checking if a pin is high or not probably, I just don't know how to do it.

On another note, I'm in the process of ordering a bunch more MCUs and various electronics for me to play with. I think I'm going to develop small boards for simple purposes, like a 4 digit seven segment display board that I can just hook a couple of wires to for communication. Or an H-Bridge board I can use to power motors. Sure I could buy those things, but that's no fun (and it's probably more expensive that way.) That way I can quickly build things because everything would be so modular.

Oh on another cool note, I got communication between my Palm PDA and my MCU to work using asynchronous communication and the Tx and Rx lines. (UART specifically) I've also got both communicating with the computer. This is really cool for me because it lets me debug SO much easier (and since the palm is portable, I can do it anywhere).

Oh and lastly, I've been building a robot that my efforts will be put to use in. I love the way it's turning out. I'll probably make a post about it when I get further along.

Reading switches is just reading for a 1 on a port when the port is configured as an input. If the processor is being powered with 5 volts, you would likely need to put 5V in on the pin. Do not hook up 5 volts directly to the pin. It is always a good idea to throw in a current limiting resistor. Debouncing is simple averaging typically. You define the criteria for an input to be considered high. For instance, you might read the port 5 times and say if it is high 3 of those times, you assume the switch has been pressed. Obviously it is easy to read the port a lot more than that and debounce better. You just want to ensure you don't get noise on the input including the noise when a switch is pressed.

I believe there is a way to block interrupts while you are in an interrupt, but I don't believe it is the default. I have experienced daisy chained interrupts, and it isn't pretty.

You are correct that interrupts are hard to explain. The best description would probably be that they are a task that runs in the background to take care of low level stuff. While that isn't exactly the truth, it gives a good picture. The only thing bad about it is knowing how to keep your interrupts from blowing up your code.

I haven't done any robot programming since my IEEE days. It sounds like a lot of fun.