Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #261597 > unrolled thread
| Started by | Ralph Aichinger <ra@pi.h5.or.at> |
|---|---|
| First post | 2019-08-13 09:33 +0200 |
| Last post | 2019-08-16 13:06 +0200 |
| Articles | 5 on this page of 85 — 17 participants |
Back to article view | Back to de.sci.electronics
(Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-13 09:33 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-08-13 10:42 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-13 07:25 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-08-13 15:15 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-13 13:45 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-08-14 07:33 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Neumann <an5275@sedo.com> - 2019-08-14 14:24 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 08:36 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-08-21 20:39 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-21 21:14 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Heinz Saathoff <newshsaat@arcor.de> - 2019-08-22 09:00 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Neumann <an5275@sedo.com> - 2019-08-22 10:35 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Neumann <an5275@sedo.com> - 2019-08-22 10:34 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Gerhard Hoffmann <dk4xp@arcor.de> - 2019-08-22 15:19 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Andreas Neumann <an5275@sedo.com> - 2019-08-24 10:34 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-13 17:10 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-13 13:54 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-14 10:53 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 06:44 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 05:35 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 07:29 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-14 11:20 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 07:32 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-14 09:49 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-13 19:29 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-13 14:54 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-13 21:06 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-13 13:45 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-13 13:56 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rainer Knaepper <rainerk@smial.prima.de> - 2019-08-14 00:38 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-14 09:53 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-14 10:56 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-14 11:36 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 07:15 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 05:44 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 07:53 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 15:24 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 17:06 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rainer Knaepper <rainerk@smial.prima.de> - 2019-08-15 09:27 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-16 08:58 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-16 11:25 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-08-21 20:49 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-08-13 15:11 +0000
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-13 18:47 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rafael Deliano <rafael_deliano@arcor.de> - 2019-08-13 18:28 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-13 18:53 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rafael Deliano <rafael_deliano@arcor.de> - 2019-08-14 17:42 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 05:47 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-15 10:58 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 08:26 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 15:36 +0200
Forth 2: (was Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 17:28 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-13 18:52 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-08-14 06:49 +0000
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Ralph Aichinger <ra@pi.h5.or.at> - 2019-08-14 09:58 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 10:57 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 11:10 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-14 11:40 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-08-14 13:58 +0000
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Michael Bäuerle <michael.baeuerle@stz-e.de> - 2019-08-14 16:46 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 17:24 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Michael Bäuerle <michael.baeuerle@stz-e.de> - 2019-08-14 18:23 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 19:05 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Michael Bäuerle <michael.baeuerle@stz-e.de> - 2019-08-15 11:28 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-15 13:43 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Michael Bäuerle <michael.baeuerle@stz-e.de> - 2019-08-15 15:03 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Joerg Niggemeyer <joerg.niggemeyer@nucon.de> - 2019-08-16 13:45 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 17:29 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 06:10 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-15 09:13 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-15 11:16 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Rainer Knaepper <rainerk@smial.prima.de> - 2019-08-14 00:27 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Markus Faust <mfaust@htwm.de> - 2019-08-14 10:31 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 11:01 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-14 11:23 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-14 11:42 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Josef Moellers <josef.moellers@invalid.invalid> - 2019-08-14 11:50 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-14 07:34 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-08-14 17:34 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs "Wolfgang Allinger" <all2001@spambog.com> - 2019-08-15 07:21 -0400
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Stefan <df9bi@arcor.de> - 2019-08-15 20:22 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-15 23:18 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Stefan <df9bi@arcor.de> - 2019-08-16 06:56 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-08-16 09:06 +0200
Re: (Atmel-) Mikrocontroller: Interrupts und "lange" ISRs Stefan <df9bi@arcor.de> - 2019-08-16 13:06 +0200
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Stefan <df9bi@arcor.de> |
|---|---|
| Date | 2019-08-15 20:22 +0200 |
| Message-ID | <qj47sk$9gb$1@news.albasani.net> |
| In reply to | #261597 |
Am 13.08.2019 um 09:33 schrieb Ralph Aichinger: > Jetzt habe ich folgendes Problem: Das ganze geht "meistens" > sehr schnell (Sekunden erhöhen, fertig, Counter läuft alleine > auf 0 zurück). Bei vollen Minuten muß ich die Minute erhöhen, > das tut auch nicht weh. > > Nur zu manchen Zeitpunkten (Jahresanfang Mitternacht GMT, > Anfang Sommerzeit, Schaltjahre, Schaltsekunden) muß ich > eventuell langwierigere Dinge machen. Gibt es außer > "ganz ganz sicher sein, daß die Berechnung keine Sekunde dauert" > noch Möglichkeiten wie man sowas abhandelt? Z.B. wie man den > zeitkritischen Teil (Sekunden, Minuten) vom weniger zeitkritischen > Teil (Stunden, Tage, Wochentag, Monat ...) getrennt abzuarbeiten? > > Oder ist die Idee mit dem Interrupt überhaupt schlecht? Auf einem 8051 hab ich aber sowas ähnliches mal gemacht: Wenn in der IRQ Routine festgestellt wird, dass die aufwändige Berechnung gemacht werden soll, die Adresse einer normalen Subroutine auf den Stack schreiben, dann einen RETI ausführen woraufhin das Programm nicht dorthin springt, wo INT das Programm unterbrochen hat, sondern in die Subroutine deren Adresse jetzt auf dem Stack steht. Jetzt kann der IRQ erneut aufgerufen werden während die aufwändige Berechnung läuft. Wenn die Berechnungen fertig sind mit RET dorthin zurückspringen, wo der erste INT aufgetreten ist. Ich glaube, das Status Register musste man auch noch auf den Stack schreiben. Genau weiß ich das nicht mehr. War damals in Assembler, in C auf dem AVR würde ich da heute die Finger von lassen und das so machen, wie weiter oben von anderen Postern beschrieben.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-15 23:18 +0200 |
| Message-ID | <grm606ForknU2@mid.individual.net> |
| In reply to | #261721 |
Am 15.08.2019 um 20:22 schrieb Stefan: > Auf einem 8051 hab ich aber sowas ähnliches mal gemacht: > > Wenn in der IRQ Routine festgestellt wird, dass die aufwändige > Berechnung gemacht werden soll, die Adresse einer normalen Subroutine > auf den Stack schreiben, dann einen RETI ausführen woraufhin das > Programm nicht dorthin springt, wo INT das Programm unterbrochen hat, > sondern in die Subroutine deren Adresse jetzt auf dem Stack steht. Es wäre einfacher, vor längeren Rechnungen die Interrupts wieder zu erlauben. Wenn die Rechnerei lange genug dauert, stürzt das irgendwann mit Stack Overflow ab, so oder so. Andernfalls baut sich der Stack wieder ab, so oder so. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Stefan <df9bi@arcor.de> |
|---|---|
| Date | 2019-08-16 06:56 +0200 |
| Message-ID | <qj5d2l$ctk$1@news.albasani.net> |
| In reply to | #261749 |
Am 15.08.2019 um 23:18 schrieb Hans-Peter Diettrich: > Am 15.08.2019 um 20:22 schrieb Stefan: > >> Auf einem 8051 hab ich aber sowas ähnliches mal gemacht: >> >> Wenn in der IRQ Routine festgestellt wird, dass die aufwändige >> Berechnung gemacht werden soll, die Adresse einer normalen Subroutine >> auf den Stack schreiben, dann einen RETI ausführen woraufhin das >> Programm nicht dorthin springt, wo INT das Programm unterbrochen hat, >> sondern in die Subroutine deren Adresse jetzt auf dem Stack steht. > > Es wäre einfacher, vor längeren Rechnungen die Interrupts wieder zu > erlauben. Es hängt wohl vom Prozessor ab, ob man einen INT wieder freigeben kann, während er bereits abgearbeitet wird. > Wenn die Rechnerei lange genug dauert, stürzt das irgendwann > mit Stack Overflow ab, so oder so. Andernfalls baut sich der Stack > wieder ab, so oder so. Sowas funktioniert natürlich nur, wenn der zeitliche Abstand zwischen den seltenen Ereignissen, von denen der OP schrieb, niemals kürzer wird, als die Zeit, die man für die aufwändige Berechnung benötigt. Aber wie schon geschrieben: Einfacher ist es, solche Dinge in eine Idl-Routine zu verlegen, d.h. das Programm besteht aus einer Hauptschleife in der zeitunkritische Dinge zyklisch abgearbeitet werden und INT-Routinen, in denen der Rest passiert. Eine INT-Routine kann dann ein Flag setzen, mit dem der Hauptschleife signalisiert, dass etwas berechnet werden soll.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-08-16 09:06 +0200 |
| Message-ID | <grn472Fcm4U3@mid.individual.net> |
| In reply to | #261752 |
Am 16.08.2019 um 06:56 schrieb Stefan: > Am 15.08.2019 um 23:18 schrieb Hans-Peter Diettrich: >> Am 15.08.2019 um 20:22 schrieb Stefan: >> >>> Auf einem 8051 hab ich aber sowas ähnliches mal gemacht: >>> >>> Wenn in der IRQ Routine festgestellt wird, dass die aufwändige >>> Berechnung gemacht werden soll, die Adresse einer normalen Subroutine >>> auf den Stack schreiben, dann einen RETI ausführen woraufhin das >>> Programm nicht dorthin springt, wo INT das Programm unterbrochen hat, >>> sondern in die Subroutine deren Adresse jetzt auf dem Stack steht. >> >> Es wäre einfacher, vor längeren Rechnungen die Interrupts wieder zu >> erlauben. > > Es hängt wohl vom Prozessor ab, ob man einen INT wieder freigeben kann, > während er bereits abgearbeitet wird. Das verstehe ich nicht. Es liegt doch weniger am Prozessor als an der reentrant Programmierung des Handlers. > Aber wie schon geschrieben: Einfacher ist es, solche Dinge in eine > Idl-Routine zu verlegen, d.h. das Programm besteht aus einer > Hauptschleife in der zeitunkritische Dinge zyklisch abgearbeitet werden > und INT-Routinen, in denen der Rest passiert. Eine INT-Routine kann dann > ein Flag setzen, mit dem der Hauptschleife signalisiert, dass etwas > berechnet werden soll. Da waren dann aber gewisse Leute anderer Ansicht, mir mußt Du das nicht erklären. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Stefan <df9bi@arcor.de> |
|---|---|
| Date | 2019-08-16 13:06 +0200 |
| Message-ID | <qj62np$l8f$1@news.albasani.net> |
| In reply to | #261754 |
Am 16.08.2019 um 09:06 schrieb Hans-Peter Diettrich: > Am 16.08.2019 um 06:56 schrieb Stefan: >> Am 15.08.2019 um 23:18 schrieb Hans-Peter Diettrich: >>> Am 15.08.2019 um 20:22 schrieb Stefan: >>> >> Es hängt wohl vom Prozessor ab, ob man einen INT wieder freigeben kann, >> während er bereits abgearbeitet wird. > > Das verstehe ich nicht. Es liegt doch weniger am Prozessor als an der > reentrant Programmierung des Handlers. Weiß ich nicht genau. Ich habe da Erfahrungen mit dem 8051 in Assembler. Da wurde der jeweils aktivierte INT wieder scharf geschaltet, wenn ein RETURN_From_INT ausgeführt wurde. Wenn die INT-Routine zu lang war, konnte der folgende INT verloren gehen. Mit AVR habe ich sowas nicht gemacht weil ich den eh nur in C programmiere und solche Dinge wie vom OP beschreiben nicht nötig waren. Beim STM32 muss/kann man auch in "C" das entsprechende Flag selber frei geben bevor man die INT-Routine verlässt, d.h. es müsste möglich sein, reentrante Routinen zu schreiben. Hab ich bisher vermieden.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | de.sci.electronics
csiph-web