Go Down

Topic: "Falschen" Prozessor nutzen (Read 3800 times) previous topic - next topic

Ich fange gerade mal an mit dem Ding (also dem Arduino Uno) zu spielen ... und für meine ersten Gehversuche (also LED blinken lassen und so) muss ich ja nicht unbedingt den ATMEGA 328 haben, dachte ich mir. Habe ja noch einen alten ATMEGA8 hier herumliegen, der tuts doch erstmal genauso? Sind ja schließlich pinkompatibel, die beiden ICs. Und die Anzahl der möglichen Uploads pro Chip ist begrenzt ... wäre ja Verschwendung, die für Spielereien sinnlos zu verbraten.

Gesagt, getan. Bootloader habe ich auf den Chip draufgekriegt, ein erstes kleines Testprogramm auch. Damit der Compiler weiß, daß er heute für einen anderen Chip übersetzen soll, habe ich unter "Tools / Board" einen Eintrag mit "Atmega 8" gesucht und ganz unten auch einen gefunden. 

Es läuft auch prima, die LED blinkt, die Serial.Print()s schreiben ihren Senf ins Fenster ... aber eines fällt mir doch auf.

Wenn ich den Atmega 328 in der Fassung habe und den Reset-Button drücke, startet das Programm, das ich darauf geladen habe, ziemlich schnell. Wenn ich den Atmega 8 in der Fassung habe und den Reset-Button drücke, dann dauert es ca. 10 Sekunden, bis das Programm startet. Was zum Teufel macht der so lange?

Hat jemand eine Idee, woran das liegen kann, und wie man es beheben kann?

Gruß

Late_night.

uwefed

#1
Oct 10, 2012, 01:42 am Last Edit: Oct 10, 2012, 11:47 pm by uwefed Reason: 1
Da sind 2 verschiedene Bootloader drauf. Der neue ist schneller mit der Kontrolle, ob ein Sketch draufgeladen werden soll und der andere alte auf dem ATmega8 ist laaannngggsssammer.
Der Bootloader ist für die Veschiedenen Modelle kompiliert und kann nicht so einfach ausgetauscht werden. Ich weiß nicht ob man die Quelldatei des neuen Bootlaoders für den ATmega8 compilieren kann und ob der dann funktioniert.

Grüße Uwe

Udo Klein

Wenn Du den Bootloader aufgespielt hast, dann hast Du dazu zwangsläufig einen ISP gebraucht. Wieso lässt Du den Bootloader dann nicht einfach weg und flashst immer per ISP. Das ist im Zweifelsfall immer schneller als der Bootloader.
Check out my experiments http://blog.blinkenlight.net


Wenn Du den Bootloader aufgespielt hast, dann hast Du dazu zwangsläufig einen ISP gebraucht. Wieso lässt Du den Bootloader dann nicht einfach weg und flashst immer per ISP. Das ist im Zweifelsfall immer schneller als der Bootloader.


Hmm ... gute Idee, eigentlich.

Wenn ich mein eigenes Programm  mit ISP aus der Arduiuno-Umgebung einspiele, wird dann der Bootloader automatisch gelöscht bzw. überschrieben und NUR mein Programm aufgespielt? Oder bleibt der Bootloader drinnen - für den Fall, daß ich ihn das Nächste Mal doch wieder benutzen will?

In Letzterem Falle würde das mein Problem mit den 10 Sekunden Verzögerung vor Programmstart nämlich nicht lösen ... denn es ist ja wohl der Bootloader, der da seine gemächlichen Runden dreht, bevor er die Kontrolle an mein Programm übergibt.

Im Ersteren Falle müsste ich dem Chip wohl auch noch mitteilen, daß er jetzt bitteschön OHNE Bootloader arbeiten soll - oder? Ich weiß, das macht man mit anderen Fuses ... aber mit welchen? Für Tips bin ich dankbar. Nicht daß ich zu faul wäre, mir das selbst herauszusuchen, neinneinnein ... ich will nur nicht das Risiko eingehen, falsche Fuses zu setzen. ;-)

Gruß

Late_night.

Udo Klein

Wenn Du direkt Flashst, dann setzt die IDE die Fuses normal so, daß danach kein Bootloader drin ist. Du kannst den Bootloader aber jederzeit wieder flashend. Fragt sich nur wozu ;)
Check out my experiments http://blog.blinkenlight.net

Realizer

Dies kann ich bestätigen ;) Habe mal auch einen Atmega 8 genommen und ihn auf den Arduino gesteckt. Dann ein Blink-Programm mit AtmelStudio geschrieben und über ISP in den Arduino gespielt.

