Atmega8 + SRF02 (I2C)

[mefiX]

Hallo Zusammen,

ich bastle an einem Füllstandsmesser mit einem Atmega8, einem 16x2 LCD und dem SRF02-Ultraschallmodul.
Ich poste hier, weil nicht genau klar ist, ob es sich um ein Hardware- oder Sofwtare-Problem handelt.
Die Kommunikation zwischen Controller und PonyProg klappte schon perfekt, ich habe die CPU bereits mehrmals ausgelesen und beschrieben.
Die I2C-Kommunikation klappte auch schon perfekt, ich hatte schon die Entfernung auf dem LCD-Display.
Softwareseitig benutze ich die Bibliotheken von Peter Fleury (http://jump.to/fleury) für das LCD und I2C.
Ich habe jetzt schon 3 Atmegas geschrottet (denke ich zumindest), die jeweils zuletzt mit folgendem Code geflasht wurden:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include "delay.h"
#include "lcd.h"
#include "i2cmaster.h"

#define SRF02_ADDRESS 0xE0
#define HEIGHT 400
#define RADIUS 100

/* SRF02 - Get Distance in cm. */
unsigned int read_cm(unsigned char address)
{
	unsigned char lowbyte,highbyte;
	unsigned int distance;

	i2c_start_wait(address+I2C_WRITE);
	while (i2c_write(0));
	while (i2c_write(81));
	i2c_stop();

	i2c_start_wait(address+I2C_WRITE);
	while (i2c_write(2));
	i2c_stop();

	delayms(65);

	i2c_start_wait(address+I2C_READ);
	highbyte = i2c_readAck();
	lowbyte = i2c_readNak();
	distance = (highbyte*256)+lowbyte;
	i2c_stop();

	if(distance > 150)
	{
		PORTD = 0x00;
	}

	return distance;
} 

int main(void)
{
	char buf[16];
	unsigned dist;
	double fill_percent;
	
	i2c_init();
    
    DDRD &=~ (1 << PD2);        /* Pin PD2 input              */
    PORTD |= (1 << PD2);        /* Pin PD2 pull-up enabled    */

	DDRB |= (1 << PB0); /* enable B0 as output (Toggle-LED!) */


    /* initialize display, cursor off */
    lcd_init(LCD_DISP_ON);

    for (;;) {
		
		//PORTB ^= (1<<PB0);
		
		// Start Distance Measurement
		PORTB &= ~(1 << PB0);
		dist = read_cm(SRF02_ADDRESS);
        PORTB |= (1 << PB0);
		
		/* clear display and home cursor */
        lcd_clrscr();
        
		fill_percent = 100 - ((double) dist / HEIGHT * 100);

		sprintf(buf, "Proz: %d", (int)fill_percent);
		lcd_puts("Fuellstand:\n");
		lcd_puts(buf);

		delayms(3000);
	}
}

Die Funktion read_cm liest dabei zyklisch die Distanz vom SRF02-Modul.
Aktuell bootet der Controller nicht mehr, aber ich habe den Effekt, dass mit externem 4MHz Quarz ODER Quarzoszillator der Chip nach Einschalten der Spannung für kurze Zeit arbeitet, dann wieder einfriert (LED blinkt dann schneller, weil vorher 1MHz per _F_CPU eingestellt war!).
Ich habe auch schon versucht, alle I2C-Komponenten aus der Schaltung zu lassen, das half leider auch nichts.
Kann man einen Programmiermodus durch manuelle Beschaltung erzwingen, sodass die CPU erst garnicht bootet, ich meine dabei den Modus, den PonyProg benutzt um die CPU zu flashen?
Bei der Beschaltung habe ich mich genaustens an die Tutorials hier im Wiki gehalten.
Das LCD betreibe ich im 4-Bit-Mode (DB0-3 auf GND; DB4-7 an Pins D4-7; RS an Pin D0, RW an D2, E an D1), die Ports und Pins habe ich in der lcd.h entsprechend eingetragen (funktionierte ja auch schon!).
Für den I2C-Bus habe ich die Hardware-Implementierung von Peter Fleury benutzt (i2cmaster.S). SDA und SCL habe ich mit einem Pullup-Widerstand von 4,7kOhm versehen. Zunächste dachte ich, den Wert des SRF02 alle 3 Sekunden abzufragen sei zu oft, aber ich denke daran liegt es eher nicht!?

Wo liegt mein Fehler?

Ich würde mich sehr über Hinweise freuen.
MFG,
mefiX

[Gock]

Kann es sein, dass Du vergessen hast die Fusebits für Deinen Quarz einzustellen? Das könnte einiges erklären.
Gruß

[mefiX]

Hallo!

Ich wollte die Fusebits eigentlich unberührt lassen und den internen Taktgenerator mit 1MHz benutzen. Das Quarz und den Quarzoszi mit 4MHz habe ich jetzt nur zum Debuggen angeschlossen, ob es daran liegt. Könnte es denn sein, dass die Register der Fusebits überschrieben wurden?

Ich hatte mir bei vorherigen Tests 2 Atmega32 zerschossen, weil ich nicht wusste, dass die Häkchen in PonyProg invers zu verstehen sind, genau deswegen wollte ich jetzt darauf verzichten!

Also wie gesagt, ich habe nichts an den Fusebits eingestellt und die CPU lief für mindestens 20 Mal flashen...

Vielen Dank für die Antwort!

LG,
mefiX

[Gock]

Also wenn Du die Fusebits nicht überschrieben hast, dann wurden sie auch nicht überschrieben.
Aber zerschießen kann man sich einen Mega eigentlich nicht durch flashen. Das geht nur, wenn ein Hardwarefehler vorliegt oder, wenn die Software in desaströser Weise auf die Hardware zugreift und sich dann aus Versehen selbst hinrichtet.
Wird er denn heiß, bevor er stirbt?
Wenn Du schon einen Quarz dran hast, dann aktivier' ihn doch einfach mal über die Fusebits.
Mit Ponyprog kenne ich micht nicht aus, ich benutze AVRStudio.
Warum nimmt man eigentlich Ponyprog? Was ist daran besser als AVRStudio oder was kann es zusätzlich?
Gruß

[mefiX]

Hi!

Ich benutze einen Programmer über die Parallele Schnittstelle, AVR kann leider nur den seriellen ansteuern, deswegen PonyProg.
AVRStudio benutze ich aber zum Programmieren.

Hier ein Bild vom Schaltungsaufbau:
(click für große Version!)
Bild hier  

Rechts im Bild, mein Programmer.
Die Fusebits kann ich nicht mehr schreiben.

LG,
mefiX

[Hubert.G]

@Gock
Mit dem AVR-Studio kannst du die einfachen Programmer (74HC244, oder nur Widerstände, einfache serielle) nicht verwenden, dafür gibts halt PonyProg ( vielleicht auch noch was anderes).
Für viele einfach eine Kostenfrage.

[Hubert.G]

@mefiX
Hast du vielleicht versehentlich das LockBit gesetzt, dann geht auch nichts mehr, versuche mal ein Chiperase.

[Gock]

Einfrieren klingt nach Übertragungsfehler. Fleurys Code ist nicht IRQ basierend, dh. es wird gewartet. Wenn nix zurückkommt, weil ein Fehler in der Übertragung ist, dann friert der µC ein. Ich glaube, es gibt keinen Timout.
Hast Du schon mal die Übertragungsrate erniedrigt? Hast Du den Takt richtig in der Software angegeben? Sind die Leitungen wirklich gut verbunden?
Für Datenübertragungen aller Art ist ein Quarz schon besser geeignet, weil er genauer ist. Weiß aber nicht, ob das eine Fehlerursache sein kann.
Oder
Halt' mal ein Oszi an die Versorgungsspannung!
Gruß

[mefiX]

Hi!

Also ich habe weder an den Fusebits noch an irgendwelchen anderen Lock- oder Optionsbits etwas geändert, in der Hinsicht sollte alles im Auslieferungszustand sein.

Chip-Erase klappt leider auch nicht mehr.

Die Taktfrequenz im aktuellen Flash steht leider auf 1MHz (_F_CPU), ich habe aber nur ein 4MHz Quarz und ein 4MHz Quarzosi.

Kann es sein, dass die Leitungen des Bread-Boards einfach zu schlecht sind?
Die Schaltung steht die ganze Zeit neben mir, zwischendurch sehe ich immer mal wieder ein Blinken der Toggle-LED.

Die I2C-Verbindung sollte auch in Ordnung sein, ich habe Alles schon mal für ca. 5 Minuten am Stück laufen lassen, lief perfekt.

Meine letzte Änderung am Code war:

      fill_percent = 100 - ((double) dist / HEIGHT * 100);
      sprintf(buf, "Proz: %d", (int)fill_percent);

Kommt die CPU vll. nicht mit dem Cast zurecht?

Ich kann mir ja jetzt wieder 3 neue Atmegas kaufen, aber ich vermute, dass ich die dann auch schrotte :-/

VLG,
mefiX

[linux_80]

Hallo,

wenn Du an den Fusebits nix gemacht hast, ist es dem AVR egal welcher Quarz da draussen dranhängt, er benutzt ihn ja nicht.

Evtl. musst Du doch alle Leitungen nochmal neu Stecken, damit die Kontake besser werden. Oder zumindest durchpiepsen, ob da auch richtiger Kontakt herrscht. Wenn eine der Leitungen einen Wackler hat, ist es Glückssache obs geht.