AS 6 mit STK500 programmieren "Error ID 0x11"

[David S. (tischler)]

Hallo liebe Gemeinde,

ich mache gerade meine ersten Schritte mit AS6, dem STK500 und C.

Habe eine Kleinigkeit geschrieben und wollte es zum Atmel8 schieben - 
darauf erhalte ich die untere Fehlermeldung.
Leider finde ich im Netz nichts zu "Error ID 0x11" - habt ihr eine 
Ahnung?

/*
 * Project1.c
 *
 * Created: 14.09.2013 00:26:55
 *  Author: Tischler
 */ 


#include <avr/io.h>

int main(void)
{
void painta();  // forward declaration
void paintb();
void paintc();
void paintd();
void painte();
void paintf();

DDRB  = 0b11111111;
DDRD  = 0b00000000;
PORTD = 0b11111111;

  while(1)
  {
    // Fuehre Aktion aus, wenn Bit Nr. 0 in PIND low (gedrueckt) ist
    if ( PIND & (0<<PIND0) )
    {
      painta();
    }
    
      if ( PIND & (0<<PIND1) )
    {
      paintb();
    }

    if ( PIND & (0<<PIND2) )
    {
      paintc();
    }

    if ( PIND & (0<<PIND3) )
    {
      paintd();
    }

    if ( PIND & (0<<PIND4) )
    {
      painte();
    }

    if ( PIND & (0<<PIND5) )
    {
      paintf();
    }  
    
  main();
  }
return 0;
}
  
void painta(void)
{
  PORTB = 0b11111111;
  main();
}
  
void paintb(void)
{
  PORTB = 0b00000000;
  main();
}
  
void paintc(void)
{
  PORTB = 0b11111111;
  main();
}
  
void paintd(void)
{
  PORTB = 0b00000000;
  main();
}
  
void painte(void)
{
  PORTB = 0b11111111;
  main();
}
  
void paintf(void)
{
  PORTB = 0b00000000;
  main();
}

[isnah (Gast)]

Warum muss es immer Atmel-studio sein? Für die Kombination STK500 mit 
ATmega8 wurde das AVR-Studio "erfunden" und das funktioniert garantiert.

[STK500-Besitzer (Gast)]

David Schwandt schrieb:
> darauf erhalte ich die untere Fehlermeldung.

Wann erhälst du die Fehlermeldung?
Hast du das STK500 als Programmer richtig eingestellt.
AS6 ist etwas "blöd"...

isnah schrieb:
> Warum muss es immer Atmel-studio sein? Für die Kombination STK500
> mit
> ATmega8 wurde das AVR-Studio "erfunden" und das funktioniert garantiert.

Nur weil mal mit dem AtmelStudio auch noch ARMe, XMegas etc. 
programmieren kann, muss es nicht das falsche sein...

[katastrophenheonz (Gast)]

Hi,
Und wenn du die Probleme mit dem Programme gelöst hast, wirst du 
feststellen, dass dein Programm nicht funktioniert. Zum einen wegen der 
Aufrufe von main(), die dort nicht hingehören. Guck dir mal eines der 
zahlreichen  vorhandenen minimalprogamme zum LED-Blinken an, und wie 
dort Schleifen und funktionsaufrufe verwendet werden. C-Buch von vorn 
nach hinten durcharbeiten könnte auch helfen. Zum anderen sind deine 
Bit-abfragen falsch. Guckst du hier

http://www.mikrocontroller.net/articles/Bitmanipulation

wie man einzelne Bits abfragt und setzt.

Gruß, Heinz

[David S. (tischler)]

STK500-Besitzer schrieb:
> Wann erhälst du die Fehlermeldung?
> Hast du das STK500 als Programmer richtig eingestellt.
> AS6 ist etwas "blöd"...

Die Meldung kommt, wenn ich den Atmega programmieren möchte bzw. auf den 
grünen Pfeil "Debuggen" klicke. Er fängt an zu programmieren, man siehts 
an den LED's, aber schließt nicht ab.
Das STK500 ist eigentlich richtig konfiguriert, ich habe bereits 
programmieren können. Auch FUSE Abfragen etc. läuft. Es werden mir auch 
keine Errors und keine Warnings in der Error List. Unter Output sagt er 
mir:

