GPIO Eingang bei langer Leitung schuetzen...

[Sieghard Schicktanz]

Hallo Helmut,

Du schriebst am Wed, 13 May 2020 13:18:17 +0200:

[Gründe für die Verbreitung von C]
....
> o C ist sehr stark verbreitet.

Das dürfte Nr. 1 mit großem Abstand sein.

Deshalb wurden Debugger, Patches, Updates, und ähnliches erfunden, und
inzwischen sind wir soweit, daß sogar Autos \"OTA\" (Over The Air) Updates
brauchen, damit man sie (nicht) fernsteuern kann...
Das brachte alles viele viele Arbeitsplätze für Leute, die sich in ihrem
Fachbereich nicht recht etablieren konnten und deswegen lieber zu
programmieren anfingen...

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Joerg,

Du schriebst am Tue, 12 May 2020 15:55:47 -0700:

schnell genug (eigentlich schon seit Jahrzehnten), um das nebenbei in
^^^^^^^^
einer Abfrage-Task zu machen - bzw. wie eher gängig in der
Hauptschleife des Anwendungsprogramms.

Genau das macht man im Zeitalter des Energiesparens nicht. Wozu soll der
uC diese ganze Zeit laufen? Das ist meist nicht noetig.

Wenn der Controller sowieso nix zu tun hat, dann ist er sowieso
überflüssig. Und wenn er was zu tun hat, dann kann er eine Kontaktabfrage
auch nebenbei mit erledigen. Das geht sogar dann, wenn er zwischen den
Abfrageaktionen immer mal wieder ein paar hundert µs bis ein paar ms
\"schläft\". Das spart dann die Interrupt-Latenz, Registersicherungsaktionen
und nachher das ganze wieder zurück.

... (Ich bin halt gewohnt, alles mit meinen kleinen
Multitasking-Scheduler-Funktiönchen zu machen, die
Reisenschleifentechnik habe ich nie gemocht und nie gemacht.)

Hmm, jetzt verlaesst mich mein Deutsch wirklich, ich weiss nicht, was mit
Riesenschleifentechnik gemeint ist.

