Wie beim ATtiny zum Reset-Vektor springen

[tsilly (Gast)]

Hallo,
irgendwie sehe ich den Wald vor lauter Bäumen nicht.

Wie springe ich beim ATtiny in der Software (in C programmiert) zum 
Reset-Vektor?

[Peter D. (peda)]

Mit einem Watchdog-Reset.
Ein Call nach 0x0000 ist nicht ausreichend (keine Register werden 
resettet).

[tsilly (Gast)]

Peter D. schrieb:
> Mit einem Watchdog-Reset.

Heißt das, den Watchdog disabeln und dann zurücksetzen?

[Dieter F. (Gast)]

https://www.microchip.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_softreset.html

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tsilly schrieb:
> Heißt das, den Watchdog disabeln und dann zurücksetzen?
Den Watchdog einschalten, nicht zurücksetzen und abwarten, bis das 
Unvermeidliche passiert.

[H.Joachim S. (crazyhorse)]

Es gibt nur selten einen guten Grund, tatsächlich einen Reset aus der 
Software heraus auszuführen. Liegt bei dir tatsächlich so ein Fall vor?

[tsilly (Gast)]

Lothar M. schrieb:
> Den Watchdog einschalten, nicht zurücksetzen und abwarten, bis das
> Unvermeidliche passiert.

Ich möchte aber ohne zu warten direkt einen Software-Reset durchführen.

[tsilly (Gast)]

H.Joachim S. schrieb:
> Liegt bei dir tatsächlich so ein Fall vor?

Ja.

[Klaus (Gast)]

tsilly schrieb:
> Wie springe ich beim ATtiny in der Software (in C programmiert) zum
> Reset-Vektor?

Liefert dir deine C-Librarie keine Funktion dafür? Die für meine 
Prozessoren hat so was.

MfG Klaus

[H.Joachim S. (crazyhorse)]

tsilly schrieb:
> Ich möchte aber ohne zu warten direkt einen Software-Reset durchführen.

Die kleinste watchdog-Zeit ist glaube ich 2ms - ist das zu lang?

[Einer K. (Gast)]

tsilly schrieb:
> Ja.

Ja?
Würdest du mir/uns den Grund mitteilen?

[tsilly (Gast)]

H.Joachim S. schrieb:
> Die kleinste watchdog-Zeit ist glaube ich 2ms - ist das zu lang?

Nach dem was ich in den Beschreibungen sehe, ist die kleinste Zeit 15 
ms.

Ich benötige eine Zeit von < 1 ms.

[Einer K. (Gast)]

Nun sach doch bitte mal: Warum?

Als Anreiz liefere ich dir deine (falsche) Lösung für dein (vermutlich) 
irrationales Problem:

void softReset()
{
  // Vorbereitungen treffen
  cli();
  
  ((void(*)(void))0)(); // Resetvektor anspringen
}

[tsilly (Gast)]

Arduino Fanboy D. schrieb:
> Nun sach doch bitte mal: Warum?

Ich überwache mehrere Funktionen, die Eingangswerte liefern. Sollte nur 
eine dieser Funktionen nicht ausgeführt werden, dann bleiben Werte ggf. 
hängen und Ausgangsdaten können falsch berechnet werden. Als Folge davon 
kann ein großer Teil der Schaltung in ein Stück Kohle verzaubert werden. 
Das Ganze befindet sich in einem Umfeld, wo auch stärkere EMV-Ereignisse 
auftreten können.

[Peter D. (peda)]

tsilly schrieb:
> wo auch stärkere EMV-Ereignisse
> auftreten können.

Ich finde es immer wieder seltsam, wie EMV als Begründung für dubiose 
Software-Hacks herangzogen wird.

Essentiell für EMV ist zuallererst eine ordentliche Schutzbeschaltung 
der VCC und aller IOs, sowie eine durchdachte Massefüherung. Danach 
kommt dann natürlich eine sorgfältige Softwareplanung, Erstellung und 
Testung.
Und das im Einschaltmoment (alle IOs des MC sind floatend) für 
definierte Zustände der angeschlossenen Hardware zu sorgen ist, brauche 
ich wohl nicht zu erwähnen.

[H.Joachim S. (crazyhorse)]

tsilly schrieb:
> Ich überwache mehrere Funktionen, die Eingangswerte liefern. Sollte nur
> eine dieser Funktionen nicht ausgeführt werden, dann bleiben Werte ggf.
> hängen und Ausgangsdaten können falsch berechnet werden. Als Folge davon
> kann ein großer Teil der Schaltung in ein Stück Kohle verzaubert werden.
> Das Ganze befindet sich in einem Umfeld, wo auch stärkere EMV-Ereignisse
> auftreten können.

Also doch wie vermutet: Du brauchst keinen reset.

[Einer K. (Gast)]

tsilly schrieb:
> Ich überwache mehrere Funktionen, die Eingangswerte liefern. Sollte nur
> eine dieser Funktionen nicht ausgeführt werden, dann bleiben Werte ggf.
> hängen und Ausgangsdaten können falsch berechnet werden.

