Wie krieg ich meinen ATMega8 programmiert? [Anfängerprobleme]

Marc F. schrieb:
> ldi r16, 0b00000001 ; 0b00000001 in r16 laden (legt die
> Ausgangskonfigoration in r16 ab)
>          out PORTB, r16      ; r16 ins IO-Register PORTB ausgeben, PB0
> wird dadurch low

du schreibst ne 1 und das soll low sein?

den AVR kenne ich nicht.

PS für mich ist 2^0 = 1 und damit aktiv und high

3,9k ist ziemlich viel reicht grad so für uh LEDs ultra helle, normale 
Dunkelleds werden da nicht mehr leuchten.

Hi,

AVCC verbinde ich (je nach Lage der Dinge) mit Vcc und 100n nach Masse.
3,9k vor den LEDs sind ganz schön viel.

Fuses: BODEN und EESAVE kannst Du erst mal weglassen.

Sieh Dir mal die incl. Datei an: die Ports haben Namen, die man 
verwenden kann, also so:

1

 ldi r16, (1<<PB0)+(1<<PB1)

Sieh Dir mal diese Seite an: 
http://www.avr-asm-tutorial.net/avr_de/beginner/index.html

MfG
Elux

Hardwareaufbau kontrollieren. Sind die LEDs wirklich am richtigen Port 
angeschlossen? Foto vom Steckbrett?

Reiner O. schrieb:
> Sieh Dir mal die incl. Datei an: die Ports haben Namen, die man
> verwenden kann, also so: ldi r16, (1<<PB0)+(1<<PB1)

er hat doch die LEDs nach VCC angechlossen, mit high leuchten die doch 
nie.
Fehlende AVCC war auch ein guter Hinweis aber sollten nur Port C 
betreffen nicht Port B.

AVCC is the supply voltage pin for the A/D Converter, Port C (3..0), and 
ADC (7..6).
Beitrag "Port C am ATmega8"

Marc F. schrieb:
> bzw. beliebige Variationen daraus bewirkt nichts an den beiden Ausgängen
> PB0 und PB1. Sie bleiben immer auf ca. 2.8VDC.

klar weil die in der Schleife immer von high nach low wechseln und dein 
Messgerät nicht so schnell ist?

+1 für die ausführliche Beschreibung. :-)

Joachim B. schrieb:
> klar weil die in der Schleife immer von high nach low wechseln und dein
> Messgerät nicht so schnell ist?

Die Schleife besteht lediglich aus einem Sprung zu sich selbst, warum 
also sollte sich der Zutand des Ausgangs verändern?

In der Tat läßt sich aber eine Spannung um die 3 Volt messen, wenn die 
LEDs so angeschlossen sind UND der Ausgang hochohmig ist (selbst 
nachvollzogen). Bei einem hochohmigen Port ohne Beschaltung geht die 
Spannung gegen Null.

Icke ®. schrieb:
> In der Tat läßt sich aber eine Spannung um die 3 Volt messen, wenn die
> LEDs so angeschlossen sind UND der Ausgang hochohmig ist

dann muss ne Unterbrechung sein, dazu passt aber nicht das er scheinbar 
den Port B auf out setzt und auf high, da erwarte ich an Port B nahe an 
VCC.

Das hier macht mich noch stutzig:
Marc F. schrieb:
> Zusätzlich habe ich noch mein Oszilloskop jeweils zwischen LED und
> uP-Ausgang geklemmt.

den Oszi in Reihe zu Port und LED? mit seinen 1M bis 10M Ri was soll das 
werden?

Joachim B. schrieb:
> dann muss ne Unterbrechung sein, dazu passt aber nicht das er scheinbar
> den Port B auf out setzt und auf high, da erwarte ich an Port B nahe an
> VCC.

Davon ausgehend, daß der µC funktioniert und das Programm tatsächlich so 
geflasht wurde, müßte am Hardwareaufbau irgendwas faul sein. Deswegen 
soll er das überprüfen und ein Foto einstellen.

