jamius.com

I am glad that was helpful. It was hard to try to keep it short and informative. One day I will have to get where I can make videos. It is great to see you doing this for everyone because micro-controllers can be very useful in some situations. It is all about choosing the right took for the job. I love that Jaimie was able to create his spider tank with mainly gears. I find it a very good solution to avoid the added cost of electrical hardware.

As for finding micro-controllers, I haven't done much of that in years. I use to get Motorola or PIC micro-controllers. Motorola split off their chip business and I no longer recall the name of the new company. There are incredibly small cheap one time programmable controllers out there. The best thing is to buy one reprogrammable one and then one time programmables for the finished products.

The communications your are talking about is just simple serial communications, although there are various flavors. I2C is something you will see mentioned a lot and there are others that aren't popping into my head at the moment. A lot of times the only big difference is the protocol and parity and things like that.

sjvsworldtour wrote:I am glad that was helpful. It was hard to try to keep it short and informative. One day I will have to get where I can make videos. It is great to see you doing this for everyone because micro-controllers can be very useful in some situations. It is all about choosing the right took for the job. I love that Jaimie was able to create his spider tank with mainly gears. I find it a very good solution to avoid the added cost of electrical hardware.

The communications your are talking about is just simple serial communications, although there are various flavors. I2C is something you will see mentioned a lot and there are others that aren't popping into my head at the moment. A lot of times the only big difference is the protocol and parity and things like that.

I think it's awesome that jaimie did it with gears and stuff too. But if you wanted to make anything with sensors and stuff, MCUs are the way to go.

As for the communications... I actually remembered a bit ago. It's just usart or uart, one or the other, I forget which one it actually is.

I've done it before, and I have a serial adapter I can wire up to the MCU. I've communicated with my computer before, just not in a while. Maybe I still have the program. I just want to communicate with my computer for debugging purposes. (Sure I can make an LED blink numbers, but that's annoying)

I actually worked a project once where coming up with a way to quickly blink out large numbers with an LED became very important. You never know what may come up.

sjvsworldtour wrote:I actually worked a project once where coming up with a way to quickly blink out large numbers with an LED became very important. You never know what may come up.

Stuck on an island with a giant LED and one microcontroller and programming devices and a ship is sailing away?

Actually, that's how I've done my debugging in the past. It's easy and works in a pinch (or if you don't have many I/O ports available). But, it takes time and is annoying. So I think I'm going to solder up a board with a small 7 segment display. That and keep a communication function in my header file so I can easily turn it on and off and I can see all of my output on the computer screen.

This was a product that was very cost critical and they felt it too expensive to add another LED to the board. Go figure.

I'd really recommend Arduino boards for beginners in microcontroller programming. The whole board can be connected by USB to computer (is shown as a serial port), and can draw all its power from the usb port. The most basic board (Arduino Uno) contains ~8MHz Atmel microcontroller, which is good enough for most stuff. You can add more features by buying (or making) "shields", which can be stacked on the connectors on the arduino board. No soldering needed For programming, there is a free C/C++ compiler (avr-gcc), and a decent (also free) IDE. Everything is open source. Works on Windows, linux and macos.

One fun thing about the Unos are that they can be made to show up as input devices (or other things) on your PC, eg. a joystick. Then just stick an acceleration sensor on the board, add some C++ and you've got a Wii-ish game controller for PC

Sorry if this sounds a bit like an advertisement, i just love this thing

Videos 6 and 7 uploaded. I really need to start being quicker about these things. There's just so much to learn it's hard to shove it into tiny segments.

Video six is how to hook up a seven segment display, and video seven is how to program it. Oh and yes, I am AT the 15 minute mark for video 7. One second longer and it wouldn't work, as me how I know... lol

Next update: Functions and header files.

Kudos for leaving the break bug in during the video. It is a very common programming error when using switch statements.

In general, it isn't a good idea to use absolute paths for header files. You should be able to enter a relative path or just give the file name if the file is in the same directory as your main file.

Header files can be used as you have shown here and it will work, but headers typically do not contain functions. They usually contain a function prototype. Please excuse me if I screw up the syntax. I have been programming in PHP for years now, so my C is rusty. A function prototype looks
something like this.

void display( int num );

The obvious question is how does that do anything? We all it does is tell the compiler when it is compiling your main program that a function is available with that syntax.

Where would you put the code for the function? You put it in another .c file, maybe display.c. That file would contain the function as you wrote it.

Why would you do this? Because when you build (or make) a program, the compiler converts your program into a object file (usually with an obj extension). Then the linker takes all the obj files and makes them into the executable, in this case the hex file you are using to program the chip. The inclusion of the <io.h> file will cause the linker to add other object code to support any functions you use from io.h. Similarly, if you use a display.h, you would have to tell the linker to include display.obj. This is done in various ways from editing a make file, which is the brute force method, or through a project in your development environment, which makes it much easier.

Why would you want the obj files? Because unless you change the display.c file associated with display.obj, the display.c file is not compiled again. For small projects, it isn't a big deal, but for large projects, you might get tired of waiting on the compiler.

Don't let me confuse people with these comments. What you did will work. What I am mentioning is just more of the preferred way to do things. C is very flexible and will allow you to do a lot of things different ways.

Thanks! I don't pretend to be perfect in my videos, I've probably made at least one mistake in every video I've done.

I honestly didn't know any of the object, header, and c file things that you talked about. I remember going over it quickly in class a couple of years ago, but I was too excited to start programming to remember any of that stuff!

So basically what you are saying is that the way I have it now, my display function is compiled every time I build the program. If I had it in a separate .c file with just the function prototype in the header file, it wouldn't be compiled unless I changed it? I can see where that will come in handy with large programs/slow compilers. I'll probably do it the way you said, since it sounds like it's more "correct" or "accepted" that way. It's not any more work for me.

Oh and I'm guessing it's not a good idea to use absolute paths for header files because I could never give the program to a friend and expect it to work... right? Yeah the whole file paths in windows have always confused me for some reason. Like why can I just have the avr/io.h in there? That header file is nowhere NEAR my program. It's in C:\WinAVR\avr\include\avr... I mean maybe the program just takes the "include" folder as it's root? So if I put my header file in the exact same folder as my .c file, I can just put #include<myfile.h>?

EDIT: On a slightly cooler note, I read up on multiplexing and got both digits working on the display with only the addition of two transistors (and a bunch more wires). Pretty cool stuff. Then again, I think anything I haven't done before is cool. I don't think I did it... correctly though. It's basically flashing at the clock speed of the microcontroller (1MHz... way faster than it needs to flash, and probably way faster than the transistors can switch.. well, I did throw a small pause in there, so maybe it's not running THAT fast, but still, I didn't do it right). So I'm working on doing it with a timer to get it around 500 Hz or so (as I'm told that's a good number to shoot for when doing 7 segment displays.) I wonder if I can use PWM to switch the transistors...