Wie kommst du auf die lustige Idee, dass deine Eingangsauswertung im 
(hypothetischen) Fehlerfall noch funktioniert, und der Soft Reset dann 
durchgeführt wird?

[Wie immer (Gast)]

H.Joachim S. schrieb:

> Also doch wie vermutet: Du brauchst keinen reset.

Was will jemand mit einer solchen Aussage bezwecken, nachdem er das 
Problem geschildert bekam?

-Ist das nur eine blöde Reaktion?
-Soll dadurch Streit provoziert werden?
-Hat der Antwortende eine bessere Lösung?

[HildeK (Gast)]

Arduino Fanboy D. schrieb:
> Wie kommst du auf die lustige Idee, dass deine Eingangsauswertung im
> (hypothetischen) Fehlerfall noch funktioniert, und der Soft Reset dann
> durchgeführt wird?

... und diese Fehler der Eingangswerte behebt?

@tsilly (Gast): Den einzigen Weg, den ich kenne, ist einen GPIO mit dem 
Resetpin zu verbinden und den dann zu bedienen.

[tsilly (Gast)]

Arduino Fanboy D. schrieb:
> Eingangsauswertung im
> (hypothetischen) Fehlerfall noch funktioniert

Sie könnte funktionieren, wenn nur die Eingangswerteermittlung ausfällt. 
Damit ist dann nicht mehr sichergestellt, dass ich mit "echten" Werten 
arbeite.

Aber wie auch immer, über eine funktionierende Möglichkeit zum 
sofortigen Reset würde ich mich immer noch freuen.

[TestX (Gast)]

@tsilly

Deine "lösung" mit einem reset ist absoluter Unsinn...sobald es zu dem 
fall kommt dass irgendwelche Register/ram kippen kann man nur noch in 
einen sicheren Zustand springen...alles andere führt zu 
unvorhersehbarem Verhalten (wird der Reset o.ä. überhaupt noch korrekt 
ausgeführt etc etc).

Finde die Ursache für dein  Problem und beseitige diese! Falls deine 
Audgangsbeschaltung gefährliche Zustände annehmen kann müssen diese 
ausgeschlossen werden. EMV ist kein Problem für Profis...

[tsilly (Gast)]

TestX schrieb:
> kippen kann man nur noch in
> einen sicheren Zustand springen

Richtig, genau das soll erreicht werden, indem alles wieder bei Null 
beginnt und sämtliche kruden Werte/Zustände gelöscht werden.

[Sebastian R. (sebastian_r569)]

HildeK schrieb:
> Den einzigen Weg, den ich kenne, ist einen GPIO mit dem
> Resetpin zu verbinden und den dann zu bedienen.

Was aber auch kein sicherer Reset ist. Der Resetimpuls muss eine 
bestimmte Länge haben, die aber länger ist, als der Pin auf Ground ist, 
bevor der Reset zuschlägt und ihn auf Hi-Z bringt.

Zusammen mit einem Resetcontroller oder Monoflop würde das aber 
funktionieren.

[Einer K. (Gast)]

tsilly schrieb:
> über eine funktionierende Möglichkeit zum
> sofortigen Reset würde ich mich immer noch freuen.

Was gefällt dir an meinem Vorschlag nicht?

Er entspricht doch exakt deiner Anforderung!

Siehe:
tsilly schrieb:
> Wie springe ich beim ATtiny in der Software (in C programmiert) zum
> Reset-Vektor?

[H.Joachim S. (crazyhorse)]

Wie immer schrieb:
> Was will jemand mit einer solchen Aussage bezwecken, nachdem er das
> Problem geschildert bekam?
>
> -Ist das nur eine blöde Reaktion?
nein
> -Soll dadurch Streit provoziert werden?
nein
> -Hat der Antwortende eine bessere Lösung?
ja, wahrscheinlich. Und es wurde ja auch schon mehrfach gesagt: Die 
Ursache(n) beseitigen.

Ansonsten: wenn der Prozessor an sich noch läuft (und das muss er ja um 
einen gezielten reset aus dem Programmm heraus auszuführen), kann man an 
der Stelle genausogut die Fehler behandeln so dass eben nichts 
kritisches passiert. Selbst wenn der Reset erst mal ne Lösung wäre - 
nichts garantiert, dass im komplett gestörten Umfeld die Programmstelle 
tatsächlich ausgeführt wird. Irgendwann fällt dir diese Scheinlösung auf 
die Füsse.

Tatsächlich gefährliche Zustände für die nachfolgende Schaltung sollte 
man durch Hardware verriegeln, ich sage jetzt mal als primitives 
Beispiel die Ansteuerung einer diskreten H-Brücke durch Portpins.

[Peter D. (peda)]

