Thanks for the D to A tutorial. It's useful for someone who is currently transitioning out of the Arduino world and into the world of 'grown-up' AVR programming.

Now I need to accomplish the equivalent of an analogRead and I wonder if there is a how-to either here or somewhere else that is along the same very concise lines as your D to A tutorial.

Thanks for any info, particularly if it saves me hours of trying to decipher the data sheet.

=PR=

Check out our accelerometer tutorials: These are using A to D to gather data:

http://www.evilmadscientist.com/article.php/ADXL330

http://www.evilmadscientist.com/article.php/ADXL335

Thanks for the tip. I am going to look at that now.

=PR=

Just what I wanted. Thanks very much indeed.

You might also enjoy some of our other AVR-centric articles:

http://www.evilmadscientist.com/article.php/avrstuff

I will check them out, for sure.

I've one question about your A to D code, and it concerns ADCW.

This isn't mentioned in the AVR datasheets but I assume it provides a way to read the low and high bytes and concatenate them - is this correct?

Yes, that's an alias for grabbing the full result as an unsigned int (16-bit) in a single operation.

I got another one for you. (Yes, I'm aware that isn't good English).

How do I use the Reset pin for input or output? Is there a simple trick that I'm missing? I know I could use the fuses to disable reset but I don't really want to do that (my widget is still in development).

=PR=

Yes, you can change the fuse settings on the AVR to disable the reset pin. After that, the pins is available to use as a regular I/O pin.

You *cannot* use the reset pin for I/O unless reset is disabled. Think about it: every time that you output a low signal, the chip would reset. Or, as an input, it would reset whenever the input was low.

And if reset is disabled, that means that any further programming (by normal means anyway) is off the table? So I would have to be sure that my code was in its final form before I did that.

And if reset is disabled, that means that any further programming (by normal means anyway) is off the table? So I would have to be sure that my code was in its final form before I did that.

Yes, pretty much. I suggest leaving the reset pin as reset, even in your final application.

There *are* ways to rescue a chip without a reset pin, though. I think that the AVR rescue shield may work, for example.

Happy Easter.

Well, it's going rather well over here in ATtinyVILLE (population: 1024).

I am sharing a pin between my mode button and my light sensor so I can keep reset as reset. I have a pullup on PB4 and my LDR and pushbutton go in parallel from PB4 to GND. It works pretty well because the LDR can't pull the pin as low as the pushbutton does so I can easily tell if the ADC is outputting a light reading or a button push. Odd thing is that a button push does not show as a zero on the ADC, more like a 6 or 7. Not a showstopper but a little surprising.

Something else odd but unrelated: in my code if I change a var from unsigned int to unsigned long, my compiled code goes from 784 bytes to 1054 bytes. Any idea on that?

Thanks .......=PR=

. Odd thing is that a button push does not show as a zero on the ADC, more like a 6 or 7.

Not surprising. It would be surprising if you read an exact zero; it's still an analog measurement, after all.

in my code if I change a var from unsigned int to unsigned long, my compiled code goes from 784 bytes to 1054 bytes. Any idea on that?

Depends what you're doing with that variable. An unsigned int is a 16-bit number. The AVR has 8-bit data locations in most places, so a fair amount of swapping is needed to deal with it. An unsigned long is 32 bits long-- four bytes -- and obviously much more overhead required. Doing complex software algorithms, like division, takes up a heck of a lot more with longer variables.

I wouldn't be surprised to see a 1 on the ADC rather than a zero, but 7/255 of 5V is significant (I'm reading ADCH only since 8-bit accuracy is sufficient).

As far as the variable issue goes: it's just a loop counter. It gets incremented and compared to various constant values and occasionally reset to zero. No multiplication or division.

Wait. I lied. There is a modulo operator:

if (!(loopcount%500)) { ..... } // do this every 500th time around

could this really increase the size of my code by this factor?