In this episode I will be repairing my AVR ISP MKII programmer by replacing the on-board boost converter (TPS61020) and I will also upgrade the 6 pin ISP programming cable to 1m length.

August 4th, 2009

Matrix keyboard explained

Matrix keyboard setup

In many cases you want to add some input interface to the project, the most simple is to use some push-buttons but what if you need to set some values, some of you might say:  you can do it with up-down, left-right, select button and some clever menu. Yes that’s about right but just imagine the software if you want to set values from 0-9999, or applications like access control, counters.

The most commonly known is the 12 (34) type which has off course 12 buttons noted from 0-9 and *, # for extra features. Well so far there isn’t anything clever about it, 12 buttons which need 12 input pins, wrong it needs just 7, the push buttons are organized in rows and columns, each row shares the same horizontal connection, while each column shares the same vertical connection. For a better understanding look at the schematic:

matrix keyboard schematic

Because of this matrix connection the reading of active button(which is pushed) isn’t so straightforward, each column has to be processed sequentially.

The resistors are external components, there are not included into the keypad but certainly needed, R1-R4 are the pull-up resistor, in the demo application the atmega88’s internal pull-ups are used, R5-R7 are for current limiting.

A few words about the firmware, the keyboard is connected to PORTB, PB0-PB3 are configured as inputs with the internal pull-up active, these will read which row is active, PB4-PB6 are configured as outputs and serve for column selection, their default value is logic ‘1’ the same as the row pins default value. The reading is made sequentially, the first column is selected by setting PB4(COL1) to logic ‘0’ and the pins PB0-PB3 are red, if no key is pressed the pins remain in their default state: logic ‘1’ else their value is logic’0′ we must go trough these steps for each column, once a pressed key is found its space thus value is determined, the function restores the corresponding column select pins default state and exits, this way speeding up the process.

Lets take an example: key 4 is pressed, column 1 is selected by setting PB4 to logic ‘0’, when we read PB0-PB3 PB1 will be logic ‘0’, since we know which column is active (it would be really funny otherwise since we wrote the firmware) the exact location of the pressed key is determined. Now we have 2 coordinates x(0..2),y(0..3)  x=1 is the row, y=0 is the column the most simple way to turn these coordinates into a value is using a 2 dimension look-up table:

const unsigned char KeyMap[3][4] = {{1,4,7,ESC},{2,5,8,0},{3,6,9,ENTER}}; // values ESC and ENTER are defined by macros

By simply addressing the table with the coordinates we have the corresponding value of the pressed key  value = KeyMap[x][y]; the look-up table can also hold any data of choice like ASCII, or can have other type definition as long as its dimension matches the keypads dimension [x][y].

Since the keypad or any other human machine interface tends to be asynchronous, which means that at any moment the firmware should be able to sense and to handle the input, the entire process or in other words the scanning must be executed periodically. This can be done inside some timer interrupt routine or just by adding some delays to the main cycle, if possible avoid using the mains power frequency or any multiple of this for scanning.

Also between the column selection and the effective pin reading some delay must be inserted, this allows time for the electrical state of the wires, traces to stabilize. After one pressed key is sensed the function exits, thus multiple pressed key will not be recorded although the modification needed to the firmware is quite simple, so consider this a challenge.

I attached the entire AVR Studio project, it is written in C, using the winavr package, it will be easy to integrate into any project. In the near future I will explain how to save I/O pins by sharing the row pins with other functions like driving the 7 segment display.

Matrix keyboard explained: [download]

June 10th, 2009

DIY 2.5GHz Counter with AVR

DIY 2.5Ghz counter with AVR

Counters that can go into gigahertz range can be pretty expensive so you might want to consider DIY solution if your measurements are not critical. Of course since we are dealing with extremely high frequency the quality of the build depends highly on your skills. Care must be taken with PCB manufacturing, component placement, screening and shielding, noise sources, etc.

This is a project of a counter built around AT90S8535 microcontroller and it measures both the frequency of the input signal and it’s strength. The values are display on a LCD, the signal strength is shown dBm units and as a bar-graph. Also you can use it with an external 10Mhz clock, in this mode on LCD will be displayed the letter “E”   in the left upper corner and “I” when internal clock is used.

