Programmierung von ATmega8-16PU macht Probleme

Christian W. schrieb:
> - Der ATmega ist nagelneu

Das könnte das Problem sein. Hast Du schon Fuses setzen können? Neue 
ATmegas laufen mit internem 8 MHz Takt und Takteiler 8. Resultat sind 1 
MHz Taktfrequenz. Das ist beim Programmieren mittels ISP zu beachten, da 
die maximale Frequenz der ISP-Clock um einen gewissen Teiler kleiner 
sein muss. Leider habe ich den Teiler gerade nicht im Kopf (4?).

Christian W. schrieb:
> - Falscher Quarz? Ich verwende einen 4,0000 statt 3,6864?

Der Quarz geht einem nagelneuen ATmega am Boppes vorbei. ;) Der läuft - 
solange die Fuses diesbezüglich nicht gesetzt sind - mit 1 MHz (8 MHz 
interner Takt mit Taktteiler 8).

Christian W. schrieb:
> - fehlende Kondensatoren direkt an den Spannungseingängen am IC (100nF)?

Sollte nicht Ursache für Dein Problem sein, solche Kondensatoren sind 
aber sehr empfehlenswert.

Hallo  Christian W. ,

>   Ein Klick auf "Ignorieren" bringt auch nichts

das haben auch schon viele Hasen gesagt, die dann im Schlund des Adlers 
endeten.

Leider konnten wir diese Hasen nicht mehr befragen!

 Gastino G. sagte schon was  dazu.

schritt 1:
einen kleinen Messpin an GND des Prozessors löten
schritt 2
Minuskabel des  Multimeters an diesen Messpin
schritt 3 :
Mit Multimetre dann messen an VCC und dann an RESET

beide müssen High sein
RESET fällt kurz auf LOW bei jedem versuch zu programmieren (kann man 
messen)

TIPP:
meistens sind MISO oder MOSI vertauscht

grussi klausi

Hallo, danke für die Beiträge. Ich werd das alles mal testen. Fusebits 
kann ich leider nicht setzen, geschweige denn auslesen aus dem Chip, 
jedesmal kommt diese "Device missing..." Meldung.

Hab mal einen Schaltplan angehängt, wie die Platine momentan aussieht, 
vielleicht hat jemand Lust, mal kurz drüberzuschauen.

Danke

Christian

hallo Christian W.,

hast du denn ein Oscilloscope zur Hand ?

gruss

Hallo,

danke für die schnellen Nachrichten.

Im PonyProg ist momentan der Siprog API gewählt, COM Schnittstelle 
stimmt auch. Ich hab auch schon andere Adapter im PonyProg getestet aber 
ohne Erfolg.

Ein Pullup-Widerstand am Reset-PIN ist nicht vorhanden, der PIN geht 
direkt an den Wannenstecker mit einem Draht.

Oszi hab ich keines...

Die MOSI MISO Belegungen stimmen auf der Platine 1:1.

Hab mal ein Digitalmultimeter angesteckt. Da ergibt sich folgendes:

- Platine ohne Stromversorgung und mit angesteckter serieller 
Schnittstelle: Reset PIN hat -0,35V

- Platine MIT Stromversorgung und mit angesteckter serieller 
Schnittstelle: Reset PIn hat + 4,73V

- Die 4,73 V ändern sich auch dann nicht, wenn ich versuche zu 
Programmieren oder etwas aus dem IC auszulesen.

Kann das tatsächlich sein, dass das Programmierinterface Schrott ist? 
Das hab ich mir fertig gekauft.

Kann ich während des Programmiervorgangs mit einer Krokoklemme den 
Reset-PIN auf Masse ziehen oder geht da was kaputt?

Danke

Christian

Hallo Christian,

> Kann ich während des Programmiervorgangs mit einer Krokoklemme den
> Reset-PIN auf Masse ziehen oder geht da was kaputt?

Das kannst du und es geht nix kaputt...  leider nützt es aber auch nix.
Der Reset geht beim Proggen ja nur kurz auf Low um den Vorgang 
einzuleiten.
Dauerreset verhindert also das proggen.

Das du an die Fuses nicht herankommst ist unter diesen Umständen auch 
klar.
.. eigentlich benötigt man diese in deinem Stadium auch ersteinmal 
nicht.

.. anderen Prozessor versucht (wegen der Pferde vor der Apotheke)

gruss K.

p.s.
am Anfang sind es oft Einstellungen bezüglich des Programmers .. 
respektive
der PC Hardware, die , falls falsch, Probleme machen.

zudem solltest Du in diesem Stadium eher versuchen die Fuses auszulesen 
als irgendwas zu proggen.