Ich hab auch in einigen Anwendungen eine Fehlerüberwachung. Aber sie 
setzt natürlich direkt die angeschlossene Hardware in einen sicheren 
Zustand und nicht alle IOs auf floatend (Resetzustand).
Und falls man bestimmte Variablen in einen Initzustand bringen will, 
dann macht man das mit einer Init-Funktion direkt. Das geht dann auch 
schneller, als den gesamten RAM zu schreddern.

[HildeK (Gast)]

Sebastian R. schrieb:
> Zusammen mit einem Resetcontroller oder Monoflop würde das aber
> funktionieren.

... oder mit einer Diode, die dann den eh vorhandenen Kondensator 
entlädt. Das verhält sich dann genauso wie beim Power-Up.

[Karl B. (gustav)]

Hi,
das WDR-timeout setzt nicht den immer noch autonom taktenden µP außer 
Kraft.
Wenn totaler Reset, dann Hardware-Reset. Also Stop des Taktgebers.
Warten, bis Oszillator sauber eingeschwungen ist, dann SW von vorne.
Das geht vielleicht mit HW-Beschaltung am Reseteingang.

tsilly schrieb:
> Ich überwache mehrere Funktionen, die Eingangswerte liefern. Sollte nur
> eine dieser Funktionen nicht ausgeführt werden, dann bleiben Werte ggf.
> hängen und Ausgangsdaten können falsch berechnet werden.

Die Sache kenne ich, wenn ein angeschlossenes Gerät zum Beispiel über 
UART
"Mist" zeigt. WDR ist da so wie so obligatorisch. Dann möchte ich auch 
den UART zusätzlich neu initialisieren.
Bei einem meiner Messgeräteprogramme wird zyklisch der UART und der 
Timer wieder initialisiert. Die Idee kam von jemandem, der einen 
Drehzahlmesser für sein Auto mit ATMEL AVRs realisierte. Mit jeder Menge 
Fehlerabfang-Routinen.
Momang, muss das Prog. erst noch raussuchen.

ciao
gustav

[Bitte einen Namen eingeben (Gast)]

Noch eine Anmerkung:
Watchdog und Betätigung des Reset-Pins funktioniert bei allen ATtinys. 
Die neuen ATtinys x17 und x07 bieten auch ein Software-Reset.

[Oliver S. (oliverso)]

tsilly schrieb:
> Ich überwache mehrere Funktionen, die Eingangswerte liefern. Sollte nur
> eine dieser Funktionen nicht ausgeführt werden, dann bleiben Werte ggf.
> hängen und Ausgangsdaten können falsch berechnet werden.

Aus was für einem Grund sollte da eine der Funktionen nicht ausgeführt 
werden? Und warum gehst du davon aus, daß zwar Eingangsfunktionen nicht 
immer ausgeführt werden, deine (potentielle) Resetfunktion aber 
garantiert immer?

Fragen über Fragen...

Ansonsten wurde schon alles gesagt. Die AVRs können keinen Reset per 
Software, nur per Hardware.

Wenn die Watchdogzeit zu lang ist, brauchst du eine externe Resetlogik, 
die per Ausgangspin getriggert wird.

Oliver

[spess53 (Gast)]

Hi

>Die neuen ATtinys x17 und x07 bieten auch ein Software-Reset.

Sag doch gleich, das das die Neuen aus der tinyAVR 1-serie das können.

MfG Spess

[spess53 (Gast)]

Hi


Nachtrag: Die megaAVR 0-serie kann auch Softwarereset.

MfG Spess

[tsilly (Gast)]

Arduino Fanboy D. schrieb:
> Was gefällt dir an meinem Vorschlag nicht?

Mein optimierender C-Compiler kommt damit leider nicht klar.

Jetzt habe ich aber eine offensichtlich funktionierende Lösung:

asm volatile (" rjmp 0");

[Tim T. (tim_taylor)]

Peter D. schrieb:
> Mit einem Watchdog-Reset.
> Ein Call nach 0x0000 ist nicht ausreichend (keine Register werden
> resettet).

Abgesehen davon ist ein rjmp 0 totaler Blödsinn für dein Vorhaben.

[Oliver S. (oliverso)]

tsilly schrieb:
> Mein optimierender C-Compiler kommt damit leider nicht klar.

Welchen wundersamen C-Compiler benutzt du denn?

Oliver

[Jitterer (Gast)]

Krass. Da weiss man, dass man EMV Probleme hat und will nur noch Werten 
nach einem Reset glauben...

Ich wuerde generell keinen Werten glauben bevor ich weiss keine EMV 
Probleme mehr zu haben.

[tsilly (Gast)]

Jitterer schrieb:
> Ich wuerde generell keinen Werten glauben bevor ich weiss keine EMV
> Probleme mehr zu haben.

In welcher Umgebung betreibst Du denn Deine Geräte ganz ohne 
EMV-Beeinflussung, Gewitter und Höhenstrahlung?

[H.Joachim S. (crazyhorse)]

