LCD and the buzzer

Support A-Star and Orangutan
1

I have just got my Orangutan controller and right now am having too much fun with it. The orangutan-lib and the examples on this forum have been fantastic in getting me up and running.

But I’m a little stuck. I have a IR range sensor connected to ADC6 and using a small variation of the analog test program from the o-lib, I have managed to get and write out the sensor readings to the LCD. (woo hoo!, not bad for day 1)

Then i thought it might be fun to have the buzzer give an audible tone as well (freq varies with distance, like when I backup my wife’s minivan).

But for some reason when I use the buzzer (also in o-lib) the LCD doesn’t work.

Is there some sharing of timers or something that is going on here that I don’t understand. Is it possible to continually update the LCD and make the buzzer ring in the same loop?

2

I hate to say this, but I have no idea!

Ok, maybe I do. The buzzer code in orangutan-lib doesn’t use interrupts or timers, so it’s fairly lightweight. But it gets around this by completely taking over the CPU for the duration of the tone. So when the buzzer is going, nothing else is. No ADC reads, no LCD writes, no nuthin’.

Jim Remington posted some more CPU-friendly buzzer code some months ago. I can’t remember if it was timer based or what, but if you’re planning on doing music (I still plan on making a mini-sumo that’ll play Ride of the Valkyries as it charges across the ring), that would be a much better route to take.

I hope I’m understanding the conditions of your test correctly (trying to make sound while updating the LCD). If I’m not, let me know. Electrically the LCD and the buzzer are completely isolated. So if you’re not making sound while updating the LCD, and vice-versa, the two should play nicely together. If they don’t, that indicates something else that needs fixing.

Good to hear you’re up and running on day one! Man, that’s music to my ears. Well… minus the buzzer, apparently. But music all the same.

Tom

3

I think i figured it out. I was calling a delay after the buzzer. It didn’t even register in me that it might conflict with the LCD.

I have another question regarding the LCD code. I notice that if I reset the controller, that more times than not I lose the second line of my display. Even when I turn it off and on (with ISP in or out) i can’t seem to get the second line of output to return.

Here is the code that I am experimenting with.

#include <avr/io.h>
#include <stdlib.h> 
//#include <util/delay.h>
#include "device.h"
#include "analog.h"
#include "lcd.h"
#include "buzzer.h"

int main(void) {

	int val;
	int prev;
	int min = 1024;
	int max = 0;

	lcd_init();
	analog_init();

	for(;;) {
		
		// let's take an average of 20 readings since there is a lot of noise
		int i=0;
		long sum = 0;
		for(i =0;i<20;i++) {
			sum += analog10(6);
		}

		val = sum / 20;
		if( val < min ) min = val;
		if( val > max ) max = val;

		if( val > 90 ) {
			buzzer(5*val , 200);
			//_delay_ms(200.0);
		} 

		if( abs( prev - val ) > 10 ) { 
			lcd_gotoxy(0,0);
			lcd_string("ADC: " );
			lcd_int(val);

			lcd_gotoxy(0,1);
			lcd_int(min);

			lcd_gotoxy(4,1);
			lcd_int(max);

			prev = val;
		}
	}


	return(0);
}
4

Ooooh, now that sounds familiar. What version of o-lib are you using? Is it 0.2, or 0.3? That behavior sounds a lot like the 0.2 code. I thought I’d caught all that before the 0.3 release, but I could be wrong.

Tom

5

using 0.3, if that helps (or hurts :slight_smile:.

6

Makes me go “owie!” but it’s good to know. I’ll try to test this when I get home tonight.

Tom