Guten Morgen, ihr fleissigen! :)

Vorweg: Funktionieren tut noch nix.

Es hat jetzt etwas gedauert, bis ich mich wieder voll diesem Projekt 
zuwenden konnte. Dafür gibt es von mir aber auch nur genau beschriebene 
Posts. ;)

Vielen Dank für die vielen Vorschläge, in Gänze habe ich wohl alles, was 
in den Rückmeldungen erwähnt wurde, umgesetzt.

1. Das Schema
Wie richtig bemerkt, stimmte das Schema nicht. Darum gibts jetzt das 
neue, korrigierte und verbesserte Schema als Anhang.

Ebenfalls dabei ist ein Pinout meines AVRISP und ein "Beweisfoto", das 
die Verbindung zwischen ISP und Breadboard zeigt; hier steckt der Fehler 
meines wissens nicht.

2. Der Aufbau
Wie ihr dem Bild (Anhang) entnehmen könnt, habe ich ein relativ grosses 
Breadboard. Zum Zeitpunkt meines ersten Posts hatte ich daher auch noch 
eine gänzlich andere Schaltung im "diagonal gegenüberliegenden 
Quadranten" des Boards. Bitte nicht schlagen, ich weiss, das gehört sich 
so nicht.

Da "kontrolliere den Aufbau" eine der beliebtesten Rückmeldungen war, 
beschloss ich dann aber auch ziemlich schnell , das Board komplett zu 
leeren und die Schaltung mit dem neuen, korrigierten Schema frisch 
aufzubauen.

Ich persönlich mag es nicht, wenn die LEDs zu hell zünden, wenn sies 
nicht müssen, daher habe ich die Widerstände so hoch dimensioniert und 
zur zufridenheit zwischen VCC und Masse getestet. Bevor ich hier aber 
eine unnötig langwierige Diskussion vom Zaun breche: Wie im Schema 
ersichtlich habe ich natürlich die Vorwiderstände gewechselt. Sind jetzt 
je 100 Ohm, rein rechnerisch könnte ich auch noch auf je 75 Ohm runter. 
Leuchten sie halt hell, wenn sie es dann mal tun sollten.

Eine weitere, nicht speziell gekennzeichnete Änderung stellt die 
Stromversorgung dar, welche jetzt durch ein Labornetzgerät erfolgt.

Falls sich einige Fragen, was "dieser grosse Kondesator, der nicht im 
Schema ist" auf dem Breadboard zu suchen hat: Es handelt um einen C 
2200uF/25V zwischen VCC und Masse und um eine Gewohnheit von mir.
Ich setze mittlerweile immer, trotz Labornetzgerät einen grossen 
Kondesator ein, um einen bequemen Erdkontakt für die Oszilloskop-Klemme 
zu haben.

3. Der Flash-Versuch und das ernüchternde Ergebnis
So habe ich mit neuem Aufbau und frischem Mut noch einmal das Gleiche 
wie im ersten Post versucht.

Atmel Studio erkennt den Controller, ich kann darauf zugreifen und ihn 
auslesen, soweit alles in Ordnung aber auch nicht weniger 
vielversprechend als zu Beginn.

Verändern des Binärwertes von "0b00000000" zu "0b11111111" bzw. alle 
möglichen Kombinationen dazwischen, brachten keine sicht- oder messbare 
änderung an PB0 oder PB1.

In meinem Initialpost befindet sich im Anhang die Datei 
"flashing_blur.png"; sichtbar dort ist der MouseOver-Effekt auf der 
Schaltfläche "Program".

Ganz explizit gefragt, bevor hier noch etwas in einer 
Selbstverständlichkeit untergeht: Sollte nach drücken des Buttons 
"Program" die LED quasi "direkt" leuchten oder muss noch irgend etwas 
getan werden?

