jamius.com

Video Three Uploaded, check the first post and below. This one was how to install the software. I know, boring, but if I didn't make it I'm sure SOMEONE would ask a question. Plus I said I'd walk you through every aspect.

This is great! Keep the videos coming. Eventually I'll definitely build this, as I've always wanted to play with one of these.

Now to just find some time to play

Ugh, I had the next video uploaded and ready to go, but it was over 15 minutes . This was the fun one too, I actually programmed it! I guess I'll have to split it in half.

EDIT: Videos are uploading now. I've (tried to) change the titles of the videos so they are Jaimie style, and easy to follow. Project MicroControllers I'm now calling it. I'm up to video 4.5! haha

On a side note, I'm having so much fun with this. Making these videos is great because I have to learn the stuff before I try to teach it to you. For example, I just figured out timers on the microcontroller tonight. I had never known how to do them before, I simply used nested loops to waste processor time and energy. I hope you guys enjoy these as much as I enjoy making them.. Maybe jaimie will get a hold of them and make cool things from small microcontrollers! I can't even imagine what he'd do with them.

Here ya go guys, video 4 and 4.5. In these two videos I write a simple program and send it to the microcontroller.




Enjoy!

Good stuff. The conversion from binary to hex isn't that difficult, but for now just using a web page or calculator to do it is fine.

The hex file is actually just text. If you look at the contents, you will see a lot of hex values, which correspond with the machine code. You don't need to know this, but it isn't that mysterious either.

The forgetting to build thing will get you every time. It will drive you nuts because you will think you fixed a bug in your code, it will look like it is fixed on the screen, but when you program the micro and run it, nothing changes. Definitely get in the habit of building regularly. It also lets you know if you have a syntax bug in your code, such as leaving a semi-colon of the end of a line, or my favorite of mismatched parenthesis.

One of the best issues I ever ran across was a dos programming environment that was running on a windows machine. I kept making changes and building and the results weren't changing. The issue was that the compiler was actually building a file that was in the trash, not the file I was editing. Yea, this sounds crazy and made absolutely no sense, but it was what it was. Occasionally throwing in a syntax bug to ensure the correct file is being built can be useful if you think you are not seeing your changes reflected when you run the program.

The other thing you may run into with micro-controller compilers (builders) is compilers that optimize your code, usually for size or speed. I have ran into issues where the compiler introduced bugs when optimizing. If you don't need to optimize, don't. If you need to speed things up or find room for more code in the processor, optimization is worth looking at. If it isn't needed, optimizing can cause you a world of hurt.

sjvsworldtour wrote:Occasionally throwing in a syntax bug to ensure the correct file is being built can be useful if you think you are not seeing your changes reflected when you run the program.

The other thing you may run into with micro-controller compilers (builders) is compilers that optimize your code, usually for size or speed. I have ran into issues where the compiler introduced bugs when optimizing. If you don't need to optimize, don't. If you need to speed things up or find room for more code in the processor, optimization is worth looking at. If it isn't needed, optimizing can cause you a world of hurt.

Oh don't worry, I don't have to occasionally throw one in there, I write enough of them. I had a similar issue. I was working on the initial program I wrote, then after I finished the vid I was working on a new one, based off of that one. So I was building it and programming the MCU and NOTHING was happening. I, for the life of me, couldn't figure out why. Turns out I hadn't changed the hex file location so I was just programming the MCU over and over again with the old program hex file. lol

Yes, I know about optimization issues as well. I'll probably get into that eventually, but not any time soon, as I've never written a program that hasn't optimized well. Most of the time, optimization will make your program smaller (good cause the storage on the MCU is very limited) and faster (also good). Although I did think that the optimization initially didn't like my infinite loop, but after changing it from optimized to no optimization then back, it worked fine...

Update 5 uploaded and ready for your viewing pleasure....

The bit minipulation gets a lot easier if you understand what each bit means. To do this you need to understand why hexadecimal is used so much in programming. It is very easy to convert from binary to hex if you remember the following table.
Bin Hex Dec
0000 0 0
0001 1 1
0010 2 2
0011 3 3
0100 4 4
0101 5 5
0110 6 6
0111 7 7
1000 8 8
1001 9 9
1010 A 10
1011 B 11
1100 C 12
1101 D 13
1110 E 14
1111 F 15

Each digit in a binary number increases by 2 as you move from left to right, so the value of the bit places are 8421. Notice that if I look at D, which is 1101 and replace the ones with the bit position values I get 8 4 0 1 and if I add those up I get 13, the decimal value.