ok danke für die antworten.

ich werde bei der pc hardware ansetzen mit fehlersuchen, da mir der 
programmieradapter den ich verwende ziemlich komisch vorkommt. weil: im 
sub-d-steckergehäuse sitzt ein kleiner smd-ic, der da meiner meinung 
nach nicht hingehört und vielleicht den direkten datenaustausch zwischen 
pc und atmel verhindert. eigentlich müssten ja ein paar widerstände und 
ein transistor reichen?

kann ich diesen programmieradapter wie in der grafik angehängt 
verwenden? ich verwende PonyProg 2.07c Beta.

danke

christian

Hallo,

danke für die Nachricht.

Ich hab jetzt einen 10k Widerstand gegen VCC an Reset gehängt, zwar ist 
die Spannung am Reset PIN geringfügig auf 4,91 V gestiegen, aber auch 
beim Programmieren bleiben die 5 V und ändern sich nicht, auch nicht 
sehr kurz. (Wie lange wird der PIN auf Masse gezogen beim 
Programmiervorgang? Merkt man das mit einem Digitalmulti überhaupt?)

Fazit: Auch mit dem 10k Pullup lässt sich der Prozessor nicht 
programmieren. Als nächstes werd ich mal einen seriellen Adapter bauen 
und diesen dann statt des jetzigen Testen.

Christian

Gregor schrieb:
> Hallo,
>
> ohne PulUp (10k gegen Vcc)auf dem RESET wird der Mega8 meines Wissens
> nicht laufen; und nicht programmierbar sein.

Genauso ist es. Der Kollektor des Transistors ist bei dem Programmer an 
Reset beschaltet  - ohne Pull-up kann das gar nicht funktionieren.

Edit: Zu spät. :)

@Spess: Ist der interne Pull-Up am Reset-Port von Anfang an aktiv? Im 
Datenblatt (ATmega48) steht bei der Beschreibung des Reset-Pins nichts 
dazu:

"RESET, Reset pin: When the RSTDISBL Fuse is programmed, this pin 
functions as a normal I/O
pin, and the part will have to rely on Power-on Reset and Brown-out 
Reset as its reset sources.
When the RSTDISBL Fuse is unprogrammed, the reset circuitry is connected 
to the pin, and the
pin can not be used as an I/O pin.
If PC6 is used as a reset pin, DDC6, PORTC6 and PINC6 will all read 0.
PCINT14: Pin Change Interrupt source 14. The PC6 pin can serve as an 
external interrupt
source."

Ich nehme alles zurück, im Datenblatt ist die RESET-Logik abgebildet und 
da befindet sich natürlich ein pull-up.

#include <avr/io.h> /* Standardregister */

// Hauptprogramm
int main(void)
{

  // Datenrichtung festlegen
  // DDRD = Gesamter B Port ist Ausgang
  DDRD = 0xff;

  // Alle LEDs an
  PORTD |= (1 << 0); /* PIN aktivieren */
  PORTD |= (1 << 1);
  PORTD |= (1 << 2);
  PORTD |= (1 << 3);
  PORTD |= (1 << 4);
  PORTD |= (1 << 5);
  PORTD |= (1 << 6);
  PORTD |= (1 << 7);

  return 0;
}

Christian

Hallo, sorry habs grade korrigiert...
geht aber immer noch nicht...

Kann das sein dass der gesamte HEX-Code im Speicherchip des 
Programmieradapters festhängt?

Ich hab mir grade den Originalen USB Programmieradapter bestellt, 
vielleicht klappts ja dann mit dem besser...?

Wow geil ich habs grade geschafft.

Hab alle Programme geschlossen, alles abgesteckt, neu gestartet,

dann den Reset PIN auf Masse gelegt

dann programmiert

dann den Reset-Masse-PIN wieder von Masse genommen

Alle LEDs leuchten!

Wie geil


Vielen Dank euch allen für die schnelle Hilfe :-)

Viele Grüße

Christian

ok werd ich machen...

was mich noch interessiert ist, warum manchmal meine leds angehen, und 
manchmal nicht?

teilweise ist es so, dass alle leds bis auf eine brennen.

ist mein 22k basiswiderstand am transistor vielleicht zu groß?
welchen widerstand kann man hier empfehlen?

danke

christian

Christian W. schrieb:

> ist mein 22k basiswiderstand am transistor vielleicht zu groß?
> welchen widerstand kann man hier empfehlen?

Mit 10k wirst Du nicht viel falsch machen. 22k sind tatsächlich etwas 
groß.

Hallo zusammen,