Es gibt dort kein Bootloader. Das Blinkprogramm beginnt sehr zeitnah mit der Abarbeitung des Programmes. Ich bin derzeit sowieso ziemlich hin und hergerissen. Benutze ich Arduino IDE mit dem Bootloader, dann kann ich ohne ISP fast an jedem PC Programme uploaden. Wenn ich einen ISP besitze kann ich die volle Speichermenge des Atmel Controllers ausnutzen.

Nun habe ich doch direkt mal noch eine Frage ;): Wenn ich ein Programm in der Arduino IDE schreibe, dann das Hexfile mittels Atmelstudio in einen Controller schreibe, funktioniert das Programm dann auch ? Oder sind einige Funktionen vom Bootloader abhängig ?

Inwiefern hat der Bootloader mit dem Code zu tun ?
Eine Kuh macht muuhh.
Viele Kuehe machen Muehe

sth77

Der Bootloader hat keinen Einfluss auf den Code, er raubt nur dessen Platz. :D
Mein Arduino-Blog: http://www.sth77.de/ - letzte Einträge: Teensy 3.0 - Teensyduino unter Window 7 - Teensyduino unter Windows 8

Udo Klein

Theoretisch könnte man aus dem Code auf den Bootloader zugreifen um den Flash Speicher als erweitertes EEPRom zu nutzen. Praktisch scheitet es aber daran, daß man ja nicht weiß welcher Bootloader da ist. Soll heissen: theoretisch könnte man den Bootloader auch ausnutzen. Gesehen habe ich sowas aber noch kein einziges Mal.

Jemand der sowas tut weiß genau wie der BL aussehen muß. Alle anderen profitieren eher davon keinen zu haben ;)
Check out my experiments http://blog.blinkenlight.net

Realizer

#8
Oct 12, 2012, 11:46 pm Last Edit: Oct 12, 2012, 11:48 pm by Realizer Reason: 1
Danke Euch allen :) Diese Information ist recht wichtig, wie ich glaube.

Somit kann ich den ordinären Arduino als "Platine" nutzen, weil dort der 6-polige ISP Stecker drauf ist. Dann habe ich noch einen Quartz und eine Steckleiste die es mir ermöglicht, Breadboard schnell und einfach zu integrieren.

