Blutiger Anfänger möchte gerne mit STK500 programmieren

[Hane10 -. (hane10)]

Hallo,

vorhin hatte ich schon Probleme mit dem Verbindungsaufbau meines STK500 
und dem Laptop. Nun steht die Verbindung und ich würde gerne ein kleines 
Programm auf meinen ATMEGA8515 programmieren.
Bisher habe ich folgendes gemacht:
neues Projekt erstellt AVR GCC
dann bei der Auswahl links den AVR Simulator und rechts mein ATMEGA8515
anschließend habe ich nur noch diesen Code aus meinem Buch eingegeben:

#include <avr/io.h>

int main()
{
        DDRB=0xFF;
  led2_status=0xFF;
  PORTB=led2_status;

}

wie gesagt ich bin blutiger Anfänger :)

Danch hab ich auf "Build" geklickt, aber es passiert weiterhin nichts, 
also meine LED leuchtet nicht. Ich bekomme nur eine Meldung Build 
started at...
mehr leider nicht! Liegt es daran, dass ich ganz am Anfang den Simulator 
ausgewählt habe? Leider finde ich das Board STK500 nicht in dieser 
Liste.

Könntet ihr mir bitte weiterhelfen??

Vielen Dank im Voraus

Hane89

[STK500-Besitzer (Gast)]

Hane89 --- schrieb:
> Könntet ihr mir bitte weiterhelfen??

Schon mal einen Blick ins AVR-GCC-Tutotial geworfen?!

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial

[Bernd (Gast)]

Hane89 --- schrieb:
> Liegt es daran, dass ich ganz am Anfang den Simulator
> ausgewählt habe?

Anders als bei richtigen Debuggern läuft das Programm beim Simulator 
nicht auf dem µC sondern wird emuliert.

[Hane10 -. (hane10)]

Ja, hab mir die Anleitung ein wenig angesehen. Da kann man einiges 
nachlesen, aber ich hab jetzt nicht viel dazu gefunden, was mit dem AVR 
Studio 4 und dem STK 500 zu tun hat. Vielleicht hab ichs übersehen oder 
so?

mfg

[Hane10 -. (hane10)]

@Bernd

also heißt das jetzt, dass ich am Anfang bei meiner Projekteinstellung 
nicht auf AVR Simultor gehen soll? Aber was soll ich dann auswählen? Ich 
finde mein STK 500 nicht in dieser Liste

mfg

[ich (Gast)]

Ich weiß nicht wie es beim STK500 ist, da ich nur selber gebaute Boards 
verwendet habe. Üblicherweise muss man das Hex-File noch mit dem 
Programmer auf den uC schieben. Btw. das Programm läuft zwar, es wird 
aber vermutlich nix passieren. Du setzt 2 Register danach ist das 
Programm zu ende. Damit es "läuft", muss im Programm eine 
Endlossschleife vorgesehen werden. Siehe Tutorial auf der Seite hier.

[Hane10 -. (hane10)]

Okay, aber wenn ich doch was übersetzen möchte, dann muss doch auch 
irgendwie das Porgramm sagen, Fehler beim laden oder nach dem 
Kompilieren, ob der Code i.O. ist, aber leider macht das AVR Studio 4 
gar nichts.

[HildeK (Gast)]

Ich nehme zum Übersetzen immer Build&Run (Strg+F7):
Dann muss man noch das entstandene Kompilat auf den Baustein laden. Dazu 
muss in den Projekteinstellungen erst mal der korrekte Baustein 
ausgewählt werden. Mit dem Button 'Connect to the selected AVR 
programmer' öffnet sich ein Fenster, wo man dann die Verbindung zum IC 
prüfen kann, die Fuses einstellen und eben das Programm an den Prozessor 
übertragen kann.
Einige Sekunden warten und fertig.

[HildeK (Gast)]

Hane89 --- schrieb:
> dann muss doch auch
> irgendwie das Porgramm sagen, Fehler beim laden oder nach dem
> Kompilieren, ob der Code i.O. ist,

