Fehler in MIGHTYCore?

Moin, könnte es sein, dass in der MIGHTYCore ein Fehler ist?
Ich kann ein Programm z. B. Blink nur im Modus 1MHz-intern auf einen ATMEGA32 hochladen. Gebe ich andere interne Frequenz angebe wird diese nicht verwendet. Das Programm läuft zwar, passt aber nicht zur Prozessorfrequenz. So wie ich das auf die Schnelle gesehen habe, passt es für 1MHz. Ich hatte auch schon öfter (jetzt natürlich nicht reproduzierbar) das sich der Chip im ISP-Modus nur 1-2mal ansprechen lässt, danach steigt der Programer mit einer Fehlermeldung aus "avrdude: ser_open(): can't open device "\.\COM11": Zugriff verweigert".
Atmel Studio zeigt mir die verwendeten 1MHz in den Fuses an, lässt sich aber auch nicht immer auslesen.

Sehr seltsam

Hast Du nach der Umstellung der Taktfrequenz den Bootloader gebrannt? Dabei werden auch die Fuses gesetzt.

Ne, Bootlader hab ich nicht verwendet, hab den ISP

Das passiert mindestens wenn...
Der serielle Monitor greift in einer zweiten Instanz auf den Port zu.

Wenn eine zweite Instanz (Auch der Gleichen!) IDE-Version läuft, geht das nicht.
Grundsätzlich dafür sorgen, das jeder SerMon der Arduino-IDE geschlossen ist.

Ah, ok d.h. wenn ich noch ein anderes Arduino-Fenster aufhabe passiert das? Ist mir so noch nie aufgefallen.

Wenn da irgendwo ein SerMon mitläuft? Ja.
Jede zweite Instanz stört.
Ich hab das hier gerade in den letzten Tagen beim Umschalten zwischen bootloader via ISP und Log via USB/Serial erfahren dürfen.

Will ich mal drauf achten, danke erstmal.

Das geht nur per ISP, oder HVPP.

Wenn du die Fuses nicht änderst, dann ändert sich auch nicht der Takt!
Die Einstellung im Boards Menue reicht dafür nicht.

Ist ja wie zu BASCOM-Zeiten, dann hatte das Eine mit dem Anderen nix zu tun. Und die Fuses lassen sich in der Arduino-IDE vorsichtshalber nicht ändern...?

Doch natürlich!
Auf Bootloader brennen drücken.(aber das wolltest du ja nicht)
Dann werden die Fuses geschrieben.
Und wenn du ein Board mit Bootloader gewählt hast dann auch der Bootloader,.

Ach so, weil ich den Bootloader hier nicht gebraucht habe, habe ich die Finger davon gelassen. Man lernt halt nie aus. Danke erstmal

Jain!
Wenn du nur ein weiteres Arduino Fenster(Thread) aufmachst(z.B. über Datei->Neu), geht das klar. Dann können die beiden "Instanzen" sich schon über den COM Port einig werden. Sie teilen sich einen seriellen Monitor.

Wenn du aber eine weitere Arduino Anwendung aufmachst(z.B. über das Windows Menü) , dann sehen die sich nicht und sprechen auch nicht miteinander. Jede hat ihren eigenen Monitor. Ihre eigene COM Verwaltung. Und dann, genau dann, gibt es diese Probleme.

Erst wählst Du die Taktfrequenz, dann hiermit, ob Du einen Bootloader haben möchtest:
grafik
Dann gehst Du auf "Bootloader brennen", der die Fuses setzt und dann entweder eine Datei optiboot_flash_atmega32_*.hex oder empty.hex überträgt.
Bei einem UNO werden viele Optionen für den µC auf nicht änderbare Standardwerte gesetzt, um es dem Anwender einfacher zu machen. Die Datei boards.txt gibt Auskunft.

Jetzt wo ich es lese, da war mal was.

Und es ist noch immer da :face_with_hand_over_mouth: