Hallo liebes Forum :-) Ich hoffe ihr könnt mir mal etwas erklären. Ich habe ein Programm auf einem Attiny24 laufen, welches den PT2272 Funkdecoder immitiert. Allerdings mit Lernfunktion und zusätzlichem Ein-/Austaster. Nun habe ich während des Programmablaufs mehrere Zustände, die ich erfassen und Festhalten muss. Dazu habe ich ein Register, indem ich alle Zustände mit Bit Operationen speichere und wieder abrufe. Also ähnlich dem Statusregister. Da ist auch der manuelle Ein-/Austaster mit drin, der bei gedrückter Taste eine 1 in Registerposition "Bit 1" schreibt. Das Programm klappt auch wunderbar, nur konnte ich jetzt ein Komisches Phänomen feststellen. Beim Einschalten des Mikrocontrollers, also Spannung anlegen, ging die zu schaltende LED sporadisch mit an. Habe die Zustände, die das Programm durchläuft mit LEDs erfasst und komme nun zu dem Schluss, das alles so ist, wie es soll. Beim Startvorgang lösche ich nun immer dieses Register mit den Schaltzuständen, bevor das eigentliche Programm startet. Der Fehler trat bisher nicht mehr auf, nur kann mir jemand das Verhalten erklären? Wird der Controller evtl. durch die angelegte Spannung kurz nervös und rattert wild durch die Register? Danke schonmal :-) Ist auch keine große Frage :-) Gruß Daniel
Daniel schrieb: > Wird der Controller evtl. durch die angelegte Spannung kurz nervös und > rattert wild durch die Register? Das ist durchaus nicht unmöglich. Zwei potentielle Ursachen dafür kommen in Frage: 1) Zu langsames Ansteigen der Versorgungsspannung (z.B. durch zu groß gewählte Bypass-Kondensatoren). 2) Der Systemtakt benötigt zu lange, um stabil zu werden. Das kann durch 1) bedingt sein, aber auch andere Ursachen haben (z.B. bei Verwendung eines Quarzes: grenzwertige Bürdekapazitäten für den Quarz).
Nagut, ich benutze das interne Quarz. Das könnte eine Ursache sein. Oder eben der momentane Aufbau auf einem Steckbrett. Ich schalte momentan über Stecker ziehen ein und aus. Hätte ich oben mit reinschreiben sollen. Ist ja nicht ganz unwichtig :-( Fand es halt nur komisch das immer das Bit 1 in meinem Schaltregister gesetzt wird. (Das mache ich so, weil die Tasten für "An/Aus" und die "Lerntaste" entprellt werden.) Das Bit kann eigentlich nur in der Entprellroutine gesetzt werden, wird es aber nicht, wie ich mit Testweise eingefügtem Code, der bei dem "sbr"-Befehl eine weitere LED anschaltet geprüft habe.
Hast du Reset vernünftig beschaltet, oder fest auf +Ub gelegt? 10K gegen + und 100n gegen Masse ist ganz gängig. Das macht über den Daumen gepeilt eine Millisekunde Reset nach dem Einschalten, bis er losläuft. Bootloader können auch schon mal seltsame Nebenwirkungen haben, wie sie auf Evaluationboards zum seriellen Flashen verwendet werden.
Ich vermute, dass dein Taster beim Stromanlegen erstmal eine "1" liefert. Wie sieht denn die Schaltung aus? Ist da ein Kondensator am Taster, der eine kurze Zeit zum Aufladen benötigt?
:
Bearbeitet durch User
Meist werden beim Reset der Speicher (RAM) und die Mehrzweckregister (R1, R2, R3...) nicht auf einen festgelegten Wert gesetzt. Beim Programmcounter ist es klar, der muss an einer bekannten meist gleichen Adresse stehen, wenn es los gehen soll. Aber selbst der Stackpointer wird nicht von allen Mikrokontrollern quasi selbsttätig initialisiert. Special Function Register haben dagegen meist dokumentierte Startwerte, wobei einzelne Bits davon die Ausnahme zur Regel sein können. Wenn Du in C programmierst, trifft Dein Code auf geordnetere Verhältnisse. Das aber nur, weil vor Deinem Code der sogenannte Startup Code, den der Compiler mit anschleppt, abläuft.
Daniel schrieb: > Nagut, ich benutze das interne Quarz. Das würde mich nun doch sehr wundern. Ich kenne nämlich keinen µC, der einen internen Quarz besitzen würde...
Habe den Reset mit einem Widerstand gegen Plus. Masse mit 100nF Kondensator. Die Taster sind direkt mit dem Mikrocontroller verbunden und schalten Masse. Interner Pullup-Widerstand ist ebenfalls aktiviert. Daran sollte es eigentlich nicht liegen, denke ich mal. Komischerweise macht das Programm jetzt auch nach mehrmaligem An und Ausschalten keine mucken mehr. Lässt sich wunderbar über Funk an und ausschalten. Gehe also davon aus, das er die Register beim starten mit irgendwas beschreibt. Ist da etwas drüber bekannt, das die das machen? Hmm... Ist im übrigen Register 20. Danke, das ihr euch Zeit für mich genommen habt :-)
Daniel schrieb: > Ist da etwas drüber bekannt, das die das machen? Keine Ahnung. Und wenn schon. Nach dem Reset sind alle Register in einem eindeutigen Zustand. Und das auch fantastischerweise immer im selben. Die Inhalte sind im Datenblatt angegeben. Schalt den Brown Out Detect ein! Gerald B. schrieb: > Hast du Reset vernünftig beschaltet, oder fest auf +Ub gelegt? 10K gegen > + und 100n gegen Masse ist ganz gängig. Das macht über den Daumen > gepeilt eine Millisekunde Reset nach dem Einschalten, bis er losläuft. Das mag zwar sein, aber dafür ist die externe, nicht unbedingt notwendige Resetbeschaltung nicht da. Damit das Startverhalten verbessern zu wollen, ist schlichtweg Unsinn.
:
Bearbeitet durch User
Thomas E. schrieb: > Nach dem Reset sind alle Register in einem eindeutigen Zustand. NEEIIN! Es sind dann nur die Peripherie-Register in einem eindeutigen Zustand. Nicht aber die Register der MCU (also R0..R31). Deren Inhalt ist genauso zufällig wie der des SRAM insgesamt (tatsächlich handelt es sich bei diesen Registern am Ende auch bloß um SRAM, nur ihre Adresse macht diese paar SRAM-Zellen zu MCU-Registern). Leider suggeriert hier z.B. der Atmel-Simulator ein definiertes Verhalten dieser paar SRAM-Zellen (da bin auch ich auch mal drauf reingefallen), aber ein solches ist weder dokumentiert noch besteht es in der Realität. Aber wirklich blöd ist in diesem Zshg. vor allem die Mehrdeutigkeit des Begriffs "Register". Das sorgt für Missverständnisse, die nicht nötig wären.
> Begriffs "Register". Das sorgt für Missverständnisse
Es gibt doch die Unterscheidung 'Special Function Registers' und
'Working Registers', und Letztere starten eben undefiniert.
c-hater schrieb: > NEEIIN! Immer ruhig bleiben. Wen interessiert der RAM-Inhalt. Daß man den selbst auf einen definierten Zustand setzt oder dies dem freundlichen Compiler überlässt, ist doch wohl selbstverständlich. Ich kann das Problem das TO ohnehin nicht nachvollziehen. Wahrscheinlich fehlen sowieso nur wieder die Stützkondensatoren. c-hater schrieb: > da bin auch ich auch mal drauf > reingefallen Na, das ist aber genau die Dämlichkeit, die gerade du anderen immer vorhälst.
:
Bearbeitet durch User
S. Landolt schrieb: > Es gibt doch die Unterscheidung 'Special Function Registers' und > 'Working Registers' Klar. Bloß entfällt diese Möglichkeit zur Unterscheidung halt, sobald irgendjemand nur noch von Registern spricht. Capisce?
> ... ohnehin nicht nachvollziehen ...
Nun ja, er programmiert offenbar in Assembler und spricht von Register
20 - vielleicht hat er wirklich versäumt, dieses zu Beginn auf einen
definierten Zustand zu setzen.
Thomas E. schrieb: > Na, das ist aber genau die Dämlichkeit, die gerade du anderen immer > vorhälst. Nein. Der Unterschied ist: Ich LERNE. Und ich KANN lernen. Und ich WILL lernen. Und ich verwende seit 30 Jahren jedes Jahr sehr viel Zeit darauf, genau das zu tun. Und natürlich und völlig selbstverständlich lernt man am nachhaltigsten aus selbst gemachten Fehlern... Sofern man denn überhaupt lernen WILL. Und sich selber Fehler eingestehen kann. Also so ziemlich genau das Gegenteil von deiner verkorksten Persönlichkeit ist...
Ohoh... was ist denn hier los? :-( Trau mich schon garnicht mehr zu antworten :-( Stützkondensatoren hab ich ehrlich gesagt nicht drin, nur den an Masse halt. S. Landolt schrieb: > er programmiert offenbar in Assembler und spricht von Register > 20 - vielleicht hat er wirklich versäumt, dieses zu Beginn auf einen > definierten Zustand zu setzen. Ja, ich benutze Assembler. Soll zum Kennenlernen der CPU gut sein. Verstehe die ganzen Klammern bei C sowieso nicht :-D Mittlerweile hab ich Assembler auch lieb gewonnen. Wer weiß wie lange :-D Und ja, ich hab vergessen Register 20 auf einen deninierten Zustand zu setzen. Ich würde das Register einfach löschen mit "clr". Dann ist alles 0 und definiert, oder etwa nicht? 0 schon, aber auch definiert? Andererseits was soll man anders definieren als 0? Glaub ich hab meine Frage selbst beantwortet :-D Und der Rest von euch hat sich wieder lieb.
Daniel schrieb: > Ich würde das Register einfach löschen mit "clr". Dann ist alles 0 und > definiert, oder etwa nicht? Jepp, damit ist es definiert. > Andererseits > was soll man anders definieren als 0? Das kann in bestimmten Fällen durchaus schonmal Sinn ergeben. Hängt einfach von der Anwendung ab. Bei R20 aber kein Problem. "ldi R20,immediate_value" tut den Job und ist in keiner Hinsicht teurer als ein "clr R20". Blöder kommt es schon bei R <16. Da steht "ldi" leider nicht zur Verfügung...
Aber bei Registern unter R16 könnte man ja: ldi R20,immediate_value mov R15,R20 machen? Oder auch gleich clr R15. Und immediate_Value muss ich vorher als .def immediate_Value = 0x00 meinetwegen definieren, ja? Oder meinetwegen 0x20 bei speziellen Sachen? Wieder was gelernt :-)
Das muss ja nicht immer Null sein, könnten auch beliebige Status sein.
Na dann mach' noch 2 Stütz-C's auf kürzestem Wege zwischen Masse und +5V am µC. Einen KerKo 100n und einen Elko 47µ. Ob ein Stützkondensator wirklich fehlt, merkt man nicht so ohne weiteres. Nur mit aufwendigen Messungen. Und wenn es "kippelt" muß das auch nicht zwangsläufig regelmäßig auftreten. Ein "zu viel" gibt es dabei nicht, aber sehr wohl ein "zu wenig". Bei den Centbeträgen verbaue ich die lieber großzügig. Das ist noch eine Angewohnheit aus der Zeit der TTL-Gräber ;-)
Daniel schrieb: > Aber bei Registern unter R16 könnte man ja: > ldi R20,immediate_value > mov R15,R20 > machen? Natürlich. > Und immediate_Value muss ich vorher als > .def immediate_Value = 0x00 meinetwegen definieren, ja? Nein, das ist nicht zwingend.
c-hater schrieb: > Also so ziemlich genau das Gegenteil von deiner verkorksten > Persönlichkeit ist... https://www.youtube.com/watch?v=2_0zwbNpJvI
Oweh, bin ich ein SEHR altmodischer AVR-ASM-Fummler? Ich habe (gewollt) noch nie eines der "General Purpose"- Register R0...31 ohne eine klare Wert-Zuweisung benutzt. Also nie so ein Problem gehabt... VERGESSEN hab ich es natürlich schon mal - da sollte es aber meist ein Wert != NULL sein... Dass der Stackpointer (Lo/Hi) gleich zu Anfang auf RAMEND (Lo/Hi) gesetzt werden muss, ist bei AVR wirklich doof, aber in jedem Code-Beispiel vermerkt. Merkt man aber, da zuverlässig GARNIX funktioniert... Habe mir auch nie Gedanken über die ultimativ-optimale NULL-Zuweisung gemacht: CLR Rx ist jedenfalls IMMER OK, da eine LDI-Zuweisung erst ab R16 möglich ist... Ansonsten fällt mir kein I/O-Register ein, dass keinen Standard-Wert hat. Gibt es eigentlich welche != NULL?
Jacko schrieb: > Ansonsten fällt mir kein I/O-Register ein, dass keinen > Standard-Wert hat. Gibt es eigentlich welche != NULL? Ja, die Register für den z.B. Uart, sind default-mäßig auf 8N1 bei den AVRs eingestellt ;) EEPROM Kontrollregister hat auch das ein und andere Bit, dass beim Start nicht definiert ist.
> Dass der Stackpointer (Lo/Hi) gleich zu Anfang auf > RAMEND (Lo/Hi) gesetzt werden muss, ist bei AVR > wirklich doof, > Gibt es eigentlich welche != NULL? Zum Beispiel eben genau der Stackpointer, der bei allen neueren Typen auf RAMEND gesetzt ist.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.