tsilly schrieb:
> Jetzt habe ich aber eine offensichtlich funktionierende Lösung:
>
> asm volatile (" rjmp 0");

Du willst offensichtlich auf nichts hören, auch gut. Viel Erfolg.

[tsilly (Gast)]

H.Joachim S. schrieb:
>> asm volatile (" rjmp 0");
>
> Du willst offensichtlich auf nichts hören, auch gut. Viel Erfolg.

Mehr als funktionieren kann es nicht:
In der Software passiert hiermit das Gleiche wie bei einem 
Watchdog-Reset.

[Tim T. (tim_taylor)]

Einfach mal zum Spaß für den TO, was ist der Unterschied Zwischen:

asm volatile ("rjmp 0");

und

asm volatile ("clr r30");
asm volatile ("clr r31");
asm volatile ("ijmp");

Und warum reicht die 2. Variante immer noch nicht?

[Tim T. (tim_taylor)]

Ach was solls, ich hab eh keine Lust:

Der Resetvektor nullt noch das SREG und setzt den Stackpointer.

Aber alle Register behalten ihre Werte, ist also kein definierter 
Anfangszustand!

[Dieter F. (Gast)]

tsilly schrieb:
> In der Software passiert hiermit das Gleiche wie bei einem
> Watchdog-Reset.

Nomen est omen.

[Einer K. (Gast)]

Meine Oma sagte schon:
> Wer in die falsche Richtung läuft,
> der braucht sich nicht zu beeilen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tsilly schrieb:
> Jetzt habe ich aber eine offensichtlich funktionierende Lösung:
> asm volatile (" rjmp 0");
Du hast den Abschnitt des Datenblatts, in dem beschrieben wird, was der 
Reset ausser dem Sprung nach Adresse 0 sonst noch alles macht, offenbar 
nicht angesehen. Oder nicht verstanden.

tsilly schrieb:
> Das Ganze befindet sich in einem Umfeld, wo auch stärkere
> EMV-Ereignisse auftreten können.
Dann mach das Design in Hardware und Software dagegen robust. Erwarte 
z.B. in deinem Programm nicht, dass der gelesene Eingangswert stimmt. 
Gehe davon aus, dass da gerade so ein EMV-Ereignis stattfand.

> Ausgangsdaten können falsch berechnet werden. Als Folge davon kann ein
> großer Teil der Schaltung in ein Stück Kohle verzaubert werden.
Dann solltest du per Hardware dafür sorgen, dass das nicht passiert. 
Oder fackelt dir dann dein System ab, wenn der Debugger mal auf einen 
Breakpoint läuft oder der Programmierer noch einen Fehler im Programm 
hat?

[H.Joachim S. (crazyhorse)]

Lothar, lass es gut sein, hat keinen Sinn.

[Jitterer (Gast)]

> Höhenstrahlung?

Dieser kann man nur duch rad-hard typen ausweichen.
Oder allenfalls der orientierung.
Ich wuerd den code also zuverlaessiger machen. Also

-nur 1 loop.
-alle Funktionalitaeten immer vor Gebrauch initialisieren.

Alles andere wird aufwendig

[aha (Gast)]

Sebastian R. schrieb:
> Was aber auch kein sicherer Reset ist. Der Resetimpuls muss eine
> bestimmte Länge haben, die aber länger ist, als der Pin auf Ground ist,
> bevor der Reset zuschlägt und ihn auf Hi-Z bringt.

Was ist denn das für ein Unsinn. Der Controller macht einen Reset, 
schaltet den Port auf high und dann ist der Reset nicht lang genug. 
Hauptsache was gegenan quarken und wenn es noch so schwachsinnig ist.

[Frank M. (ukw) (Moderator)]

tsilly schrieb:
> Mein optimierender C-Compiler kommt damit leider nicht klar.

Übersetzt:

Du hast einen Fehler im Programm und willst ihn mit einem Soft-Reset 
kaschieren.

Und nein: Dein C-Compiler ist höchstwahrscheinlich nicht dafür 
verantwortlich. Viele Programmierfehler kommen erst ans Tageslicht, wenn 
man die Optimierung einschaltet.

[Einer K. (Gast)]

Frank M. schrieb:
> Übersetzt:
>
> Du hast einen Fehler im Programm und willst ihn mit einem Soft-Reset
> kaschieren.

Naja...
Hier schmeckt dem Compiler der anonyme FuncionPointer scheinbar nicht.
Beitrag "Re: Wie beim ATtiny zum Reset-Vektor springen"

Wie auch immer... ist sowieso ein Irrweg.

[Thomas (kosmos)]

Man kann sein Programm so gestalten das am Anfang eine Schleife 
durchläuft und jede RAM-Zelle mit 0 beschreibt.

Einen Reset kann man dann auch so durchführen in dem man den 
Programmcounter auf 0 setzt, ergo starten das Programm am Anfang und 
löscht dann alles was im RAM steht.

