momentan arbeite ich an einem Projekt, bei dem ich einen Atmega zwar mit Code, der von der Arduino-IDE generiert wird, bespiele, selbigen aber direkt (d.h. ohne Bootloader) ausführe.
Dazu verwende ich ein STK500, bei dem es ja möglich ist, die Zielspannung anzugeben, und programmiere den Chip via ISP.
Nun ist mir folgendes aufgefallen: Setze ich die Zielspannung auf 3.3 V und spiele mein Programm auf, läuft es wie erwartet. Setze ich allerdings die Zielspannung auf 5 V (oder versorge den Atmega extern mit 5 V), läuft das Programm auf einmal deutlich langsamer.
könnte es ein "mißverständnis" zwischen compiler und fuses sein?
mit 3,3V kannst Du nicht mit 16MHz arbeiten. mit 5V schon. wenn also die fuses immer auf "interner 8MHz takt" gesetzt bleiben, der compiler aber bei 5V für "externer 16MHz takt" kompiliert, wird ein programm nur halb so schnell arbeiten, das auf den takt abgestimmt ist.
Laut Datenblatt http://www.atmel.com/Images/doc8161.pdf Seite 316 Bild "Figure 28-1. Maximum Frequency vs. VCC" ist die max erlaubte Taktfrequenz von der Versorgungsspannung abhängig. Das heißt aber Du kannst einen Atmega bei 3,3V mit einer zu hohen Taktfrequenz (über 12Mhz) betreiben. Er läuft wahrscheinlich auch, aber Atmel garantiert keinen stabilen Betrieb. Die Taktfrequenz wird aber nicht von der Höhe der Versorgungsspannung bestimmt oder beeinflußt. Ein 8Mhz - Quarz oder Resonator wird immer mit 8Mhz laufen unabhängig von der Versorgungspannung.
Bei welchen Sketch hast Du das Problem bemerkt?
Grüße Uwe
Eisebaer:
mit 3,3V kannst Du nicht mit 16MHz arbeiten. mit 5V schon. wenn also die fuses immer auf "interner 8MHz takt" gesetzt bleiben, der compiler aber bei 5V für "externer 16MHz takt" kompiliert, wird ein programm nur halb so schnell arbeiten, das auf den takt abgestimmt ist.
Hmm ... ich spiele immer die .elf-Datei ein, d.h. die Fuses sollten dabei ja eigentlich gesetzt werden; davon abgesehen habe ich sie aber anfangs auch mal auf den Standardwert (aus der boards.txt) gesetzt ... (davon abgesehen schätze ich die Differenz mal ganz grob auf mindestens Faktor 10 ein ... )
uwefed:
Laut Datenblatt http://www.atmel.com/Images/doc8161.pdf Seite 316 Bild "Figure 28-1. Maximum Frequency vs. VCC" ist die max erlaubte Taktfrequenz von der Versorgungsspannung abhängig. Das heißt aber Du kannst einen Atmega bei 3,3V mit einer zu hohen Taktfrequenz (über 12Mhz) betreiben. Er läuft wahrscheinlich auch, aber Atmel garantiert keinen stabilen Betrieb. Die Taktfrequenz wird aber nicht von der Höhe der Versorgungsspannung bestimmt oder beeinflußt. Ein 8Mhz - Quarz oder Resonator wird immer mit 8Mhz laufen unabhängig von der Versorgungspannung.
Ja, es ist ein 16 MHz-Quarz auf dem betreffenden Board; daher hätte ich aber eher das umgekehrte Verhalten erwartet (Probleme bei 3V, tadelloser Betrieb bei 5 V).
uwefed:
Bei welchen Sketch hast Du das Problem bemerkt?
Getestet habe ich bisher den "rf22_client" aus der RF22-Library, ergänzt um ein paar Status-Leds; ich kann das morgen aber auch nochmal mit einem reinen Blink-Sketch testen (hatte ich bisher unterlassen, da der Codeteil, in dem mir das Verhalten auffiel, nichts mit der Library zu tun hatte und EIGENTLICH zu der Zeit kein derart zeit-bedürftiger Interrupt auslösen sollte).
Welches Board wählst Du während des Compilierens an? Ist es immer das gleiche oder wählst Du jeweils ein anderes aus, je nachdem ob Du mit 3V3 oder 5V fährst?
uwefed:
Bei welchen Sketch hast Du das Problem bemerkt?
Ich habe das eben nochmal mit einem einfachen Blink-Sketch getestet; das Problem tritt tatsächlich nur auf, wenn die RF22-Lib verwendet wird …Aber wieso klappt das dann mit 3 Volt?
Auf dem Board ist ein 74HC4050-Levelshifter, aber der sollte ja die Übersetzung des SPI-Buses von 5V auf 3V schnell genug hinbekommen, als dass das Programm durch einen reduzierten SPI-Takt einfach dauerhaft im Interrupt idlet, oder? Weil was anderes könnte ich mir gerade nicht so recht erklären, der Atmega wird ja nicht überprüfen, was für eine Spannung anliegt und entsprechend umschalten ?… ?
Verstehe ich das richtig: Du lädst jeweils das identische .hex-File auf den ATmega und je nachdem ob Du 3V3 ansetzt oder 5V verhält er sich unterschiedlich?
Falls das nicht die Vorgehensweise ist, sage uns bitte genau, wie Du vorgehst (Schritt für Schritt). Welche Software verwendest Du für den Upload? AVRdude? Welche Parameter verwendest Du dabei? Welche Fuses werden bei Dir wie gesetzt?
Außer dass ich direkt das .elf und nicht das .hex lade: Ja, genau wie du es schreibst.
AVR Studio 4; überall Standardparameter.
Fuses sind auf FF DA 05, wie in der boards.txt angegeben (wobei ich auch schon die Fuses von einem Arduino Pro Mini kopiert habe, die ja interessanterweise leicht von FF DA 05 abweichen …).
Mit diesen Fuses wird ein externer Taktgeber aktiviert. Da Du ja einen Quarz hast, sollte das bei 5V funktionieren, bei 3V würde ich auch Probleme erwarten.
Hast Du mal mit dem Multimeter nachgemessen, welche Spannung der Prozessor abkriegt in den jeweiligen Situationen? Oder vertraust Du einfach darauf, dass Dein Development-Board das liefert, was Du einstellst?
uses sind auf FF DA 05, wie in der boards.txt angegeben (wobei ich auch schon die Fuses von einem Arduino Pro Mini kopiert habe, die ja interessanterweise leicht von FF DA 05 abweichen …).
In meinem board.txt nicht. Was steht denn bei Dir drin?
pylon:
Hast Du mal mit dem Multimeter nachgemessen, welche Spannung der Prozessor abkriegt in den jeweiligen Situationen?
Ja, stimmt leider ... :-/
pylon:
In meinem board.txt nicht. Was steht denn bei Dir drin?
pro5v328.name=Arduino Pro or Pro Mini (5V, 16 MHz) w/ ATmega328
pro5v328.upload.protocol=arduino
pro5v328.upload.maximum_size=30720
pro5v328.upload.speed=57600
pro5v328.bootloader.low_fuses=0xFF
pro5v328.bootloader.high_fuses=0xDA
pro5v328.bootloader.extended_fuses=0x05
pro5v328.bootloader.path=atmega
pro5v328.bootloader.file=ATmegaBOOT_168_atmega328.hex
pro5v328.bootloader.unlock_bits=0x3F
pro5v328.bootloader.lock_bits=0x0F
pro5v328.build.mcu=atmega328p
pro5v328.build.f_cpu=16000000L
pro5v328.build.core=arduino
pro5v328.build.variant=standard
Das ist aber zugegebenermaßen die Arduino 1.0.4 IDE (ich habe da ein paar Libraries modifiziert und die Änderungen noch nicht auf die neue Version portiert …).
Aber der Tipp war dennoch hilfreich - es sieht so aus, als sei mein Programmieradapter hinüber - wenn ich externe 3V3 anlege, ist das Verhalten identisch zu 5V - daher danke schon mal, ich werde jetzt versuchen, herauszufinden, wo genau der Adapter eine Macke hat und wieso das bei 5V nicht auftrat ...
Das ist aber zugegebenermaßen die Arduino 1.0.4 IDE (ich habe da ein paar Libraries modifiziert und die Änderungen noch nicht auf die neue Version portiert …).
Aber bei Dir sind die Fuses doch auch FF DA 05, also gleich wie bei mir. Worauf hast Du denn angespielt mit Deiner Bemerkung über die Fuses?
pylon:
In meinem board.txt nicht. Was steht denn bei Dir drin?
falsch verstanden; die Fuses, die abweichen, kamen beim Auslesen eines gekauften Pro Mini heraus. Wobei das scheinbar ebenfalls auf den defekten Programmieradapter zurückzuführen war denn jetzt passen sie auf einmal wunderbar ...