Page 2 of 2

Screwy Things

Life is full of compromises, and microcontrollers are no exception. Every microcontroller I have ever used has something a little strange about it. Here's a list of few of things I've found that didn't quite make sense to me. Consider them a "heads-up" so you don't have to find them yourself.

• I discovered you can't load an immediate into some of the registers. I kept getting a compiler error that I could not understand! Drove me crazy for an indeterminate amount of time. So why do the immediate instructions not work on registers R0–R15? Here's Atmel's explanation:
  
  
  All AVR instructions, with a few exceptions, are 2 bytes long. This means that there are only 65,536 (64K) possible combinations to make an instruction set from. When we specified the AVR instruction set, some compromises had to be made to utilize these 64K combinations as efficiently as possible. Unlike a CISC controller, where an instruction can be one, two, three or even more bytes, we could not implement on the AVR all the instructions we would like to have. As an example, an immediate instruction that addresses all 32 registers needs 8 bits for the constant and another 5 bits to address a register file. This instruction would occupy 8K of the total instruction space. In other words, if we made eight immediate instructions that worked on the entire register file, no more instructions could be implemented. Making the instruction word 17 bits long was never been considered as an economical nor convenient solution.

  The process of designing the AVR instruction set included a lot of gives and takes. We have consulted C compiler experts who have given us a lot of advice on how to tune the instruction set to yield compact C-code. As an example, the compiler experts advised us to sacrifice the ADDI for a SBCI (subtract immediate with carry).

  For those instructions that are missing, convenient workarounds exist. The code efficiency of the AVR should prove that we have found a good compromise between which instructions to implement, and which to omit.

  
  
  
• Another odd thing occurred when I set up some flag registers (the simulator was invaluable in understanding this one). There are two commands to set a bit in a register, sbr and cbr. They expect numbers 0 to 255 following them to know what bit to set. (That way you can set multiple bits at a time, Atmel says; I think they hid the or and the and operation under a different name.) What gets me is that the sbrs branch expects number 0 to 7 to define the bit. This makes it impossible to set and clear the flag with the same name you use to test it. I ended up defining an x_bit_mask to manipulate the bit and an x_bit_flag to check the bit. Just make sure you don't confuse the labels because the assembler will not catch that mistake!
  
  
• One final weird thing—the reset pin on the Tiny 15 can be used as an output if you disable the reset line when programming. (Note: a fuse is programmed separately from the flash). I planned on using the I/O capabilities of this pin, and originally had it hooked up to an LED. I couldn't get it to work right, so I turned it into an input, which seemed to work fine, then I sent the problem to an apps engineer. He said the I/O of this particular pin is not controlled by the Port B register, but by the DDRB register. Basically it is an open-collector output, so when you configure it as an output, it automatically sinks current. As an input it behaves as you would think. I thought this I/O behavior was a little strange, but serendipity struck. As luck would have it, the same day I got this explanation we discovered that the Holtek 49R50 has a whole rack of similar I/O pins (using on a new project at work). But we will save that story for another day.

Things are finally humming along pretty well! Not bad for someone who has spent more time lately telling others what to do without really knowing how to do it. It feels good to create something on my own again. I don't get all the time on it I'd like as my wife is beginning to think I'm a geek again. I'm even developing an indescribable urge to wear a pocket protector. There just aren't enough pencils around anymore!

Man that melted solder smells good.

---

*	If you'd like a more in-depth analysis of this structure, take a look at May I Interrupt You for a Millisecond? and Making Your Time Worthwhile. I owe Robert quite a lot in learning to set up code.
**	"O" is an acronym for output. Can you guess what "I" is? I believe acronyms are what keep engineers sane. If we couldn't use acronyms, we'd have so much to say in so little time that we'd simply explode. Acronyms increase our throughput, safely venting that unbearable pressure.

<< Previous

Product Engineering Archive

Guides and Experts   Analog Avenue   EDA Tools   PLD   DSP   EDA   Embedded Systems   Power   Test

		Click here to get your listing up.