It is similar for hex. What if I have a hex number like 0x3B. The digit positions in hex are times 16, not 2 as in binary, so the digit values get bigger much quicker. From left to right that are 16^1, 16^0 which is 16 and 1. This is a simple example. Once you add more digits for hex it gets really messy. But for the example you do something similar to what was done above with decimal. Above we basically multiplied each number by the value in the bit position, which is why 0 ended up in one place. The bit position was 0 so 0 time 2 is 0. Now here, since it is base 16, you multiply by 16. So to convert 0x3B to decimal, you just multiply by the digits position and the value 3*16 + 11(which is B) * 1 which is 48+11 which is 59 in decimal.

Yea, that explanation was too long. Maybe I can do better with the shifting. Think of it this way. Left shift multiplies by 2 and right shift divides by 2. This is true as long as you don't get into underflow or overflow.

For easy examples, lets deal with nibbles, which are 4 bits. The biggest number you can store in a nibble is 255, which is 2^4-1. The 4 is the number of bits. Why minus one? It is because we count starting at zero. For instance in decimal the biggest number that can be held in two digits is 99, which is 10^2-1, which is 100-1, which is 99.

A nibble is only good for demonstration purposes because you aren't likely going to run into a 4 bit processor, but 8 bit is common. I am just making the numbers easier. So above we decided that the biggest number we could store would be 255 in our nibble. Now lets shift some bits. For simplicity, lets shift 0x01. What do we get if we do 1<<7? Well, I already said think of it as multiplying by two or dividing by 2. So here you are going to multiply by two 7 times.
So we get 1*2*2*2*2*2*2*2 = 4 * 4 * 4 * 2 = 16 * 8 = 128. Yea, that is right. Now, happens if I shift it one more time? The answer you get is zero. Why? Because 128*2=256, which is bigger than the 255 we said a nibble could hold. Since we were only shifting one bit, the only set bit was shifted off. Basically, each time you shift a bit off to the left, you subtract 256 from your total. So 128*2-256=0.

No lets look at shifting right, which is much quicker. As I have said, shifting right is like dividing by 2. So if we have 3 stored in our nibble and we shift it right once, what do we get? 3/2 = 1. The lowest order bit got shifted right and disappeared (underflow). The bit that was in the 2 position is shifted to the one position and you get the answer of 1. If you shift it again, you get zero, because the one position bit will disappear.

You also mentioned XOR(^). Don't confuse it with my use of the same character above for raising a number to a power. In C, there is no operator to raise a number to a power, although there is a function to do it. So, understand that ^ means exclusive or, lets make it simple. Exclusive or means one but not both. So the truth table is like this.

0 ^ 0 = 0
0 ^ 1 = 1
1 ^ 0 = 1
1 ^ 1 = 0

The only difference between the truth table for an or and the truth table for an exclusive or is when both are one. For a regular or, then answer would be 1.

Now for a neat trick you can do with exclusive or. This actually comes in handy when memory is extremely tight. You can swap the places of two numbers without needing a third location. For instance, if you had plenty of memory, you do this.

C = A
A = B
B = C

And you swapped A and B. With exclusive or, you can do this.

A = A ^ B;
B = A ^ B;
A = A ^ B;

The values of A and B will be swapped. Try it with any combination of A and B with each equal to 1 or 0. Yea, amazing isn't it. And yes, it will work with bigger numbers through bit manipulation.

Why thank you for your explanation! I was hoping you'd stop by.

I've always been able to quickly convert binary to hex. When you work with them enough you just start memorizing the 1 combinations. I did not know about the 8421 and 16^3,16^2,16^1,16^0 thing. I actually have never even heard of that before. Makes a ton of sense though.

FINALLY I UNDERSTAND BIT SHIFTING. That makes so much sense. I literally have never even heard of that. Regardless my simple explanation of "it just works" works.

I've also understood XOR, I just never used it. Truth tables make sense to me, I've just never come across a situation where I need to use XOR.

Hmmm, now that I think about it that switching two variables without a third would be useful if I had two different ADCs going on at the same time with different settings... Well, not at the same time but to switch between the two it'd be useful...

So, I'm kinda stumped as to what my next video should be. I was thinking maybe just another simple program turning on and off more LEDs and stuff (maybe throw something else in there), or I could get into something that actually involved getting to know the microcontroller, like ADC or PWM or Timers. I could always do a LED program as an introduction to loops.

Hey, sorry for the double post, but I have a question...

Does anybody know of any good brand of one time programable (OTP) chip? They'd be programmed the same way (or similar, right?). (Or at least I'd be able to do it with the hardware I have, right?)

I was thinking about buying a couple to make a 8 segment LED mini-board. It only needs to be programmed once, and it'd free up SO many I/O ports on my MCU. I'd just make it communicate via (I don't know the name of the protocol) the Tx and Rx pins.

Besides, wiring up a 4 digit 8 segment LED to an atmega8 would be impossible. hahaha

That'd be a cool communication tutorial.

Oh, yeah, I've basically decided to do an 8 segment LED tutorial next. It's basically turning LEDs on and off, but I'll show how to write a function and maybe introduce (personal) header files too.