Die Lösung, einen Atmega168 zum Programmieren des Attiny`s, (Arduino als ISP), funktioniert nicht wegen Ermangelung des Speichers. Uno kaufen war nicht angesagt. Daher einen Programmer her, der das kann. Ich bereue diese Entscheidung nicht im Geringsten. Nun könnte man meinen, ich komme von dem Arduino weg. Nein ! Die Systeme sind in Kombination eher noch interessanter und durch den FTDI Chip am Diecimila eine Nummer zum lernen und entwickeln. Ich kaufe mir halt nicht jedes Jahr einen neuen Arduino, zumal die neue Generation einen Prozessor hat, der fest eingelötet ist ;)
Eine Kuh macht muuhh.
Viele Kuehe machen Muehe

Vielen Dank auch von mir bei Allen, die etwas zur Klärung der Sachlage beigetragen haben. Daß ein Programm, daß ich in der Arduino-IDE geschrieben habe, auch ohne das Vorhandensein eines Bootloaders läuft, war mir nicht so wirklich klar.

Mit dieser Erkenntnis ausgestattet, würde nun sehr gerne meinen USBasp ständig am Arduino angeschlossen lassen und mein Programm immer mit seiner Hilfe "brennen und sofort starten". Aber die Entwickler der Arduino-IDE werfen mir da ein paar Steine in den Weg.  =(

Wenn ich die Funktion "Upload mit Programmer" aufrufe, dann bekomme ich grundsätzlich eine Messagebox mit dem folgenden Text:
Quote from: Arduino IDE

The connection to the Board failed. This tool can try to fix the issue by disabling and re-enabling the related device.

Auch ein Klicken auf den Button "Fix" führt zu keinem Erfolg.

Wenn ich dagegen meinen ISP-Brenner (wie erwähnt, ein USBasp, was ich natürlich auch im Menü der Arduino-IDE angegeben habe) von einem anderen Programm aus starte (wie z.B. Khazama AVR Programmer oder eXtreme Burner AVR), dann funktioniert er ganz prima und schreibt mir nach Herzenslust HEX-Files in den ATMega. Es liegt also wohl nicht an der Hardware.

Nun könnte ich ja auch einfach auf das Brennen aus der Arduino-IDE heraus verzichten und mein HEX-File mit Hilfe eines dieser Programme "zu Fuss" brennen. Aber dazu muss ich es erst einmal finden.

Eine Suche nach der Stelle, an der ich suchen soll, führte mich zu der folgenden Information:
Quote from: Arduino Cookbook

The compiler produces a number of object files (files with an extension of .o that will be combined by the link tool). These files are stored in /tmp on Mac and Linux.
On Windows, they are in the applet directory (a folder below the Arduino install directory).

The object files are then linked together to make a hex file to upload to the board. Avrdude, a utility for transferring files to the Arduino controller, is used to upload to
the board.

Auf meinen PC mit Windows XP bezogen ist das schlichtweg falsch. Ich habe zwar ein "applet"-directory gefunden, aber das ist leer ...

Nach längerem Suchen wurde ich dann im Verzeichnis "C:\Dokumente und Einstellungen\<Windows-Nutzer-Name>\Lokale Einstellungen\Temp\" fündig. Hier legt die IDE bei jedem Compiliervorgang ein Verzeichnis mit dem Namen "build<irgendeineZahl>.tmp" an. Wenn ich dort suche, finde ich mit viel Glück alle HEX-Dateien meiner bisherigen Versuche, und auch noch viele weitere Dateien, die mir die Festplatte zumüllen. In welchem Unterverzeichnis ich allerdings suchen soll, muß ich mühsam selbst herausfinden.

Einmal habe ich mir jetzt die Mühe gemacht, die richtige HEX-Datei anhand des Erstellungsdatums herauszusuchen und mit dem externen Brennprogramm auf meinen ATMEGA zu laden. Schau an, es funktioniert!  :smiley-yell:   Und zwar ohne diese durch den Bootloader hervorgerufene ärgerliche 10-Sekunden-Verzögerung nach dem Drücken des Reset-Knopfes. Mein Programm startet sofort, wie ich es haben will. Ganz prima.

Richtig glücklich wäre ich jetzt, wenn mir noch jemand sagt, wie ich

- entweder die Fehlermeldung der IDE wegbekomme, damit die den USBasp richtig erkennt und ich mein Programm mit ihm aus der IDE heraus brennen kann,

- oder aber die IDE dazu veranlassen kann, daß es die HEX-Datei (und wenn möglich, noch mehr "interessante" Dateien, wie z.B. die EEP- und die ELF-Datei) dorthin schreibt, wo auch mein Programm (also die INO-Datei) steht. Dort würden diese Dateien nämlich m.E. eigentlich hingehören ...

Wenn beide Probleme gelöst werden, habe ich auch nichts dagegen.  :)

Hat jemand Ideen?

Gruß

Late_night

Udo Klein

Schritt 1: In der IDE unter Filer -> Preference "show verbose output during upload" ankreuzen und die detailierte Fehlermeldung posten. Danach kann man schon eher sagen wo das Problem liegt. Und wenn Du den anderen "verbose" Haken auch noch ankreutzt, dann siehst Du auch sofort was in welchen Verzeichnisen los ist.

Und wenn Du es wirklich ganz genau wissen willst: in meinem Buch gibt es ein Kapitel "hinter den Kulissen", da trete ich das richtig breit ;)
Check out my experiments http://blog.blinkenlight.net

Danke für den Tip, Udo. Habe ich gleich gemacht.

Das Problem liegt wohl daran, daß die IDE zum Brennen das Programm "C:\Programme\Arduino\hardware/tools/avr/bin/avrdude.exe" aufruft. Dieses ist nur 9kB groß und startet die besagte Dialogbox (wohl durch Aufruf von avrdudefix.exe). Wenn man statt "avrdude.exe" das Programm "avrdude2.exe" mit der gleichen Kommandozeile startet, dann wird prima gebrannt. Die Datei "avrdude2.exe" ist übrigens identisch mit der eigentlichen Datei "avrdude.exe", wie sie z.B. mit WinAVR installiert wird. Sie wurde von den Entwicklern der IDE wohl einfach nur umbenannt, damit das eigene Programm gestartet werden kann, und jetzt nicht mehr gefunden.

Daß es mit meinen anderen Brennprogrammen funktioniert, liegt einfach daran, daß die eine Kopie von "avrdude.exe" finden und benutzen, die sich im Verzeichnis von WinAVR befindet, das auf meinem Rechner ebenfalls installiert ist.

Wie kann ich der IDE beibringen, daß sie bitteschön zum Brennen "avrdude2.exe" aufrufen soll, wie es sich gehört?

Das zweite Problem war mit dem Tracing des Compilierlaufes nicht zu lösen, allenfalls habe ich die Bestätigung für die von mir oben beschriebene Verwendung der Inhaltsverzeichnisse gefunden. Mein Wunsch wäre es ja, die hier aufgerufenen Kommandozeilen nicht nur zu verstehen (das tue ich), sondern so zu ändern, daß sie das tun, was ich gerne hätte, nämlich die Outputfiles des Compilers (HEX, EEP, ELF, ..) direkt neben meinen Quellcode (*.INO) zu schreiben.

Normalerweise stehen solche Kommandozeilen irgendwo in einem Make-File oder Batch-File oder so, wo man dran herumspielen kann ... ich habe es aber nicht gefunden ...  =(


Und wenn Du es wirklich ganz genau wissen willst: in meinem Buch gibt es ein Kapitel "hinter den Kulissen", da trete ich das richtig breit ;)

Nett, das Du die Gelegenheit nutzt, um Werbung für Dein Buch zu machen, das hilft mir aber gerade nicht WIRKLICH weiter. ;)

Gruß

Late_night
(ganz gegen meine Gewohnheiten tagsüber)

Realizer

Da klemmt`s bei mir schon viel weiter vorne. Bei der IDE 1.0.1 kann ich den AVRISP mkII garnicht erst nutzen, da hier keine COM Schnittstelle zur Verfügung steht. Das Auswahlfeld für die serielle Schnittstelle ist ausgegraut. Am Atmelstudio funktioniert es ohne Comport direkt auf den ISP.

