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.
Salut ... Wenn ich mir das aktuelle (SVN-Revision 253) makefile ansehe stelle ich fest das die Fusebits nicht gleich sind.
1 | fuse: |
2 | ifeq ($(MCU),atmega2561) |
3 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U lfuse:w:0xe6:m |
4 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0x91:m |
5 | # $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0xd1:m |
6 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U efuse:w:0xfd:m |
7 | endif |
8 | ifeq ($(MCU),atmega644) |
9 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U lfuse:w:0xe6:m |
10 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0xd1:m |
11 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U efuse:w:0xfd:m |
12 | endif |
13 | ifeq ($(MCU),atmega644p) |
14 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U lfuse:w:0xe6:m |
15 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U hfuse:w:0xd1:m |
16 | $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_FUSE) -q -U efuse:w:0xfd:m |
17 | 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
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
Das mit dem refresh kannst du auch selber schnell ändern. Schau mal in die Datei "apps/modules/cmd_adc.c" nach folgendem Codefragment:
1 | /* printf_P( PSTR( "<HTML>"
|
2 | "<HEAD>"
|
3 | "<TITLE>ADC</TITLE>"
|
4 | "</HEAD>"
|
5 | "<BODY>" ));*/
|
6 | cgi_PrintHttpheaderStart(); |
7 | 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.
1 | printf_P( PSTR( "<HTML>" |
2 | "<HEAD>"
|
3 | "<meta http-equiv=\"refresh\" content=\"30; \">" |
4 | "<TITLE>ADC</TITLE>"
|
5 | "</HEAD>"
|
6 | "<BODY>" )); |
7 | /* cgi_PrintHttpheaderStart(); */
|
8 | 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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.