Unten ist ein Fenster namens Build. Da steht dann im Idealfall drin:
Build succeeded with 0 Warnings...

Man kann das unter 'View  Toolbars  Build Output' aktivieren, falls es 
fehlen sollte.

[ich (Gast)]

Gucke mal auf youtube. Da gibt es ne Menge Videos zum Thema AVR Studio 
4. Teilweise auch Vorlesungen oder Übungen von (indischen - also auf 
englisch) Unis. Die zeigen Stritt für Schritt wie man das Programm 
bedient.

[Bernd (Gast)]

Hane89 --- schrieb:
> Aber was soll ich dann auswählen? Ich
> finde mein STK 500 nicht in dieser Liste

Das STK muss einmalig beim Atmel Studio angemeldet werden. Dort wird der 
COM-Port der seriellen Schnittstelle eingetragen. Danach kann das STK500 
als Tool ausgewählt werden.

[Hane10 -. (hane10)]

hab mir mal auf youtube ein paar videos angeschaut. Also wenn ich auf
Tools -> Program AVR -> connect -> connect klicke, erscheint ein 
Fenster, wo ich dann in dem Register "Program" unter "Flash" mein Input 
Hex File auswähle und dann auf "Program" klicke, anschließend bringt er 
mir diese ganzen Meldungen:

Getting isp parameter.. SD=0x0a .. OKOK
Reading FLASH input file.. OK
Setting mode and device parameters.. OK!
Entering programming mode.. OK!
Erasing device.. OK!
Programming FLASH ..      OK!
Reading FLASH ..      OK!
FLASH contents is equal to file.. OK
Leaving programming mode.. OK!

Danach gehe ich auf Build and Run, aber leider blinken meine LED's 
nicht!
Habe den Code abgeändert in:

#include<avr/io.h>
#include<util/delay.h>

int main (void)

{
  DDRB=0xff

  while (1)
  {
    PORTB=0xff;
    _delay_ms(1000);
    PORTB=0x00;
    _delay_ms(1000);
  }
  return 0;
}