Since AVR microcontrollers have synchronous counter input, the law says the maximum input frequency should not exceed half the clock frequency. Even so 2.5Ghz is way too high for the microcontroller to handle, so a prescaler that divides that frequency to a measurable one is needed. The input impedance of the prescaler is set to 50 ohms, the signal is amplified by 20dB and then fed into a two way splitter. One way goes to the Analog Devices AD8314 log-detector for signal strength measurement.

The other way goes to the first divider, MC12095, set to divide by 2. Putting pin 6 (SW) to ground would set the dividing factor to 4. MC12095 can accept 2.5Ghz input frequency. The output resistor increases output power and keeps impedance at 50 ohms, the parallel 2pF capacitor is for impedance matching. The next divider, SAB6456 can be set to divide by 64 or 256, in our case 64 is used by leaving pin 5 (MC) unconnected.

The divider’s output is then gated with nand gates and reaches a 4020 counter. AVR counter works on 16 bits and with 14 bits from the 4020 we get a 30 bits counter. The source code for the microcontroller is writen in Bascom and you can find it in the link for download. A test is presented with a 500Mhz signal but i was  curious if it can really go far up to 2.5Ghz. Let me know if you build it and test it.

DIY 2.5GHz Counter with AVR: [Link]

Seven segment display

In this article I intend to explain the functionality and usage of the seven segment display, probably you have seen many projects with these type of displays, however the price drop of LCD’s tend to overtake the market, there are a still few applications for which these devices are more suited. For large numeric displays, like clock’s, railway station displays, low-cost measuring devices or very stressing environments the led based displays are better, and cheaper.  The most simple led display available is the seven segment display, it consists of 7 led stripes arranged forming the number 8, because of its simple construction it is very robust and can function in very low or high temperatures, can withstand vibrations,  mechanical shocks without problems, for what the LCD would fail to work or even get permanently damaged.

single sevene segment

If we look at one digit we can see 10pins each segment and the small dot are LED’s, each of them has one terminal connected to a common pin, from this comes the name common anode or common cathode, and the other terminal is connected to a standalone pin, since the common pin is doubled, we have the 10 pins for each digit.

seven segment config

Lets take as example the common anode type, to light the segments we need to connect the positive supply rail to the common pin, and pull to ground the segments, each segment depending on its size can handle a few miliamps, after all we are talking about LED’s not bulbs. That’s fine if you need just one number to display, but how can these digits be connected to form a multi-digit display? The first approach is to connect each segment to a micro-controller pin, this way for each digit you need 8 pins and isn’t elegant at all.

The other solution is to connect each corresponding segment from the digits to a common bus, and power the digits one at a time, thus multiplexing the data.

seven segment schematic

This multiplexing probably sounds more complicated than it really is, look at the next picture:

illustrated seven segment operation

Since the digits share the same data bus, each digit will have the same number displayed, like the wheel on the picture, to change the number the “data guy” rotates the wheel. So how can we display 1234 you might ask, well wee need another guy, the selector, which will leave only one digit to be seen, all the others are shut off, by synchronizing the “data guy” and the “selector guy ” so they operate at the same time, when the wheel is at the 1111 position, the selector opens the first window, when at 2222 it opens the second and so on. By changing the data and selecting the digits at many times per second the human eye will see a steady image with 1234, the display refresh rate should be above 50 times in 1 second, otherwise the image may flicker.

In the schematic the “selector guy” is implemented by the PNP(BC327) transistors and the “data guy” is the data bus (PORTB0..7). For the practical demonstration I used my own avr development board with ATmega88, four HD1131R type seven segment digits which I rescued from an old TV a few years ago, the connections are made on a prototyping pcb with scrap wires. The data port is PORTB, for selection the PD4..PD7 pins where used.

Like I mentioned earlier we need a periodic data update with digit selection to have a steady image, and since the entire display refresh should be above 50Hz and we have four digits we need to change the digits at frequencies greater than 200Hz. Since the amount of time which one digit is turned on is 1/digit count, as the display has more digits the light intensity gets weaker, in our case the HD1131R has 1.6V voltage drop, by powering from 5V and trough 330Ohm results 10mA trough each segment, but since we have 4 digits the average current received by each segment is 10/4=2.5mA, this will result in a very fade light. For the demo application I used 220Ohm values, with the on board 100Ohm resistors the average current is 2.5mA/segment, although I could have used only the on board resistors, thus having 8.5mA average current, but the peak would be 35mA, and the micro-controller can handle at maximum 25mA/pin, off course the pin won’t get blowed right away from 35-50mA, but you should be careful when designing similar circuits.

