ATtiny13 und PWM

[LotadaC]

Richtig, auch als Diskussionsgrundlage wäre ein Schaltplan besser geeignet - insbesondere bei komplexeren Schaltungen. Abgesehen von den Prüfmechanismen, die das Layout-Programm noch bietet...
ABER: wenn ich das recht verstehe, hat er den Plan(Layout) jetzt mal eben nur so auf die Schnelle nur auf Dein Drängen hin gekrizzelt - eigentlich steht ja noch nichtmal das Programmkonzept, die Pinbelegung ist noch nicht endgültig (da wären dann manchmal auch layouttechnische Aspekte zu berücksichtigen), also ist es für 'n Schaltplan und Layout mMn noch zu früh.

Ggf kann man das auch erstmal auf'nem Steckbrett testen?

P.S.:
Sind nun wirklich 4 separate Ausgänge gefordert - das Programm soll ja immer 2 Paare identisch behandeln - oder könnte man auch je 2 MOSFETs parallel an den entsprechenden AVR-Pin hängen?
Verträgt der AVR-Pin überhaupt die Umladeströme (eines/zweier FETs)?
Strombegrenzungswiderstände?
Was ist mit Gate-PullUps/-Downs um 'nen festen Pegel zu garantieren, solange der AVR-Pin tristate ist?
Wie soll die Programmierung erfolgen? (also letztendlich - einmal außerhalb der Schaltung und nach dem Einlöten nie wieder, oder ISP-fähig?)
(zum Testen auf'm Steckbrett, ok - aber auch da willst Du vielleicht nicht bei jedem Versuch umstecken wollen)

 

[Janiiix3]

Richtig, auch als Diskussionsgrundlage wäre ein Schaltplan besser geeignet - insbesondere bei komplexeren Schaltungen. Abgesehen von den Prüfmechanismen, die das Layout-Programm noch bietet...
ABER: wenn ich das recht verstehe, hat er den Plan(Layout) jetzt mal eben nur so auf die Schnelle nur auf Dein Drängen hin gekrizzelt - eigentlich steht ja noch nichtmal das Programmkonzept, die Pinbelegung ist noch nicht endgültig (da wären dann manchmal auch layouttechnische Aspekte zu berücksichtigen), also ist es für 'n Schaltplan und Layout mMn noch zu früh.

Ggf kann man das auch erstmal auf'nem Steckbrett testen?

Seit dem mir TommyB. ein Breadboard empfohlen hat, möchte ich es auch nicht mehr missen. Ich würde dir auch sowas empfehlen (wenn du nicht schon eins besitzt)

 

[dino03]

Hi,

Schaltplan und Layout sind zwei verschiedene Sachen.

Ein Schaltplan ist vergleich bar mit der bereits angesprochenen Landkarte.
Wenn du die Landkarte dann zu einem Papierkneul zusammenknüllst, dann hast du nen Layout

Da kann man wirklich noch viel erkennen Die Leute werden ihre Freizeit bestimmt nicht opfern um erstmal durch Reverse-Engineering aus dem Layout wieder nen Schaltplan zu machen.

Noch schöner wäre nen doppelseitiges Layout mit gemischter (SMD und bedrahtet) Bestückung. Teilweise die SMD-Bauteile noch auf der gegenüberliegenden Seite zwichen den Pins der bedrahteten Bauteilen. Da wird dir dann bestimmt niemand drauf antworten

Merke: Du möchtest die Hilfe haben. Also mußt du dafür sorgen das dir die Leute auch helfen können. Entweder du investierst ein wenig Zeit und lieferst die Infos die benötigt werden oder du investierst ganz viel Zeit um das Problem selber zu lösen. Denke immer daran das die Leute hier in ihrer Freizeit und ohne Bezahlung helfen.

Gruß
Dino

 

[Tiedge]

Moment mal, wie schon LotadaC geschrieben hat, ist das Layout nur entstanden weil Janiiix3
drum gedrängt hatte.

Dies hatte ich auch bereits erwähnt, den eine Schaltung kann man erst machen wenn das Programm fertig ist RICHTIG.

Wenn alles soweit ist, werde ich auch natürlich einen Schaltplan anlegen, aber last mich doch erst mal, das mit dem Programm hin bekommen. Und nicht gleich immer alles schlecht machen.

 

[Janiiix3]

Moment mal, wie schon LotadaC geschrieben hat, ist das Layout nur entstanden weil Janiiix3
drum gedrängt hatte.

Dies hatte ich auch bereits erwähnt, den eine Schaltung kann man erst machen wenn das Programm fertig ist RICHTIG.

Wenn alles soweit ist, werde ich auch natürlich einen Schaltplan anlegen, aber last mich doch erst mal, das mit dem Programm hin bekommen. Und nicht gleich immer alles schlecht machen.

Schlecht machen?
gedrängt?

Ich hoffe du hast dich verschrieben. Wie kann man ein Programm schreiben wenn man nicht mal 100 % weiß wie die Hardware aussehen soll ? Das sind Anmerkungen / Vorschläge. .. du weißt wie deine Schaltung aussehen / arbeiten soll... mit deinen Angaben kann ich ( evtl. auch andere hier ) nicht viel anfangen. Wenn du wirklich 100 % effektive Hilfe erwartest solltest du auch schon drüber nachdenken was man dir sagt...

 

[Tiedge]

LotadaC;

P.S.:
Sind nun wirklich 4 separate Ausgänge gefordert - das Programm soll ja immer 2 Paare identisch behandeln - oder könnte man auch je 2 MOSFETs parallel an den entsprechenden AVR-Pin hängen?
Verträgt der AVR-Pin überhaupt die Umladeströme (eines/zweier FETs)?
Strombegrenzungswiderstände?
Was ist mit Gate-PullUps/-Downs um 'nen festen Pegel zu garantieren, solange der AVR-Pin tristate ist?
Wie soll die Programmierung erfolgen? (also letztendlich - einmal außerhalb der Schaltung und nach dem Einlöten nie wieder, oder ISP-fähig?)
(zum Testen auf'm Steckbrett, ok - aber auch da willst Du vielleicht nicht bei jedem Versuch umstecken wollen)



Ich habe 4 separate Ausgänge genommen, weil ich sicher bin das der AVR Pin nur einen Verträgt.
Das sind N Kanal MosFets, ich gehe davon aus, das die Umladeströme nicht all zu groß sind, ich kann ja noch immer eine 10k dazwischen machen, wenn der Test nicht gut verlaufen sollte.
Für die Programmierung werde ich noch Pins vorsehen.

LG
Christian

 

[Tiedge]

Als erstes wollte ich nur wissen wie das mit den Timer Programmieren geht.
Ich habe auch geschrieben was ich vorhabe.
Wieso muss man dann gleich einen Schaltplan haben.
Ich möchte doch erst mal das Programmieren lernen.

 

[LotadaC]

...Wie kann man ein Programm schreiben wenn man nicht mal 100 % weiß wie die Hardware aussehen soll ?...

Wie kann man die Hardware festlegen bevor man das programmtechnische Konzept fertig hat? Einzelne Details vielleicht, aber der ganze Plan?
Du legst Dich erst auf zB 'n Tiny13 fest, und versuchst dann hinterher irgendwie erfolglos 'n nicht vorhandenen HW-UART zu verwenden, weil Dein Programmkonzept das (dann hinterher festgelegt) so vorsieht?

Er hat Doch vermerkt, daß er keine Ahnung vom Timer hat, da hat er sich insbesondere auch noch nicht au Prozessorpins festgelegt...

 

[Tiedge]

Danke LotadaC

 

[dino03]

Hallo,

mal kurz zu meinem Beitrag: Ich habe mich da lediglich auf Schaltplan/Layout bezogen. Nicht darauf ob das zu diesem Zeitpunkt sinnvoll ist.

Wie kann man die Hardware festlegen bevor man das programmtechnische Konzept fertig hat? Einzelne Details vielleicht, aber der ganze Plan?
Du legst Dich erst auf zB 'n Tiny13 fest, und versuchst dann hinterher irgendwie erfolglos 'n nicht vorhandenen HW-UART zu verwenden, weil Dein Programmkonzept das (dann hinterher festgelegt) so vorsieht?

Ich mache das folgendermaßen:

Man sieht sich als erstes erstmal an was man evtl für Funktionen benötigt. zB I2C, SPI, UART, INT, ADC, ... Daraus ergibt sich schon in etwa der benötigte Atmel. Dann hält man sich wenn irgend möglich die entsprechenden Funktions-Pins frei. Die restlichen jetzt noch freien Pins werden dann auf die digitalen IOs verteilt (Taster, LEDs, LCD, ...) wobei man zB versucht die Leitungen sauber auf den Ports zu gruppieren. Bei Kraut und Rüben-Verteilung wird es schnell unübersichtlich und erschwert die Programmierung. Wenn es eng wird, dann sollte man eher nen größeren Atmel nehmen als sich irgendwelche Verrenkungen einfallen zu lassen. Also keine RSTDIS-Fuse oder solche Späße. Man sollte sich auch die Pins für den Quarz freihalten. Wenn man vor hat irgendwas mit Zeitsteuerung zu machen sollten auch die XTAL-Pins frei sein.

Von diesem Kern arbeitet man sich nun nach außen in die Pheripherie (Transitorstufen, Treiber, ...). Dabei kann es dann vorkommen das man wegen besserer Leitungsverlegung ein paar Portbelegungen ändert. Das ist dann ein dauerndes hin und her bis man ein Optimum gefunden hat.

Erst nun fange ich bei mir mit dem Programm an. Zuerst mit einem Skelett was mir lediglich die Hardware testet und anzeigt das alles sauber läuft. Dann wird Schritt für Schritt jede Funktion einzeln eingebaut.

Gruß
Dino

 

[Tiedge]

Hi,
ich weis ja nicht wie viel Programme Du geschrieben hast, ich habe bis jetzt nur ein Lernpacket in der Hand gehabt und habe da diese Aufgaben abgearbeitet. Leider kam da nichts von Timer oder solche Dinge vor. Bis jetzt bin ich noch am Lesen und versuch dass mit dem Timer auf die Rolle zubekommen. Klar wenn ich etwas Erfahrung habe, werde ich mir bestimmt auch erst einen anderen Wag suchen um eine Schaltung zu Planen

 

[LotadaC]

...Man sieht sich als erstes erstmal an was man evtl für Funktionen benötigt. zB I2C, SPI, UART, INT, ADC, ... Daraus ergibt sich schon in etwa der benötigte Atmel. Dann hält man sich wenn irgend möglich die entsprechenden Funktions-Pins frei...

eben.
Dazu muß man aber schon ein grundliegendes Konzept des Programmes haben, also was letztendlich wie, und mit welcher internen Hardware, gemacht werden soll. Wenn dann zB mehrere Timer oder mehrere PWMs für eine Aufgabe bereitstehen, kann man das später wählen, ebenso bei mehreren UARTs.
Ich fange bei sowas immer mit 'ner Skizze an, bei der der Controller (erstmal noch kein konkreter) in der Mitte steht, und rundrum die anzusteuernden Aufgaben. Alles nur grob schematisch als Block. Beim konkreten Problem hier also einerseits der RC-Empfänger, und auf der anderen Seite Deine MOSFET-LEDs. Das Signal vom RC zum Controller wird eingezeichnet, mit Pfeil zum Controller (Input), ggf sogar mit'ner Verdeutlichung der Signalform darüber (also 20ms Periode, 1,5+/-0,5ms high). Auf der anderen Seite Hast Du Signale vom Controller zu den MOSFET-LED-Blöcken.
Eine meiner ersten Fragen spielte darauf an, ob diese lediglich an/ausgeschaltet werden sollen, oder ob die via PWM "dimmbar" sein sollen. Das ginge nämlich mit HW-PWM beim Tiny13 nur mit 2 Kanälen. Die Signale sind also Ausgänge, und "normale" (beliebige->Dino) digitale I/Os (konkret Os - Outputs).
Mit der Entscheidung gegen die PWM-Ausgänge bist Du jetzt auch frei, was den einen Timer betrifft, jetzt mußt Du Dir überlegen, wie Du das Signal erfaßt, welche Pins für Dich in Frage kommen.
Der Timer ist immer(!) ein Zähler, der zählt immer(!) irgendwelche Takte. Das können entweder extern getriggerte Takte über den Tn-Pin, oder ein Takt der aus dem Systemtakt abgeleitet ist (Timer-Prescaler) sein, bei einigen Controller kann sogar auf einen asynchronenen (zum Systemtakt) separaten Quarz gekoppelt werden. Wenn Du die Frequenz des (ggf vorgeteilten effektiven) Timer-Taktes kennst, kannst Du also mit der Anzahl der Timer-Takte die verstrichene Zeit berechnen - oder andersrum: wenn Du auf irgend'ne konkrete Zeit prüfen/vergleichen willst, kannst Du ausrechnen, wieviele effektive Timer-Takte der Timer dazu getickt haben muß.
Wenn Du bei Deinem Signal also die High-Zeit "messen" willst (also die Timer-Takte zählen), mußt Du Dir Überlegen, wie Du auf entsprechende Flankenwechsel reagieren kannst, und im nächsten Schritt, wie der Timer dazu sinnig eingestellt werden könnte. Dadurch wird eventuell der Signal-Input-Pin festgelegt.
Wenn die bereits festgelegten Pins also im Schema eingetragen sind, und bei der "beliebigen" zumindest die Anzahl feststeht, kannst Du mit dem Datenblatt des Controllers überblicken ob (das) der Controller überhaupt paßt, und die beliebigen I/Os schonmal 'ne Vorauswahl treffen. Also wie Dino angedeutet hat, bestimmte Pins ausschließen, deren Spezialfunktionen eventuell noch gebraucht werden könnten. Hier konkret hat sich das bereits erledigt, da Du mit den 4 Ausgängen und dem einen Eingang eh alle Pins verwendest.

Jetzt wäre der Zeitpunkt, daß in einen Schaltplan zu übertragen (Eagle zB), also Controller mit Stromversorgung, Pufferelko+Kerko, Anschluss der zum RC-Empfänger führt (Netz gleich auf RC_in oder so benennen), Block mit dem Mosfet/LED-Anschluß zeichnen (erhalten die 'ne separate Stromversorgung?).
Die Netze, die vom Controller zu den Mosfets führen, erhalten dann auch sinnige Namen, und werden im Plan als Label erkennbar gemacht.
Diesen Plan kannst Du dann (wenn Du willst) im Forum diskutieren lassen. (ggf willst Du das dann noch ISP-fähig bekommen)
Dann wäre das Layout fällig, was natürlich auch diskutiert werden kann. Bei komplexeren Aufgabestellungen kann es hier durchaus nochmal zu Veränderungen im Plan kommen.
Bei so einem kleinen Projekt kannst Du natürlich auf das Layout als Leiterplatte verzichten, und das auf'n Steckbrett übertragen (was ja konkret auch'n Layout ist -> Fritzing).

Wenn das alles erfolgt ist, kannst Du nun damit beginnen, das Programmkonzept - die Idee - in konkreten Code zu implementieren. Je nach verwendeter externer Hardware ggf erstmal nur mit einem Funktionstest dieser (->Dino)

---

@Dino: abgesehen von der Forderung:"4 einzeln angesteuerte Kanäle" (wobei die immer paarweise sind) wäre das ein weiteres Anwendungsgebiet für den Tiny10 (ein RC-IN, zwei PWM_OUTs, alle Pins belegt)...
Hmm... 'ne alte RC-Funke hab ich noch im Keller...

 

[Tiedge]

Hallo,
also die LED will ich erst mal nur ein- ausschalten können. Das Dimmen gibt dann mal was für meine Heli.

 

[Tiedge]

Hallo,
so ich habe mein Programm soweit zusammen ist aber nicht in Assembler,
es ist in Bascom, da ich im Netz mehr Info über Bascom gefunden habe als über Assembler.
Ich habe es sogar geschafft meine 4 Kanäle Blinken zu lassen.
Schaut Euch mal mein Programm an, bestimmt finden Ihr noch was wo man verbessern könnte.
Schaltplan kommt in ein paar Tagen nach.

P.s. LotadaC bin nicht bei Portb.2 als Eingang geblieben sondern Portb.1,
ich danke Dir für deine Bereitschaft zum Helfen.

Mir freundlichen Grüßen
Christian

 

[LotadaC]

Hmm...
die versteckte Kritik an der Unterstützung mußt Du Dir eigentlich selbst zuschreiben... zumindest ich habe mehrfach versucht, Dich auf genau diese Lösung (abgesehen vom Blinken) zu treiben. Deswegen auch insbesondere die Frage, ob der RC-In-Pin feststeht, oder man auch einen anderen nehmen könnte (insbesondere den INT0).

...Du willst jetzt also schnell auf Flanken des Signales (welches an einem sinnigen Pin anliegt) reagieren können, um den Timer zurückzusetzen/auszuwerten - was bietet sich da für Dich an?...

Andererseits hättest Du das natürlich ebenso über den PinChangeInterrupt eines beliebigen anderen Pins lösen können - aber die Konfiguration des INT0 schien mir für den Anfang einfacher...

Der Hinweis für den Rest des Algorithmus ist eigentlich hier versteckt:

...Mit der Entscheidung gegen die PWM-Ausgänge bist Du jetzt auch frei, was den einen Timer betrifft, jetzt mußt Du Dir überlegen, wie Du das Signal erfaßt, welche Pins für Dich in Frage kommen.
Der Timer ist immer(!) ein Zähler, der zählt immer(!) irgendwelche Takte. Das können entweder extern getriggerte Takte über den Tn-Pin, oder ein Takt der aus dem Systemtakt abgeleitet ist (Timer-Prescaler) sein, bei einigen Controller kann sogar auf einen asynchronenen (zum Systemtakt) separaten Quarz gekoppelt werden. Wenn Du die Frequenz des (ggf vorgeteilten effektiven) Timer-Taktes kennst, kannst Du also mit der Anzahl der Timer-Takte die verstrichene Zeit berechnen - oder andersrum: wenn Du auf irgend'ne konkrete Zeit prüfen/vergleichen willst, kannst Du ausrechnen, wieviele effektive Timer-Takte der Timer dazu getickt haben muß.
Wenn Du bei Deinem Signal also die High-Zeit "messen" willst (also die Timer-Takte zählen), mußt Du Dir Überlegen, wie Du auf entsprechende Flankenwechsel reagieren kannst, und im nächsten Schritt, wie der Timer dazu sinnig eingestellt werden könnte. Dadurch wird eventuell der Signal-Input-Pin festgelegt....

Ich hatte eigentlich von Dir eine Antwort auf die Frage (erstes Zitat) erwartet, um dann das Thema externer/PinChange-Interrupt anzusprechen, und danach die Lösung für den Timer zu entwickeln... bzw Dich entwickeln zu lassen!
Ich hätte Dir das ganze in ASM natürlich auch bereits nach eins/zwei Tagen fertig vor die Nase hauen können (wie zB bei Thomas's 7bit-UART - bei dem weiß ich aber, daß er das eigentlich nicht lernen will/muß, bzw daß ich von ihm im Gegenzug wenns drauf ankommt auch mal schnell 'ne Lösung in VB etc programmiert bekomme) - aber ich wollte Dich das selbst angehen lassen.

---

Hier mal der Übersichtlichkeit halber Dein Listing in lesbarer Form:

'******************************************************
'Projekt: RC Schalter mit TINY13
'Bascom-Version: 2.0.7.5
'
'Hardware:
'R/C-Kanal an PB1 (INT0)
'Schalt-LED an PB0
'Schalt-LED an PB2
'Schalt-LED an PB3
'Schalt-LED an PB4
'
'28.05.2014 Christian Tiedge
'******************************************************
'======================================================
'System-Einstellungen
'======================================================
'Definition für TINY13
$regfile "attiny13.dat"
$crystal = 600000
$hwstack = 16
$swstack = 8
$framesize = 24
'======================================================
'Konfigurationen
'======================================================
'Konfiguration der I/O-Ports´s
Config Portb.1 = Input
Config Portb.0 = Output
Config Portb.2 = Output
Config Portb.3 = Output
Config Portb.4 = Output
Config Portb.5 = Output
'Konfiguration des Timer0 mit Prescaler 8
Config Timer0 = Timer , Prescale = 8
'Konfiguration des INT0
Config Int0 = Change 'Interrupt bei jedem Flankenwechsel (0->1 und 1->0)
'======================================================
'Deklarationen
'======================================================
Dim Reading As Bit
Dim Rc_value As Byte
Dim Error As Bit
'======================================================
'Initialisierungen
'======================================================
'Zuweisung der Interrupt-Service-Routinen
On Int0 Rc_read
On Timer0 Rc_error
'Timer-Freigabe
Config Timer0 = Timer , Prescale = 8
Enable Timer0
Stop Timer0
'Freigabe der Interrupt-Routinen
Enable Int0
Enable Interrupts
'======================================================
'Hauptprogramm-Schleife
'======================================================
Do
'LCD-Ausgabe während der langen Lesepause...
If Reading = 0 Then
'PIN je nach Impulslänge umschalten
If Rc_value > 150 Then
'Mittelstellung
Portb.0 = 1 ' Schaltet LED an PORTB.0 an
Portb.2 = 1 ' Schaltet LED an PORTB.2 an
Portb.3 = 1 ' Schaltet LED an PORTB.3 an
Portb.4 = 1 ' Schaltet LED an PORTB.4 an
Else
Portb.0 = 0 'Schaltet LED bei nicht erfüllen aus
Portb.2 = 0
Portb.3 = 0
Portb.4 = 0
End If
If Rc_value > 200 Then
'Vollausschlag
Portb.0 = 0
Portb.2 = 0
Portb.4 = 0
Portb.3 = 0
Waitms 600
Portb.3 = 0
Portb.4 = 1
Waitms 300
Portb.3 = 1
Portb.4 = 0
Waitms 300
Portb.3 = 0
Portb.0 = 1
Portb.2 = 1
Waitms 300
Portb.2 = 0
Portb.0 = 0
Else
Portb.3 = 0
Portb.4 = 0
End If
End If 'reading = 0
Loop
End 'Programmende (nur formal)
'======================================================
'ISR für INT0 - R/C-Signal mit Timer lesen
'======================================================
Rc_read:
'Den Timer starten mit steigender Flanke
If Reading = 0 Then
Start Timer0
Reading = 1
'Den Timer stoppen mit fallender Flanke
Else
Stop Timer0
Rc_value = Timer0
Timer0 = 0
Reading = 0
End If
'Error-Bit rücksetzen
Error = 0
Return
'======================================================
'ISR für Timer0 - Fehlerhandling Timeroverflow
'======================================================
Rc_error:
'Error-Bit setzen
Error = 1
Reading = 0
Stop Timer0
Rc_value = 112 'Mittelwert
Return

Es fällt auf, daß Du den Timer ständig startest und anhälst. Das ist neben der Verwendung des TOV0-IRQ für die Fehlerbehandlung unnötig umständlich.
Sinniger wäre es doch so:
Bei jedem Timerüberlauf wird ja automatisch das Überlaufflag des Timers gesetzt - unabhängig davon ob der IRQ verwendet wird oder nicht. Du brauchst also den IRQ und das Error-Flag gar nicht, da die nötige Information bereits im TOV0-Flag steckt.
In der ISR des externen IRQ machst Du 'ne Fallunterscheidung über die Flanke. Wenns 'ne steigende Flanke war wird einfach der Timer zurückgesetzt und das TOV0-Flag gelöscht, wenns 'ne Fallende Flanke war wird überprüft ob das TOV0-Flag gesetzt ist. Wenn ja, kannst Du hauch hier Deine Werte für den Fehlerfall schreiben, wenn hingegen alles ok war liest Du einfach den Timer aus...
Wenn Du willst, kannst Du auch noch auf Werte <1ms oder >2ms prüfen. Alles andere fängt der Überlauf ab. Einziges Problem was so nicht behandelt ist ist, wenn der Sender während der High-Phase abgeschaltet wird, da so erst bei der Fallenden Flanke darauf reagiert wird.

 

[Tiedge]

Danke Dir für die schnelle Antwort.
Ich werde mir das jetzt noch mal genau ansehen. Ich werde auch weiter hin Assembler versuchen.
Wenn ich mein Programm neu bearbeitet habe, werde ich es wieder einstellen.
Hier schon mal der Schaltplan.

Mfg

 

[Tiedge]

Lotadac, das sollte keine Kritik an das Forum sein, ich weis auch das Du versucht hast mich darauf zu Stumpen.
Mir ist aber leider nicht das Licht an gegangen. Da ich jetzt aber eine Richtung habe, werde ich dies natürlich versuchen in Assmbler umzusetzen.

Ich muss zu geben das mit dem Sender abschalten in der High- Phase, habe ich nicht beachtet und es ist so wenn ich den Sender aus schalte egal in was für eine Phase, schaltet der Tiny auf High.
Wird mir das Problem mal genau ansehen müssen.

 

[Pirx]

Hallo Tiedge,

hinsichtlich deiner Schaltung empfehle ich dir, den RESET-Anschluss (PB5) nicht offen zu lassen, sondern über einen Pullup an 5V zu legen.

Weitere Infos siehe hier :
http://www.avr-praxis.de/forum/showthread.php?2375-Reset-beim-ATtiny13&highlight=RESET-Pin

Gruß
Pirx

 

[LotadaC]

Vorweg, das wurde ja bereits in de verlinkten Thread angedeutet, schadet ein zusätzlicher Pullup nicht wirklich... solange der resultierende Gesamtwiderstand (mit dem ggf parallelen internem Pullup) trotzdem durch den Programmer auf Gnd gezwungen werden kann.
Der interne Pullup des Reset-Pins ist üblicherweise hochohmiger als die der anderen Pins, da er für HV-Programming mit 12V klarkommen muß.

So, wenn man sich in den Datenblättern mal die interne Beschaltung der Pins ansieht, (alternate port functions) erkennt man als letztes Regelglied vor dem "Pullup-FET-Treiber" einen... ähm ... nennen wir ihn "Pullup-Override-Multiplexer". Wenn dort das Signal "PUOE - Pull-up Override Enable" high (1) ist, erhält der Pull-up-FET-Treiber das Signal "PUOV - Pull-up Override Value". Egal, was PORT, DDR und PUD verlangen.

Beim Mega48/88/... ist das einfach - in der entsprechenden Tabelle findet sich dann PUOE=RSTDSBL (also bei unprogrammierter Fuse eine "1") und PUOV=1. Solange dort also der Reset Reset ist, ist der interne Pullup mit Vcc verbunden.
Allerdings ist er mit 30 bis 80 KOhm angegeben - wenn man also 'ne hinreichend lange Leitung (Antenne) an dem Pin hat (Programmierbuchse), und hinreichend starke EM-Störungen vorliegen, könnte der interne Pullup zu schwach sein. Ansonsten braucht man eigentlich keinen externen Pullup.

Beim Tiny13 liegt da allerdings noch die Funktion des Debugwires mit drauf - und da komme ich irgendwie gar nicht mehr mit dem DB klar...

PUOE=((NOT(RSTDSBL)) AND (DWEN)
beides sind Fuses, da sagt jetzt aber 'ne Fußnote bei beiden "1 when the fuse is "0" (programmed)" Default sind beide Fuses unprogrammiert (1). Also DWire aus, und Reset enabled.
PUOE kann also nur dann 1 werden, wenn RSTDSBL nicht programmiert ist UND DWEN programmiert ist...
Dann würde PUOV=1 wirksam werden, der interne Pull-up aktiviert.

Mit einem ODER würde es mMn Sinn machen, aber der Punkt ist Doch ein UND... oder?

(Ich beziehe mich auf das 2535J-Datenblatt des Tiny13 (ohne A)- gibts ein neueres, bzw steht da was anderes drin?)

 

[Senpai]

Also im Datenblatt zum ATtiny13 steht das der extern zugeschaltete Pullup bei DW zwischen 10 und 20KOhm sein soll wennn verwendet.