Forum: Mikrocontroller und Digitale Elektronik ATmega2560 - LED blinkt nicht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von LarsBeuth (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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
int main (void) {
7
8
   DDRB |= (1 << PB7);
9
10
   while(1) {
11
       PORTB ^= (1 << PB7);
12
       _delay_ms(500);
13
   }
14
15
   return 0;
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.

1
>>  make
2
avr-g++ -mmcu=atmega128 -I. -gstabs   -Os -pedantic -Wall -Wextra -std=c++14  main.cpp   --output main.elf     -lm
3
avr-objcopy -O ihex -R .eeprom main.elf main.hex
4
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
5
--change-section-lma .eeprom=0 -O ihex main.elf main.eep
6
avr-objcopy: --change-section-lma .eeprom=0x0000000000000000 never used
7
8
>> avrdude -c avrisp2 -P usb -p m2560 -U flash:w:main.hex
9
10
avrdude: AVR device initialized and ready to accept instructions
11
12
Reading | ################################################## | 100% 0.00s
13
14
avrdude: Device signature = 0x1e9801 (probably m2560)
15
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
16
         To disable this feature, specify the -D option.
17
avrdude: erasing chip
18
avrdude: reading input file "main.hex"
19
avrdude: input file main.hex auto detected as Intel Hex
20
avrdude: writing flash (196 bytes):
21
22
Writing | ################################################## | 100% 0.06s
23
24
avrdude: 196 bytes of flash written
25
avrdude: verifying flash memory against main.hex:
26
avrdude: load data flash data from input file main.hex:
27
avrdude: input file main.hex auto detected as Intel Hex
28
avrdude: input file main.hex contains 196 bytes
29
avrdude: reading on-chip flash data:
30
31
Reading | ################################################## | 100% 0.07s
32
33
avrdude: verifying ...
34
avrdude: 196 bytes of flash verified
35
36
avrdude: safemode: Fuses OK (E:FD, H:D8, L:FF)
37
38
avrdude done.  Thank you.

Also wenn ich die hex mit einer durch Arduino compilerten austausche, 
dann blinkt die LED.

Sieht jemand den Fehler?

Beste Grüße.

:
von Harry L. (mysth)


Bewertung
-1 lesenswert
nicht lesenswert
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.
1
#define F_CPU 1600000UL
2
 
3
#include <avr/io.h>
4
#include <util/delay.h>
5
6
int main (void) {
7
8
   DDRB |= (1 << PB7);
9
10
   while(1) {
11
       PORTB ^= (1 << PB7);
12
       _delay_ms(500);
13
       PORTB |= (1 << PB7);
14
       _delay_ms(500);
15
   }
16
17
   return 0;
18
}

so wirds dann auch blinken.

von Karl M. (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Hallo ,

Ja ich sehe den Fehler, der GCC kompiliert nicht für dein Zielsystem .
Das steht sehr gut lesbar im log.

von Harry L. (mysth)


Bewertung
-2 lesenswert
nicht lesenswert
LarsBeuth schrieb:
> DDRB |= (1 << PB7);

ist auch falsch!
1
        PORTB &= ^(1 << PB7);

von Harry L. (mysth)


Bewertung
1 lesenswert
nicht lesenswert
LarsBeuth schrieb:
> avr-g++ -mmcu=atmega128

Das solltest du natürlich auch korrigieren!

von Karl M. (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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.

von Karl M. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Harry L. schrieb:
> LarsBeuth schrieb:
> DDRB |= (1 << PB7);
>
> ist auch falsch!
Nein, ist korrekt!

von Martin B. (ratazong)


Bewertung
-1 lesenswert
nicht lesenswert
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++);
  }
}

von Harry L. (mysth)


Bewertung
2 lesenswert
nicht lesenswert
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

von Karl M. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Martin B. Komma

Ich habe doch schon die Lösung genannt, es wurde das Projekt für einen 
falschen AVR übersetzt.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jacko (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
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???  ;-)

von Jedi Knight (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Manfred (Gast)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Jedi Knight (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Jacko schrieb:
> Muss man mit einem ATmega2560 seine ersten BLINK-Übungen machen?

Und warum nicht? Womit hast du angefangen, damit ? 
http://www.hh.schule.de/metalltechnik-didaktik/museum/abakus/sonstige-eigene/ab21-630-11a.jpg

Beitrag #5712969 wurde von einem Moderator gelöscht.
von Jedi Knight (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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 ? ........ ^^

Beitrag #5712976 wurde von einem Moderator gelöscht.
Beitrag #5712989 wurde von einem Moderator gelöscht.
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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.

Beitrag #5712994 wurde von einem Moderator gelöscht.
von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Lars,

> #define F_CPU 1600000UL

Ist es richtig das das "nur" 1,6MHz sind oder sollen es doch eher 16MHz 
(#define F_CPU 16000000UL) sein?

rhf

: Bearbeitet durch User
von LarsBeuth (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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!

von LarsBeuth (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Otto (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja mit nem Bootloader und USB RS232 Wandler, FTDI und Konsorten...

von LarsBeuth (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Otto (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Ralph S. (jjflash)


Bewertung
0 lesenswert
nicht lesenswert
... 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 !!!

Beitrag #5713287 wurde von einem Moderator gelöscht.
Beitrag #5713299 wurde von einem Moderator gelöscht.
von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
5 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Beitrag #5713321 wurde von einem Moderator gelöscht.
Beitrag #5713501 wurde von einem Moderator gelöscht.
von Arduino Fanboy D. (ufuf)


Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Beitrag #5713608 wurde von einem Moderator gelöscht.
Beitrag #5713626 wurde von einem Moderator gelöscht.
Beitrag #5713632 wurde von einem Moderator gelöscht.
Beitrag #5713634 wurde von einem Moderator gelöscht.
Beitrag #5713639 wurde von einem Moderator gelöscht.
Beitrag #5713644 wurde von einem Moderator gelöscht.
von Philipp G. (geiserp01)


Bewertung
1 lesenswert
nicht lesenswert
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.

Beitrag #5713665 wurde von einem Moderator gelöscht.
Beitrag #5713669 wurde von einem Moderator gelöscht.
Beitrag #5713675 wurde von einem Moderator gelöscht.
Beitrag #5713676 wurde von einem Moderator gelöscht.
Beitrag #5713680 wurde von einem Moderator gelöscht.
Beitrag #5713682 wurde von einem Moderator gelöscht.
Beitrag #5713683 wurde von einem Moderator gelöscht.
Beitrag #5713685 wurde von einem Moderator gelöscht.
Beitrag #5713686 wurde von einem Moderator gelöscht.
Beitrag #5713699 wurde von einem Moderator gelöscht.
Beitrag #5713707 wurde von einem Moderator gelöscht.
Beitrag #5713719 wurde von einem Moderator gelöscht.
von Philipp G. (geiserp01)


Bewertung
1 lesenswert
nicht lesenswert
schreib was du willst ufuf hat dennoch Recht, ihr habt ihn zuerst dumm 
angemacht.

Beitrag #5713959 wurde von einem Moderator gelöscht.
Beitrag #5713967 wurde von einem Moderator gelöscht.
Beitrag #5713970 wurde von einem Moderator gelöscht.
Beitrag #5713982 wurde von einem Moderator gelöscht.
Beitrag #5713988 wurde von einem Moderator gelöscht.
Beitrag #5713997 wurde von einem Moderator gelöscht.
Beitrag #5714003 wurde von einem Moderator gelöscht.
von Thomas G. (Firma: Frickelhauptquartier) (taximan)


Bewertung
1 lesenswert
nicht lesenswert
Zwischen den ganzen - mittlerweile ja leider üblichen Beschimpfungen und 
Beleidigungen - mal wieder eine Fachfrage; welchen Auftrag hat das "UL" 
bei der Frequenzdefinition?

Beitrag #5714009 wurde von einem Moderator gelöscht.
Beitrag #5714010 wurde von einem Moderator gelöscht.
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Thomas G. schrieb:
> welchen Auftrag hat das "UL"
> bei der Frequenzdefinition?
Unsigned Long

von Seine LED leuchtet nicht (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Thomas G. schrieb:
> Zwischen den ganzen - mittlerweile ja leider üblichen Beschimpfungen und
> Beleidigungen - mal wieder eine Fachfrage; welchen Auftrag hat das "UL"
> bei der Frequenzdefinition?

https://www.rapidtables.com/prog/cref/const.html

Beitrag #5714025 wurde von einem Moderator gelöscht.
Beitrag #5714034 wurde von einem Moderator gelöscht.
Beitrag #5714035 wurde von einem Moderator gelöscht.
Beitrag #5714037 wurde von einem Moderator gelöscht.
Beitrag #5714045 wurde von einem Moderator gelöscht.
Beitrag #5714046 wurde von einem Moderator gelöscht.
Beitrag #5714055 wurde von einem Moderator gelöscht.
von Thomas G. (Firma: Frickelhauptquartier) (taximan)


Bewertung
0 lesenswert
nicht lesenswert
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.

Beitrag #5714059 wurde von einem Moderator gelöscht.
Beitrag #5714062 wurde von einem Moderator gelöscht.
Beitrag #5714066 wurde von einem Moderator gelöscht.
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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:
1
unsigned test = 4711U;

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Thomas G. schrieb:
> Also eine positive (unsigned) 64-Bit (long) Zahl.

Nein!

Long ist nur als "mindestens 32bit" spezifiziert, meisten sind es 
tatsächlich 32bit. Für 64bit musst du "unsigned long long" bzw "ULL" 
schreiben.

> würde unsigned int UI auch funktionieren?
Bei arm-gcc ja, bei avr-gcc nein.

Siehe Spec: https://de.wikipedia.org/wiki/Datentypen_in_C
Für arm-gcc: 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/Babfcgfc.html
Für avr-gcc: 
https://de.wikibooks.org/wiki/C-Programmierung_mit_AVR-GCC/_Datentypen

Gerade bei F_CPU habe ich bisher aber immer nur einfach die Zahl als 
Literal hingeschrieben, ohne solche Buchstaben suffixe.

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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
unsigned int  testA = 47115645654; // geht ohne Warnung durch
2
unsigned int  testB = 47115645654ULL; // gibt Geschrei

: Bearbeitet durch User
Beitrag #5714097 wurde von einem Moderator gelöscht.
von Joachim B. (jar)


Bewertung
2 lesenswert
nicht lesenswert
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!

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> so eine Krümellei, was soll es denn sonst sein?

long long int sieht jedenfalls doof aus, viel schöner wäre longilong.
1
#define longilong long long int
2
#define ulongilong unsigned long long int
3
#define years *364*24*60*60*1000;
4
5
longilong time=now() + 100 years;

A lala lala long ....

: Bearbeitet durch User
von Stefan S. (chiefeinherjar)


Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> A lala lala long ....

Scheiße, jetzt habe ich einen Ohrwurm...

A la la la la long, a la la la la long long li long long long ...

von Stefan ⛄ F. (stefanus)


Bewertung
-2 lesenswert
nicht lesenswert
Wenn wir hier nur oft genug "longilong" benutzen glaubt das irgendwann 
ganz Deutschland. Wollen wir mal versuchen, es durchzusetzen?

von Thomas G. (Firma: Frickelhauptquartier) (taximan)


Bewertung
0 lesenswert
nicht lesenswert
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!

Beitrag #5714151 wurde von einem Moderator gelöscht.
Beitrag #5714183 wurde von einem Moderator gelöscht.
Beitrag #5714194 wurde von einem Moderator gelöscht.
Beitrag #5714226 wurde von einem Moderator gelöscht.
von M. P. (phpmysqlfreak)


Bewertung
0 lesenswert
nicht lesenswert
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...

Beitrag #5714289 wurde von einem Moderator gelöscht.
Beitrag #5714654 wurde von einem Moderator gelöscht.
Beitrag #5715065 wurde vom Autor gelöscht.
Dieser Beitrag kann nur von angemeldeten Benutzern beantwortet werden. Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.