Tiny13 LED leuchtet nicht hell auf

[chr2k]

Hallo Experten,

ich verzweifel echt noch an dieser Materie.
Mal geht mein Programmer nicht, dann geht er mal wieder, dann kann ich die Fusebits DCBA nicht setzen, oder wenn ich sie setze dann bekomm ich ne fehelrmeldung und dann kann ich den µC reseten usw usw

Zu allem Übel kommt noch hinzu, das ich selbst bei einfachstem code probleme habe den zum laufen zu bekommen:

$regfile = "ATtiny13.DAT"
$crystal = 16000                                            'Frequenz des internen Oszillators

$hwstack = 6                                                'hardwarestack herabsetzen damit genügend variablen zur verfügung stehen


Portb.3 = 1
Wait 3
Portb.3 = 0

Portb.4 = 1
Wait 3
Portb.4 = 0


Return

End

- die oberen 3 zeilen mit inhalt habe ich aus einem reaktivlicht code "übernommen
- die fusebits hab ich auch so gesetzt wie beim reaktivlicht

ergebnis in der schaltung: die LED leuchten nicht hell auf sondenr glimmen nur für die zeit in der sie "an" sind. Versorgungsspannung 3V über 2x AA.
Die Versorgungsspannung bricht auch nciht ein wenn der Tiny bzw die schaltung an der spannungsquelle hängen. Selbst mit einem 5V Handyladegerät gehts nicht.
Hab die Schaltung auf einem Steckbrett verschaltet. Durchgang hab ich überall.
Die LEDs leuchten in der normalen Helligkeit auf wenn ich sie direkt an 3V hänge
Der Tiny scheint immer nur (gemessene) 1,6V durchzuschalten. Selbst wenn ich die LEDs vom µC abhänge.

Hat jemand eine Ideewas das sein könnte?

Spielt das Fusebit E hier eine Rolle? Welch eine Rolle psielt es denn überhaupt?
und hat die Schnelligkeit des µC damit etwas zu tun? ob er nun auf 128kHz oder 9,xMhz läuft?!

Vielen Dank

Gruß Christian

 

