Using Volatile keyword in embedded code

Volatile is probably the least documented keyword in most tutorials and books. This is the primary cause of most misuses and bugs related to it. If you already are programming microcontrollers, you probably know that volatile is always used on global variables that are accessed from interrupt service routines. Otherwise, code won’t work. After few requests, I decided to drop few lines about volatile keywords. This keyword is commonly used to tag memory type. We hear “volatile memory” and “non-volatile memory” when discussing computer hardware. As a quick reminder – “non-volatile memory” is a type of memory that stores its contents even when power is off. Such type of memory is EEPROM, Flash, and FRAM. This is easy from a hardware perspective. But what volatile keyword means in C or C++ code? This is an indicator (called qualifier) to the compiler that tells that this variable may be changed during program flow even if it doesn’t look like it be. This means that compiler must treat this value seriously and keep optimizer away from it.

Continue reading

Interfacing GPS Module with AVR

GPS modem is a device which receives signals from satellites and provides information about latitude, longitude, altitude, time, etc. The GPS navigator is more famous on mobiles to track the road maps. The GPS modem has an antenna which receives the satellite signals and transfers them to the modem. The modem, in turn, converts the data into useful information and sends the output in serial RS232 logic-level format. The information about latitude, longitude, etc., is transmitted continuously and accompanied by an identifier string. The connection of GPS modem with AVR microcontrollers shown in the circuit diagram. The ground pin of max 232 and serial o/p of the GPS modem is made standard. Pin 2 of MAX232 is connected to pin 3 of GPS modem, and pin 3 of max 232 is connected to pin 2 of the modem. This type of connection is called a serial cross cable.

Continue reading

Software Debouncing of buttons

Connecting a button as an input to a microcontroller is a relatively easy task, but there are some problems. The main problem is that switches bounce, i.e., when you press (or release) a button, it will often change level a couple of times before it settles at the new level. So if you, for example, connect the switch to a pin with an external interrupt enabled, you will get several interrupts when you press the button once. This behavior usually is not wanted. Even if the buttons didn’t bounce (with filtering hardware, for example), we still want to capture the event of a pushed button and take some action once for every button press, so we need to keep track of the state of the switch as well. One technique used in this tutorial to handle this is to check (poll) the button(s) periodically and only decide that a button is pressed if it has been in the pressed state for a couple of subsequent polls.

Continue reading

Interfacing matrix keyboard with AVR

The keypad is the most widely used input device to provide input from the outside world to the microcontroller. The keypad makes an application more users interactive.  The concept of interfacing a keypad with the ATmega16 is similar to interface it with any other microcontroller. Many applications require a large number of keys connected to a computing system which includes a PC keyboard, Cell Phone keypad, and Calculators. If we attach a single key to MCU, we connect it directly to i/o line. But we cannot connect; say 10 or 100 keys directly MCUs because it will eat up precious i/o line and MCU to Keypad interface will contain lots of wires. The rows R0 to R3 are Input to the Microcontroller. They are made an input by setting the proper DDR Register in AVR. The columns C0 to C3 are also connected to MCUs i/o line. These are kept at High Impedance State (AKA input); in high z state (z= impedance) state, these pins are neither HIGH nor LOW they are in TRI-STATE. And in their PORT value, we set them all…

Continue reading

Sensing Temperature Using AVR

lm35

In this new tutorial, we will be interfacing an LM35-based temperature sensor with ATMEGA32. The three main types are thermometers, resistance temperature detectors, and thermocouples. All three of these sensors measure a physical property (i.e., the volume of a liquid, current through a wire), which changes as a function of temperature. In addition to the three main types of temperature sensors, there are numerous other temperature sensors available for use. However, the LM35-based sensors are precision-integrated temperature sensors with an output voltage linearly proportional to the Centigrade temperature. The main advantage is these types of sensors don’t require any external calibration. They are internally calibrated and simply generate the output to the temperature they detect. The device is used with single power supplies or with plus and minus supplies. As the LM35 draws only 60 μA from the supply, it has very low self-heating of less than 0.1°C in still air. The LM35 is rated to operate over a −55°C to +150°C temperature range, while the LM35C is rated for a −40°C to +110°C range (−10° with improved accuracy). The…

Continue reading

Interfacing Ultrasonic Rangefinder with AVR

HC-SR04 sensor

In this tutorial, we are going to interface ultrasonic rangefinder with the all-popular ATMEGA8. An ultrasonic rangefinder is used to find the range of an obstacle or a wall from the sensor. However, when there are cheap methods available to find a distance like the IR sensor or even a combination of LEDs and LDR would do, but the question is why we use a more expensive sensor. The reason is:- Typically the IR sensors have a detection range from 30-80 cm or even less depending upon the manufacturer and also the LEDs used. However, for an ultrasonic rangefinder, the distance can be measured accurately up to 400cm with an accuracy of 1cm. Ultrasonic rangefinders find applications to measure a level of a liquid, object sensing. Also, the great thing with this sensor is they require no calibration; no conversion from analog to digital data, and the code are is not limited to any particular manufacturer sensor. The code will work pretty much with almost all sensors available in the market.

Continue reading