Müsste ich da vielleicht noch eine zusätzliche Software (Treiber) intallieren, der mir einen Comport zur Verfügung stellt ? Beissen sich dann vieleicht die beiden Treiber, so wie ich es zuvor schon befürchtet habe? Der Diamex All-AVR scheint irgendwie etwas Besonderes zu sein ;)

Eine Kuh macht muuhh.
Viele Kuehe machen Muehe

Udo Klein

AVRISPmkII braucht keinen Comport. Zur seriellen Kommunikation braucht man einen Comport, das kann ein Programmer logischerweise nicht leisten.

Wenn man den ISP direkt zum Flashen verwenden will kann man das per Eintrag in der Datei boards.txt erledigen:

Code: [Select]

atmega328ispmk2.name=Arduino ATmega328 AvrISPmkII

atmega328ispmk2.upload.maximum_size=32768
atmega328ispmk2.upload.using=avrispmkii

atmega328ispmk2.build.mcu=atmega328p
#atmega328ispmk2.build.f_cpu=16000000L
atmega328ispmk2.build.f_cpu=1000000L
atmega328ispmk2.build.core=arduino


in programmers.txt sollte dazu folgendes drinstehen:

Code: [Select]
avrisp.name=AVR ISP
avrisp.communication=serial
avrisp.protocol=stk500v1

avrispmkii.name=AVRISP mkII
avrispmkii.communication=usb
avrispmkii.protocol=stk500v2


@Late_night
Was avrdude vs. avrdude2 angeht: was hindert Dich daran die Datei avrdude2 auf avrdude zu kopieren? Oder stehe ich gerade auf dem Schlauch.

Quote

Nett, das Du die Gelegenheit nutzt, um Werbung für Dein Buch zu machen, das hilft mir aber gerade nicht WIRKLICH weiter. smiley-wink

Schon klar, kostenlosen Support darf ich immer gerne machen. Ein Buch schreiben, weil hier einige danach gefragt haben, darf ich auch gerne. Einen kostenlosen Blog auch. Darauf hinweisen aber nicht...
Check out my experiments http://blog.blinkenlight.net

sth77


Da klemmt`s bei mir schon viel weiter vorne. Bei der IDE 1.0.1 kann ich den AVRISP mkII garnicht erst nutzen, da hier keine COM Schnittstelle zur Verfügung steht. Das Auswahlfeld für die serielle Schnittstelle ist ausgegraut.

Udo hat ja bereits geschrieben, dass kein Com-Port beim MKII benötigt wird. Wie der Zufal so spielt, habe ich gerade ein jungfräuliches Win7-System aufgesetzt, woraufhin ich auch nochmal den MKII installiert habe. Der funktioniert mit dem libusb-Treiber hervorragend, wobei die Installation mal wieder für ein paar graue Haare sorgte. ;)
Zunächst habe ich mir den aktuellen Treiber besorgt: http://sourceforge.net/projects/libusb-win32/files/
Im Verzeichnis bin gibt es die Datei inf-wizard, die startet man, während der MKII angeschlossen ist. Aus der erscheinenden Auswahlliste (device selection), wählt man den Programmer aus, es werden aber auch andere USB-Geräte gelistet. Daraufhin werden am wählbaren Speicherort Treiber angelegt. Ich habe daraufhin alles, was im Geräte-Manager zum MKII erscheint, deinstalliert und den MKII abgeklemmt und den Rechner neu gestartet. Nach dem Neustart konnte ich aus meiner angelegten Quelle direkt den Treiber installieren - ein kurzer Test brachte die Bestätigung, dass alles reibungslos funktioniert.
Mein Arduino-Blog: http://www.sth77.de/ - letzte Einträge: Teensy 3.0 - Teensyduino unter Window 7 - Teensyduino unter Windows 8

Go Up