Meiner Meinung hat man was falsch programmiert wenn der µC hängen 
bleibt, habe den Watchdog Reset bisher nur verwendet um den µC aus einem 
Sleep Mode aufzuwecken aber nicht weil der µC hängenbleibt.

Würd mich aber trotzdem mal in welchem Fall der WD bei euch angeschlagen 
hat.

[mr. mo (Gast)]

Frank M. schrieb:
> Und nein: Dein C-Compiler ist höchstwahrscheinlich nicht dafür
> verantwortlich. Viele Programmierfehler kommen erst ans Tageslicht, wenn
> man die Optimierung einschaltet

Das ist so wahr. könntemirniepassieren

[CK (Gast)]

Thomas O. schrieb:
> Würd mich aber trotzdem mal in welchem Fall der WD bei euch angeschlagen
> hat.

Wenn man mit State-Maschinen arbeitet und nicht alle Eventualitäten 
berücksichtigt hat, und die Software dadurch in einen Dead-Lock gerät.

Sprich durch Bugs in der Software.

Das durch Kosmische Strahlung ein Bit in einem Register umkippt ist um 
eine Größenordnungen seltener.

[Tim T. (tim_taylor)]

Arduino Fanboy D. schrieb:
> Frank M. schrieb:
>> Übersetzt:
>>
>> Du hast einen Fehler im Programm und willst ihn mit einem Soft-Reset
>> kaschieren.
>
> Naja...
> Hier schmeckt dem Compiler der anonyme FuncionPointer scheinbar nicht.
> Beitrag "Re: Wie beim ATtiny zum Reset-Vektor springen"
>
> Wie auch immer... ist sowieso ein Irrweg.

Stimmt, ist zwar nen Irrweg, aber wenn mans richtig macht, sollte es 
gehen:

 void (*fp)(void) = 0x0000;

 fp();

Und wieder die Büchse der Pandora geöffnet^^ Muhahaha...

[tsilly (Gast)]

Wenn ein Sprung zum Reset-Vektor ein Irrweg sein soll, dann wäre es 
interessant zu erfahren, weswegen in µCs die Reset-Vektoren extra 
ausgewiesen werden?
Man findet bei vielen µCs auch einen speziellen Befehl, der sich RESET 
nennt. Wollen uns die µC-Hersteller damit nur in die Irre leiten oder 
steckt vielleicht doch ein Sinn dahinter?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tsilly schrieb:
> weswegen in µCs die Reset-Vektoren extra ausgewiesen werden?
Hast du jetzt endlich den Abschnitt "Reset" im Datenblatt gelesen?

Der allerletzte Schritt der Reset-FSM ist es, an die Resetadresse zu 
springen.
Du kannst im Fehlerfall überall hinspringen wo du willst. Wenn du 
meinst, es bringt dir irgendwas, in einem voll konfigurierten µC an die 
Resetadresse zu springen und zu versuchen, bereits initialisierte und 
laufende(!) Hardware nochmal zu initialisieren, dann tu das.

Der Witz daran ist aber, dass es eben manche Hardwareregister gibt, die 
du nur nach einem richtigen Reset neu oder anders beschreiben kannst.

> Man findet bei vielen µCs auch einen speziellen Befehl, der sich RESET
> nennt.
Mit diesem Befehl werden dann aber eben auch die Hardwareregister auf 
die Initialwerte zurückgesetzt, weil damit die Resetstatemachine des µC 
angestoßen wird.

> oder steckt vielleicht doch ein Sinn dahinter?
Natürlich steckt ein Sinn dahinter. Nämlich der, dass eben die 
Resetmaschine neben vielen anderen Register auch die Register des 
Programmcounters auf 0 setzt.

Also kurz und gut: wenn du meinst, dass es deinem Programm hilft, wenn 
du nach einem Fehler irgendwo hinspringst, dann tu das. Mir bleibt die 
Hoffnung, dass ich dieses Gerät nie in die Finger bekomme...

[Jitterer (Gast)]

Wie schon erwaehnt wurde ist ein Sprung zum Resetvektor kein Reset. Denn 
ein Reset initialisiert die Hardware, gemaess Datenblatt. Was ein Sprung 
zum Resetvektor eben nicht tut.

Egal, mach mal. Vielleicht bringt's ja was. Und sonst eben nicht.

[tsilly (Gast)]

Lothar M. schrieb:
> Mir bleibt die
> Hoffnung, dass ich dieses Gerät nie in die Finger bekomme...

Oh, da ist aber schon einiges mit verschiedenen µCs draußen (und bald 
auch was mit dem ATtiny).

Was solls, schaue Dir einfach keine Shows mehr im Fernsehen an, kaufe 
Dir nichts mehr zu essen, meide Krankenhäuser und lass zukünftig auch 
das Autofahren sein. Dann bist Du auf der sicheren Seite.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tsilly schrieb:
> Was solls, schaue Dir einfach keine Shows mehr im Fernsehen an, kaufe
> Dir nichts mehr zu essen, meide Krankenhäuser und lass zukünftig auch
> das Autofahren sein.
Jetzt bin ich als Anwender also selber Schuld dran, dass ich Geräte 
kaufe, worauf vermurkste Software läuft. Kann man so sehen...

