mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR-NET-IO mit ATmega644


Autor: Manfred O. (taigatiger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe mir das Pollin-Board zugelegt um von extern Ein-/Ausgaben zu
machen. Mit dem ATmega32 klappt alles auch mit anderer SW intern mit
192...
Nun wollte ich mal OpenMCP heraufladen und habe dafür den ATmega32 durch
einen ATmega644 augetauscht, soll ja pinkompatibel sein. Mit AVR-Dragon
habe ich dann das mit ATmega644-Option compilierte OpenMCU-Hexfile über
AVR-Studio 4.xx auf das AVR-NET-IO-Board geladen. Nur das Programm
funktionierte nicht. Auch ein anderes Programm kann nun nicht mehr auf
den ATmega644 geladen werden, das Teil ist einfach nicht mehr
erreichbar, weder mit AVR-Studio als auch mit avrdude. Wenn ich den
ATmega32 wieder einsetze ist wieder alles okay. Was ist da los? Kann der
ATmega644 kaputt gegangen sein? Oder muß man noch zusätzliche
Einstellungen machen?
Für Hinweise wäre ich sehr dankbar.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Mar Vol (marvol)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manfred,

ich habe OPENMCP mit ATMega644 erfolgreich zum Laufen gebracht (außer 
die Erkennung vom DHCP wollte nicht so...). Wenn Du Dir den Makefile 
anschaust, müssen die Fusebits geändert werden:

fuse:
ifeq ($(MCU),atmega2561)
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U lfuse:w:0xe6:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0xd1:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U efuse:w:0xfc:m
  PROGRAM_F=ok
endif
ifeq ($(MCU),atmega644)
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U lfuse:w:0xe6:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0xd1:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U efuse:w:0xfc:m
  PROGRAM_F=ok
endif

Bevor ich irgendwas auf den Controller geschickt habe, habe ich erst die 
Fuses gesetzt, überprüft ob diese auch wirklich gesetzt sind (geht alles 
mit avrdude). Danach habe ich das Programm mit dem Makefile übertragen 
und es lief. Ich vermute, Du hast beim Flashen über AVR Studio die Fuses 
zerschossen, Du mußt mal suchen mit welcher Einstellung die übertragen 
wurden. Ich habe die Controller nur dann wieder zum Leben erwecken 
können, wenn ich dann wieder mit dem richtigen Quarz gebrannt habe. Es 
scheint aber noch andere Möglichkeiten zu geben.

Gruß
Marvol

Autor: Manfred O. (taigatiger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, vielen Dank erst einmal. Weil man die Fuse-Bits wohl zuerst mal 
setzen muß ist hier mein Problem. Das habe ich nicht gemacht, weil ich 
glaubte, daß das die Software macht, die ich da lade. Nun kann ich mit 
einfachen Mitteln den 644 nicht mehr ansprechen weil die Signatur des 
Prozessors auf 000000 steht und von keinem Programm/Adapter angesprochen 
werden kann. Wird wohl nur noch mit HV-Prog machbar sein, aber das kann 
der Dragon, ich muß mir nur noch Verbindungsleitungen herstellen oder 
besorgen, weil man das Teil dann in "Prototype Area" prozessorspezifisch 
verdrahten muß.
War alles mein Fehler, denn erst einmal hätte ich die Fusebits auslesen 
und richtig setzen müssen. Nun kaufe ich mir entweder einen neuen 644 
oder versuche den alten Prozessor wieder zum Leben zu erwecken.
Nochmals vielen Dank.

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...man kann die Fuses jederzeit neu setzen!

Wie es sich anhört hast Du aber wohl die falschen Oszillator-Optionen 
gewählt. Entweder läuft Dein AVR nun zu langsam (setz' mal die 
Programmierfrequenz beim Dragon herunter), oder er braucht nun eine 
externe Taktquelle. Die Forumssuche sollte Dir da erschöpfend 
weiterhelfen...

Autor: Manfred O. (taigatiger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es waren nicht die Fuses. Die Programmierfrequenz des Dragon war zu 
groß. Ich mußte sie auch 250 kHz zurück nehmen, jetzt gibt es keine 
Probleme mehr mit dem Setzen der Fuse-Bits oder dem Programmieren des 
Flash.
Ganz klar ist mir das aber doch nicht, denn mit dem ATmega32 gab es 
keinerlei Probleme.
Ebenso macht das AVR-Studio neuester Version (4.18 Build 684) Probleme, 
weil es immer mal wieder blockiert und entfernt werden muß. Ich benutze 
es nur zur Ansteuerung des Dragon, weil er damit besser zu handeln ist.
Vielen Dank für die Hilfe.

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es waren nicht die Fuses. Die Programmierfrequenz des Dragon war zu
> groß. Ich mußte sie auch 250 kHz zurück nehmen, jetzt gibt es keine
> Probleme mehr mit dem Setzen der Fuse-Bits oder dem Programmieren des
> Flash.
> Ganz klar ist mir das aber doch nicht, denn mit dem ATmega32 gab es
> keinerlei Probleme.

Das hört sich verdächtig nach falschem(tm) Takt an. Die 
Programmierfrequenz sollte normalerweise(tm) < F_CPU/4 sein, hier darf 
mal also annehmen, dass der m644 mit nur 1MHz läuft - und das wiederum 
klingt sehr verdächtig nach 'internal RC-oszi @ 8MHz und CKDIV8'.

Ergo (wie schon mehrfach genannt): Fuses prüfen! Dazu ggf. ins 
Datenblatt schauen.

HTH

Autor: Manfred O. (taigatiger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem internen Takt dürfte nicht sein, obwohl es darauf hindeuten 
kann. Die Fuse-Bits habe ich genau so eingestellt sind wie im Makefile 
vom OpenMCP angegeben sind , aber sonderbar ist, daß dort für beide 
Prozessoren ATmega2561 und ATmega644 die gleichen Einstellungen 
angegeben sind (siehe oben bei Marvol). Das mit diesen Bits ist sowieso 
etwas verwirrend für mich und das Datenblatt gibt ohne tagelange 
Durchsicht keine schnelle Auskunft.

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Salut ...

Wenn ich mir das aktuelle (SVN-Revision 253) makefile ansehe stelle ich 
fest das die Fusebits nicht gleich sind.
fuse:
ifeq ($(MCU),atmega2561)
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U lfuse:w:0xe6:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0x91:m
#  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0xd1:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U efuse:w:0xfd:m
endif
ifeq ($(MCU),atmega644)
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U lfuse:w:0xe6:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0xd1:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U efuse:w:0xfd:m
endif
ifeq ($(MCU),atmega644p)
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U lfuse:w:0xe6:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0xd1:m
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U efuse:w:0xfd:m
endif

Aber so wie du das Problem beschreibst würde ich nochmal einen genauen 
blick auf die Fusebits werfen. Notfalls hilf ein "make fuse" auf der 
Konsole wenn du dich im Verzeichnis von OpenMCP befindest. Damit werden 
dann per avrdude und einem avrispMK2 die Fusebits gesetzt für die 
ausgewählt Plattform. Als einfachen Test wäre mal interessant wie 
schnell eigentlich dein RS232 vom AVR-NET-IO läuft. Die 
Standardeinstellung ist dort 57600 Baud.

CA Dirk

Autor: Manfred O. (taigatiger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die serielle Schnittstelle läuft und lief immer mit 57600 Baud. Die 
Fuse-Bits stimmen genau mit der letzten Fassung überein. Habe den 
ProgSpeed nun auf 2 MHz und es funktioniert. Es ist völlig unklar was 
das war, aber jetzt ist es offenbar okay. Kann auf OpenMCP von überall 
zugreifen usw. Was mir nicht gefällt ist das, daß man ständig neue Werte 
anfordern muß, statt daß sich die automatisch aktualisieren, z.B. die 
analogen Eingänge. Aber vielleicht gibt es mal eine neue Ausgabe, in der 
das so geht. Oder ich eigne mir entsprechende Kenntnisse über 
InternetProg an und kann das dann selber machen, denn die SW für OpenMPC 
selbst finde ich ausgesprochen klar und sauber programmiert und gut 
kommentiert, was keine Selbstverständlichkeit ist, sehr schön.
Vielen Dank nochmals für die Hilfe.
Manfred

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit dem refresh kannst du auch selber schnell ändern. Schau mal in 
die Datei "apps/modules/cmd_adc.c" nach folgendem Codefragment:
/*  printf_P( PSTR(  "<HTML>"
          "<HEAD>"
          "<TITLE>ADC</TITLE>"
          "</HEAD>"
          "<BODY>" ));*/
  cgi_PrintHttpheaderStart();
  printf_P( PSTR( "<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\">" ) );

und füge deinen eigenen HTML-Header ein (jetzt wird zu erzeugen des 
HTML-Headers cgi_PrintHttpheaderStart(); aufgerufen). Das 
auskommentierte Beispiel steht ja noch darüber. So wie du es haben 
willst könnte es dann so aussehen.
  printf_P( PSTR(  "<HTML>"
          "<HEAD>"
          "<meta http-equiv=\"refresh\" content=\"30; \">"
          "<TITLE>ADC</TITLE>"
          "</HEAD>"
          "<BODY>" ));
/*  cgi_PrintHttpheaderStart(); */
  printf_P( PSTR( "<table border=\"0\" cellpadding=\"5\" cellspacing=\"0\">" ) );

Damit wird die Seite alle 30 Sekunden neu geladen. Ich werte deinen 
Vorschlag mal als Wunsch und habe es auch schon eingepflegt in die 
Sourcen.

CA Dirk

Autor: Manfred O. (taigatiger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Dirk,
danke, AnalogRefresh funktioniert einwandfrei, aber beim DigitalOut 
schalten die Bits 0 und 1 nicht, die anderen sind okay. Ich habe überall 
gesucht, aber nichts gefunden. Habe meine alte Version geladen, alles 
okay, aber bei der neuesten Version das "Schaltversagen" bemerkt.
Manfred

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Salut ...


Das ist kein Versagen, sondern Absicht wenn TWI (I2C) eingeschaltet ist 
;-). Schau mal einfach in die config.h und schaltet TWI aus. Ist recht 
neu das Feature für den AVR-NET-IO. Es ist mit aufgenommen worden da ich 
mir zum basteln das AVR-NET-IO AddOn zugelegt habe. Aber ich sollte mal 
die zwei Digitalports ausschalten wenn TWI an ist, verwirrt wie ich 
gerade merke :-).
Bin gerade ein bisschen am umbauen von OpenMCP weil das AddOn auch 
unterstützt werden soll.

CA Dirk

Edit: Dann werden auch die Namen GPIO wegfallen und direkt die PortPins 
per Namen (z.B. PortC4 etc.) ausgegeben die angesteuert/ausgelesen 
werden können. Ist dann übersichtlicher. Aber da bin ich gerade dabei 
die Abstraktionsschicht für zu schreiben.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.