Alle relevanten und dauernd benötigten Bearbeitungs- und Sicherheits-
Funktionen in einer einzigen riesigen und jedesmal vollständig zu
durchlaufenden endlosen Programmschleife (\"main loop\") abzugrasen.
Leider immer noch \"Stand der Technik\" wie vor 20 Jahren (und mehr),
anstatt das alles in einzelne, leicht überschau- und prüfbare Abschnitte
zu zerlegen und die Umschaltung zwischen denen einer Standardroutine zu
überlassen (die sogar schon \"ab Werk\" im Prozessor implementiert sein
könnte). Da sind sogar SPSen (\"PLCs\") fortschrittlicher, auch wenn dort
die einzelnen Code-Abschnitte jedesmal vollständig abgearbeitet werden
müssen.

....

Meine Erwähnung des \"sz\" kommt daher, daß es ein \"sz\" im Deutschen
eigentlich nur in seltenen Zusammensetzungen gibt, das scharfe \"ß\" hat
damit nichts zu tun. ...

Huch? Da habe ich Jahrzehnte in Germanien gewohnt und das wusste ich
nicht. Dachte \"sz\" und \"Buckel-s\" seien das gleiche.

Kein Problem - das wissen die meisten hier auch nicht. Das alte \"lange s\"
ist halt schon zu lange ausgestorben.

....
> Englisch ist wirklich einfacher

Täusch\' Dich da mal nicht. Wieviele Möglichkeiten gibt es z.B., im
Englischen den Laut \"f\" zu schreiben?
(The contents of the file made the physician laugh.)

...
Ja. Du bringst halt immer gern unüberprüfbare Beispiele als Nachweise.

Ich kann sie bei Bedarf immer erklaeren. Nur (meist) nicht das genaue
Produkt, aber das sollte verstaendlich sein.

Du _erklärst_, aber Du weist nicht nach. Das ist ein \"kleiner\" Unterschied.

...
verfügbar war, kann, spricht da ja auch nichts dagegen. Nur \"sollte\" das
anschließende Prüfen auf eine Störflanke dann halt auch nicht per
Polling, evtl. sogar noch innerhalb der Interrupt-Routine. erfolgen.

Das ist i.d.R. nicht sinnvoll, weil man die ISR dann ueber die laengste
zu beruecksichtigende Prellzeit laufen lassen muesste. Das ist heute oft

Eben, genau das schrieb ich doch.

> nicht mehr bio-oeko genug. Man kann dieselbe ISR nehmen, doch die braucht

Und das hat nix mit \"bio-oeko\" zu tun, sondern ganz simpel mit Funktion -
viele MC können nur eine Ebene Interrupts, und wenn die aktiv ist, dann
_geht_ _nichts_ _mehr_.

> dann zwei Inputs. Eine vom Pin, und danach wird die auf Timer Output

Jajaja, man kann alles unnötig verkomplizieren.

Wenn der Chip aber sowieso nicht im \"Tiefschlaf\" auf den Interrupt
warten kann, weil er halt noch viele andere Sachen zu erledigen hat,
dann bringt ein Interrupt für eine triviale Portabfrage hauptsächlich
unnötigen Overhaed - das kann u.U. bis zu einem Faktor 100 gehen. Die
....
Wenn der uC noch einen Haufen anderer Jobs hat, klar.

Ich kenne das eigentlich als Normalfall, daß der MC ausreichend zu tun hat,
daß sich die Verzugszeiten beim ständigen Schlafenlegen und Wiederaufwachen
eher nicht lohnen. Und wo man das machen könnte, ist meistens der Aufwand
dafür zu groß, oder das Prozessörchen (bis \'runter zu 6 Pins) kann das
nichtmal.

....

denn, der Prozessor wartet wirklich nur auf den Kontakt und gönnt sich
dabei ein Ruhepause (\"Tiefschlaf\") und kann nur so wieder zur Arbeit
geholt werden.

Letzteres ist bei sehr vielen Produkten der Sensorik der Fall. Da
erledigen wir so gut wie alles mit ISR und kalkulieren in
Mikroamperestunden.

Da ist also die \"Sensorik\" nur Beiwerk? Das sind wohl (Deine) \"IIoT\"-
Anwendungen mit Funkübertragung? Dort schaut die Sache natürlich anders aus
als bei direkt arbeitenden Steuerungsanwendungen.

....

Nein. Und nachdem er seinen Banana Pi dafür benutzt, der sowieso nicht
\"schläft\", erst recht nicht.

Der Banana Pi hat keinen Sleep Mode? Und da wollt Ihr Eure AKW

Er hat durchaus, aber er hat auch ein vollständiges Betriebssystem (Linux)
und macht wohl noch \"ein wenig\" mehr als nur den Kontakt abzufregen. Das
hat mit Kernkraftwerken nix zu tun.

....
> Sowas war bisher immer eine der leichteren Uebungen. Es is auch so, dass

\"Every problem has an easy, simple, and wrong solution\". Oder so.

....

in Javascript im Browser machen, wenn \"man\" das \"richtig\" programmieren
will...

Machen wir immer in C und Inline-Assembler.

War auch nur ein kleiner Seitenhieb auf einen anderen parallelen Thread.

[Überspannungsspikes}
10mA geht eigentlich immer. Bei Bedarf den Hersteller per Anfrage
nerven, bei Produktentwicklungen natuerlich schriftlich. Mache ich
oft.

Und Du kriegst das natürlich auch offiziell verbindlich bestätigt. Klar,
ist ja ganz einfach.

Ein Schreiben eines Applications Engineers gilt zumindest in den USA als
offizielle Stellungnahme der Firma. Bei Euch nicht?

Es fragt sich _welcher_ Firma. Der Distributor kann da viel erzählen...
Hersteller halten sich da gerne \"bedeckt\" und drücken sich nur vage aus.

Kennst Du Karl Valentin? \"Buchbinder Wanninger\"?

Noch nicht.

Mußt Du Dir im Original anhören. Das ist - leider - enorm zeitnah, wenn
auch inzwischen mit anderen Grundthemen...

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Joerg,

Du schriebst am Tue, 12 May 2020 15:55:47 -0700:

schnell genug (eigentlich schon seit Jahrzehnten), um das nebenbei in
^^^^^^^^
einer Abfrage-Task zu machen - bzw. wie eher gängig in der
Hauptschleife des Anwendungsprogramms.

Genau das macht man im Zeitalter des Energiesparens nicht. Wozu soll der
uC diese ganze Zeit laufen? Das ist meist nicht noetig.

Wenn der Controller sowieso nix zu tun hat, dann ist er sowieso
überflüssig. Und wenn er was zu tun hat, dann kann er eine Kontaktabfrage
auch nebenbei mit erledigen. Das geht sogar dann, wenn er zwischen den
Abfrageaktionen immer mal wieder ein paar hundert µs bis ein paar ms
\"schläft\". Das spart dann die Interrupt-Latenz, Registersicherungsaktionen
und nachher das ganze wieder zurück.

... (Ich bin halt gewohnt, alles mit meinen kleinen
Multitasking-Scheduler-Funktiönchen zu machen, die
Reisenschleifentechnik habe ich nie gemocht und nie gemacht.)

Hmm, jetzt verlaesst mich mein Deutsch wirklich, ich weiss nicht, was mit
Riesenschleifentechnik gemeint ist.

Alle relevanten und dauernd benötigten Bearbeitungs- und Sicherheits-
Funktionen in einer einzigen riesigen und jedesmal vollständig zu
durchlaufenden endlosen Programmschleife (\"main loop\") abzugrasen.
Leider immer noch \"Stand der Technik\" wie vor 20 Jahren (und mehr),
anstatt das alles in einzelne, leicht überschau- und prüfbare Abschnitte
zu zerlegen und die Umschaltung zwischen denen einer Standardroutine zu
überlassen (die sogar schon \"ab Werk\" im Prozessor implementiert sein
könnte). Da sind sogar SPSen (\"PLCs\") fortschrittlicher, auch wenn dort
die einzelnen Code-Abschnitte jedesmal vollständig abgearbeitet werden
müssen.

....

Meine Erwähnung des \"sz\" kommt daher, daß es ein \"sz\" im Deutschen
eigentlich nur in seltenen Zusammensetzungen gibt, das scharfe \"ß\" hat
damit nichts zu tun. ...

Huch? Da habe ich Jahrzehnte in Germanien gewohnt und das wusste ich
nicht. Dachte \"sz\" und \"Buckel-s\" seien das gleiche.

Kein Problem - das wissen die meisten hier auch nicht. Das alte \"lange s\"
ist halt schon zu lange ausgestorben.

....
> Englisch ist wirklich einfacher

Täusch\' Dich da mal nicht. Wieviele Möglichkeiten gibt es z.B., im
Englischen den Laut \"f\" zu schreiben?
(The contents of the file made the physician laugh.)

...
Ja. Du bringst halt immer gern unüberprüfbare Beispiele als Nachweise.

Ich kann sie bei Bedarf immer erklaeren. Nur (meist) nicht das genaue
Produkt, aber das sollte verstaendlich sein.

Du _erklärst_, aber Du weist nicht nach. Das ist ein \"kleiner\" Unterschied.

...
verfügbar war, kann, spricht da ja auch nichts dagegen. Nur \"sollte\" das
anschließende Prüfen auf eine Störflanke dann halt auch nicht per
Polling, evtl. sogar noch innerhalb der Interrupt-Routine. erfolgen.

Das ist i.d.R. nicht sinnvoll, weil man die ISR dann ueber die laengste
zu beruecksichtigende Prellzeit laufen lassen muesste. Das ist heute oft

Eben, genau das schrieb ich doch.

> nicht mehr bio-oeko genug. Man kann dieselbe ISR nehmen, doch die braucht

Und das hat nix mit \"bio-oeko\" zu tun, sondern ganz simpel mit Funktion -
viele MC können nur eine Ebene Interrupts, und wenn die aktiv ist, dann
_geht_ _nichts_ _mehr_.

> dann zwei Inputs. Eine vom Pin, und danach wird die auf Timer Output

Jajaja, man kann alles unnötig verkomplizieren.

Wenn der Chip aber sowieso nicht im \"Tiefschlaf\" auf den Interrupt
warten kann, weil er halt noch viele andere Sachen zu erledigen hat,
dann bringt ein Interrupt für eine triviale Portabfrage hauptsächlich
unnötigen Overhaed - das kann u.U. bis zu einem Faktor 100 gehen. Die
....
Wenn der uC noch einen Haufen anderer Jobs hat, klar.

Ich kenne das eigentlich als Normalfall, daß der MC ausreichend zu tun hat,
daß sich die Verzugszeiten beim ständigen Schlafenlegen und Wiederaufwachen
eher nicht lohnen. Und wo man das machen könnte, ist meistens der Aufwand
dafür zu groß, oder das Prozessörchen (bis \'runter zu 6 Pins) kann das
nichtmal.

....

denn, der Prozessor wartet wirklich nur auf den Kontakt und gönnt sich
dabei ein Ruhepause (\"Tiefschlaf\") und kann nur so wieder zur Arbeit
geholt werden.

Letzteres ist bei sehr vielen Produkten der Sensorik der Fall. Da
erledigen wir so gut wie alles mit ISR und kalkulieren in
Mikroamperestunden.

Da ist also die \"Sensorik\" nur Beiwerk? Das sind wohl (Deine) \"IIoT\"-
Anwendungen mit Funkübertragung? Dort schaut die Sache natürlich anders aus
als bei direkt arbeitenden Steuerungsanwendungen.

....

Nein. Und nachdem er seinen Banana Pi dafür benutzt, der sowieso nicht
\"schläft\", erst recht nicht.

Der Banana Pi hat keinen Sleep Mode? Und da wollt Ihr Eure AKW

Er hat durchaus, aber er hat auch ein vollständiges Betriebssystem (Linux)
und macht wohl noch \"ein wenig\" mehr als nur den Kontakt abzufregen. Das
hat mit Kernkraftwerken nix zu tun.

....
> Sowas war bisher immer eine der leichteren Uebungen. Es is auch so, dass

\"Every problem has an easy, simple, and wrong solution\". Oder so.

....

in Javascript im Browser machen, wenn \"man\" das \"richtig\" programmieren
will...

Machen wir immer in C und Inline-Assembler.

War auch nur ein kleiner Seitenhieb auf einen anderen parallelen Thread.

[Überspannungsspikes}
10mA geht eigentlich immer. Bei Bedarf den Hersteller per Anfrage
nerven, bei Produktentwicklungen natuerlich schriftlich. Mache ich
oft.

Und Du kriegst das natürlich auch offiziell verbindlich bestätigt. Klar,
ist ja ganz einfach.

Ein Schreiben eines Applications Engineers gilt zumindest in den USA als
offizielle Stellungnahme der Firma. Bei Euch nicht?

Es fragt sich _welcher_ Firma. Der Distributor kann da viel erzählen...
Hersteller halten sich da gerne \"bedeckt\" und drücken sich nur vage aus.

Kennst Du Karl Valentin? \"Buchbinder Wanninger\"?

Noch nicht.

Mußt Du Dir im Original anhören. Das ist - leider - enorm zeitnah, wenn
auch inzwischen mit anderen Grundthemen...

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Joerg]

On 2020-05-13 15:06, Sieghard Schicktanz wrote:

Hallo Joerg,

Du schriebst am Tue, 12 May 2020 15:55:47 -0700:

schnell genug (eigentlich schon seit Jahrzehnten), um das nebenbei in
^^^^^^^^
einer Abfrage-Task zu machen - bzw. wie eher gängig in der
Hauptschleife des Anwendungsprogramms.

Genau das macht man im Zeitalter des Energiesparens nicht. Wozu soll der
uC diese ganze Zeit laufen? Das ist meist nicht noetig.

Wenn der Controller sowieso nix zu tun hat, dann ist er sowieso
überflüssig.

Sorry, aber das ist nun wirklich ein Fehlschluss. uC braucht man in
allen Faellen, wo wir solche ISR benutzt haben. Um Sensoren zu erfassen,
Datenpakete zu schnueren, Meldungen durchzureichen an andere Messtellen,
und so weiter. 99.9% der Zeit schlafen sie. Die anderen 0.1% waeren ohne
uC nicht realisierbar.

... Und wenn er was zu tun hat, dann kann er eine Kontaktabfrage
auch nebenbei mit erledigen. Das geht sogar dann, wenn er zwischen den
Abfrageaktionen immer mal wieder ein paar hundert µs bis ein paar ms
\"schläft\". Das spart dann die Interrupt-Latenz, Registersicherungsaktionen
und nachher das ganze wieder zurück.

Polling braucht so gut wie immer mehr Energie als Interrupt.

... (Ich bin halt gewohnt, alles mit meinen kleinen
Multitasking-Scheduler-Funktiönchen zu machen, die
Reisenschleifentechnik habe ich nie gemocht und nie gemacht.)

Hmm, jetzt verlaesst mich mein Deutsch wirklich, ich weiss nicht, was mit
Riesenschleifentechnik gemeint ist.

Alle relevanten und dauernd benötigten Bearbeitungs- und Sicherheits-
Funktionen in einer einzigen riesigen und jedesmal vollständig zu
durchlaufenden endlosen Programmschleife (\"main loop\") abzugrasen.
Leider immer noch \"Stand der Technik\" wie vor 20 Jahren (und mehr),
anstatt das alles in einzelne, leicht überschau- und prüfbare Abschnitte
zu zerlegen und die Umschaltung zwischen denen einer Standardroutine zu
überlassen (die sogar schon \"ab Werk\" im Prozessor implementiert sein
könnte). Da sind sogar SPSen (\"PLCs\") fortschrittlicher, auch wenn dort
die einzelnen Code-Abschnitte jedesmal vollständig abgearbeitet werden
müssen.

Da sind wir mit unserer Sensorik denn doch weiter

[...]

...
Englisch ist wirklich einfacher

Täusch\' Dich da mal nicht. Wieviele Möglichkeiten gibt es z.B., im
Englischen den Laut \"f\" zu schreiben?
(The contents of the file made the physician laugh.)

Ja, sowas gibt es wohl. Oder die Aussprache von \"Worcester Sauce\", die
jeder gewoehnlichen Regel entbehrt.

...
Ja. Du bringst halt immer gern unüberprüfbare Beispiele als Nachweise.

Ich kann sie bei Bedarf immer erklaeren. Nur (meist) nicht das genaue
Produkt, aber das sollte verstaendlich sein.

Du _erklärst_, aber Du weist nicht nach. Das ist ein \"kleiner\" Unterschied.

Wie soll ich denn etwas \"nachweisen\"? Dazu muesste mindestens ein
NG-Teilnehmer hier anreisen. Sind immerhin rund 10000km.

...
verfügbar war, kann, spricht da ja auch nichts dagegen. Nur \"sollte\" das
anschließende Prüfen auf eine Störflanke dann halt auch nicht per
Polling, evtl. sogar noch innerhalb der Interrupt-Routine. erfolgen.

Das ist i.d.R. nicht sinnvoll, weil man die ISR dann ueber die laengste
zu beruecksichtigende Prellzeit laufen lassen muesste. Das ist heute oft

Eben, genau das schrieb ich doch.

nicht mehr bio-oeko genug. Man kann dieselbe ISR nehmen, doch die braucht

Und das hat nix mit \"bio-oeko\" zu tun, sondern ganz simpel mit Funktion -
viele MC können nur eine Ebene Interrupts, und wenn die aktiv ist, dann
_geht_ _nichts_ _mehr_.

Immerhin schreiben wir das 21.Jahrhundert. Hin- und Herschalten zwischen
Port Status Change und Timer Output ging aber auch schon im 20.Jahrhundert.

dann zwei Inputs. Eine vom Pin, und danach wird die auf Timer Output

Jajaja, man kann alles unnötig verkomplizieren.

Das ist doch pille-palle einfach

Wenn der Chip aber sowieso nicht im \"Tiefschlaf\" auf den Interrupt
warten kann, weil er halt noch viele andere Sachen zu erledigen hat,
dann bringt ein Interrupt für eine triviale Portabfrage hauptsächlich
unnötigen Overhaed - das kann u.U. bis zu einem Faktor 100 gehen. Die
...
Wenn der uC noch einen Haufen anderer Jobs hat, klar.

Ich kenne das eigentlich als Normalfall, daß der MC ausreichend zu tun hat,
daß sich die Verzugszeiten beim ständigen Schlafenlegen und Wiederaufwachen
eher nicht lohnen. Und wo man das machen könnte, ist meistens der Aufwand
dafür zu groß, oder das Prozessörchen (bis \'runter zu 6 Pins) kann das
nichtmal.

Gerade im Bereich der Beobachtung von Aussensensoren war das (in meinen
Faellen) nie der Normalfall. Da mussten wir mit jeder Mikroamperestunde
knausern.

...
denn, der Prozessor wartet wirklich nur auf den Kontakt und gönnt sich
dabei ein Ruhepause (\"Tiefschlaf\") und kann nur so wieder zur Arbeit
geholt werden.

Letzteres ist bei sehr vielen Produkten der Sensorik der Fall. Da
erledigen wir so gut wie alles mit ISR und kalkulieren in
Mikroamperestunden.

Da ist also die \"Sensorik\" nur Beiwerk? Das sind wohl (Deine) \"IIoT\"-
Anwendungen mit Funkübertragung?

Yup. Gerade wieder an einer dran, diesmal in ein Handy-Netz.

... Dort schaut die Sache natürlich anders aus
als bei direkt arbeitenden Steuerungsanwendungen.

Bei denen muessen wir das oft auch. Ich habe es erst selbst nicht
glauben wollen, sogar in einer grossen Passagiermaschine mussten wir die
uC auf totale Sparflamme bringen. Die betrachten inzwischen jeden
Tropfen Kerosin einzeln. Da haben wir viel in ISR hineingehievt und
zwischendurch verschiedene Sleep Modes.

Einer der Gruende, warum wir bei vielen uC Projekten Resonatoren und
keine Quarze verwenden (starten schneller).

[...]

...
Sowas war bisher immer eine der leichteren Uebungen. Es is auch so, dass

\"Every problem has an easy, simple, and wrong solution\". Oder so.

\"When you then sell thousands of devices it was the correct solution\".
Oder \"A solution is as good as the customer says it is\".

[...]

[Überspannungsspikes}
10mA geht eigentlich immer. Bei Bedarf den Hersteller per Anfrage
nerven, bei Produktentwicklungen natuerlich schriftlich. Mache ich
oft.

Und Du kriegst das natürlich auch offiziell verbindlich bestätigt. Klar,
ist ja ganz einfach.

Ein Schreiben eines Applications Engineers gilt zumindest in den USA als
offizielle Stellungnahme der Firma. Bei Euch nicht?

Es fragt sich _welcher_ Firma. Der Distributor kann da viel erzählen...
Hersteller halten sich da gerne \"bedeckt\" und drücken sich nur vage aus.

Daher schrieb ich Hersteller. Es muss von dem kommen. \"Bedeckt und vage\"
endet fuer die schnell auf der \"no traffic list\".

Kennst Du Karl Valentin? \"Buchbinder Wanninger\"?

Noch nicht.

Mußt Du Dir im Original anhören. Das ist - leider - enorm zeitnah, wenn
auch inzwischen mit anderen Grundthemen...

https://www.youtube.com/watch?v=5mvDqcolOEU&list=OLAK5uy_l3Y_vzQGV-WQD0gUsjCnJZKa7VINqJo4o

Ui, da muss ich mich sprachlich echt konzentrieren.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Joerg]

On 2020-05-13 15:06, Sieghard Schicktanz wrote:

Hallo Joerg,

Du schriebst am Tue, 12 May 2020 15:55:47 -0700:

schnell genug (eigentlich schon seit Jahrzehnten), um das nebenbei in
^^^^^^^^
einer Abfrage-Task zu machen - bzw. wie eher gängig in der
Hauptschleife des Anwendungsprogramms.

Genau das macht man im Zeitalter des Energiesparens nicht. Wozu soll der
uC diese ganze Zeit laufen? Das ist meist nicht noetig.

Wenn der Controller sowieso nix zu tun hat, dann ist er sowieso
überflüssig.

Sorry, aber das ist nun wirklich ein Fehlschluss. uC braucht man in
allen Faellen, wo wir solche ISR benutzt haben. Um Sensoren zu erfassen,
Datenpakete zu schnueren, Meldungen durchzureichen an andere Messtellen,
und so weiter. 99.9% der Zeit schlafen sie. Die anderen 0.1% waeren ohne
uC nicht realisierbar.

... Und wenn er was zu tun hat, dann kann er eine Kontaktabfrage
auch nebenbei mit erledigen. Das geht sogar dann, wenn er zwischen den
Abfrageaktionen immer mal wieder ein paar hundert µs bis ein paar ms
\"schläft\". Das spart dann die Interrupt-Latenz, Registersicherungsaktionen
und nachher das ganze wieder zurück.

Polling braucht so gut wie immer mehr Energie als Interrupt.

... (Ich bin halt gewohnt, alles mit meinen kleinen
Multitasking-Scheduler-Funktiönchen zu machen, die
Reisenschleifentechnik habe ich nie gemocht und nie gemacht.)

Hmm, jetzt verlaesst mich mein Deutsch wirklich, ich weiss nicht, was mit
Riesenschleifentechnik gemeint ist.

Alle relevanten und dauernd benötigten Bearbeitungs- und Sicherheits-
Funktionen in einer einzigen riesigen und jedesmal vollständig zu
durchlaufenden endlosen Programmschleife (\"main loop\") abzugrasen.
Leider immer noch \"Stand der Technik\" wie vor 20 Jahren (und mehr),
anstatt das alles in einzelne, leicht überschau- und prüfbare Abschnitte
zu zerlegen und die Umschaltung zwischen denen einer Standardroutine zu
überlassen (die sogar schon \"ab Werk\" im Prozessor implementiert sein
könnte). Da sind sogar SPSen (\"PLCs\") fortschrittlicher, auch wenn dort
die einzelnen Code-Abschnitte jedesmal vollständig abgearbeitet werden
müssen.

Da sind wir mit unserer Sensorik denn doch weiter

[...]

...
Englisch ist wirklich einfacher

Täusch\' Dich da mal nicht. Wieviele Möglichkeiten gibt es z.B., im
Englischen den Laut \"f\" zu schreiben?
(The contents of the file made the physician laugh.)

Ja, sowas gibt es wohl. Oder die Aussprache von \"Worcester Sauce\", die
jeder gewoehnlichen Regel entbehrt.

...
Ja. Du bringst halt immer gern unüberprüfbare Beispiele als Nachweise.

Ich kann sie bei Bedarf immer erklaeren. Nur (meist) nicht das genaue
Produkt, aber das sollte verstaendlich sein.

Du _erklärst_, aber Du weist nicht nach. Das ist ein \"kleiner\" Unterschied.

Wie soll ich denn etwas \"nachweisen\"? Dazu muesste mindestens ein
NG-Teilnehmer hier anreisen. Sind immerhin rund 10000km.

...
verfügbar war, kann, spricht da ja auch nichts dagegen. Nur \"sollte\" das
anschließende Prüfen auf eine Störflanke dann halt auch nicht per
Polling, evtl. sogar noch innerhalb der Interrupt-Routine. erfolgen.

Das ist i.d.R. nicht sinnvoll, weil man die ISR dann ueber die laengste
zu beruecksichtigende Prellzeit laufen lassen muesste. Das ist heute oft

Eben, genau das schrieb ich doch.

nicht mehr bio-oeko genug. Man kann dieselbe ISR nehmen, doch die braucht

Und das hat nix mit \"bio-oeko\" zu tun, sondern ganz simpel mit Funktion -
viele MC können nur eine Ebene Interrupts, und wenn die aktiv ist, dann
_geht_ _nichts_ _mehr_.

Immerhin schreiben wir das 21.Jahrhundert. Hin- und Herschalten zwischen
Port Status Change und Timer Output ging aber auch schon im 20.Jahrhundert.

dann zwei Inputs. Eine vom Pin, und danach wird die auf Timer Output

Jajaja, man kann alles unnötig verkomplizieren.

Das ist doch pille-palle einfach

Wenn der Chip aber sowieso nicht im \"Tiefschlaf\" auf den Interrupt
warten kann, weil er halt noch viele andere Sachen zu erledigen hat,
dann bringt ein Interrupt für eine triviale Portabfrage hauptsächlich
unnötigen Overhaed - das kann u.U. bis zu einem Faktor 100 gehen. Die
...
Wenn der uC noch einen Haufen anderer Jobs hat, klar.

Ich kenne das eigentlich als Normalfall, daß der MC ausreichend zu tun hat,
daß sich die Verzugszeiten beim ständigen Schlafenlegen und Wiederaufwachen
eher nicht lohnen. Und wo man das machen könnte, ist meistens der Aufwand
dafür zu groß, oder das Prozessörchen (bis \'runter zu 6 Pins) kann das
nichtmal.

Gerade im Bereich der Beobachtung von Aussensensoren war das (in meinen
Faellen) nie der Normalfall. Da mussten wir mit jeder Mikroamperestunde
knausern.

...
denn, der Prozessor wartet wirklich nur auf den Kontakt und gönnt sich
dabei ein Ruhepause (\"Tiefschlaf\") und kann nur so wieder zur Arbeit
geholt werden.

Letzteres ist bei sehr vielen Produkten der Sensorik der Fall. Da
erledigen wir so gut wie alles mit ISR und kalkulieren in
Mikroamperestunden.

Da ist also die \"Sensorik\" nur Beiwerk? Das sind wohl (Deine) \"IIoT\"-
Anwendungen mit Funkübertragung?

Yup. Gerade wieder an einer dran, diesmal in ein Handy-Netz.

... Dort schaut die Sache natürlich anders aus
als bei direkt arbeitenden Steuerungsanwendungen.

Bei denen muessen wir das oft auch. Ich habe es erst selbst nicht
glauben wollen, sogar in einer grossen Passagiermaschine mussten wir die
uC auf totale Sparflamme bringen. Die betrachten inzwischen jeden
Tropfen Kerosin einzeln. Da haben wir viel in ISR hineingehievt und
zwischendurch verschiedene Sleep Modes.

Einer der Gruende, warum wir bei vielen uC Projekten Resonatoren und
keine Quarze verwenden (starten schneller).

[...]

...
Sowas war bisher immer eine der leichteren Uebungen. Es is auch so, dass

\"Every problem has an easy, simple, and wrong solution\". Oder so.

\"When you then sell thousands of devices it was the correct solution\".
Oder \"A solution is as good as the customer says it is\".

[...]

[Überspannungsspikes}
10mA geht eigentlich immer. Bei Bedarf den Hersteller per Anfrage
nerven, bei Produktentwicklungen natuerlich schriftlich. Mache ich
oft.

Und Du kriegst das natürlich auch offiziell verbindlich bestätigt. Klar,
ist ja ganz einfach.

Ein Schreiben eines Applications Engineers gilt zumindest in den USA als
offizielle Stellungnahme der Firma. Bei Euch nicht?

Es fragt sich _welcher_ Firma. Der Distributor kann da viel erzählen...
Hersteller halten sich da gerne \"bedeckt\" und drücken sich nur vage aus.

Daher schrieb ich Hersteller. Es muss von dem kommen. \"Bedeckt und vage\"
endet fuer die schnell auf der \"no traffic list\".

Kennst Du Karl Valentin? \"Buchbinder Wanninger\"?

Noch nicht.

Mußt Du Dir im Original anhören. Das ist - leider - enorm zeitnah, wenn
auch inzwischen mit anderen Grundthemen...

https://www.youtube.com/watch?v=5mvDqcolOEU&list=OLAK5uy_l3Y_vzQGV-WQD0gUsjCnJZKa7VINqJo4o

Ui, da muss ich mich sprachlich echt konzentrieren.

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Rolf Bombach]

Helmut Schellong schrieb:

On 05/11/2020 22:35, Rolf Bombach wrote:
Helmut Schellong schrieb:

Es gab eine Diskussion im Thread, welche alternativen
Transistoren anstelle von 2N3055 verwendet werden könnten.
Vergessen?

Alternative zu 2N3055? Bist du des Wahnsinns
Der 2N3055 ist der uA741 der Leistungstransistoren!
Wenn das der Holger liest, kriegt er einen
Schreibkrampf.

Ich hänge an meinen Exemplaren.
Ich ziehe die betreffende Schublade aus meinem Raaco-Magazin,
stelle sie auf den Tisch, setze mich davor, und heule vor Rührung.

Ich hoffe, es sind mindestens 2N3055H, hometaxial hamse auch
nie wieder hingekriegt. Oder hast du gar noch einfachdiffundierte?
Zu jenen Zweiten hatte man explizit keine Freilaufdiode
an induktiven Lasten, war bei diesen Transistoren nicht nötig.

Man kann sich denken, was bei der Reparatur alter Geräte mit
neuen Transistoren dann so passieren kann.
Wobei, fällt mir gerade ein, IBM hatte bei den Lochern für
die Lochkarten so EL34-ähnliche Röhren, da hat man natürlich
noch mehr Spannungsreserve.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Helmut Schellong schrieb:

On 05/11/2020 22:35, Rolf Bombach wrote:
Helmut Schellong schrieb:

Es gab eine Diskussion im Thread, welche alternativen
Transistoren anstelle von 2N3055 verwendet werden könnten.
Vergessen?

Alternative zu 2N3055? Bist du des Wahnsinns
Der 2N3055 ist der uA741 der Leistungstransistoren!
Wenn das der Holger liest, kriegt er einen
Schreibkrampf.

Ich hänge an meinen Exemplaren.
Ich ziehe die betreffende Schublade aus meinem Raaco-Magazin,
stelle sie auf den Tisch, setze mich davor, und heule vor Rührung.

Ich hoffe, es sind mindestens 2N3055H, hometaxial hamse auch
nie wieder hingekriegt. Oder hast du gar noch einfachdiffundierte?
Zu jenen Zweiten hatte man explizit keine Freilaufdiode
an induktiven Lasten, war bei diesen Transistoren nicht nötig.

Man kann sich denken, was bei der Reparatur alter Geräte mit
neuen Transistoren dann so passieren kann.
Wobei, fällt mir gerade ein, IBM hatte bei den Lochern für
die Lochkarten so EL34-ähnliche Röhren, da hat man natürlich
noch mehr Spannungsreserve.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Sebastian Wolf schrieb:

Am 11.05.2020 um 22:49 schrieb Rolf Bombach:

Temperaturwechsel sind Mist. Es ist extrem schwierig, ein
Gerät dermassen abzudichten, dass es nicht \"atmet\". Notfalls
hilft am ehesten Ölfüllung oder Totalverguss.

Totalverguss klappt bestens durch versenken im Marianengraben.

Bei einem dieser Geräte streift mich dieser Gedanke bei
jeder Inbetriebnahme. Die Firma hat sich allerdings
mittlerweile selber ausser Betrieb genommen.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Reinhardt Behm schrieb:

On 5/12/20 2:28 AM, Rolf Bombach wrote:
Gerrit Heitsch schrieb:

Ja. Hast du ihn dann auf die berühmten 640 KB hingewiesen mit denen ein DOS-Rechner sehr lange auskommen musste?

Java ist ein Ausreisser, man hat den Verdacht, daß der/die Sprachdesigner Aktien von RAM-Herstellern hatte.

Und Haskell usw.? So Forschungssprachen, die unendlich gut
auf unendlich grossen unendlich schnellen Systemen laufen...

Als Echtzeit-System (dauert echt Zeit)

YMMD.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Sebastian Wolf schrieb:

Am 11.05.2020 um 22:49 schrieb Rolf Bombach:

Temperaturwechsel sind Mist. Es ist extrem schwierig, ein
Gerät dermassen abzudichten, dass es nicht \"atmet\". Notfalls
hilft am ehesten Ölfüllung oder Totalverguss.

Totalverguss klappt bestens durch versenken im Marianengraben.

Bei einem dieser Geräte streift mich dieser Gedanke bei
jeder Inbetriebnahme. Die Firma hat sich allerdings
mittlerweile selber ausser Betrieb genommen.

--
mfg Rolf Bombach

 

[Helmut Schellong]

On 05/12/2020 21:16, Rolf Bombach wrote:

Helmut Schellong schrieb:
On 05/11/2020 22:35, Rolf Bombach wrote:
Helmut Schellong schrieb:

Ich hänge an meinen Exemplaren.
Ich ziehe die betreffende Schublade aus meinem Raaco-Magazin,
stelle sie auf den Tisch, setze mich davor, und heule vor Rührung.

Ich hoffe, es sind mindestens 2N3055H, hometaxial hamse auch
nie wieder hingekriegt. Oder hast du gar noch einfachdiffundierte?
Zu jenen Zweiten hatte man explizit keine Freilaufdiode
an induktiven Lasten, war bei diesen Transistoren nicht nötig.

Ich habe ein Exemplar wie:
https://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/2N3055_RCA.JPG/330px-2N3055_RCA.JPG

Fast alle anderen neueren Exemplare sind auch RCA.
RCA hat den Begriff \'hometaxial\' geprägt, meine ich.

https://upload.wikimedia.org/wikipedia/commons/5/52/Power_transistor.jpg

Der dürfte kein Echter sein.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm

 

[Helmut Schellong]

On 05/12/2020 21:16, Rolf Bombach wrote:

Helmut Schellong schrieb:
On 05/11/2020 22:35, Rolf Bombach wrote:
Helmut Schellong schrieb:

Ich hänge an meinen Exemplaren.
Ich ziehe die betreffende Schublade aus meinem Raaco-Magazin,
stelle sie auf den Tisch, setze mich davor, und heule vor Rührung.

Ich hoffe, es sind mindestens 2N3055H, hometaxial hamse auch
nie wieder hingekriegt. Oder hast du gar noch einfachdiffundierte?
Zu jenen Zweiten hatte man explizit keine Freilaufdiode
an induktiven Lasten, war bei diesen Transistoren nicht nötig.

Ich habe ein Exemplar wie:
https://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/2N3055_RCA.JPG/330px-2N3055_RCA.JPG

Fast alle anderen neueren Exemplare sind auch RCA.
RCA hat den Begriff \'hometaxial\' geprägt, meine ich.

https://upload.wikimedia.org/wikipedia/commons/5/52/Power_transistor.jpg

Der dürfte kein Echter sein.


--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm

 

[Sieghard Schicktanz]

Hallo Joerg,

Du schriebst am Sun, 10 May 2020 11:57:54 -0700:

Du kennst Dich tiefgreifend mit der Hardware von Mikrocontrollern
aus?

Enough to be dangerous

Offensichtlich.

Es hat inzwischen fuer dutzende erfolgreiche Produkte gereicht. Dabei
gebe ich meist die Code Architektur im Groben vor und der Code selbst
wird von anderen geschrieben.

Das ist wohl auch besser so - damit hat der (oder die) Programmierer
weitgehend freie Hand in der Aufteilung der Funktionen und der Zuordnung
der Hardware-Funktionseinheiten. Wenn das dann nicht rein theoretisch
arbeitende Leute sind, sollte dabei durchaus brauchbares \'rauskommen.

...
Das muss ja auch nicht innerhalb der ISR geschehen.

So hattest Du das aber geschrieben.

Wo denn? Das macht man ueber eine zweite ISR, siehe weiter unten.

Nein, das macht man nicht \"über eine zweite ISR\", sondern allenfalls über
eine Zustandsmaschine. Aber heute sind auch die Mikrocontroller schnell
genug (eigentlich schon seit Jahrzehnten), um das nebenbei in einer
Abfrage-Task zu machen - bzw. wie eher gängig in der Hauptschleife des
Anwendungsprogramms. (Ich bin halt gewohnt, alles mit meinen kleinen
Multitasking-Scheduler-Funktiönchen zu machen, die Reisenschleifentechnik
habe ich nie gemocht und nie gemacht.)

Wir machen sowas bei Fluss-Sensoren staendig und das funktioniert

Das _daß_ ist hier uninteressant, ...

\"dass\" mit sz? Wo? <kopfkratz

Nein, nicht mit \"sz\", sondern mit \"ß\", \"german double ess\".
Und \"daß\" aufgrund des implziten Satzteils \"daß es gemacht wird\".

Verstehe ich jetzt ueberhaupt nicht. Habe ich einen Schreibfehler
gemacht? Kann passieren, Deutsch ist bei mir etwas rostig geworden.

Nein, Du hast keinen Schreibfehler gemacht, aber rostig ist Dein
Verständnis von Deutsch offenbar. Du hast lediglich nicht mitgekriegt,
daß ich halt eine recht verkürzt dargestellte Implikation Deines Arguments
bringen wollte:
\"Wir machen sowas ständig..\" -> \"Damit ist gesagt, _daß_ es funktioniert\".

Meine Erwähnung des \"sz\" kommt daher, daß es ein \"sz\" im Deutschen
eigentlich nur in seltenen Zusammensetzungen gibt, das scharfe \"ß\" hat
damit nichts zu tun. Das ist eine Ligatur aus zwei unterschiedlichen
Buchstaben, nämlich dem alten, nicht mehr gebräuchlichen und fast nicht
mehr bekannten \"langen s\" (schaut wie die obere Hälfte eines Integral-
Zeichens aus) und einem damit verbundenen \"runden s\". Daß das manche
Zeichesatzkünstler dann so verbogen haben, daß das runde s recht eckig
dargestellt wurde, hat wohl manche \"schlauen\" Leute dazu gebracht, das
als Ligatur eines (langen) s mit einem z zu interpretieren und (falsch)
zu benennen. Adobe hat das in seinen Postscript-Zeichensätzen noch richtig
gesehen und bezeichnet (\"german double s\"), die HTML-Entwickler schon
nicht mehr (\"&szlig;\" - da ist grade noch die Ligatur erwähnt. Eigentlich
müßte das \"&sslig;\" heißen). Aber das nur am Rand erwähnt.

....

... und das _wozu_ noch viel mehr - hier wäre
das _wie_ relevant. Aber ich darf doch sicher annehmen, daß das einem
NDA unterliegt?

Ja, Consulting Vertrag. Die letzten Faelle waren eine Anlage zur

I.O. Sonst wäre es ja nachprüfbar - war das ggfs. der Grund für die
Erwähnung? Es könnte der Verdacht aufkommen, wenn man sich Deine
Argumentationen in solchen Fällen ansieht.

seufz

Ja. Du bringst halt immer gern unüberprüfbare Beispiele als Nachweise.

....

Warum koennte man solche \"Event\" als Interrupt abarbeiten wollen? Ein uC
braucht sehr wenig Energie, wenn er nicht die ganze Zeit per laufender
Polling Routine einen Port beobachten muss. Moderne koennen sogar in
einen Schlafmodus geschickt werden und aus diesem innerhalb weniger zig
usec aufwachen. D.h. Du hast durch diese Methode einen erheblichen
Vorteil bei Batteriebetrieb.

Sofern der MC (Micro-Controller) das an _dem_ Pin, der dafür (noch)
verfügbar war, kann, spricht da ja auch nichts dagegen. Nur \"sollte\" das
anschließende Prüfen auf eine Störflanke dann halt auch nicht per Polling,
evtl. sogar noch innerhalb der Interrupt-Routine. erfolgen.
Wenn der Chip aber sowieso nicht im \"Tiefschlaf\" auf den Interrupt warten
kann, weil er halt noch viele andere Sachen zu erledigen hat, dann bringt
ein Interrupt für eine triviale Portabfrage hauptsächlich unnötigen
Overhaed - das kann u.U. bis zu einem Faktor 100 gehen. Die Bearbeitung im
Interrupt mit Umschaltungen und Vorbereitungen für die nächste Flanke wird
dabei auch komplexer als im \"Hintergrundprogramm\" im \"Vorbeigehen\".
Gut, eine einfache Tastenabfrage mag da weniger kritisch sein, aber es gibt
ja auch andere Signale von Kontakten, die ggfs. kritische Reaktionen
auslösen könen und sollen - wenn da was falsch erkannt wird und zu Schäden
führt, kann dasdurchaus unangenehm werden. Deswegen arbeiten meine
Entprellfunktionen immer mit mehrstufiger Pufferung (wie auch von Wolfgang
Allinger angeührt) und zusätzlich mit Kurzimpulsunterdrückung mit
definiertem Zeitverhalten.

Welche Produkte das genau sind und wie die genaue Sensorik darin
aussieht, darf ich aus naheliegenden Gruenden nicht erwaehnen. Das ist
hier auch gar nicht noetig, denn es sollte trotzdem klar sein, warum die
Methode ISR besser ist.

Ist sie nicht - ISRs sollten für wirklich zeitkritische Aktiuonen
vorbehalten sein, langweilige mechanische Signale (Größenordnung
einstellige kHz) sind besser im Hintergrundprogramm aufgehoben, es sei
denn, der Prozessor wartet wirklich nur auf den Kontakt und gönnt sich
dabei ein Ruhepause (\"Tiefschlaf\") und kann nur so wieder zur Arbeit geholt
werden.

Hint: In Marcs Fall (Reed Kontakt) kann auch die Nachpruefung \"Ist der
Kontakt immer noch geschlossen?\" ueber eine zweite ISR erfolgen. Das

Nein. Und nachdem er seinen Banana Pi dafür benutzt, der sowieso nicht
\"schläft\", erst recht nicht.

> macht man ueber einen Timer und den betreibt man am besten am langsam

(\"man\" sowieso nicht)

laufenden stromsparenden internen RC Oszillator. Der Timer startet nach
Ablauf der ersten ISR (erster Kontakschluss) und wenn dieser Timer
abgelaufen ist, prueft diese zweite ISR, ob der Kontakt noch geschlossen
ist, und erhoeht erst dann den Zaehlerstand.

Womit der Aufwand dann wirklich auf die Spitze getrieben ist.
Aber bitte - das kann \"man\" dann ja auch mit einer Bibliotheksfunktion in
Javascript im Browser machen, wenn \"man\" das \"richtig\" programmieren will...

Bei Netzbetrieb ist das alles nicht noetig oder wird oft fuer nicht
noetig gehalten. Der Strom kommt ja aus der Steckdose. Oder so.

Ja, da wird inzwischen viel unnützes gemacht...

[Überspannungsspikes}
Da gibt\'s manchmal - selten - sogar Spezifikationen. Z.B. bei Microchip
für die PICs (Clamp current, 20mA absolute maximum), nicht aber für die
....
10mA geht eigentlich immer. Bei Bedarf den Hersteller per Anfrage nerven,
bei Produktentwicklungen natuerlich schriftlich. Mache ich oft.

Und Du kriegst das natürlich auch offiziell verbindlich bestätigt.. Klar,
ist ja ganz einfach.
Kennst Du Karl Valentin? \"Buchbinder Wanninger\"?

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Joerg,

Du schriebst am Sun, 10 May 2020 11:57:54 -0700:

Du kennst Dich tiefgreifend mit der Hardware von Mikrocontrollern
aus?

Enough to be dangerous

Offensichtlich.

Es hat inzwischen fuer dutzende erfolgreiche Produkte gereicht. Dabei
gebe ich meist die Code Architektur im Groben vor und der Code selbst
wird von anderen geschrieben.

Das ist wohl auch besser so - damit hat der (oder die) Programmierer
weitgehend freie Hand in der Aufteilung der Funktionen und der Zuordnung
der Hardware-Funktionseinheiten. Wenn das dann nicht rein theoretisch
arbeitende Leute sind, sollte dabei durchaus brauchbares \'rauskommen.

...
Das muss ja auch nicht innerhalb der ISR geschehen.

So hattest Du das aber geschrieben.

Wo denn? Das macht man ueber eine zweite ISR, siehe weiter unten.

Nein, das macht man nicht \"über eine zweite ISR\", sondern allenfalls über
eine Zustandsmaschine. Aber heute sind auch die Mikrocontroller schnell
genug (eigentlich schon seit Jahrzehnten), um das nebenbei in einer
Abfrage-Task zu machen - bzw. wie eher gängig in der Hauptschleife des
Anwendungsprogramms. (Ich bin halt gewohnt, alles mit meinen kleinen
Multitasking-Scheduler-Funktiönchen zu machen, die Reisenschleifentechnik
habe ich nie gemocht und nie gemacht.)

Wir machen sowas bei Fluss-Sensoren staendig und das funktioniert

Das _daß_ ist hier uninteressant, ...

\"dass\" mit sz? Wo? <kopfkratz

Nein, nicht mit \"sz\", sondern mit \"ß\", \"german double ess\".
Und \"daß\" aufgrund des implziten Satzteils \"daß es gemacht wird\".

Verstehe ich jetzt ueberhaupt nicht. Habe ich einen Schreibfehler
gemacht? Kann passieren, Deutsch ist bei mir etwas rostig geworden.

Nein, Du hast keinen Schreibfehler gemacht, aber rostig ist Dein
Verständnis von Deutsch offenbar. Du hast lediglich nicht mitgekriegt,
daß ich halt eine recht verkürzt dargestellte Implikation Deines Arguments
bringen wollte:
\"Wir machen sowas ständig..\" -> \"Damit ist gesagt, _daß_ es funktioniert\".

Meine Erwähnung des \"sz\" kommt daher, daß es ein \"sz\" im Deutschen
eigentlich nur in seltenen Zusammensetzungen gibt, das scharfe \"ß\" hat
damit nichts zu tun. Das ist eine Ligatur aus zwei unterschiedlichen
Buchstaben, nämlich dem alten, nicht mehr gebräuchlichen und fast nicht
mehr bekannten \"langen s\" (schaut wie die obere Hälfte eines Integral-
Zeichens aus) und einem damit verbundenen \"runden s\". Daß das manche
Zeichesatzkünstler dann so verbogen haben, daß das runde s recht eckig
dargestellt wurde, hat wohl manche \"schlauen\" Leute dazu gebracht, das
als Ligatur eines (langen) s mit einem z zu interpretieren und (falsch)
zu benennen. Adobe hat das in seinen Postscript-Zeichensätzen noch richtig
gesehen und bezeichnet (\"german double s\"), die HTML-Entwickler schon
nicht mehr (\"&szlig;\" - da ist grade noch die Ligatur erwähnt. Eigentlich
müßte das \"&sslig;\" heißen). Aber das nur am Rand erwähnt.

....

... und das _wozu_ noch viel mehr - hier wäre
das _wie_ relevant. Aber ich darf doch sicher annehmen, daß das einem
NDA unterliegt?

Ja, Consulting Vertrag. Die letzten Faelle waren eine Anlage zur

I.O. Sonst wäre es ja nachprüfbar - war das ggfs. der Grund für die
Erwähnung? Es könnte der Verdacht aufkommen, wenn man sich Deine
Argumentationen in solchen Fällen ansieht.

seufz

Ja. Du bringst halt immer gern unüberprüfbare Beispiele als Nachweise.

....

Warum koennte man solche \"Event\" als Interrupt abarbeiten wollen? Ein uC
braucht sehr wenig Energie, wenn er nicht die ganze Zeit per laufender
Polling Routine einen Port beobachten muss. Moderne koennen sogar in
einen Schlafmodus geschickt werden und aus diesem innerhalb weniger zig
usec aufwachen. D.h. Du hast durch diese Methode einen erheblichen
Vorteil bei Batteriebetrieb.

Sofern der MC (Micro-Controller) das an _dem_ Pin, der dafür (noch)
verfügbar war, kann, spricht da ja auch nichts dagegen. Nur \"sollte\" das
anschließende Prüfen auf eine Störflanke dann halt auch nicht per Polling,
evtl. sogar noch innerhalb der Interrupt-Routine. erfolgen.
Wenn der Chip aber sowieso nicht im \"Tiefschlaf\" auf den Interrupt warten
kann, weil er halt noch viele andere Sachen zu erledigen hat, dann bringt
ein Interrupt für eine triviale Portabfrage hauptsächlich unnötigen
Overhaed - das kann u.U. bis zu einem Faktor 100 gehen. Die Bearbeitung im
Interrupt mit Umschaltungen und Vorbereitungen für die nächste Flanke wird
dabei auch komplexer als im \"Hintergrundprogramm\" im \"Vorbeigehen\".
Gut, eine einfache Tastenabfrage mag da weniger kritisch sein, aber es gibt
ja auch andere Signale von Kontakten, die ggfs. kritische Reaktionen
auslösen könen und sollen - wenn da was falsch erkannt wird und zu Schäden
führt, kann dasdurchaus unangenehm werden. Deswegen arbeiten meine
Entprellfunktionen immer mit mehrstufiger Pufferung (wie auch von Wolfgang
Allinger angeührt) und zusätzlich mit Kurzimpulsunterdrückung mit
definiertem Zeitverhalten.

Welche Produkte das genau sind und wie die genaue Sensorik darin
aussieht, darf ich aus naheliegenden Gruenden nicht erwaehnen. Das ist
hier auch gar nicht noetig, denn es sollte trotzdem klar sein, warum die
Methode ISR besser ist.

Ist sie nicht - ISRs sollten für wirklich zeitkritische Aktiuonen
vorbehalten sein, langweilige mechanische Signale (Größenordnung
einstellige kHz) sind besser im Hintergrundprogramm aufgehoben, es sei
denn, der Prozessor wartet wirklich nur auf den Kontakt und gönnt sich
dabei ein Ruhepause (\"Tiefschlaf\") und kann nur so wieder zur Arbeit geholt
werden.

Hint: In Marcs Fall (Reed Kontakt) kann auch die Nachpruefung \"Ist der
Kontakt immer noch geschlossen?\" ueber eine zweite ISR erfolgen. Das

Nein. Und nachdem er seinen Banana Pi dafür benutzt, der sowieso nicht
\"schläft\", erst recht nicht.

> macht man ueber einen Timer und den betreibt man am besten am langsam

(\"man\" sowieso nicht)

laufenden stromsparenden internen RC Oszillator. Der Timer startet nach
Ablauf der ersten ISR (erster Kontakschluss) und wenn dieser Timer
abgelaufen ist, prueft diese zweite ISR, ob der Kontakt noch geschlossen
ist, und erhoeht erst dann den Zaehlerstand.

Womit der Aufwand dann wirklich auf die Spitze getrieben ist.
Aber bitte - das kann \"man\" dann ja auch mit einer Bibliotheksfunktion in
Javascript im Browser machen, wenn \"man\" das \"richtig\" programmieren will...

Bei Netzbetrieb ist das alles nicht noetig oder wird oft fuer nicht
noetig gehalten. Der Strom kommt ja aus der Steckdose. Oder so.

Ja, da wird inzwischen viel unnützes gemacht...

[Überspannungsspikes}
Da gibt\'s manchmal - selten - sogar Spezifikationen. Z.B. bei Microchip
für die PICs (Clamp current, 20mA absolute maximum), nicht aber für die
....
10mA geht eigentlich immer. Bei Bedarf den Hersteller per Anfrage nerven,
bei Produktentwicklungen natuerlich schriftlich. Mache ich oft.

Und Du kriegst das natürlich auch offiziell verbindlich bestätigt.. Klar,
ist ja ganz einfach.
Kennst Du Karl Valentin? \"Buchbinder Wanninger\"?

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Rolf,

Du schriebst am Mon, 11 May 2020 21:17:11 +0200:

[C]

C ist die mit gewaltigem Abstand verbreitetste P.-Sprache.

Insbesondere wenn man die ca. 99% maschinengenerierten Code dazurechnet.

Viele sagen: \'An C kommt man nicht vorbei!\'.

Das ist das schlimmste daran.
Wobei ca. 99% der Menschheit durchaus daran vorbeikommt.

Das restliche Prozent teilt sich halt zu ungleichmäßig auf. Ich möcht\'
das mal so sagen: C ist so verbreitet, weil es so überaus viel mehr Usanier
als Schweizer gibt.
(Usanier: Kernighan/Ritchie, C; Schweizer: Prof. Niklas Wirth, Pascal)

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Sieghard Schicktanz]

Hallo Rolf,

Du schriebst am Mon, 11 May 2020 21:17:11 +0200:

[C]

C ist die mit gewaltigem Abstand verbreitetste P.-Sprache.

Insbesondere wenn man die ca. 99% maschinengenerierten Code dazurechnet.

Viele sagen: \'An C kommt man nicht vorbei!\'.

Das ist das schlimmste daran.
Wobei ca. 99% der Menschheit durchaus daran vorbeikommt.

Das restliche Prozent teilt sich halt zu ungleichmäßig auf. Ich möcht\'
das mal so sagen: C ist so verbreitet, weil es so überaus viel mehr Usanier
als Schweizer gibt.
(Usanier: Kernighan/Ritchie, C; Schweizer: Prof. Niklas Wirth, Pascal)

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Joerg]

On 2020-05-12 14:39, Sieghard Schicktanz wrote:

Hallo Joerg,

Du schriebst am Sun, 10 May 2020 11:57:54 -0700:

[...]

...
Das muss ja auch nicht innerhalb der ISR geschehen.

So hattest Du das aber geschrieben.

Wo denn? Das macht man ueber eine zweite ISR, siehe weiter unten.

Nein, das macht man nicht \"über eine zweite ISR\", sondern allenfalls über
eine Zustandsmaschine. Aber heute sind auch die Mikrocontroller schnell
genug (eigentlich schon seit Jahrzehnten), um das nebenbei in einer
Abfrage-Task zu machen - bzw. wie eher gängig in der Hauptschleife des
Anwendungsprogramms.

Genau das macht man im Zeitalter des Energiesparens nicht. Wozu soll der
uC diese ganze Zeit laufen? Das ist meist nicht noetig.

... (Ich bin halt gewohnt, alles mit meinen kleinen
Multitasking-Scheduler-Funktiönchen zu machen, die Reisenschleifentechnik
habe ich nie gemocht und nie gemacht.)

Hmm, jetzt verlaesst mich mein Deutsch wirklich, ich weiss nicht, was
mit Riesenschleifentechnik gemeint ist.

Wir machen sowas bei Fluss-Sensoren staendig und das funktioniert

Das _daß_ ist hier uninteressant, ...

\"dass\" mit sz? Wo? <kopfkratz

Nein, nicht mit \"sz\", sondern mit \"ß\", \"german double ess\".
Und \"daß\" aufgrund des implziten Satzteils \"daß es gemacht wird\".

Verstehe ich jetzt ueberhaupt nicht. Habe ich einen Schreibfehler
gemacht? Kann passieren, Deutsch ist bei mir etwas rostig geworden.

Nein, Du hast keinen Schreibfehler gemacht, aber rostig ist Dein
Verständnis von Deutsch offenbar. Du hast lediglich nicht mitgekriegt,
daß ich halt eine recht verkürzt dargestellte Implikation Deines Arguments
bringen wollte:
\"Wir machen sowas ständig..\" -> \"Damit ist gesagt, _daß_ es funktioniert\".

Ah, jetzt ja

Meine Erwähnung des \"sz\" kommt daher, daß es ein \"sz\" im Deutschen
eigentlich nur in seltenen Zusammensetzungen gibt, das scharfe \"ß\" hat
damit nichts zu tun. ...

Huch? Da habe ich Jahrzehnte in Germanien gewohnt und das wusste ich
nicht. Dachte \"sz\" und \"Buckel-s\" seien das gleiche.

... Das ist eine Ligatur aus zwei unterschiedlichen
Buchstaben, nämlich dem alten, nicht mehr gebräuchlichen und fast nicht
mehr bekannten \"langen s\" (schaut wie die obere Hälfte eines Integral-
Zeichens aus) und einem damit verbundenen \"runden s\". Daß das manche
Zeichesatzkünstler dann so verbogen haben, daß das runde s recht eckig
dargestellt wurde, hat wohl manche \"schlauen\" Leute dazu gebracht, das
als Ligatur eines (langen) s mit einem z zu interpretieren und (falsch)
zu benennen. Adobe hat das in seinen Postscript-Zeichensätzen noch richtig
gesehen und bezeichnet (\"german double s\"), die HTML-Entwickler schon
nicht mehr (\"&szlig;\" - da ist grade noch die Ligatur erwähnt. Eigentlich
müßte das \"&sslig;\" heißen). Aber das nur am Rand erwähnt.

Englisch ist wirklich einfacher

...
... und das _wozu_ noch viel mehr - hier wäre
das _wie_ relevant. Aber ich darf doch sicher annehmen, daß das einem
NDA unterliegt?

Ja, Consulting Vertrag. Die letzten Faelle waren eine Anlage zur

I.O. Sonst wäre es ja nachprüfbar - war das ggfs. der Grund für die
Erwähnung? Es könnte der Verdacht aufkommen, wenn man sich Deine
Argumentationen in solchen Fällen ansieht.

seufz

Ja. Du bringst halt immer gern unüberprüfbare Beispiele als Nachweise.

Ich kann sie bei Bedarf immer erklaeren. Nur (meist) nicht das genaue
Produkt, aber das sollte verstaendlich sein.

...
Warum koennte man solche \"Event\" als Interrupt abarbeiten wollen? Ein uC
braucht sehr wenig Energie, wenn er nicht die ganze Zeit per laufender
Polling Routine einen Port beobachten muss. Moderne koennen sogar in
einen Schlafmodus geschickt werden und aus diesem innerhalb weniger zig
usec aufwachen. D.h. Du hast durch diese Methode einen erheblichen
Vorteil bei Batteriebetrieb.

Sofern der MC (Micro-Controller) das an _dem_ Pin, der dafür (noch)
verfügbar war, kann, spricht da ja auch nichts dagegen. Nur \"sollte\" das
anschließende Prüfen auf eine Störflanke dann halt auch nicht per Polling,
evtl. sogar noch innerhalb der Interrupt-Routine. erfolgen.

Das ist i.d.R. nicht sinnvoll, weil man die ISR dann ueber die laengste
zu beruecksichtigende Prellzeit laufen lassen muesste. Das ist heute oft
nicht mehr bio-oeko genug. Man kann dieselbe ISR nehmen, doch die
braucht dann zwei Inputs. Eine vom Pin, und danach wird die auf Timer
Output umgeschaltet, danach wieder zurueck. Auf diese Art kann man die
ISR sofort nach Erkennen des logischen Pegelwechsels und Umschalten auf
Timer Output bzw. umgekehrt wieder schlafenlegen, und damit den ganzen
uC bis auf dessen Timer.

Wenn der Chip aber sowieso nicht im \"Tiefschlaf\" auf den Interrupt warten
kann, weil er halt noch viele andere Sachen zu erledigen hat, dann bringt
ein Interrupt für eine triviale Portabfrage hauptsächlich unnötigen
Overhaed - das kann u.U. bis zu einem Faktor 100 gehen. Die Bearbeitung im
Interrupt mit Umschaltungen und Vorbereitungen für die nächste Flanke wird
dabei auch komplexer als im \"Hintergrundprogramm\" im \"Vorbeigehen\".
Gut, eine einfache Tastenabfrage mag da weniger kritisch sein, aber es gibt
ja auch andere Signale von Kontakten, die ggfs. kritische Reaktionen
auslösen könen und sollen - wenn da was falsch erkannt wird und zu Schäden
führt, kann dasdurchaus unangenehm werden. Deswegen arbeiten meine
Entprellfunktionen immer mit mehrstufiger Pufferung (wie auch von Wolfgang
Allinger angeührt) und zusätzlich mit Kurzimpulsunterdrückung mit
definiertem Zeitverhalten.

Wenn der uC noch einen Haufen anderer Jobs hat, klar.

Welche Produkte das genau sind und wie die genaue Sensorik darin
aussieht, darf ich aus naheliegenden Gruenden nicht erwaehnen. Das ist
hier auch gar nicht noetig, denn es sollte trotzdem klar sein, warum die
Methode ISR besser ist.

Ist sie nicht - ISRs sollten für wirklich zeitkritische Aktiuonen
vorbehalten sein, langweilige mechanische Signale (Größenordnung
einstellige kHz) sind besser im Hintergrundprogramm aufgehoben, es sei
denn, der Prozessor wartet wirklich nur auf den Kontakt und gönnt sich
dabei ein Ruhepause (\"Tiefschlaf\") und kann nur so wieder zur Arbeit geholt
werden.

Letzteres ist bei sehr vielen Produkten der Sensorik der Fall. Da
erledigen wir so gut wie alles mit ISR und kalkulieren in
Mikroamperestunden.

Hint: In Marcs Fall (Reed Kontakt) kann auch die Nachpruefung \"Ist der
Kontakt immer noch geschlossen?\" ueber eine zweite ISR erfolgen. Das

Nein. Und nachdem er seinen Banana Pi dafür benutzt, der sowieso nicht
\"schläft\", erst recht nicht.

Der Banana Pi hat keinen Sleep Mode? Und da wollt Ihr Eure AKW
abschalten ...

macht man ueber einen Timer und den betreibt man am besten am langsam

(\"man\" sowieso nicht)

laufenden stromsparenden internen RC Oszillator. Der Timer startet nach
Ablauf der ersten ISR (erster Kontakschluss) und wenn dieser Timer
abgelaufen ist, prueft diese zweite ISR, ob der Kontakt noch geschlossen
ist, und erhoeht erst dann den Zaehlerstand.

Womit der Aufwand dann wirklich auf die Spitze getrieben ist.

Sowas war bisher immer eine der leichteren Uebungen. Es is auch so, dass
diese einmal geschriebenen Routinen bei anderen Projekten
wiederverwendet werden.

Aber bitte - das kann \"man\" dann ja auch mit einer Bibliotheksfunktion in
Javascript im Browser machen, wenn \"man\" das \"richtig\" programmieren will...

Machen wir immer in C und Inline-Assembler.

Bei Netzbetrieb ist das alles nicht noetig oder wird oft fuer nicht
noetig gehalten. Der Strom kommt ja aus der Steckdose. Oder so.

Ja, da wird inzwischen viel unnützes gemacht...

Einer der Gruende, warum ich einen kleinen Pogoplug als NAS umgebaut
habe. Wir koennen nicht einfach ueber Umweltschutz reden und dann aber
die Energie weiter rauspfeffern.

[Überspannungsspikes}
Da gibt\'s manchmal - selten - sogar Spezifikationen. Z.B. bei Microchip
für die PICs (Clamp current, 20mA absolute maximum), nicht aber für die
...
10mA geht eigentlich immer. Bei Bedarf den Hersteller per Anfrage nerven,
bei Produktentwicklungen natuerlich schriftlich. Mache ich oft.

Und Du kriegst das natürlich auch offiziell verbindlich bestätigt. Klar,
ist ja ganz einfach.

Ein Schreiben eines Applications Engineers gilt zumindest in den USA als
offizielle Stellungnahme der Firma. Bei Euch nicht?

Kennst Du Karl Valentin? \"Buchbinder Wanninger\"?

Noch nicht.

https://bar.wikipedia.org/wiki/Buchbinder_Wanninger

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Joerg]

On 2020-05-12 14:39, Sieghard Schicktanz wrote:

Hallo Joerg,

Du schriebst am Sun, 10 May 2020 11:57:54 -0700:

[...]

...
Das muss ja auch nicht innerhalb der ISR geschehen.

So hattest Du das aber geschrieben.

Wo denn? Das macht man ueber eine zweite ISR, siehe weiter unten.

Nein, das macht man nicht \"über eine zweite ISR\", sondern allenfalls über
eine Zustandsmaschine. Aber heute sind auch die Mikrocontroller schnell
genug (eigentlich schon seit Jahrzehnten), um das nebenbei in einer
Abfrage-Task zu machen - bzw. wie eher gängig in der Hauptschleife des
Anwendungsprogramms.

Genau das macht man im Zeitalter des Energiesparens nicht. Wozu soll der
uC diese ganze Zeit laufen? Das ist meist nicht noetig.

... (Ich bin halt gewohnt, alles mit meinen kleinen
Multitasking-Scheduler-Funktiönchen zu machen, die Reisenschleifentechnik
habe ich nie gemocht und nie gemacht.)

Hmm, jetzt verlaesst mich mein Deutsch wirklich, ich weiss nicht, was
mit Riesenschleifentechnik gemeint ist.

Wir machen sowas bei Fluss-Sensoren staendig und das funktioniert

Das _daß_ ist hier uninteressant, ...

\"dass\" mit sz? Wo? <kopfkratz

Nein, nicht mit \"sz\", sondern mit \"ß\", \"german double ess\".
Und \"daß\" aufgrund des implziten Satzteils \"daß es gemacht wird\".

Verstehe ich jetzt ueberhaupt nicht. Habe ich einen Schreibfehler
gemacht? Kann passieren, Deutsch ist bei mir etwas rostig geworden.

Nein, Du hast keinen Schreibfehler gemacht, aber rostig ist Dein
Verständnis von Deutsch offenbar. Du hast lediglich nicht mitgekriegt,
daß ich halt eine recht verkürzt dargestellte Implikation Deines Arguments
bringen wollte:
\"Wir machen sowas ständig..\" -> \"Damit ist gesagt, _daß_ es funktioniert\".

Ah, jetzt ja

Meine Erwähnung des \"sz\" kommt daher, daß es ein \"sz\" im Deutschen
eigentlich nur in seltenen Zusammensetzungen gibt, das scharfe \"ß\" hat
damit nichts zu tun. ...

Huch? Da habe ich Jahrzehnte in Germanien gewohnt und das wusste ich
nicht. Dachte \"sz\" und \"Buckel-s\" seien das gleiche.

... Das ist eine Ligatur aus zwei unterschiedlichen
Buchstaben, nämlich dem alten, nicht mehr gebräuchlichen und fast nicht
mehr bekannten \"langen s\" (schaut wie die obere Hälfte eines Integral-
Zeichens aus) und einem damit verbundenen \"runden s\". Daß das manche
Zeichesatzkünstler dann so verbogen haben, daß das runde s recht eckig
dargestellt wurde, hat wohl manche \"schlauen\" Leute dazu gebracht, das
als Ligatur eines (langen) s mit einem z zu interpretieren und (falsch)
zu benennen. Adobe hat das in seinen Postscript-Zeichensätzen noch richtig
gesehen und bezeichnet (\"german double s\"), die HTML-Entwickler schon
nicht mehr (\"&szlig;\" - da ist grade noch die Ligatur erwähnt. Eigentlich
müßte das \"&sslig;\" heißen). Aber das nur am Rand erwähnt.

Englisch ist wirklich einfacher

...
... und das _wozu_ noch viel mehr - hier wäre
das _wie_ relevant. Aber ich darf doch sicher annehmen, daß das einem
NDA unterliegt?

Ja, Consulting Vertrag. Die letzten Faelle waren eine Anlage zur

I.O. Sonst wäre es ja nachprüfbar - war das ggfs. der Grund für die
Erwähnung? Es könnte der Verdacht aufkommen, wenn man sich Deine
Argumentationen in solchen Fällen ansieht.

seufz

Ja. Du bringst halt immer gern unüberprüfbare Beispiele als Nachweise.

Ich kann sie bei Bedarf immer erklaeren. Nur (meist) nicht das genaue
Produkt, aber das sollte verstaendlich sein.

...
Warum koennte man solche \"Event\" als Interrupt abarbeiten wollen? Ein uC
braucht sehr wenig Energie, wenn er nicht die ganze Zeit per laufender
Polling Routine einen Port beobachten muss. Moderne koennen sogar in
einen Schlafmodus geschickt werden und aus diesem innerhalb weniger zig
usec aufwachen. D.h. Du hast durch diese Methode einen erheblichen
Vorteil bei Batteriebetrieb.

Sofern der MC (Micro-Controller) das an _dem_ Pin, der dafür (noch)
verfügbar war, kann, spricht da ja auch nichts dagegen. Nur \"sollte\" das
anschließende Prüfen auf eine Störflanke dann halt auch nicht per Polling,
evtl. sogar noch innerhalb der Interrupt-Routine. erfolgen.

Das ist i.d.R. nicht sinnvoll, weil man die ISR dann ueber die laengste
zu beruecksichtigende Prellzeit laufen lassen muesste. Das ist heute oft
nicht mehr bio-oeko genug. Man kann dieselbe ISR nehmen, doch die
braucht dann zwei Inputs. Eine vom Pin, und danach wird die auf Timer
Output umgeschaltet, danach wieder zurueck. Auf diese Art kann man die
ISR sofort nach Erkennen des logischen Pegelwechsels und Umschalten auf
Timer Output bzw. umgekehrt wieder schlafenlegen, und damit den ganzen
uC bis auf dessen Timer.

Wenn der Chip aber sowieso nicht im \"Tiefschlaf\" auf den Interrupt warten
kann, weil er halt noch viele andere Sachen zu erledigen hat, dann bringt
ein Interrupt für eine triviale Portabfrage hauptsächlich unnötigen
Overhaed - das kann u.U. bis zu einem Faktor 100 gehen. Die Bearbeitung im
Interrupt mit Umschaltungen und Vorbereitungen für die nächste Flanke wird
dabei auch komplexer als im \"Hintergrundprogramm\" im \"Vorbeigehen\".
Gut, eine einfache Tastenabfrage mag da weniger kritisch sein, aber es gibt
ja auch andere Signale von Kontakten, die ggfs. kritische Reaktionen
auslösen könen und sollen - wenn da was falsch erkannt wird und zu Schäden
führt, kann dasdurchaus unangenehm werden. Deswegen arbeiten meine
Entprellfunktionen immer mit mehrstufiger Pufferung (wie auch von Wolfgang
Allinger angeührt) und zusätzlich mit Kurzimpulsunterdrückung mit
definiertem Zeitverhalten.

Wenn der uC noch einen Haufen anderer Jobs hat, klar.

Welche Produkte das genau sind und wie die genaue Sensorik darin
aussieht, darf ich aus naheliegenden Gruenden nicht erwaehnen. Das ist
hier auch gar nicht noetig, denn es sollte trotzdem klar sein, warum die
Methode ISR besser ist.

Ist sie nicht - ISRs sollten für wirklich zeitkritische Aktiuonen
vorbehalten sein, langweilige mechanische Signale (Größenordnung
einstellige kHz) sind besser im Hintergrundprogramm aufgehoben, es sei
denn, der Prozessor wartet wirklich nur auf den Kontakt und gönnt sich
dabei ein Ruhepause (\"Tiefschlaf\") und kann nur so wieder zur Arbeit geholt
werden.

Letzteres ist bei sehr vielen Produkten der Sensorik der Fall. Da
erledigen wir so gut wie alles mit ISR und kalkulieren in
Mikroamperestunden.

Hint: In Marcs Fall (Reed Kontakt) kann auch die Nachpruefung \"Ist der
Kontakt immer noch geschlossen?\" ueber eine zweite ISR erfolgen. Das

Nein. Und nachdem er seinen Banana Pi dafür benutzt, der sowieso nicht
\"schläft\", erst recht nicht.

Der Banana Pi hat keinen Sleep Mode? Und da wollt Ihr Eure AKW
abschalten ...

macht man ueber einen Timer und den betreibt man am besten am langsam

(\"man\" sowieso nicht)

laufenden stromsparenden internen RC Oszillator. Der Timer startet nach
Ablauf der ersten ISR (erster Kontakschluss) und wenn dieser Timer
abgelaufen ist, prueft diese zweite ISR, ob der Kontakt noch geschlossen
ist, und erhoeht erst dann den Zaehlerstand.

Womit der Aufwand dann wirklich auf die Spitze getrieben ist.

Sowas war bisher immer eine der leichteren Uebungen. Es is auch so, dass
diese einmal geschriebenen Routinen bei anderen Projekten
wiederverwendet werden.

Aber bitte - das kann \"man\" dann ja auch mit einer Bibliotheksfunktion in
Javascript im Browser machen, wenn \"man\" das \"richtig\" programmieren will...

Machen wir immer in C und Inline-Assembler.

Bei Netzbetrieb ist das alles nicht noetig oder wird oft fuer nicht
noetig gehalten. Der Strom kommt ja aus der Steckdose. Oder so.

Ja, da wird inzwischen viel unnützes gemacht...

Einer der Gruende, warum ich einen kleinen Pogoplug als NAS umgebaut
habe. Wir koennen nicht einfach ueber Umweltschutz reden und dann aber
die Energie weiter rauspfeffern.

[Überspannungsspikes}
Da gibt\'s manchmal - selten - sogar Spezifikationen. Z.B. bei Microchip
für die PICs (Clamp current, 20mA absolute maximum), nicht aber für die
...
10mA geht eigentlich immer. Bei Bedarf den Hersteller per Anfrage nerven,
bei Produktentwicklungen natuerlich schriftlich. Mache ich oft.

Und Du kriegst das natürlich auch offiziell verbindlich bestätigt. Klar,
ist ja ganz einfach.

Ein Schreiben eines Applications Engineers gilt zumindest in den USA als
offizielle Stellungnahme der Firma. Bei Euch nicht?

Kennst Du Karl Valentin? \"Buchbinder Wanninger\"?

Noch nicht.

https://bar.wikipedia.org/wiki/Buchbinder_Wanninger

--
Gruesse, Joerg

http://www.analogconsultants.com/

 

[Wolfgang Allinger]

On 12 May 20 at group /de/sci/electronics in article r9f345$f7i$2@dont-email.me
<rolfnospambombach@invalid.invalid> (Rolf Bombach) wrote:

Reinhardt Behm schrieb:
On 5/12/20 2:28 AM, Rolf Bombach wrote:
Gerrit Heitsch schrieb:

Ja. Hast du ihn dann auf die berühmten 640 KB hingewiesen mit denen ein
DOS-Rechner sehr lange auskommen musste?

Java ist ein Ausreisser, man hat den Verdacht, daß der/die Sprachdesigner
Aktien von RAM-Herstellern hatte.

Und Haskell usw.? So Forschungssprachen, die unendlich gut
auf unendlich grossen unendlich schnellen Systemen laufen...

Als Echtzeit-System (dauert echt Zeit)

YMMD.

Wie jetzt, Du kanntest den Unterschied zwischen Echt-Zeit und Echtzeit
nicht?

Windoof&Co arbeitet mit Echt-Zeit.
Meine embedded Projekte alle in (harter) Echzeit.



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 12 May 20 at group /de/sci/electronics in article r9f345$f7i$2@dont-email.me
<rolfnospambombach@invalid.invalid> (Rolf Bombach) wrote:

Reinhardt Behm schrieb:
On 5/12/20 2:28 AM, Rolf Bombach wrote:
Gerrit Heitsch schrieb:

Ja. Hast du ihn dann auf die berühmten 640 KB hingewiesen mit denen ein
DOS-Rechner sehr lange auskommen musste?

Java ist ein Ausreisser, man hat den Verdacht, daß der/die Sprachdesigner
Aktien von RAM-Herstellern hatte.

Und Haskell usw.? So Forschungssprachen, die unendlich gut
auf unendlich grossen unendlich schnellen Systemen laufen...

Als Echtzeit-System (dauert echt Zeit)

YMMD.

Wie jetzt, Du kanntest den Unterschied zwischen Echt-Zeit und Echtzeit
nicht?

Windoof&Co arbeitet mit Echt-Zeit.
Meine embedded Projekte alle in (harter) Echzeit.



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot