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