[#ammensleben]

moin moin

du hast in deinem code vergessen den portb.3 vorm "do" auf output zu setzen

Config Portb.3 = Output

 

[Kappler]

Mit welcher Frequenz läuft den dein Tiny? Hast du ihn tatsächlich auf 16kHz gestellt?
Diese Frequenz hast du dem Programm nämlich über den $crystal-Befehl mitgeteilt, und diese wird auch verwendet, um die benötigten Wartezyklen für die wait-Befehl zu ermitteln.

Wenn Bascom nun "denkt", dass der Tiny mit 16kHz läuft, er aber tatsächlich mit höherer Frequenz arbeitet, dann ergbt sich statt einem Blinken ein Flackern, was bei höherer Flackerfrequenz durchaus als Glimmen interpretiert werden kann...

Die 1,6V sind etwa die Hälfte der Batteriespannung, was auch auf ein solches gleichgetaketes Flackern hindeuten könnte.

Sicherer ist es, wenn du statt der wait- bzw. waitms-Befehle den Watchdog verwendest und den Tiny zum Warten in den Sleep-Modus versetzt. Das braucht zum Einen weniger Batterieenergie (was aber im Verglich zum Verbrauch der LED eher zu vernachlässigen ist), zum Anderen ist es unabhängig von der Taktfrequenz.

Um den Tiny auf 16kHz zu schalten, müssen die Fusebits übrigens so gesetzt werden, dass der interne 128kHz-Oszillator verwendet wird und zusätzlich der 8er-Teiler aktiviert ist.
Bei dieser Taktfrequenz soll es aber wohl zum Teil Probleme mit dem Programmer geben, so dass es sinnvoller ist, zum Testen und Progammieren zunächst den 8er-Teiler ausgeschaltet zu lassen und diesen erst ganz zum Schluss zu setzen, wenn alles fertig und bereit für den Wald ist.
Daher sollte zunächst der $crystal-Wert auf 128000 gesetzt werden und erst vor dem Aktivieren des Frequenzteilers auf 16000. Oder noch besser gar keine wait-Befehle verwenden sondern wie oben erwähnt den Watchdog zum Warten einsetzen. Dann kann man mit dem $crystal nichts verkehrt machen.

Des weiteren enthält dein Programm keine Endlosschleife sondern wird genau einmal durchlaufen und dann kommt ein return.
Ich weiß jetzt nicht genau, was nach diesem return geschieht, aber üblich ist das so wohl nicht...

 

[gomerffm]

Hallo Christian,
ohne jetzt zuviel klugsch... zu wollen....
So für die ersten Versuche mit dem Tiny würde ich empfehlen, die Fusebits unverändert zu lassen. Sie einfach mal auslesen.
Dann nimm Dir doch einfach ein getestetes, lauffähiges Programm aus dem Forum bzw. Kochbuch und probiere es für Deine aktuellen Bedürfnisse umzustricken.
Wirst dabei feststellen, dass es immer wieder nach dem gleichen Schema abläuft und welche Einstellungen mal initial im Programm definiert sein müssen (Prozessor, ggf. HW-Stack,Taktfrequenz, Portkonfiguartion, ggf. Variablen...)
so mal als Beispiel:

$regfile = "ATtiny13.DAT"
$crystal = 113000 'Reale Frequenz des internen 128kHz-Oszillators
'
Config Portb = &B00011000 'Pinb.3 und .4 auf 'Ausgang', Rest auf 'Eingang' schalten
Portb = &B11100111 'Pullups zuschalten, außer für Pinb.3 und .4
'
Stop Adc 'A/D-Wandler abschalten, um Strom zu sparen
Stop Ac 'Analog-Komparator abschalten, um Strom zu sparen
'
Dim A As Byte
Dim Hell_dunkel As Bit

Auch was die eigentliche Programmierung angeht kann man in den Beispielen, da zumeist ordentlich kommentiert, nachvollziehen, was sich der Author bei den einzelnen Programmzeilen gedacht hat.
Das, was man davon dann nicht haben möchte einfach löschen und durch eigene "Ideen" ersetzen, als neue Datei abspeichern, compilieren und auf den Tiny übertragen.
So Dinge, wie in größerem Umfang Fusebits ändern, den Watchdog nutzen, etc würde ich dann erst in einem zweiten Schritt angehen.

 

[Windi]

Weiterhin ist da ein Fehler im Programm.
Der Return-Befehl hat hier nichts zu suchen.
Dieser steht immer am Ende eines Gosub-Unterprogrammes.

Wenn Du willst das Dein Programm ständig wiederholt wird solltest Du es in eine Do..Loop-Schleife stecken.

Der Tip von Gomerffm, zum Experimentieren die Fuses auf der Grundeinstellung zu belassen, halte ich für sehr gut. Ein jungfräulicher Tiny ist damit auf 1 Mhz eingestellt. Also bitte auch den Crystal-Wert auf 1000000 stellen.
Den Watchdog würde ich in dieser Phase noch in Ruhe lassen und mit wait bzw. waitms experimentieren.

 

[chr2k]

Moin,

der Fehler lag an den nicht geschalteten Output Ports und nicht am Crystal-Wert.
@#ammensleben: Danke für diesen Tipp.


Wegen dem Returnbefehl:
Wenn das Programm durchgelaufen ist startet es von neuem. So sind zumindest die Auswirkungen die ich an den LED's sehe. Die blinken ständig hin und her.
Aber Do/Loop Schleife hätte ich dann eingesetzt, wenn das mit dem Return nicht schn einwandfrei funktioniet hätte.


@gomerffm:
1. Was bewirken die Pullups für die anderen Ports?
2. Wo im Datenblatt des Tiny steht, wie ich den Binärcode zusammen stellen muss um die Ports zu konfigurieren? (Config Portb = &B00011000)
3. Ich bin dabei ein bestehendes Programm nach meinen bedürfnissen umzustricken aber irgendwie klappt halt so manches nicht. Vorallem wenn man das was man im Datenblatt sucht nicht findet.


@windi:
1. Das setzen des Fusebits E und DCBA habe ich als Grundvorraussetzung vorausgesetzt damit der Tiny mit derartigen Programmen richtig zusammenarbeitet (nicht zu schnell blinken lässt wenn an den wait befehl nutzt etc)
2. Wenn ich nach einem Reset des Tinys an einem seriellen Programmer (ich stelle also die jungfräulichkeit wieder her, wenn ich das mal so richtig interpretiert habe) die Fusebits in Bascom auslese sieht das dann so aus:
FB Wert
H 0
G 1
F 1
E 0 (für was ist diese Funktion, im Datenblatt find ich einfach nichts)
DCBA 1010 (das entspräche 9,6Mhz - 1Mhz hab ich in der Liste nicht gefunden)
Wo sind die Fusebits eigentlich im Datenblatt beschrieben?


Dankeschön

 

[hendyp]

Wegen dem Returnbefehl:
Wenn das Programm durchgelaufen ist startet es von neuem. So sind zumindest die Auswirkungen die ich an den LED's sehe. Die blinken ständig hin und her.
Aber Do/Loop Schleife hätte ich dann eingesetzt, wenn das mit dem Return nicht schn einwandfrei funktioniet hätte.

Wenn ich mich richtig erinnere läuft der Microcontroller nach dem Ende des eigentlichen Programms weiter durch den Speicher, der im Auslieferungszustand mit NOP (no operation) initialisiert ist. Da der Adresszähler natürlich begrenzt ist, fängt er irgendwann wieder bei 0 an. Das funktioniert aber nur so lange "zuverlässig" wie keine Programmreste im restlichen Speicher liegen. Spätestens ab da ist das Verhalten nicht mehr so wirklich vorhersehbar.

@gomerffm:
1. Was bewirken die Pullups für die anderen Ports?
2. Wo im Datenblatt des Tiny steht, wie ich den Binärcode zusammen stellen muss um die Ports zu konfigurieren? (Config Portb = &B00011000)
3. Ich bin dabei ein bestehendes Programm nach meinen bedürfnissen umzustricken aber irgendwie klappt halt so manches nicht. Vorallem wenn man das was man im Datenblatt sucht nicht findet.

Sofern ich mich da einmischen darf ... (Kapitelangaben beziehen sich auf das Datenblatt der meines Wissens aktuellen tiny13-Version ATtiny13A.)

1. Die Pullups legen die Eingänge über einen Widerstand im 10kOhm-Bereich auf Versorgungsspannung. So kann z.B. über den Anschluss eines Taster an den Microcontroller (Eingangspin --- Taster --- Masse) eine einfache Bedienung realisiert werden, da dann im offenen Zustand immer sicher eine 1 gelesen wird; ansonsten wäre die Spannung am Eingang nicht definiert.
2. Im Prinzip steht das in den Abschnitten "10.2.1 Configuring the Pin" ff. und "10.4 Register Description", wenn man sie kombiniert. Zusätzliche Hürde ist, dass das Datenblatt auf Assembler und ab und zu C zugeschnitten ist. Auch wenn ich mich mit der Basic-Programmierung nicht ganz so gut auskenne, gehe ich stark davon aus, dass "Config Port..." das DDRx-Register beschreibt.

@windi:
1. Das setzen des Fusebits E und DCBA habe ich als Grundvorraussetzung vorausgesetzt damit der Tiny mit derartigen Programmen richtig zusammenarbeitet (nicht zu schnell blinken lässt wenn an den wait befehl nutzt etc)
2. Wenn ich nach einem Reset des Tinys an einem seriellen Programmer (ich stelle also die jungfräulichkeit wieder her, wenn ich das mal so richtig interpretiert habe) die Fusebits in Bascom auslese sieht das dann so aus:
FB Wert
H 0
G 1
F 1
E 0 (für was ist diese Funktion, im Datenblatt find ich einfach nichts)
DCBA 1010 (das entspräche 9,6Mhz - 1Mhz hab ich in der Liste nicht gefunden)
Wo sind die Fusebits eigentlich im Datenblatt beschrieben?

1. Solange man dem Compiler die Taktfrequenz richtig angibt und mit dem internen Taktgeber auskommt, muss man die Fusebits eigentlich selten ändern. Der Compiler sollte dann aus der Taktfrequenz und der gewünschten Wartezeit die richtigen internen Werte berechnen.
2. Beschrieben sind die Fusebits in "17.2 Fuse Bytes". Da das Fusebit CKDIV8 gesetzt ist und Du die Frequenz nicht per Software änderst, resultieren die 9.6MHz in 1.2MHz Systemtakt. Genaueres steht auch in "6.2.2 Calibrated Internal 4.8/9.6 MHz Oscillator".

Viele Grüße und noch schöne Feiertage,
hendyp

 

[gomerffm]

@hendyp

Danke fürs Einmischen
Da gibts erstmal nix hinzuzufügen

Schöne Restweihnachten wünscht

Gomerffm

 

[stonewood]

@windi:
1. Das setzen des Fusebits E und DCBA habe ich als Grundvorraussetzung vorausgesetzt damit der Tiny mit derartigen Programmen richtig zusammenarbeitet (nicht zu schnell blinken lässt wenn an den wait befehl nutzt etc)
2. Wenn ich nach einem Reset des Tinys an einem seriellen Programmer (ich stelle also die jungfräulichkeit wieder her, wenn ich das mal so richtig interpretiert habe) die Fusebits in Bascom auslese sieht das dann so aus:
FB Wert
H 0
G 1
F 1
E 0 (für was ist diese Funktion, im Datenblatt find ich einfach nichts)
DCBA 1010 (das entspräche 9,6Mhz - 1Mhz hab ich in der Liste nicht gefunden)

Bin zwar nicht windi, aber das interessante an den Watchdog-Warteschleifen ist daß die immer funktionieren - der Watchdog-Timer ist unabhängig von der Taktfrequenz des Prozessors immer fest auf 128 Khz eingestellt. Und da das Windi-Programm halt statt wait/waitms nur watchdog-Warteschleifen benutzt ist es eigentlich ziemlich egal wie schnell der Prozessor gerade getaktet ist.

Die Clock-Einstellungen findest Du im Kapitel 6: System Clock and Clock Options
Wie das nun genau auf bascom abgebildet wird kann ich jetzt aus dem Kopf nicht sagen.
Wesentlich ist: 2 Bits geben die Taktquelle vor, zwei Bits die Startup time.

Übrigens ist mir da aufgefallen daß der Tiny13 ja einen Prescaler für den Takt hat, also 1/1, 1/2, 1/4, ... 1/256 - bascom macht da aber nur 1/1 oder 1/8. Das läuft über die Fuse 'E'.

Ach ja, die Infos zu den einzelnen Chips sind im bascom-Installationsverzeichnis in .dat-Files hinterlegt. Für den Tiny13 wäre das also ATtiny13.DAT.

(edit
Hab noch was zu den Fuse Bits gefunden: Kapitel 17.2 Fuse Bytes
Da wird auch die 1/8-Fuse erwähnt, der Link zeigt dann aber auf den Prescaler. Die 1/8 Fuse ist wohl so offensichtlich daß man die nicht weiter dokumentieren braucht ?!?

 

[chr2k]

Mal abgesehen davon, dass ich die Fusebits zum ersten Testen "eigener" Programme nciht umstellen soll, und der Watchdog Timer ja viel besser ist wurmt es mich, dass mein Programmer den Tiny nicht mehr erkennt sobald ich für das reaktivlicht die Fusebits DCBA auf 128kHz stelle.

Was zum Geier ist da faul?

 

[stonewood]

Hmm. Was stellst Du ein? Auslieferungszustand ist:
- 9,6 Mhz interner Oszillator (soweit ich weiß - hab gerade nix zum nachsehen)
- 1/8 Taktteilung
Damit läuft dann der Tiny auf 1,2 Mhz.
Wenn Du nun auf 128 Khz runterschalten willst mußt Du beides umsetzen:
- 128 Khz Takt
- 1/1 Taktteilung
Wenn Du nun nur den Takt umstellst kommt das auf 128 Khz, 1/8 Teilung. Damit läuft der Tiny auf 16 Khz. Das funktioniert auch, aber der Tiny ist dann so langsam daß ein schneller Programmer nicht mehr vernünftig (also langsam genug) mit dem redet. Beim Parallelport-Programmer hilft dann $crystal auf 16000 runterzusetzen, das Programm noch mal kompilieren, eventuell bascom beenden und neu starten damit es das feststellt.

 

[Windi]

eventuell bascom beenden und neu starten damit es das feststellt.

Bei mir hat immer kompilieren gereicht. Ein Neustart war nicht erforderlich.

 

[chr2k]

Hmm. Was stellst Du ein? Auslieferungszustand ist:
- 9,6 Mhz interner Oszillator (soweit ich weiß - hab gerade nix zum nachsehen)

Ja, das ist korrekt.

- 1/8 Taktteilung
Damit läuft dann der Tiny auf 1,2 Mhz.
Wenn Du nun auf 128 Khz runterschalten willst mußt Du beides umsetzen:
- 128 Khz Takt
- 1/1 Taktteilung

Die Teilung wäre dann Fusebit "E", richtig?
Woher weiß ich welche Teilung ich einstellen muss?

Wenn Du nun nur den Takt umstellst kommt das auf 128 Khz, 1/8 Teilung. Damit läuft der Tiny auf 16 Khz. Das funktioniert auch, aber der Tiny ist dann so langsam daß ein schneller Programmer nicht mehr vernünftig (also langsam genug) mit dem redet. Beim Parallelport-Programmer hilft dann $crystal auf 16000 runterzusetzen, das Programm noch mal kompilieren, eventuell bascom beenden und neu starten damit es das feststellt.

[/quote]

Das werde ich aber auch mal probieren. Danke

 

[stonewood]

Woher weiß ich welche Teilung ich einstellen muss?

Du willst 128 Khz haben. Also keine Teilung. Oder Du willst16 Khz - das geht dann nur mit 128/8=16. Das gleiche gilt für die anderen Taktgeneratoren, die können ja nur feste Frequenzen erzeugen. Mit der Teilung hast Du dann quasi einen 9,6/8=1,2 Mhz Taktgenerator ausgewählt.

Ach ja, zum Umsetzen der Fuses: Ich empfehle da erst mal auf 9,6 Mhz, 1/1 umzuschalten. Also nur die Teilung abschalten, das dann in den Tiny schreiben. Danach dann 9,6 Mhz auf 128 Khz umschalten. Damit läuft der Tiny auf jeden Fall, bis 10 Mhz kann der noch mit 2,7-5,5V betrieben werden. Und auf dem Basteltisch wird der ja eher mit 3 oder 5V aus der Steckdose versorgt, läuft dann also auf jeden Fall noch stabil. Falls die 1/8 Fuse aus irgendeinem Grund nicht gesetzt wird stehst Du dann nicht mit einem 16Khz-'schleicher' da.

 

[chr2k]

Du willst 128 Khz haben. Also keine Teilung. Oder Du willst16 Khz - das geht dann nur mit 128/8=16. Das gleiche gilt für die anderen Taktgeneratoren, die können ja nur feste Frequenzen erzeugen. Mit der Teilung hast Du dann quasi einen 9,6/8=1,2 Mhz Taktgenerator ausgewählt.

Ich hoffe ich hab das verstanden...

Ach ja, zum Umsetzen der Fuses: Ich empfehle da erst mal auf 9,6 Mhz, 1/1 umzuschalten. Also nur die Teilung abschalten, das dann in den Tiny schreiben. Danach dann 9,6 Mhz auf 128 Khz umschalten. Damit läuft der Tiny auf jeden Fall...

Das hatte ich auch schon versucht. Manchmal gabs einen erfolg, dann lange keinen.

Den Grund (den ich Logisch nicht nachvollziehen kann) hab ich nun auch rausgefunden:
- Mit einem neuen Projekt (Codeseite leer) kann ich die Fusebits problemlos einstellen
- Wenn ein original Code aus dem Reaktivlicht-Thread geladen ist dann gilt dito
- Wenn ich einen selbstgestrickten Code hab, wo der $crystal-wert fehlt dann geht das fusebit einstellen nicht.

Nun meine bisherige Logik:
Für mich waren die Fusebtis bis jetzt wie Jumper auf einem mainboard: Man setzt die damit das Mainboard "irgendwie anders" funktioniert. Welche Software im Endeffekt drauf kommt ist dem Mainbaord "egal". Dann spielt man den code (in meinem beispiel das Betriebssystem) auf udn es funktioniert mit den Einstellungen auf dem Mainboard (Fusebits) und im Betriebssystem (Basiccode). Ergo: Zwei getrennte Einstellungen.

Die Realität: Es ist aber wohl so, dass sich die Fusebits erst einstellen lassen, bzw man die Fusebits auslesen kann, wenn auch der Taktwert im Code (der noch nicht mal compiliert, geschwiege denn im Tiny ist) mit dem im Tiny übereinstimmt.

Ist das so wirklich normal? :schockiert:
Wenn ja find ich das ganz schön

Danke für die Geduld
und Gruß
Christian

 

[Windi]

Bascom passt die Geschwindigkeit des Programmers an die Taktfrequenz des Tinys an.
Und dafür benötigt es halt den Crystal-Wert im Programm

 

[stonewood]

Für mich waren die Fusebtis bis jetzt wie Jumper auf einem mainboard: Man setzt die damit das Mainboard "irgendwie anders" funktioniert. Welche Software im Endeffekt drauf kommt ist dem Mainbaord "egal". Dann spielt man den code (in meinem beispiel das Betriebssystem) auf udn es funktioniert mit den Einstellungen auf dem Mainboard (Fusebits) und im Betriebssystem (Basiccode). Ergo: Zwei getrennte Einstellungen.

Die Fuses waren in grauer Vorzeit tatsächlich mal sowas wie 'Sicherungen' die man nach Bedarf einmal (!) durchbrennen lassen konnte. Man stellte also gewisse Werte auf das ein was man brauchte, und dann mußte das bis in alle Ewigkeit so bleiben. Mittlerweile sind die aber auch in Flash/Eprom-Speicherzellen untergebracht und können im Nachhinein wieder geändert werden. (außer man stellt das durch die entsprechende Fuse wieder ab).

Zum Auslesen und setzen der Fuses und auch zum Programmieren muß nun aber Dein Programmer vernünftig mit dem Tiny reden - der darf den also nicht 'Überfahren'. Heißt konkret:
- Der Tiny muß sich initialisiert haben. Das hat er erst nach der 'Startup Time', bei '14CK + 64 ms' und 16 Khz sind das 0,9 ms + 64 ms = 65 ms. Bei 9,6 Mhz und '14 CK' sind das nur 0,1 µs.
- Der Tiny muß einzelne Befehle lesen und darauf reagieren können. Mit 16 Khz kann er das nur sehr langsam, mit 9.6 MHz natürlich entsprechend schneller. Nimmt der Programmer darauf keine Rücksicht versteht der Tiny nur Bahnhof, und bascom gibt z.B. nur Müll beim erkannten Prozessor aus.

Und genau das passiert bei bascom durch die $crystal-Variable: Dementsprechend wird der Programmer gedrosselt oder schneller angesteuert. So sind dann langsame Atmels noch zu programmieren, und bei schnellen Atmels dauert die Programmierung nicht ewigkeiten. Problem ist nur daß der PC keine Möglichkeit hat festzustellen wie schnell der Atmel nun wirklich läuft: Jeder Befehl muß ja vom Atmel quittiert werden, und wenn von da nix kommt ist halt kein Atmel da (oder er antwortet nicht schnell genug). Wie windi schon schrieb: Das passiert daher über die $crystal-Variable.