Das bringt mich zum Ende meines Posts und "Lateins".
Ich freue mich jetzt schon auf euer Feedback und bin zuversichtlich, 
dass meine Anfängerprobleme lösbar sind! :)

Liebe Grüsse,


Cyberfreak1992


PS: @elux
Die AVR-ASM-Tutorial-Seite kenne ich bereits, danke. Ich habe mich auch 
schon mal etwas eingelesen. Irgendwo zwischen den Kapiteln "Werkzeuge" 
und "Register" habe ich allerdigs aufgehört. Ich habe mir zum Ziel 
gesetzt zuerst einmal eine funktioniernde programmierte Schaltung zu 
haben, bzw. mich an den Beispielen, die hier im Tutorial erwähnt werden 
(insbes. LEDs anzünden und Taster auslesen) zu versuchen. Dabei reicht 
es mir, zu verstehen, was der Code macht, ohne die ganze Sprache zu 
können. Richtig in Assembler "eingraben" werde ich mich wohl erst, wenn 
sich auf Hardwareebene erfolge zeigen.

Nein, wie im Schema bezeichnet:
Vom Reset-Pin über einen 10k-PullUp-Widerstand an VCC und ein 
47nF-Kondensator an Masse.

Es hat bereits einen 100nF-Kondensator zwischen VCC und Masse (Pin 7, 
8);
dieser Wert wird auch im Tutorial vorgeschlagen.

/Ironie:ON

Was möchtest du denn belötet sehen? :D
Das Breadboard oder doch lieber direkt die DIE des uP? ;)
- Etwas Spass muss sein <:¬P

/Ironie:OFF

Liebe Grüsse,


Cyberfreak1992

Hallo Toni!

Ich habe vor einiger Zeit mal das Oszilloskop probehalber an einen 
Quarzanschluss gepinnt, um genau das heraus zu finden. Der schwingt brav 
mit f=4.000... MHz :)

Gruss

Irgendwie befürchte ich, dass hier die "Wall of Text" nicht so beliebt 
ist.
... Soweit ich verstanden habe, ist eine wichtige Regel "erst lesen, 
dann posten!"

So weit habe ich Assebler ja auch schon verstanden, mir fehlen bloss die 
Richtigen bezeichnungen, da ich mich noch nicht genauer mit der Sprache 
befasst hab und in Sachen uP und Programmierung erst an der Oberfläche 
kratze.

Also, jedenfalls noch einmal das Selbe, der Code:

Denn Quellcode habe ich von hier, genauer: 
AVR-Tutorial: IO-Grundlagen.
Ich gehe mal davon aus, dass dieser Code soweit stimmt, was die 
"Rechtschreibung" angeht.

1

 .include "m8def.inc"

2

3

         ldi r16, 0xFF          ; Zeile 1

4

         out DDRB, r16          ; Zeile 2

5

6

         ldi r16, 0b00000001    ; Zeile 3

7

         out PORTB, r16         ; Zeile 4

8

9

ende:                           ; Zeile 5

10

rjmp ende                       ; Zeile 6

Jetzt, hier mein begrenztes Code-Verstädtnis. Bitte Nachsicht wo ein 
Fachausdruck nicht stimmt, der Sinn sollte bei so einem kurzen, 
einfachen Code ja sicher erschliessbar sein.


Zu Zeile 1:
Mit dieser Anweisung wird das Register 16 mit der Konstanten "0xFF" bzw. 
"0b11111111" geladen. Dieser Zwischenschritt ist nötig, da Werte über 
Register an die betreffende(n) Stelle(n) ausgegeben werden müssen bzw. 
die Wertübergabe "nicht direkt" erfolgen kann.

Zu Zeile 2:
Durch diese Anweisung wird die Konstante 0xFF (0b11111111) via Register 
16 an DDR* (geraten: Data Direction Register) ausgegeben, wobei das * 
für den entsprechenden Port A, B, C, D steht, der gesetzt wird.  Ein 1 
macht aus dem Entsprechenden Port einen Ausgang, eine 0 einen Eingang. 
Daher auch werden mit der konstanten 0xFF einfacher Weise einfach mal 
alle Bits / Pins zum Ausgang erklärt. Das LSB entspricht hierbei dem 
entsprechenden Port Pin 0, das MSB Port Pin 7 (sofern vorhanden).