Habe die Flachbandkabel angesteckt, also den PortB mit den LED`s und den 
PortD mit den Tastern und das Flachbandkabel für ISP.
Danke schon mal im Voraus :)

[STK500-Besitzer (Gast)]

Hane89 --- schrieb:
> Danach gehe ich auf Build and Run, aber leider blinken meine LED's
> nicht!

Wie sehen die Fusebits aus?

[Hane10 -. (hane10)]

@STK500-Besitzer

[Hannes L. (hannes)]

Und hast Du auch einen externen Takt angelegt?
Dazu gibt es einen Jumper auf dem STK500 und eine Erklärung in der Hilfe 
zum STK500.

Da das STK500 kein Debugger ist, ist Build&Run eigentlich Quark, das 
ruft nur den Simulator auf, startet aber kein Programm im realen AVR.

Das Programm im realen Controller hat sofort nach dem Beschreiben der 
Hexdatei (und evtl. EEP-Datei und Fusesetting) zu arbeiten. Allerdings 
ist die Reihenfolge
- Build (also Assemblieren bzw. Compilieren bei C) und dann
- Program (Write Flash & Co).

Vor Write Flash ist im Programmer-Dialog natürlich noch unter Main der 
richtige Controllertyp auszuwählen und durch Lesen der Signature die 
Verbindung zu prüfen. Erst dann wechselt man auf Program, wählt die 
korrekten Dateien aus den richtigen Projektordnern aus und überträgt sie 
ins Flash bzw. bei Bedarf auch ins EEP.

...

[Uff! (Gast)]

Auf deinem Screenshot ist der Simulator zu sehen. Mit Simulator blinken 
keine LEDs!

[Hane10 -. (hane10)]

@hannes
also ich habe keinen externen Takt angelegt, bei mir ist standardmäßig 
bei XTAL-1 ein Jumper, d.h. laut STK500-Beschreibung, dass ich einen 
internen Takt habe, oder? Wo ich aber den Taktgenerator einstelle weiß 
ich leider nicht.

[Hane10 -. (hane10)]

@uff
ja ich meinte natürlich mein STK500-Board :), sollte ich das eventuell 
auch abfotografieren???

[Hane10 -. (hane10)]

Hiiilfee! :)

[Chris (Gast)]

Hane89 --- schrieb:
> Wo ich aber den Taktgenerator einstelle weiß
> ich leider nicht.

http://www.mikrocontroller.net/articles/AVR_Fuses#Taktquellen_Fuse_Einstellung

[Hane10 -. (hane10)]

Also sind bei mir alle fuses gesetzt außer spien, aber liegt es wirklich 
an den Einstellungen der fuses? Mfg

[Hannes L. (hannes)]

Hane89 --- schrieb:
> Hiiilfee! :)

Laut Deinem Bild hast Du per Fuses als Taktquelle extern Clock 
eingestellt, ob das stimmt, weiß ich nicht, da ich nicht weiß, ob die 
Kommunikation mit dem AVR klappt. Sollte das stimmen, dann musst Du dem 
AVR auch einen externen Takt zuführen. Das STK500 bietet diese 
Möglichkeit, es erzeugt diesen Takt mit Hilfe des eigenen MCs selbst, Du 
musst ihn nur noch zum XTAL-Pin des Target-AVRs durchschalten. Und das 
erfolgt über den dafür vorgesehenen Jumper. Um Infos darüber zu 
erhalten, rufst Du im AVRstudio die Hilfe auf (Menüpunkt, der mit "Help" 
beschriftet ist), wählst AVR-Tools, dann STK500, dann Jumper-Settings 
und findest die nötigen Infos (siehe Anhang).

Um dann zu ermitteln, ob Dein AVR ansprechbar ist, gehst Du im 
Programmer-Dialog auf das Panel "Main", wählst aus der Liste den 
entsprechenden AVR-Typ aus (ja, fast jeder AVR wird etwas anders 
angesprochen) und prüfst dann die Verbindung durch Auslesen der 
Signature. Solange das nicht klappt (bitte auch die Rückmeldungen 
lesen!), brauchst Du nicht versuchen, den AVR zu beschreiben oder an den 
Fuses zu spielen, sondern schaust erstmal, ob die von Dir eingestellte 
ISP-Frequenz nicht zu hoch ist. Sie muss kleiner als 1/4 der 
Taktfrequenz sein.

Ein weiterer oft gemachter Fehler ist das Verwenden des falschen 
Target-Sockels. Das ist etwas verwirrend, ich habe mir geholfen, indem 
ich Labels angebracht habe, die mit den Basistypen der entsprechenden 
Pinbelegung beschriftet sind. So brauche ich nicht immer mit den 
kryptischen Sockel-Namen hantieren.

Frag' jetzt aber bitte nicht, welches der richtige Sockel ist. Das steht 
nämlich alles in der Doku zum STK500, die über Help, AVR-Tools 
erreichbar ist.

...

[Hane10 -. (hane10)]

Also den richtigen Sockel hab ich sicher, hab es nachgelesen, welchen 
man nehmen muss, wenn man einen 8515 hat. Bei mir sind 5 Jumper 
gesteckt, also wie in deinem Anhang von vtarget bis oscsel. Die 
Verbindung zum Board passt normal auch, die signature hab ich auch 
auslesen können, dann kann es eigentlich nur noch an der ISP Frequenz 
liegen oder? Wo finde ich die Taktfrequenz?

[Hannes L. (hannes)]

Hane89 --- schrieb:
> die signature hab ich auch
> auslesen können, dann kann es eigentlich nur noch an der ISP Frequenz
> liegen oder?

Das ist ein Widerspruch in sich.

Wenn Du die Signature wirklich auslesen konntest (vergleiche bitte die 
gelesene Signature mit der Angabe im Datenblatt!), dann ist die 
ISP-Frequenz ok. Denn wenn die ISP-Frequenz nicht passen würde, dann 
hättest Du auch keine Verbindung und könntest auch keine Signature 
auslesen.

> Wo finde ich die Taktfrequenz?

Na unterhalb des Signature-Buttons. Da steht Settings und ISP-Frequency 
dran. Ist das sooooo schwer zu finden???

...

[Hane10 -. (hane10)]

@ Hannes

Habe die Signatur ausgelesen uns mit dem Datenblatt verglichen, es 
stimmt überein.

desc             = "ATMEGA8515";
signature        = 0x1e 0x93 0x06;

also sollte jetzt die Verbindung passen und auch die eingestellte 
Frequenz.

Anbei das Board mit den Jumperstellungen

[Hane10 -. (hane10)]

@Sanitäter
Nein man ich hab mir den Controller an den Kopf genagelt, weil ich mir 
dachte, so könnte ich vielleicht besser programmieren! :D

Also oben hätte ich mein Problem eigentlich schon beschrieben!
Ich möchte eigentlich nur mal, dass ich ein kleines Programm auf einen 
ATMEGA 8515 programmiere, aber es funktioniert irgendwie nicht!

MFG

[Hane10 -. (hane10)]

Hilfe!

[Hannes L. (hannes)]

Hane89 --- schrieb:
> Nein man ich hab mir den Controller an den Kopf genagelt,

Ich weiß nicht, was Sanitäter schrob, aber an den Kopf nageln ist keine 
gute Idee.

Kann es sein, dass Du die falsche Hexdatei brennst? Ich frage deshalb, 
weil man nach Wechseln des Projektes auch im Programmer-Dialog die neue 
Datei im neuen Projektordner einstellen muss.

...

[Hane10 -. (hane10)]

Ach mensch Leute! :D

[Hane10 -. (hane10)]

@hannes

also ich hab bis jetzt nur ein projekt und ich wähle bei Flash -> input 
hexfile -> die richtige Projekt-Hexfile aus und klicke anschließend auf 
"program"

[Hannes L. (hannes)]

Hane89 --- schrieb:
> Ach mensch Leute!

Also ein STK500 ist kein Multimediakonsumartikel, sondern ein 
Entwicklungsboard. Der erfolgreiche Umgang damit setzt voraus, dass man 
die benötigten Informationen liest und auch etwas mitdenkt. Ist wie bei 
einer Geige, damit kann auch nicht Jeder auf Anhieb umgehen. Also lies 
und verstehe endlich die zugehörigen Dokus oder stelle fest, dass Du 
dafür ungeeignet bist. Es ist nunmal nicht Jeder für jede Tätigkeit 
geeignet. Ich kann auch keine Geige spielen, obwohl ich weiß, wie sie 
funktioniert und wie sie gestimmt ist.

...

[Hane10 -. (hane10)]

Ja aber es hat mir bisher leider auch keiner helfen können zu dieser 
Problematik oder? Es gibt auch "Geigen-lehrlinge", die ab und zu Hilfe 
brauchen oder konntest du alles von Anfang an?????

[Hane10 -. (hane10)]

Danke Bernd :)

[spess53 (Gast)]

Hi

>also ich hab bis jetzt nur ein projekt und ich wähle bei Flash -> input
>hexfile -> die richtige Projekt-Hexfile aus und klicke anschließend auf
>"program"

Und was für Meldungen erscheinen dann unten im Prog-Dialog?

>  led2_status=0xFF;
>  PORTB=led2_status;

Damit wird keine LED auf dem STK500 leuchten. Die LEDs sind Null-Aktiv.

Und deine Kabel solltest du auch mal richtig herum stecken. Der 
markierte Leiter entspricht Pin 1.

MfG Spess

[Hane10 -. (hane10)]

@spess

hab den code, wie weiter oben beschrieben umgeändert in:

#include<avr/io.h>
#include<util/delay.h>

int main (void)

{
  DDRB=0xff

  while (1)
  {
    PORTB=0xff;
    _delay_ms(1000);
    PORTB=0x00;
    _delay_ms(1000);
  }
  return 0;
}

Die Flachbandkabel hab ich auch richtig rum jetz

[Hane10 -. (hane10)]

Wenn ich jetzt auf Build klicke steht unten nur Build started... aber 
mehr leider nichtt

[Hannes L. (hannes)]

Hane89 --- schrieb:
> Wenn ich jetzt auf Build klicke steht unten nur Build started...

Build und der Transfer zum realen AVR sind zwei völlig verschiedene 
Dinge.

...

[Hane10 -. (hane10)]

Hab gelesen, wenn ich auf Build klicke, erzeuge ich den HEX-Code, 
welchen ich dann beim "programmieren" auswähle bei Flash Input Hex File. 
Aber das Programm macht ja nichts, wenn ich meinen Code eingebe und 
anschließend auf Build klicke

[Hane10 -. (hane10)]

es steht nur Build started ...
und nicht ...completetd ..0 errors...0 warnings
also so sollte es laut beschreibung zumindest dort stehen

[TTL (Gast)]

spess53 schrieb:
> Die LEDs sind Null-Aktiv.

Das heisst active low. Nur für den Fall, dass jemand danach suchen 
möchte.

[TTL (Gast)]

spess53 schrieb:
> Die LEDs sind Null-Aktiv

Und es sind die Taster, die active low sind, und nicht die LEDs.

[Hane10 -. (hane10)]

@ttl

mit dem obigen Programm sollten die LED's aber schon normal blinken 
oder?

[spess53 (Gast)]

Hi

>Und es sind die Taster, die active low sind, und nicht die LEDs.

Auch die LEDs sind Low-Active. Siehe Anhang.

MfG Spess

[Hane10 -. (hane10)]

Nur mal so nebenbei: hat das mit meinem Problem zu tun, ob die LEDs und 
Taster nun low aktiv sind oder nicht???

mfg

[spess53 (Gast)]

Hi

>Nur mal so nebenbei: hat das mit meinem Problem zu tun, ob die LEDs und
>Taster nun low aktiv sind oder nicht???

Bei denem Blinkprogramm nichts. Bei deinem ersten Programm viel.

Hänge mal dein Hex-File als Anhang an. Ich habe hier noch einen 
ATMega8515 rumliegen. Da kann ich es mal ausprobieren.

MfG Spess

[Hane10 -. (hane10)]

Stimmt beim ersten Programm machts was aus :)
Ich glaub aber nicht, dass die Hex-File (Anhang) korrekt ist :)

[Hane10 -. (hane10)]

Vielen Dank schonmal Spess53!!! Endlich^^

[Herbert (Gast)]

ich schrieb im Beitrag #3029347:
> Das sind Korinthen, die du kackst. Nur für den Fall, das jemand danach
> suchen möchte.

Und du bist der Essel der sie sche***.

[Hannes L. (hannes)]

Hane89 --- schrieb:
> hat das mit meinem Problem zu tun, ob die LEDs und
> Taster nun low aktiv sind oder nicht???

Jain. Denn Du hast anscheinend mehrere Probleme.

Hane89 --- schrieb:
> es steht nur Build started ...
> und nicht ...completetd ..0 errors...0 warnings

Das ist wohl eine Frage betreffs C-Compiler. Da kann ich Dir nicht 
helfen, für C bin ich ungeeignet (eigene Feststellung, schon seit Langem 
bekannt). Ich weiß nicht, was man alles tun und einbinden muss, damit 
ein C-Programm überhaupt Compilierfähig ist. Ich muss das aber auch 
nicht wissen, denn ich werkele in Assembler.

Du kannst natürlich auch mal mit einem Dateimanager Deiner Wahl im 
Projektordner nachsehen, ob der Compiler eine Hexdatei erstellt hat. 
Dazu könnte man Datum und Uhrzeit der Erstellung der Datei im Vergleich 
zur Systemzeit des Rechners berücksichtigen.

Hane89 --- schrieb:
> DDRB=0xFF;
>   led2_status=0xFF;
>   PORTB=led2_status;

Damit bekommst Du am STK500 keine LED zum Leuchten, da die LEDs (wie 
auch die Taster) L-aktiv sind. Gut, Du hast es vermutlich inzwischen auf 
0x00 geändert, also von einem Extrem zum anderen. Denn es gibt zwischen 
0x00 und 0xff genügend Zwischenwerte, bei denen einige Portpins auf H 
und einige Portpins auf L geschaltet werden, worauf dann einige LEDs 
leuchten sollten, egal, ob sie H- oder L-aktiv sind.

...

[spess53 (Gast)]

Hi

>Ich glaub aber nicht, dass die Hex-File (Anhang) korrekt ist :)

Ist es auch nicht. Da ist kein Code drin.

MfG Spess

[spess53 (Gast)]

Hi

Probiere mal das angehängt Hex-File aus.

MfG Spess

[spess53 (Gast)]

Hi

War falsches File.

MfG Spess

[Karl H. (kbuchegg)]

Kapersky schrieb im Beitrag #3029425:
>>Probiere mal das angehängt Hex-File aus.
>
> VORSICHT!!! VIRUS!!!


Einen schönen Gruß an deinen Kaspersky.
Aber für ASCII-Text Files kann er sich seine Meldung sparen.
Die kann man im Notepad aufmachen, die kann man auch mit AVR-Studio auf 
den µC brennen, aber eines ist da ganz sicher nicht drinnen: ein Virus. 
Da ist einfach nur Text drinnen. Und zwar so wie Gott ihn schuf: 7 Bit 
ASCII. Die Probleme mit EMail Viren haben erst angefangen, als die 
BWL-er unbedingt HTML in den EMails haben wollten, bzw. Microsoft ihnen 
das gegeben hat. Vorher war das nämlich überhaupt kein Problem.

[Hane10 -. (hane10)]

Hallo Leute, also das Problem war die Software selbst!!!!
Habe AVR Studio 4.19 nochmals deinstalliert und wieder installiert!
Jetzt bekomm ich auch eeeendlich Meldungen, wenn ich das Programm z.B. 
kompiliere oder auch übersetzen möchte!!!!

Jetzt bekomme ich bei der Kompilierung von diesem Programm:

#include<avr/io.h>
#include<util/delay.h>

int main (void)

{
  DDRB=0xff

  while (1)
  {
    PORTB=0xff;
    _delay_ms(1000);
    PORTB=0x00;
    _delay_ms(1000);
  }
  return 0;
}

diese Meldungen:

Build started 5.2.2013 at 10:15:00
avr-gcc  -mmcu=atmega16 -Wall -gdwarf-2 -Os -std=gnu99 -funsigned-char 
-funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT LED_TEST.o 
-MF dep/LED_TEST.o.d  -c  ../LED_TEST.c
In file included from ../LED_TEST.c:2:0:
c:\program files (x86)\atmel\avr tools\avr 
toolchain\bin\../lib/gcc/avr/4.6.2/../../../../avr/include/util/delay.h: 
90:3:  warning: #warning "F_CPU not defined for <util/delay.h>" [-Wcpp]
../LED_TEST.c: In function 'main':
../LED_TEST.c:9:3: error: expected ';' before 'while'
make: *** [LED_TEST.o] Fehler 1
Build failed with 1 errors and 1 warnings...

kann mir da jemand weiterhelfen?

[Hane10 -. (hane10)]

ok nach DDRB=0xff kommt noch ein Semikolon :)

[Hannes L. (hannes)]

Hane89 --- schrieb:
> kann mir da jemand weiterhelfen?

Steht doch alles da:

Hane89 --- schrieb:
> 90:3:  warning: #warning "F_CPU not defined for <util/delay.h>" [-Wcpp]
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Du hast dem Compiler nicht gesagt wie schnell Dein Controller taktet, 
somit weiß er nicht, wie die Warteschleifen berechnet werden sollen.

Hane89 --- schrieb:
> ../LED_TEST.c:9:3: error: expected ';' before 'while'
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Du hast wohl ein Semikolon vergessen. Wo weiß ich nicht, ich kann kein 
C.

...

[Hane10 -. (hane10)]

na endlich es funzt, meine LEDs blinken! :)