> Dann bist Du auf der sicheren Seite.
Du hast das mit dem Fliegen vergessen, wo sich Software neuerdings 
auch drauf verlässt, dass Sensoren immer und zu jeder Zeit ungestörte 
Signale und Werte bringen.

[tsilly (Gast)]

Lothar M. schrieb:
>> Man findet bei vielen µCs auch einen speziellen Befehl, der sich RESET
>> nennt.
> Mit diesem Befehl werden dann aber eben auch die Hardwareregister auf
> die Initialwerte zurückgesetzt, weil damit die Resetstatemachine des µC
> angestoßen wird.


Du willst mir offensichtlich durch die Blume erklären, dass der ATtiny 
murks ist und ich besser einen anderen µC (z.B. PIC) genommen hätte.


Lothar M. schrieb:
> Du hast das mit dem Fliegen vergessen

Außer bei den Mischern, die die Gase zusammensetzen, die zum Schweißen 
benötigt werden, habe ich hier keine Elektroniken entwickelt.
Jedenfalls wünsche ich Dir in dieser Beziehung für die Zukunft viel 
Glück.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tsilly schrieb:
> durch die Blume erklären, dass der ATtiny murks ist
Nein, er passt einfach nicht zu deinem Programmierstil. Denn der 
benötigt ja offenbar genau diesen "Softwarereset", den der ATtiny in 
deiner gewünschten Art nicht bietet.
Das ist schade, aber wie bei allen anderen ICs: nimm eines, das deine 
Anforderungen und deine Aufgaben besser erfüllt. Und wenn die 
Bestellbezeichnung dieses ICs dann mit PIC beginnt, dann ist das eben 
so.

tsilly schrieb:
> Jedenfalls wünsche ich Dir in dieser Beziehung für die Zukunft viel Glück.
Danke dir, ich mir und dir auch.   ;-)

[Thomas S. (selli69)]

Schon erstaunlich, wie Leute wie der TO darauf reagieren, wenn aus 
berufenem Munde berechtigte Bedenken am Vorhaben des TO geäußert und 
diese auch noch mit fachlich richtigen Argumenten untermauert werden. Da 
wird dann auf Bockig geschaltet und harte Beratungsresistenz 
demonstriert.

Ich kanns ehrlich gesagt nicht verstehen, denn mich haben solche 
Einwände bereits mehrmals dazu bewogen bereits getroffene 
Designentscheidungen nochmals zu überdenken, einen Teil davon in die 
Tonne zu kloppen und Dinge anders anzugehen. Dies immer zu meinem 
eigenen Vorteil. Vom Lerneffekt ganz zu schweigen.

Warum fühlen sich heutzutage so viele persönlich angegriffen, wenn 
andere einen sachlich korrekten Einwand haben und dieser das Verwerfen 
eigener, vermutlich als Zentrum der Weisheit angenommener, Ideen 
bedeuten?

Warum werden auf den Hinweis, dass es nichts bringt den einen Pfusch mit 
dem nächsten auszukompensieren die Krallen ausgefahren?

Ist der Modus Oprandi "Befindlichkeit über Fakt" nun auch schon in der 
Welt der Elektronik angekommen? Es scheint so. Traurig, sehr traurig...

[tsilly (Gast)]

Thomas S. schrieb:
> Da
> wird dann auf Bockig geschaltet und harte Beratungsresistenz
> demonstriert.

Oder einfach ein Widerspruch zwischen dem erkannt, was in wochenlangen 
Messreihen ermittelt wurde und was hier als Meinung (natürlich auch mit 
massivem technischen Hintergrundwissen) kundgetan wird.

Thomas S. schrieb:
> Warum werden auf den Hinweis, dass es nichts bringt den einen Pfusch mit
> dem nächsten auszukompensieren die Krallen ausgefahren?

Es wäre Pfusch, wenn die Maßnahme mit dem Reset alleiniges Mittel wäre, 
mit dem die Software stabil gehalten werden soll.
Es ist aber nur ein kleiner Teil von einem ganzen Bündel von Maßnahmen 
(der aber offensichtlich mit dem ATtiny nicht besonders gut 
funktioniert), die in Hard- und Software umgesetzt werden.

[Ike (Gast)]

Das kann man gut bei Wikipedia(Kompetenzstufenentwicklung) nachlese.
bzw. einen Ansatz finden

[Karl B. (gustav)]

Jitterer schrieb:
> Wie schon erwaehnt wurde ist ein Sprung zum Resetvektor kein Reset.

Hi,
allgemeines Missverständnis.
Der Resetvector wird in die Liste der Interruptvectoren mit $0000 
eingereiht, obwohl er im strengen Sinne kein "Vector" ist. Das kursiert 
in verschieden Tutorials immer noch so. Hier ist aber was ganz anderes 
gemeint.
Ein Power OFF Reset.