An error occured while executing command with ID 0x11. Timed out waiting for a response.
67 characters was discarded waiting for response start stoken. Protocol state at time of
timeout was 'Get Sequence Number'.

katastrophenheonz schrieb:
> Und wenn du die Probleme mit dem Programme gelöst hast, wirst du
> feststellen, dass dein Programm nicht funktioniert. Zum einen wegen der
> Aufrufe von main(), die dort nicht hingehören. Guck dir mal eines der
> zahlreichen  vorhandenen minimalprogamme zum LED-Blinken an, und wie
> dort Schleifen und funktionsaufrufe verwendet werden. C-Buch von vorn
> nach hinten durcharbeiten könnte auch helfen. Zum anderen sind deine
> Bit-abfragen falsch. Guckst du hier

Das sind meine ersten Anfänge. Einen Main-Programmablauf habe ich schon 
hinbekommen, nun probiere ich mich beim Aufbau von Unterprogrammen.
Die Bit-Abfragen habe ich so aus einem Tutorial entnommen - wie wäre es 
denn richtig?

Danke an alle!

[Georg G. (df2au)]

David Schwandt schrieb:
> Die Meldung kommt, wenn ich den Atmega programmieren möchte bzw. auf den
> grünen Pfeil "Debuggen" klicke.

Willst du programmieren oder debuggen? Das ist schon ein Unterschied.

Und wirf alle main() Aufrufe raus. Die sind tödlich. Das Unterprogramm 
kehrt am Ende immer dahin zurück, wo es her gekommen ist.

[katastrophenheinz (Gast)]

>Die Bit-Abfragen habe ich so aus einem Tutorial entnommen
Dann sollte man den Tutorial-Schreiber wg. Desinformation mal die 
Leviten lesen.

>Wie wäre es denn richtig?
Steht ausführlich unter obigem Link.
Grundsätzlich geht das so, daß du dir das gesuchte Bit rausmaskierst, 
indem du alle anderen auf 0 setzt und dann guckst, ob das 
übriggebliebene 0 oder nicht 0 ist, z.B. für Bit2 aus deinem Beispiel
if ( ( PIND & 1<<PD2 ) != 0 ) // Wenn Bit2 gesetzt
oder
if ( ( PIND & 1<<PD2 ) == 0 ) // Wenn Bit2 nicht gesetzt

1<<PD2 ist gleichbedeutend zu 0b00000100, da PD2 in io.h mit 2 definiert 
ist. Durch das bitweise UND (&) zwischen PIND und 0b00000100 wird also 
erreicht, im 8bit-Ergebnis des bitwise-& alle Bits bis auf Bit2 
garantiert 0 sind, und Bit2 des Ergebnis ist identisch zu Bit2 aus PIND. 
Und dieses 8bit-Ergebnis kannst du jetzt einfach mit gleich/oder 
ungleich 0 auswerten.

Das Ganze kann man auch für mehr als ein Bit durchführen, dann musst du 
natürlich statt gleich/ungleich 0 auf das konkrete Bit prüfen, Beispiel:
if ( PIND & ( 1 << PD2 | 1 << PD3 ) == 1 << PD3 ) // Nur Bit3 gesetzt?

Gruss, Heinz

[katastrophenheinz (Gast)]

.. und überleg mal, warum ein Ausdruck der Form

0 << n

eigentlich sinnlos ist, und zwar für alle möglichen Werte von n.

[David S. (tischler)]

Ok - es liegt nicht am Code... ich kann selbst...

#include <avr/io.h>

int main (void) {
  while(1) {
  }
  return 0;
}

... nicht programmieren... Komisch, lade ich ein Programm geschrieben 
mit Assembler, läuft alles einwandfrei.
Kann ein µC, wenn er das erste mal mit Assembler programmiert worden 
ist, danach nicht mit C programmiert werden oder was ist hier los :D

[Georg G. (df2au)]

nochmals die Frage: Kann es sein, dass du programmieren und debuggen 
verwechselst?

[David S. (tischler)]

Georg G. schrieb:
> nochmals die Frage: Kann es sein, dass du programmieren und debuggen
> verwechselst?

Nun, eigentlich nicht - die Bezeichnung des "Play-Knopfes" lautet zwar 
"Start Debugging (F5)", jedoch wird der µC programmiert oder auch 
programmiert. Unter Assembler funktioniert es schließlich auch...