ich hab jetzt mal alle Basiswiderstände durch 8k6 ersetzt und außerdem 
an der +5V Leitung direkt am IC Sockel einen 0,1uF Elko angebracht... Es 
ändert sich aber leider nichts an der Situation dass einige LEDs dunkel 
bleiben.

Was mir auffällt: Ich habe ein Programm geschrieben, dass alle LEDs 
nacheinander aufleuchten lässt. LED Nr. 6 an Ausgang PD5 geht zwar an, 
erlischt aber in dem Moment wenn die nächste LED Nr. 7 angeht. Sowas hab 
ich aber nicht programmiert. Sehr komisch... LED1 geht überhaupt nicht 
an, lässt sich aber einschalten, wenn man mit einer Hilfsspannung an der 
Basis den Transistor mit der Hand durchschaltet.

Kann mir jemand sagen, wie ich über die Fuse-Bits den 4 MHz Oszillator 
aktiviere? Momentan rennt der IC noch mit 1 MHz. Vielleicht liegts ja 
daran, dass der externe Quarz "reinpfuscht"...

Danke

Christian

Hier wäre mal mein C-Code

1

// 8-Kanal-Lauflicht

2

3

#include <avr/io.h> 

4

#define F_CPU 1000000UL // Takt

5

#include <util/delay.h> 

6

7

int main(void) 

8

{ 

9

  // als Ausgang festlegen

10

    DDRD = 0xff; 

11

12

  // Warten vor dem Start

13

  _delay_ms(1000);

14

15

  // Pause zwischen den LEDs

16

  int zeit = 100;

17

18

  // Alles nacheinander einschalten

19

    PORTD |= (1 << PD1); _delay_ms(zeit);

20

    PORTD |= (1 << PD2); _delay_ms(zeit);

21

    PORTD |= (1 << PD3); _delay_ms(zeit);

22

    PORTD |= (1 << PD4); _delay_ms(zeit);

23

    PORTD |= (1 << PD5); _delay_ms(zeit);

24

    PORTD |= (1 << PD6); _delay_ms(zeit);

25

    PORTD |= (1 << PD7); _delay_ms(zeit);  

26

27

  // Warten

28

  _delay_ms(1000);

29

30

  // Alles ausschalten 

31

  PORTD &= ~(1 << PD1); 

32

    PORTD &= ~(1 << PD2); 

33

    PORTD &= ~(1 << PD3); 

34

    PORTD &= ~(1 << PD4);  

35

    PORTD &= ~(1 << PD5); 

36

    PORTD &= ~(1 << PD6);  

37

    PORTD &= ~(1 << PD7); 

38

39

    // Warten

40

  _delay_ms(500);

41

42

  // Pause zwischen den LEDs 

43

  int pause = 100;

44

45

    // Programmschleife

46

    while(1) 

47

      { 

48

49

        PORTD |= (1 << PD0); //  aktivieren 

50

            _delay_ms(pause); 

51

            PORTD &= ~(1 << PD0); //  deaktivieren 

52

53

            PORTD |= (1 << PD1); //  aktivieren 

54

            _delay_ms(pause); 

55

            PORTD &= ~(1 << PD1); //  deaktivieren 

56

57

            PORTD |= (1 << PD2); //  aktivieren 

58

            _delay_ms(pause); 

59

            PORTD &= ~(1 << PD2); //  deaktivieren 

60

61

            PORTD |= (1 << PD3); //  aktivieren 

62

            _delay_ms(pause); 

63

            PORTD &= ~(1 << PD3); //  deaktivieren 

64

65

            PORTD |= (1 << PD4); //  aktivieren 

66

            _delay_ms(pause); 

67

            PORTD &= ~(1 << PD4); //  deaktivieren 

68

69

            PORTD |= (1 << PD5); //  aktivieren 

70

            _delay_ms(pause); 

71

            PORTD &= ~(1 << PD5); //  deaktivieren 

72

73

            PORTD |= (1 << PD6); //  aktivieren 

74

            _delay_ms(pause); 

75

            PORTD &= ~(1 << PD6); //  deaktivieren 

76

77

            PORTD |= (1 << PD7); //  aktivieren 

78

            _delay_ms(pause); 

79

            PORTD &= ~(1 << PD7); //  deaktivieren 

80

81

            PORTD |= (1 << PD6); //  aktivieren 

82

            _delay_ms(pause); 

83

            PORTD &= ~(1 << PD6); //  deaktivieren 

84

85

            PORTD |= (1 << PD5); //  aktivieren 

86

            _delay_ms(pause); 

87

            PORTD &= ~(1 << PD5); //  deaktivieren 

88

89

            PORTD |= (1 << PD4); //  aktivieren 

90

            _delay_ms(pause); 

91

            PORTD &= ~(1 << PD4); //  deaktivieren 

92

93

            PORTD |= (1 << PD3); //  aktivieren 

94

            _delay_ms(pause); 

95

            PORTD &= ~(1 << PD3); //  deaktivieren 

96

97

            PORTD |= (1 << PD2); //  aktivieren 

98

            _delay_ms(pause); 

99

            PORTD &= ~(1 << PD2); //  deaktivieren 

100

101

            PORTD |= (1 << PD1); //  aktivieren 

102

            _delay_ms(pause); 

103

            PORTD &= ~(1 << PD1); //  deaktivieren 

104

105

    } // Ende while

106

107

    return 0;

108

109

} // Ende main

