Hallo zusammen,
seit paar Tagen versuche ich meinen ATtiny13A zum Laufen zu bekommen.
Ich habe verschiedene Beiträge/Artikel hier und auf anderen Seiten
durchgeforstet, aber nichts passendes für mich finden können.
Zum Anliegen:
Es soll lediglich eine LED zum blinken gebracht werden. In der Uni
arbeiten wir mit einem ATmega128 und dem STK500, das mir aber für mein
Vorhaben deutlich zu überdimensioniert scheint. Also wie gesagt, ich
will ohne Entwicklungsboard meinen tiny mit einer blinkenden LED zum
Laufen bringen. Problem hierbei ist, dass der zueghöroge Ausgang (PB3)
permanent HIGH ist, egal was ich schalte und walte.
Im Detail:
Ich habe das AVr Studio 6 und als Programmer/Debugger den Atmel ICE III.
Meinen tiny habe ich gemäß Datenblatt korrekt über SPI mit dem
programmer verbunden. Mein C-Code (siehe unten) wird korrekt gebuildet
und anschließend auch ohne Fehlermeldung auf den tiny übertragen.
Anschließend leuchtet meine LED dauerhaft.
Ich habe bereits gelesen, dass man in den Build-Einstellungen auf
"Release" stellen muss. Auch das klappt leider nicht.
Auch habe ich verschiedene Grundschaltungen ausprobiert, obwohl mein
Profesor meint, dass prinzipiell keine Grundschaltung nötig wäre. Die
aktuelle Grundschaltung sieht so aus, dass am RESET-Pin ein Pull-Up von
10k und ein 47nF Kondensator an GND angeschlossen ist. Außerdem noch ein
100nF zwischen Vcc und GND. Vcc ist übrigens eine konstante Spannung von
5V. Und an Pin PB3 ist meine LED mit Vorwiderstand an GND angeschlossen.
Einen externen Quarz verwende ich (noch) nicht, weil für meine ersten
Tests ich nicht darauf angewiesen bin und erstmal Hard- und Software
kennenlernen möchte. (In der Uni arbeiten wir bspw. mit Eclipse auf Arch
Linux).
Wo könnte mein Fehler liegen? Ist es eine fehlende Einstellung im AVR
Studio oder ist meine Schaltung falsch? Sind irgendwelche Fuses
standardmäßig "falsch" gesetzt, sodass ich sie anders setzen muss? Nach
meinen Recherchen ja eigentlich nicht. Ansonsten habe ich alle
Einstellungen auf Standard gelassen.
Ich bedanke mich schon einmal und hoffe hier keinem in irgendeiner Art
und Weise auf die Füße getreten zu haben.
Anbei noch mein C-Code:
Julian Utsch schrieb:> obwohl mein> Profesor meint, dass prinzipiell keine Grundschaltung nötig wäre.
Der gute Mann meint evtl. nur die Resetschaltung, die man auch mal
weglassen kann. Der Abblockkondensator (100nF) ist allerdings immer
nötig für einen stabilen Betrieb des MC.
Zum Problem: Das muss was ganz dummes sein, denn am Programm kann es
nicht liegen, das sieht alles richtig aus - viel isses ja auch nicht.
Entweder ist der kleine Kerl kaputt, oder nur PB3 ist kaputt. Probier
mal einen anderen Pin.
Kann eigentlich auch kein falsches Fusen sein, dann würde die LED
trotzdem blinken, wenn auch mit der falschen Frequenz. Wenn du den Tiny
programmieren kannst, ist auch ein MC Takt da.
Julian Utsch schrieb:> Wo könnte mein Fehler liegen?> Sind irgendwelche Fuses> standardmäßig "falsch" gesetzt, sodass ich sie anders setzen muss?
Ich kenne zwar den Tiny13 nicht, aber bei dem von mir gerne genommenen
Tiny25 oder auch beim Mega8 ist per Default der interne Takt auf 1MHz
eingestellt. Für 8MHz musst man den CLKDIV herausnehmen.
Vielleicht hast du nur nicht lange genug Geduld gehabt und die LED
blinkt mit 1/8 Hz anstatt mit 1Hz.
Nachtrag:
PB4 ist ebenfalls dauer haft HIGH. Die restlichen Pins waren vorher
durch die ISP Verbindungen belegt und sind LOW. Auch wenn ich das delay
weglasse und quasi PB3 auf LOW im Code schalte, bleibt PB3 HIGH.
Julian Utsch schrieb:> Sind irgendwelche Fuses> standardmäßig "falsch" gesetzt, sodass ich sie anders setzen muss? Nach> meinen Recherchen ja eigentlich nicht. Ansonsten habe ich alle> Einstellungen auf Standard gelassen.
Die Fuses sind natürlich richtig gesetzt. Ein Attiny13 läuft per default
mit 1,2MHz.
Julian Utsch schrieb:> Anbei noch mein C-Code:
1
#define F_CPU 8000000L
Damit wird keine Frequenz eingestellt, sondern dem Compiler mitgeteilt,
mit welcher der Controller läuft! Also Fuses richtig einstellen
(CLKDIV8), Frequenz richtig angeben.
Die Basisfrequenz eines Attiny13 beträgt 9,6MHz, mit CKDIV8 1,2MHz!
Also ohne Fuse-Änderung:
1
#define F_CPU 1200000L
oder ganz komfortabel, auch ohne Fuse-Einstellung:
1
#define F_CPU 9600000L
2
.
3
.
4
#include<avr/power.h>
5
.
6
.
7
intmain(void)
8
{
9
clock_prescale_set(1);
10
.
11
.
12
.
13
}
Dann passen auch die delays. Der Rest deines Programms ist zu einfach,
um falsch zu sein. Es sei denn, deine Schaltung hat eine Macke oder du
kompilierst für einen anderen Controller, flasht ein falsches Hex-File
oder dein Programmer ist Scheisse oder, oder...
Am Programm liegt es jedenfalls nicht. Wenn du meine Ratschläge
einbaust.
mfg.
Danke Thomas für den Hinweis mit der Taktrate. Das hatte ich nicht
gewusst. Bin jetzt auf die 1,2Mhz umgestiegen, aber gleicher Effekt wie
vorher.
Ich habe eben einen neuen tiny angeschlossen und ihn somit zum ersten
Mal programmiert. Diesmal ist das Programm noch primitiver. Es soll die
LED an Pin PB3 ausgeschaltet lassen. Und nach dem erfolgreichen
programmieren leuchtet die LED wieder. Ich bin ratlos. Warum ist dieser
Ausgang wieder auf HIGH?
Der Programmer ist eigentlich noch fast neu und kann unmöglich kaputt
sein.
Programmer abziehen!
Marco G. schrieb:> Kann es sein, dass der PIN Reserviert ist, wie bei anderen uCs die> JTAG-Pins und erst freigegeben werden muss?
Nein. Der hat nur 8 Pins. Da wäre JTAG etwas viel des Guten.
Das passt schon alles.
@Julian: Du misst auch an Pin 2?
PB3 liegt nicht an Pin 3, sondern an Pin 2. Sowas passiert schnell im
Eifer des Gefechts. Das Layout ist an der Stelle ein bisschen fies.
mfg.
@Thomas:
Jetzt hast du mich verwirrt ;) PB3 ist nicht Pin PB3?? Das steht doch
auch so im Datenblatt, dachte ich zumindest.
Ich hab eben deinen Code getestet. Auch hier gleiches wie vorher. Nur
Pin PB3 und Pin PB4 leuchten und zwar konstant...
Julian Utsch schrieb:> Jetzt hast du mich verwirrt ;) PB3 ist nicht Pin PB3?? Das steht doch> auch so im Datenblatt, dachte ich zumindest.
Natürlich ist PB3 an PB3. Nur das ist Pin 2 am Controllergehäuses. Die
Reihenfolge der Ports ist auf dieser Seite des Controllers PB5, PB3,
PB4. Aber wenn dich das nicht verwirrt, will ich auch keine Verwirrung
stiften.
Julian Utsch schrieb:> Ich hab eben deinen Code getestet. Auch hier gleiches wie vorher. Nur> Pin PB3 und Pin PB4 leuchten und zwar konstant...
Dann teste mal so:
Jonas G. schrieb:> Bist du dir sicher das dein Controller richtig programmiert wurde?
Der ICE III behauptet das jedenfalls, steht ja im ersten Posting. Aber
es ist ja möglich, mal ein Verify Lauf auszuführen, um da ganz sicher zu
sein. Ich möchte jetzt jedenfalls auch mal ein Bildchen vom Aufbau
sehen, denn das Programm ist ja extrem simpel und richtig. Es muss also,
wie schon geschrieben, etwas ganz dummes sein, oder die Tinys des TE
sind alle breit. Auch die Fuses können gar nicht so falsch sein, denn
der MC lässt sich ja programmieren, also muss der Oszillator zumindest
laufen. Selbst wenn der Tiny mit seinen originalen 1,2MHz rennt, muss
die LED blinken.
Anbei mein Schaltungsaufbau. Die Beschaltung hatte ich ja eingangs schon
erwähnt. Da fällt mir auch eine Frage ein. Ich habe ja ein Pull-Up am
Reset Pin und dann eine Reset Leitung zum ICE III. Funktioniert das
beides zusammen? (grünes Kabel oben links)
Wenn ich heute Abend zuhause bin, kann ich gerne Beschriftungen für die
Kabel hinzufügen, falls es benötigt wird.
Julian Utsch schrieb:> Anbei mein Schaltungsaufbau. Die Beschaltung hatte ich ja eingangs schon> erwähnt. Da fällt mir auch eine Frage ein. Ich habe ja ein Pull-Up am> Reset Pin und dann eine Reset Leitung zum ICE III. Funktioniert das> beides zusammen? (grünes Kabel oben links)
Es ist bei Problemen immer einen gute Idee, zum Testen des Controllers
den Programmer ganz einfach abzuziehen. Hängt kein Programmer am
Controller kann er ihn auch nicht beeinflussen.
Aus dem Grund ist eine einfach lösbare Steckverbindung am
Programmieranschluss immer eine gute Idee.
Julian Utsch schrieb:> Anbei mein Schaltungsaufbau.
Das sieht auch alles gut aus. So langsam bleibt dann aber auch nicht
mehr viel.
Wird das richtige File geflasht? Das wird beim Anlegen eines Projektes
NICHT automatisch eingestellt!
mfg.
Also vor dem Programmieren ist die LED aus?
Und danach, "egal" welches Hex-File geflasht wurde, an?
Was passiert wenn du den µC löschst? Ist die LED dann wieder aus?
D.h. die Ports können grundsätzlich schalten?!
uwe schrieb:> In welche Richtung ist die LED denn angeschlossen?> µC -> Anode-Kathode -> GND> µC -> Kathode-Anode -> VCC
Hm...war auch schon meine Idee, aber dann hätte sie ja trotzdem blinken
müssen.
Danke Thomas, du hattest den entscheidenden Hinweis. Es ist mir ja schon
peinlich, aber das AVR Studio hat ein altes Hexfile benutzt. In der Uni
benutzen wir Eclipse da funktioniert das ein wenig eleganter. Als ich
dann mein uC mit dem neuen Hexfile beschrieben habe, blinkte es wie
gewünscht :)
Für die Zukunft weiß ich in der Hinsicht jetzt Bescheid.
Ich danke euch für eure zahlreiche Hilfe und hoffe ihr seid mir nicht
sauer wegen so einem dummen Fehler von mir.
LG Julian
Unglaublich, wie so triviale Dinge einen aufhalten können.
Ist mir aber auch schon passiert. Ich ärgere und schäme mich dann immer
eine Weile lang in Grund und Boden. Und dann verfluche ich die Sch****
Software, die nicht so klug ist, von alleine das zu tun, was ich von ihr
erwarte :-)
Ob wir noch echte KI erleben dürfen, bevor wir sterben?