Zu Zeile 3:
In diesem Zwischenschritt wird die Konstante mit der Konfiguration der 
(nun) Ausgänge überschrieben. Dabei wird festgelegt, ob der zum Bit 
gehörige Pin (LSB: PB0) auf High oder Low geschalten wird.

Ob dieser Wert nun "0b11111100", "0b11111111" oder beliebig anders ist; 
beim erneuten Flashen mit Anpassung dieses Wertes sollte sich an den 
Ausgängen doch etwas Ändern, oder? Diese Veränderung blieb bislang aus.

Zu Zeile 4:
Hier wird der im Register 16 gespeicherte Wert an den entsprechenden 
Port (B) gesendet, also die entsprechenden "Bits am Port löschen", was 
zum leuchten der jeweiligen LEDs führen sollte.

Zu Zeile 5 und 6:
Diese Endlosschleife wird im Tutorial eingesetzt. Was genau die Funktion
ist, entzieht sich jedoch noch meiner Kenntnis.



Jetzt noch mal das wichtigste zum Schluss, für alle TLDR-Menschen:

Ganz explizit gefragt, bevor hier noch etwas in einer
Selbstverständlichkeit untergeht: Sollte nach drücken des Buttons
"Program" die LED quasi "direkt" leuchten oder muss noch irgend etwas
getan werden?

Für was braucht es die Endlosscheife im AVR-Code?

Sieht sonst noch jemand einen Fehler?


Vielen Dank und liebe Grüsse,
Cyberfreak1992

PS@Bestromer:
VCC und Masse habe ich so, seit dem ich das Steckbrett habe. Sieht auf 
den ersten Blick etwas verwirrend aus, hab es aber von Beginn an so 
gemacht, darum hab' ich mich daran gewönt und finde es (in meinen Augen) 
übersichtlich; hatte auch noch nie Probleme damit.
Allerdings wollte ich auch noch nie einen uP programmieren.. :D

Was meinst du mit parallel abgreifen?
Wie sollte das denn deiner Meinung nach aussehen? (Da besteht sicher 
noch Verbesserungspotetial bei mir :P )

Marc F. schrieb:
> ldi r16, 0b00000001 ; 0b00000001 in r16 laden (legt die
> Ausgangskonfigoration in r16 ab)
>          out PORTB, r16      ; r16 ins IO-Register PORTB ausgeben, PB0
> wird dadurch low

grrrr.....

ist das noch immer so bei dir?

wieso soll ein Port (out) low werden wenn du 1 reinschreibst?
wenn die LED an VCC hängt kann sie bei high nicht leuchten.

ist dir das denn jetzt klar?

Für mich sieht das so aus, als ob VCC und GND an den Pins 7 und 8 
vertauscht sind. Jedenfalls, wenn du dein Farbschema gelb-Masse/grün-VCC 
dort auch beibehalten hast. Wohin die Drähte führen, wird im Bild vom 
Elko verdeckt. Allerdings dürfte dann auch das Flashen nicht möglich 
sein.

Ich schrieb:
> Das hat er doch schon...

Eben nicht!

Marc F. schrieb:
> Vorweg: Funktionieren tut noch nix.

es nervt:

im Plan geht Anode LED nach VCC und dann kann sie nur leuchten bei Port 
auf OUT und Port low also nicht gesetzt.

Im Steckbrett sieht man das ein Bein der LED nach GND zu gehen scheint.

Da wundert sich der TO und sucht Fehler? immer noch und beantwortet 
keine Fragen?

Joachim B. schrieb:
> Im Steckbrett sieht man das ein Bein der LED nach GND zu gehen scheint.

Guck nochmal.