Guten Abend,
ich versuche gerade ein einfache Blinky Programm zum Laufen zu bekommen.
1
#define F_CPU 1600000UL
2
3
#include<avr/io.h>
4
#include<util/delay.h>
5
6
intmain(void){
7
8
DDRB|=(1<<PB7);
9
10
while(1){
11
PORTB^=(1<<PB7);
12
_delay_ms(500);
13
}
14
15
return0;
16
}
Die Zeile in der while mit |= oder &= ~ zu ersetzen hat auch nichts
verändert (die LED leuchtet einfach durchgängig). Wenn ich aber das
Standard-Blinky-Projekt aus der Arduino IDE nehme und diese hex flashe,
dann läuft es auch.
LarsBeuth schrieb:> #define F_CPU 1600000UL>> #include <avr/io.h>> #include <util/delay.h>>> int main (void) {>> DDRB |= (1 << PB7);>> while(1) {> PORTB ^= (1 << PB7);> _delay_ms(500);> }>> return 0;> }
Warum sollte das blinekn?
Du schaltest innerhalb der while-schleife die LED in einen Zustand aber
niemals in den Anderen.
Könnte sein, dass die delay routine die Probleme macht.
Versuch doch mal mit einer eigenen Delay routine. (reine software
delay). Ich weiss nicht, ob das delay() aus der Kompiler lib auf timern
beruht.
Mit sowas sollte man ein delay hinbekommen, was nicht wegoptimiert wird
delay()
{
volatile int i,k;
for(i=0;i<irgendwas;i++)
{
for (k=0;k<irgenwas2;k++);
}
}
Karl M. schrieb:> Harry,>> Du weisst schon was eine XOR Verknüpfung ist?>> Das stimmt schon, man kann auch direkt das PINB.7 setzen, dies hat die> selbe Wirkung.
Stimmt - sorry..."Brett vorm Kopf"
So gehts natürlich auch.
...peinlich, peinlich
Interessante Antworten!
Ich fasse mal zusammen:
LarsBeuth schrieb:> ich versuche gerade ein einfache Blinky Programm zum Laufen zu bekommen.
Das Programm ist völlig ok, und funktioniert auch.
Lasse dir in der Hinsicht keinen erzählen.
Dieses ist faul:
> avr-g++ -mmcu=atmega128> PORTB ^= (1 << PB7);
Alternativ:
> PINB = (1 << PB7);
Diese Mikrooptimierung macht den Braten aber auch nicht viel fetter.
Muss man mit einem ATmega2560 seine ersten BLINK-Übungen machen?
Viele schaffen das nicht mal mit einem Tiny25, konnten ihre
Datenblatt-Leseschwäche aber viel einfacher und billiger auf
einem Steckbrett erkennen.
Upps, falsches Hobby??? ;-)
Harry L. schrieb:>> PORTB ^= (1 << PB7);> Warum sollte das blinekn?> Du schaltest innerhalb der while-schleife die LED in einen Zustand aber> niemals in den Anderen.
Quatsch. XOR schaltet Bit 7 korrekt zwischen 0 und 1.
Ob die LED an diesem Pin hängt, ist eine andere Sache, aber umgeschaltet
wird das Bit. Du solltest keine Tipps geben, die falsch sind.
Jacko schrieb:> Muss man mit einem ATmega2560 seine ersten BLINK-Übungen machen?>> Viele schaffen das nicht mal mit einem Tiny25,
Blödmann, genau das ist der richtige Weg, Grundlagen auf dem
Zielprofessor zu erarbeiten.
Karl M. schrieb:> Martin B. Komma>> Ich habe doch schon die Lösung genannt, es wurde das Projekt für einen> falschen AVR übersetzt.
Ach? main in loop geändert, läuft die Schleife sogar auf einem Arduino.
Was
nun?
Kann es sein, dass eine kleine, verschworene Truppe absichtlich Desinfo
platziert? Kann das sein ? ........ ^^
Jedi Knight schrieb:> Ach? main in loop geändert, läuft die Schleife sogar auf einem Arduino.> Was> nun?
Gar nicht nötig...
Nur die Zeile
> #define F_CPU 1600000UL
auskommentieren.
Dann kompiliert es ohne Warnung mit der Arduino IDE.
loop() und setup() sind nicht nötig.
Aber dann gehen millis() und Konsorten nicht mehr.
Danke für eure Hilfe!
Nach dem ändern des Makefiles für die richtige Zielplattform und dem
ändern der F_CPU (ich habe eine Null zuwenig drinn gehabt - wie schon
gesagt wurde) hat es geklappt.
Danke nochmals!
Ach ja, gibt es auch die Möglichkeit den AVR über das USB Kabel zu
programmieren? Halt so wie es die Arduino IDE auch macht nur ohne
Arduino.
Nur ein USB Kabel zu brauchen und den mk2-Programmer in der Tasche zu
lassen wäre schon lässig.
Hey Otto. Danke für die Antwort. Kannst du das genauer ausführen?
Benutze ich dann weiterhin noch den AVRDUDE und muss nur einen anderen
Port und Programmer auswählen?
... davon ausgehend, dass du einen Arduino Mega2560 hast:
avrdude -c wiring -p atmega2560 -P SerialPort -b115200 -D -v
-Uflash:w:meinhexfile.hex:i
Für SerialPort den Port angeben an dem das Teil angeschlossen ist:
Bsp. für Windows
-P com5
Bsp. für Linux
-P /dev/ttyACM0
für Clone mit CH340 Chip
-P /dev/ttyASB0
Hinweis:
Ohne das Flag -D (Auto-Erase) funktioniert das ganze leider nicht !!!
Man muss dazu sagen, das die Toggle Funktionalität per Schreiben ins
PINx Register bei alten MCs wie dem Mega8 oder sonstigen Urgesteinen
(AT90S2313 oder so, igitt) noch nicht vorhanden war.
Das ist allerdings kein Grund, auf das Nichtlesen des aktuellen
Datenblattes des Mega2560 zu bestehen, wo eindeutig steht:
13.2.2 Toggling the Pin
Writing a logic one to PINxn toggles the value of PORTxn, independent on
the value of DDRxn. Note that the SBI instruction can be used to toggle
one single bit in a port.
Diese Funktionalität gibt es bei allen modernen AVR.
Bisher scheinst du da einige Blockaden vor dir her zu schieben....
Offensichtlich hast du folgende (Pin Toggle) Zeile noch nicht
verstanden:
> PINB = (1 << PB7);
Denn sonst würdest du etwas demütiger agieren.
Auch mit dieser Aussage scheinst du Probleme zu haben:
> Dann kompiliert es ohne Warnung mit der Arduino IDE.> loop() und setup() sind nicht nötig.
Denn sonst würdest du etwas demütiger agieren.
Jetzt wäre für dich ein guter Augenblick gekommen, dich kundig zu
machen, dann den Rückwärtsgang einzulegen, und zuzugeben wie derbe du
daneben liegst.
Marcus Tullius Cicero:
> Jeder Mensch kann irren, aber Dummköpfe verharren im Irrtum!
Es kann natürlich sein, dass du derartige Dingen nicht verstehst, oder
überprüfen kannst, weil dir die Hirnkapazität fehlt. Alles möglich.
Aber ist das dann deine Rechtfertigung für solche geistigen Flatulenzia?
Klar stört dich deine eigene Unfähigkeit!
Bedenke aber dabei: Der Bote ist nicht die Wurzel des Übel.
Seine LED leuchtet nicht schrieb im Beitrag #5713634:
> Das ist keine Bösartigkeit, sondern der Verzweiflung geschuldet. Ich> finde, das sollte man wissen, um Uli besser zu verstehen. Gute> Besserung, Uli, toy toy toy. Du schaffst das
Beweist ihm doch erstmal das Gegenteil auf sachlicher und technischer
Ebene, als sich hier so tief runterzulassen.
Zwischen den ganzen - mittlerweile ja leider üblichen Beschimpfungen und
Beleidigungen - mal wieder eine Fachfrage; welchen Auftrag hat das "UL"
bei der Frequenzdefinition?
Also eine positive (unsigned) 64-Bit (long) Zahl. Das sollte für
Frequenzen Reichen. Danke soweit, würde unsigned int UI auch
funktionieren. Kann es gerade nicht ausprobieren.
Thomas G. schrieb:> würde unsigned int UI auch> funktionieren.
int ist der default Datentype für Konstanten.
Ein einfaches U reicht für unsigned int
Bei UI ist das I schon für andere Zwecke reserviert.
Gcc: _complex_
Vielleicht nicht schön, aber gültig:
Jawoll!
Hier ist ein ATMega2560 Thread, also U 16Bit, UL 32 Bit und ULL 64Bit
Für andere µC/CPU gibt die Compiler Doku gerne Auskunft.
Stefanus F. schrieb:> Gerade bei F_CPU habe ich bisher aber immer nur einfach die Zahl als> Literal hingeschrieben, ohne solche Buchstaben suffixe.
Mag in vielen Fällen gut gehen.
Aber bei UL hat der Compiler die Chance, dir eine Warnung um die Ohren
zu hauen.
1
unsignedinttestA=47115645654;// geht ohne Warnung durch
Seine LED leuchtet nicht schrieb im Beitrag #5714025:
> Schon wieder falsch> unsigned long integer
so eine Krümellei
was soll es denn sonst sein?
"etwa unsigned long float" oder "unsigned long string"
manno, Grundlagen lernen kann helfen!
Arduino Fanboy D. schrieb:> Aber bei UL hat der Compiler die Chance, dir eine Warnung um die Ohren> zu hauen.
+ Beispiel
Da habe ich Glück, dass unsere Mikrocontroller noch nicht mit zig GHz
getaktet werden.
OK, hab ich das dann so richtig verstanden:
LONG >= 32-Bit
LONG LONG = 64-Bit
Und was ist mit:
VERY LONG;
MUCH LONGER &
EVEN LONGER?
Schönen Abend noch!
Freud schrieb im Beitrag #5714226:
> Habt Ihr alle eigentlich privat funktionierende soziale Beziehungen?
Sieht echt nicht so aus. - Wenn ich alles richtig verfolgt habe, ist
wirklich alles beantwortet.
@Mods
BITTE macht diese Trauerspiel hier zu...