That’s enough about the hardware, let’s see the software, for the periodic refresh I used a timer interrupt with 244Hz, resulting in 61Hz refresh rate, in Europe we have 50Hz AC power, so that’s fine, but in the case of 60Hz AC power the refresh rate should be at 70Hz to avoid the stroboscopic effect.

For the display data I used 4 byte buffer from which the interrupt reads and sends to PORTB, the buffer index can be used also for digit selection(see void DisplayData(uint8_t* Display) ).

Because of the seven segment data format by directly writing 5 to PORTB, won’t result in displaying 5, so the numeric data must be converted first, because there isn’t any easy algorithm to mathematically make this conversion, we must use another method, for a one digit display you could make if-else or switch statements, but with 2 digits you already need 100 lines of code, for 3 digits 1000 lines and so on. A very handy solution is a look-up table:

const uint8_t DigitCharTable[] = { DigImage0, DigImage1, DigImage2, DigImage3, DigImage4,\
DigImage5, DigImage6, DigImage7, DigImage8, DigImage9, };

By indexing the table with the numeric value 0-9 we get the needed data format, example PORTB = DigitCharTable[5]; results in displaying 5;

The void NumToDispValue(int16_t Number, uint8_t* DataBuffer) function uses this method to convert 16bit signed value into display compatible string.

After the conversion made, the actual display buffer needs to be updated with the new value, here is a tricky part, by converting 1234 into display compatible data we will have [DigImage1, DigImage2, DigImage3, DigImage4], by having DigImage1 at the first position and my display has  D4,D3,D2,D1 physical configuration the data displayed will look like this: 4321, it gets reversed. This can be overcome by reversing the selection lines PD4..PD7, or by copying the reversed string into the display buffer(see void StrUpdateDisplay(uint8_t* DisplayBuffer, uint8_t* UpdateData, uint8_t InvDir)  ).

After the conversion, the result is a string(not ascii!), so the string manipulation techniques can be easily used, the dot can be added to any digit, simply by setting the 7-th bit in that byte(see macro WITHPOINT(a) in SSDisplay.h ). There is also possible to display a limited amount of characters like E,F,c,C.., (see SSDisplay.h) it won’t be pretty but it’s readable.

Last but not least, since the refresh is done in interrupt, the display buffer update operation should be made atomic, in other words first disable the refresh interrupt, and then update the buffer, otherwise the image will flicker, and don’t forget to re-enable the interrupt after!

If you use only the refresh interrupt, than it’s easier to just disable all interrupts globally, although if you have other interrupt sources too, then disable only the refresh interrupt, this way you won’t hold back the other incoming events.

For data source I used the ADC to measure the potentiometer output, you can also tweak the macro’s used to handle the ADC, the dot in the 2th digit is activated if the ADC value  is above 512.

The demo project was made using avr-gcc and avrstudio, some variable type notations may differ from the ANSI C standard since I use the avr-gcc typedefs, the entire project among with schematics, pdf’s is available for download.

In the next article I will explain the usage of the matrix keyboard.

Seven segment display explained: [download]

April 29th, 2009

AVR Object tracker

AVR Object tracker

Just the simple interfacing of camera with the micro controller sounds a lot of fun, then how about real time object tracking? This device has an amazing 27 fps speed and can track multiple objects which are defined by colors. The image sensor is OV6620 CMOS, and the brain is the ATmega8, trough the serial interface the user can download snapshots, configure the device or just view the tracked objects.

This project is an ideal start-up for those involved in robotics, by upgrading the basic IR based obstacle detection your robots gain a lot more freedom and intelligence.  Beside the amazing speed of execution the hardware is quite simple, my first thought was that the firmware is written in assembler I was surprised to see that the entire project is written in C. The PC program is in java and made available by the author, great way to get started with image processing methods and algorithms.

If you want to embed this project into your application the best way is to build it as is, and use a second controller for the other functions, since the tight synchronization needed between the atmega8 and the image sensor any other functionality would greatly reduce the image processing speed.

AVR Object tracker: [pdf] [download]



© 2007-2011 YourITronics | Any logo, trademark and project represented here are property of their respective owners | Wordpress | Privacy Policy    RSS