So auf die Schnelle:

Alles aus- bzw. einschalten könntest Du natürlich auch einfacher mittels

1

//aus

2

PORTD = 0x00;

3

//ein

4

PORTD = 0xff;

Die Delay-Funktionen erwarten ein Double als Argument (wenn ich mich 
recht erinnere).
Hast Du beim Kompilieren eine Optimierungsstufe eingestellt?

In der while-Schleife gehen natürlich die jeweiligen LEDs aus, wenn Du 
die nächste einschaltest.

Wie sind die LEDs verschaltet? Kann man an Deinem Schaltplan oben ja 
nicht sehen.

Hallo, das Wort Optimierungsstufe glaub ich klingt schon mal sehr gut 
für mein Problem, ich weiß aber nicht was da eingestellt ist, ich hab 
alles auf den Einstellungen wie bei der Programm-Installation belassen. 
Kann man auch ohne Optimierung den Code Hexen? Würd ich nämlich gerne 
mal testen und sehen was dabei rauskommt.

Das was konkret nicht passt, ist folgendes:

Ich programmiere:

1

// Alles nacheinander einschalten

2

    PORTD |= (1 << PD1); _delay_ms(zeit);

3

    PORTD |= (1 << PD2); _delay_ms(zeit);

4

    PORTD |= (1 << PD3); _delay_ms(zeit);

5

    PORTD |= (1 << PD4); _delay_ms(zeit);

6

    PORTD |= (1 << PD5); _delay_ms(zeit);

7

    PORTD |= (1 << PD6); _delay_ms(zeit);

8

    PORTD |= (1 << PD7); _delay_ms(zeit);

Und der Controller macht das hier mit den 8 LEDs:

AUS-EIN-EIN-EIN-EIN-AUS-EIN-EIN

Wie gesagt, wenn die while-Schleife durchläuft, funktionieren alle 8 
LEDs ohne Probleme.

Anbei noch eine Grafik, wie meine LEDs am Controller hängen.

Christian

Christian W. schrieb:
> Und der Controller macht das hier mit den 8 LEDs:
>
> AUS-EIN-EIN-EIN-EIN-AUS-EIN-EIN
>
> Wie gesagt, wenn die while-Schleife durchläuft, funktionieren alle 8
> LEDs ohne Probleme.

PD0 programmierst Du ja nicht, insofern ist das erste AUS erklärbar. Das 
andere ist durch den Code nicht wirklich erklärbar, prüfe daher nochmal 
die Verschaltung an dem Pin.

Die Optimierungsstufe des Compilers schaltet man in den 
Compiler-Optionen ein (ergibt dann beim Aufruf des gcc -O0, -O1, -O2 
oder -O3). Ohne Optimierung kann der Compiler die Delay-Zyklen nicht 
bestimmen.

Aha, das bei PD0 sieht mir nach Leichtsinnsfehler aus... Sch**ße...

Das mit der Optimierung werd ich mal testen.

Danke

Christian

Hallo zusammen,

hab alles im Griff. Die Led Nr. 6 leuchtete deswegen nicht mehr wenn Nr. 
7 anging, weil hinten auf der Platine ein Lötfehler war. Von der einen 
Led war der Plus mit dem Minus der benachbarten Led verbunden. Das 
erklärt auch, warum Led Nr. 6 zwar alleine leuchtete, aber dann ausging, 
wenn alle anderen auch leuchteten, am Minuspol war plötzlich 
Plus-Potential und durch die Led floss kein Strom mehr.

Von der Programmierung her klappt jetzt alles einwandfrei. Hab heute den 
originalen AVR USB Programmieradapter bekommen. Der billige serielle 
Adapter den ich zu erst verwendet habe ist nicht zu gebrauchen. Da muss 
man immer per Hand den Reset Pin auf Null ziehen, das ist Sch**ße...

Vielen Dank für alle Tipps. War sehr hilfreich.

Viele Grüße

Christian