Atmega8 + SRF02 (I2C)

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:

Code:

---

#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

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

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

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ß

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

@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.

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

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ß

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:

Code:

---

      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

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.

Also wenn die µCs definitiv im Eimer sind obwohl es gewisse Zeit funktioniert hat, dann ist eher die Hardware problematisch. Ich würde die Versorgung prüfen, sämtliche Rs nachgemessen und alles abstöpseln, was nicht gebraucht wird. Außerdem die TWI Leitungen oder besser gleich alle so kurz machen wie möglich, vielleicht sogar schirmen. Vielleicht noch eine Metallplatte unterlegen, wegen Störungen, falls das Board sowas nicht eh' schon hat.
Was hängt eigentlich an den Ports? Vielleicht fließt da ja zu viel Strom...
Mehr fällt mir auf die Schnelle nicht ein.
Gruß

Hi!

Danke für Alle Ratschläge.
Ich habe alle Leitungen zwischen Programmer und µC geprüft, LCD und I2C entfernt.
An den Ports hängt (ausser Spannungsversorgung und GND):
PC6: RESET zum Programmer
PD0: RS (LCD)
PD1: Enable (LCD)
PD2: R/W (LCD)
PD3: N/C
PD4: DB4 (LCD)
PD5: DB5 (LCD)
PD6: DB6 (LCD)
PD7: DB7 (LCD)
PB0: Toggle-LED mit 1k gegen +5V
---------
PC5: I2C - SCL
PC4: I2C - SDA
...
PB5: SCK (Programmer)
PB4: MISO (Programmer)
PB3: MOSI (Programmer)

Der Rest N/C.
Als Spannungsversorgung habe ich ein 9V Universalnetzteil mit 800mA (sollte doch langen?). Als Stabilisierung ein LM7805 mit einem 4,7µF Elko und zwei 100nF Kerko. Die Spannung ist eigentlich sehr Stabil.

Hallo Zusammen!

Mir ist noch etwas aufgefallen!
Ich habe Code aus der lcd_test.c (aus der LCD-Lib) übernommen!

Code:

---

    //DDRD &=~ (1 << PD2);        /* Pin PD2 input              */
    //PORTD |= (1 << PD2);        /* Pin PD2 pull-up enabled    */

---

Der LCD-Test wartet nach jedem einzeltest auf einen Taster ... den habe ich garnicht!! An Pin2 habe ich den RW des LCDs angeschlossen ](*,)

Könnte das den µC zerschossen haben?

Übrigens kann ich als IDE folgende Kombination empfehlen (Linux + Windows!)

Eclipse
Eclipse-CDT
Eclipse-CDT-AVR-Plugin
Avrdude
Avrdude-Utils

Damit lässt sich dann auch direkt aus Eclipse heraus der Controller flashen (STK200 über Parallel).

du solltest mal deinen antennenwald(verbindungsdrähte) kürzer halten.

darauf regaieren die baugruppen ultra usw empfindlich.

*hehe* ok ;)
Wollte halt etwas geizen und habe als Drahtbrücken Telefonkabel-Adern benutzt. Wenn man die Teile bei Conrad holt bezahlt man ja ein schweine Geld ...
entsprechend unterschiedlich sind die alle lang und abisoliert :-/

Hab jetzt neue Atmega's. Mit dem ersten läuft im Moment noch Alles stabil ...

Hast Du auch ein Tutorial für die Nutzung von Eclipse und AVR?
Hab es bisher nicht hinbekommen...
Gruß

ja:
http://www.asurowiki.de/pmwiki/pmwiki.php/Main/Eclipse

Er schreibt, dass das AVR-Plugin unter Linux nicht läuft, bei mir klappte es auf anhieb. Fürs flashen braucht man unter Linux die ganzen avrdude binaries.

Ja, das kenne ich, aber ich habe keinen Asuro. Und ohne diese Bibliotheken scheint es bei mir nicht zu laufen...
Gruß

die geschichte mit der asuro-lib kann man eigentlich ignorieren, ich benutze die ja auch nicht!

oder hier:
http://www.mikrocontroller.net/articles/AVR_Eclipse

Aja, das ist besser, danke.
Jetzt bekome ich beim Debuggen nur noch den Fehler: ExecError: Launching Failed.
???

PS: Ich kann übrigens kaum glauben, dass sich Dein µC wegen LCD TasterFehlers zerstört hat...
Gruß