ciao
gustav

[Thomas S. (selli69)]

tsilly schrieb:
> Oder einfach ein Widerspruch zwischen dem erkannt, was in wochenlangen
> Messreihen ermittelt wurde und was hier als Meinung (natürlich auch mit
> massivem technischen Hintergrundwissen) kundgetan wird.

Und da isses wieder. Die Annahme, man läge mit der eigenen Sicht 
richtig, nur weil man bereits "wochenlang" am offensichtlich 
fehlerhaften (EMV-)Design herum gemessen hat. Sich einzugestehen, dass 
man u.U. einen Irrweg beschritten hat wird dabei nicht einmal in 
Betracht gezogen.

tsilly schrieb:
> Es wäre Pfusch, wenn die Maßnahme mit dem Reset alleiniges Mittel wäre,
> mit dem die Software stabil gehalten werden soll.

Gut, dann sprechen wir also von einem nur teilweise-Pfusch. Warum ein 
Reset, abgesehen vom PowerOn und Watchdogüberlauf, eine schlechte Idee 
ist haben hier einige lang und breit erklärt. Mit Stabilität hat das 
Ganze dann nämlich nichts mehr zu tun. In unserem Unternehmen ist, was 
SW-Design betrifft, eine der obersten Regeln: "Das Leben muss immer 
weiter gehen (zumindest so lange der PC des uC noch zählt)". Ein 
(SW-)Reset beendet jegliches "Leben".

tsilly schrieb:
> Es ist aber nur ein kleiner Teil von einem ganzen Bündel von Maßnahmen
> (der aber offensichtlich mit dem ATtiny nicht besonders gut
> funktioniert), die in Hard- und Software umgesetzt werden.

Naja, wenigstens kommt jetzt mal ein Anflug davon, dass man sich bei der 
Wahl des uC wohl vertan hat. Auch wenn das eine Fehlannahme ist, denn SW 
Reset braucht keiner.

[tsilly (Gast)]

Thomas S. schrieb:
> Auch wenn das eine Fehlannahme ist, denn SW
> Reset braucht keiner.

Wenn ich das jetzt glauben soll, dann müssten ja viele µC-Hersteller 
ganz schön doof sein, einen SW-RESET (sicher für viel Geld) in ihre µC 
zu implementieren, das ganze auch noch aufwendig zu dokumentieren (incl. 
App-Notes) und ihre Applikationsingenieure zum Gebrauch dieser 
Eigenschaft zu schulen.

[tsilly (Gast)]

Karl B. schrieb:
> Das kursiert
> in verschieden Tutorials immer noch so.

Zudem kursiert es auch in den Dokumenten von Atmel,
denn z.B. in iotn841.h steht:

/* Vector 0 is the reset vector */

[Thomas S. (selli69)]

tsilly schrieb:
> Wenn ich das jetzt glauben soll, dann müssten ja viele µC-Hersteller
> ganz schön doof sein, einen SW-RESET (sicher für viel Geld) in ihre µC
> zu implementieren, das ganze auch noch aufwendig zu dokumentieren (incl.
> App-Notes) und ihre Applikationsingenieure zum Gebrauch dieser
> Eigenschaft zu schulen.

Nur weils der Chiphersteller macht, heißt das noch lange nicht, dass
1. Diese Funktion sinnvoll ist.
2. Man dies Funktion benutzen muss.
3. Der "steinige Weg der Gerechten" nicht der eigentliche Weg zum Ziel 
ist.

Ich kann mich nach 20 Jahren im Embedded-Bereich nicht an einen einzigen 
Fall erinnern in dem ein SW-Reset eine vernünftige Maßnahme gewesen 
wäre, außer in Fällen in denen ein Funktionsmodul eines uC im Fehlerfall 
EINZIG durch einen Reset wieder in einen definierten Zustand gebracht 
werden konnte. Dieses ist jedoch nur der Fall, wenn das Chipdesign 
mangelhaft ist. Das ist schon vorgekommen, ist jedoch ein extremer 
Ausnahmefall und auf einzelne HW-Revisionen eines uC begrenzt.

Das ist natürlich anekdotische Evidenz und muss nichts heißen. Wenn 
jemand mir einen validen Grund für einen SW-Reset nennen kann, dann bin 
ich interessiert. Man lernt schließlich nie aus.

[Thomas (Gast)]

spess53 schrieb:
> Nachtrag: Die megaAVR 0-serie kann auch Softwarereset.

und Xmega kann schon ewig Softwarereset.

[Bernd K. (prof7bit)]

Thomas S. schrieb:
> Wenn
> jemand mir einen validen Grund für einen SW-Reset nennen kann, dann bin
> ich interessiert. Man lernt schließlich nie aus.

* Ein Gerät soll auf Befehl des Busmasters in seinen Bootloader springen 
um damit ein Firmwareupdate durchzuführen und danach neu zu starten.