[Georg G. (df2au)]

Der Chip wird mittels eines .HEX (oder .ELF) Files programmiert. Diesem 
File sieht man nicht an, ob es per Assembler oder C oder Basic erzeugt 
wurde.

Du versuchst ein C Programm zu debuggen und das kann deine 
Entwicklungsumgebung nicht ohne weitere Hilfen.

[spess53 (Gast)]

Hi

>Nun, eigentlich nicht - die Bezeichnung des "Play-Knopfes" lautet zwar
>"Start Debugging (F5)", jedoch wird der µC programmiert oder auch
>programmiert. Unter Assembler funktioniert es schließlich auch...

Aber nur wenn ein Debugger vorhanden ist. Und das STK500 ist kein 
Dedugger.

MfG Spess

[David S. (tischler)]

Also ich muss sagen, da ich weder C noch Assembler kann, und mir das 
daher frei war, welche Sprache ich neu erlerne, und außerdem mit 
Assembler alles funktioniert - habe ich einfach meine Idee in Assembler 
niedergeschrieben.
Hier mache ich auch nichts anderes als auf den Pfeil bzw. F5 zu klicken 
/ drücken, er checkt daraufhin den Code auf Fehler (und spuckt mir dies 
aus bevor er programmiert) und programmiert daraufhin den µC.

[Georg G. (df2au)]

David Schwandt schrieb:
> Hier mache ich auch nichts anderes als auf den Pfeil bzw. F5 zu klicken
> / drücken

Es wäre hilfreich, wenn du wüsstest, was du tust und was für einen 
Erfolg Voraussetzung ist. F5 ist "RUN" und bedeutet, dass das Programm 
im Debugger laufen soll. Du hast keinen Debugger, du hast einen 
Programmieradapter. Also gibt es einen Fehler.

F7 erzeugt dir ein aktuelles HEX File und zeigt dir dabei ggfs die 
Fehler in deinem Programmtext. Wenn alles bis hier hin fehlerfrei ist, 
geht es mit "Tools", "Connect Programmer" dann weiter.

[David S. (tischler)]

Georg G. schrieb:
> F5 ist "RUN" und bedeutet, dass das Programm
> im Debugger laufen soll. Du hast keinen Debugger, du hast einen
> Programmieradapter. Also gibt es einen Fehler.

Nur, dass das selbe Spielchen in der Assembler-Sprache (selbes Programm, 
keine anderen Einstellungen etc.), durch drücken von F5 programmiert 
wird. Warum auch immer.

[Spess53 (Gast)]

Hi

>Nur, dass das selbe Spielchen in der Assembler-Sprache (selbes Programm,
>keine anderen Einstellungen etc.), durch drücken von F5 programmiert
>wird. Warum auch immer.

Und was hast du als Debugger eingestellt? Das STK500 kann weder JTAG 
noch DW. Und das sind die Schnittstellen über die bei F5 das Programm in 
den Controller geschoben wird. Bei einem STK500 kannst du nur den 
Simulator benutzen. Und der programmiert keinen AVR. Der 
Fortschrittsbalken der bei F5 erscheint hat nichts mit programmieren zu 
tun.

MfG Spess

[Georg G. (df2au)]

David Schwandt schrieb:
> Nur, dass das selbe Spielchen in der Assembler-Sprache (selbes Programm,
> keine anderen Einstellungen etc.), durch drücken von F5 programmiert
> wird. Warum auch immer.

Weil bei Assembler der eingebaute Simulator als Debugger dient. Für C 
ist nichts eingebaut, da muss DU liefern.

[BeJiZi (Gast)]

Hallo,
Weiss nicht, ob Du das Problem schon gelöst hast oder nicht ... aber ich 
hatte das selbe Problem und bin auf diesen Thread gestossen, der 
eigentlich nicht viel geholfen hat. Bei mir war die Ursache des Fehlers 
ein falscher ISP clock bzw. war der ISP Clock am STK500 anders 
eingestellt als im Project.

In Tools->Device Programming->Interface Settings
und Projekt
Tool -> ISP Clock

muss die gleiche Frequenz eingestellt sein.

Dann war bei mir der Fehler behoben.