[Εrnst B. (ernst)]

tsilly schrieb:
> /* Vector 0 is the reset vector */

Bedeutet: Das ist der Vector, der beim Reset angesprungen wird.

Genauso, wie der INT0 Vector der ist, der beim Auftreten des INT0 
angesprungen wird.

Ein in Software ausgeführter Sprung auf 0x0000 ist kein Reset, genauso 
wie ein Sprung zum INT0_vect nicht dazu führt, dass dem µC ein Finger 
wächst um den Taster am Pin zu drücken.

[Thomas (Gast)]

Jitterer schrieb:
>> Höhenstrahlung?
>
> Dieser kann man nur duch rad-hard typen ausweichen.
> Oder allenfalls der orientierung.
> Ich wuerd den code also zuverlaessiger machen. Also
>
> -nur 1 loop.
> -alle Funktionalitaeten immer vor Gebrauch initialisieren.
>
> Alles andere wird aufwendig

Zudem jede Variable/struct im RAM mit zusätzlicher Prüfsumme z.B. CRC 
und bei jedem load/store überprüfen.

Tim T. schrieb:
>

>  void (*fp)(void) = 0x0000;
> 
>  fp();
>

und dazu empfiehlt sich noch __builtin_unreachable() oder ein do {fp();} 
while(1) Konstrukt.

Peripheral-Register werden damit natürlich immer noch nicht resettet...

[dummschwaetzer (Gast)]

>Das ist natürlich anekdotische Evidenz und muss nichts heißen. Wenn
>jemand mir einen validen Grund für einen SW-Reset nennen kann, dann bin
>ich interessiert. Man lernt schließlich nie aus.

Bei einigen Infineon in den Bootloader schalten, der vorher mit SW 
konfiguriert wurde

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas S. schrieb:
> außer in Fällen in denen ein Funktionsmodul eines uC im Fehlerfall
> EINZIG durch einen Reset wieder in einen definierten Zustand gebracht
> werden konnte.
Und da möchte ich behaupten, dass das Programm dazu selber nicht mehr in 
der Lage war, sondern bestenfalls noch ein Watchdog geholfen hätte.
Wobei ich sogar mal ein Programm in die Hände bekommen habe, wo der 
Programmierer die Vorgabe hatte, den Watchdog zu verwenden, dann einen 
10ms-Timerinterrupt aufgesetzt und darin einzig und allein den Watchdog 
bedient hat.
Dann Reklamation an mich, den Hardwareentwickler: "Dein Watchdog 
funktioniert nicht!!"
Fazit, wie zu erwarten: System verheddert sich in der Hauptschleife, 
Watchdog wird weiter bedient.

tsilly schrieb:
> Wenn ich das jetzt glauben soll, dann müssten ja viele µC-Hersteller
> ganz schön doof sein, einen SW-RESET (sicher für viel Geld) in ihre µC
> zu implementieren
Weil die Rest-FSM sowieso da ist, und die Implementierung dieses Befehls 
nicht viel kostet, kommen sie kommen damit einfach den Bedürfnissen 
einer speziellen Art von Programmiertechnik nach.

BTW: ich habe ein Deja Vue beim Lesen vom 
Beitrag "Reinitialisieren von Registern beim ATtiny841"
Wird das jetzt Mode?

[Thomas (Gast)]

Thomas schrieb:
> und dazu empfiehlt sich noch __builtin_unreachable() oder ein do {fp();}
> while(1) Konstrukt.
>
> Peripheral-Register werden damit natürlich immer noch nicht resettet...

Sorry, nicht unreachable, sondern fp als __attribute__((noreturn)) 
deklarieren.

[Thomas S. (selli69)]

Bernd K. schrieb:

> * Ein Gerät soll auf Befehl des Busmasters in seinen Bootloader springen
> um damit ein Firmwareupdate durchzuführen und danach neu zu starten.

Diese Funktion steckt in jedem von uns produziertem Gerät um einen 
FW-Update der einzelnen Units via CAN-Bus zu ermöglichen. Daran habe ich 
gar nicht mehr gedacht. Asche auf mein Haupt!

[Thomas S. (selli69)]

Lothar M. schrieb:
> Und da möchte ich behaupten, dass das Programm dazu selber nicht mehr in
> der Lage war, sondern bestenfalls noch ein Watchdog geholfen hätte.

Das der WD in 99% dieser Fälle dann dem Leiden ein Ende bereitet stimmt 
schon. Wir hatten jedoch den Fall in einer frühen Maskenrevision eines 
XC161, dass die Pipline in bestimmten Fällen keine Ergebnisse geliefert 
hat und nur mit einem Reset wieder zum Leben erweckt werden konnte. Frag 
mich jetzt nicht nach Details, denn das Ganze ist jetzt schon über zehn 
Jahre her und auseinandersetzen durfte sich damit (Gott sein Dank!!!) 
ein anderer Ingenieur.