Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #264062 > unrolled thread

mikrocontroller mit mehr als einem Quadrature-Decoder Timer

Back to article view | Back to de.sci.electronics

Contents

  mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-19 06:36 +0000
    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-09-19 09:25 +0200
      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-19 08:20 +0000
        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Andreas Fecht <forum@aftec.de> - 2019-09-19 10:43 +0200
          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-19 08:54 +0000
          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-09-19 11:09 +0200
          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-19 13:35 +0000
            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Andreas Fecht <forum@aftec.de> - 2019-09-19 20:39 +0200
              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-20 05:50 +0000
                Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-09-20 08:08 +0200
              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-09-21 20:52 +0200
                Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-21 22:23 +0200
    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "MaWin" <me@private.net> - 2019-09-19 11:49 +0200
    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-19 12:17 +0200
      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Bernd Laengerich <Bernd.Laengerich@web.de> - 2019-09-19 12:35 +0200
        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-19 14:51 +0200
      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "MaWin" <me@private.net> - 2019-09-19 12:48 +0200
        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-19 13:39 +0000
          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-19 16:52 +0200
            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-20 13:54 +0200
          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Gerald Oppen <Gerald.Oppen@web.de> - 2019-09-19 21:45 +0200
          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Thorsten Böttcher <thorsten_nospam@gmx.net> - 2019-09-20 07:25 +0200
            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "Wolfgang Allinger" <all2001@spambog.com> - 2019-09-20 06:48 -0400
            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-09-21 20:57 +0200
              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-22 04:08 +0200
                Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Rainer Knaepper <rainerk@smial.prima.de> - 2019-09-22 12:25 +0200
    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer olaf <olaf@criseis.ruhr.de> - 2019-09-19 16:36 +0200
      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-20 05:58 +0000
        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "Wolfgang Allinger" <all2001@spambog.com> - 2019-09-20 07:04 -0400
          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-20 13:52 +0200
            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "Wolfgang Allinger" <all2001@spambog.com> - 2019-09-20 18:15 -0400
              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-21 08:26 +0200
        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Rainer Knaepper <rainerk@smial.prima.de> - 2019-09-20 16:26 +0200
          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-20 16:56 +0200
            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Rainer Knaepper <rainerk@smial.prima.de> - 2019-09-21 03:20 +0200
              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-21 08:32 +0200
                Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Volker Bartheld <news2019@bartheld.net> - 2019-09-21 09:57 +0200
                  Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Andreas Fecht <forum@aftec.de> - 2019-09-21 10:08 +0200
                    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Marte Schwarz <marte.schwarz@gmx.de> - 2019-09-21 13:39 +0200
                      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Andreas Fecht <forum@aftec.de> - 2019-09-21 14:43 +0200
                        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-21 15:12 +0200
                        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Marte Schwarz <marte.schwarz@gmx.de> - 2019-09-22 15:36 +0200
                  Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-21 10:11 +0200
                  Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-21 12:35 +0200
                    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-21 13:15 +0200
                    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Volker Bartheld <news2019@bartheld.net> - 2019-09-23 13:52 +0200
                      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Gerhard Hoffmann <dk4xp@arcor.de> - 2019-09-23 14:22 +0200
                      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-23 14:36 +0200
                      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "horst-d.winzler" <horst.d.winzler@web.de> - 2019-09-23 17:26 +0200
                      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-23 19:29 +0200
                        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Volker Bartheld <news2019@bartheld.net> - 2019-09-24 10:43 +0200
                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Johannes Bauer <dfnsonfsduifb@gmx.de> - 2019-09-24 11:19 +0200
                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hanno Foest <hurga-news2@tigress.com> - 2019-09-24 11:32 +0200
                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-24 13:15 +0200
                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Gerhard Hoffmann <dk4xp@arcor.de> - 2019-09-24 14:00 +0200
                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Rainer Knaepper <rainerk@smial.prima.de> - 2019-09-24 19:01 +0200
                            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-24 19:59 +0200
                              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Rainer Knaepper <rainerk@smial.prima.de> - 2019-09-25 14:53 +0200
                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-25 16:31 +0200
                            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-30 09:04 +0000
                              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-09-30 14:06 +0200
                                Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Marte Schwarz <marte.schwarz@gmx.de> - 2019-09-30 16:18 +0200
                                  Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Rainer Knaepper <rainerk@smial.prima.de> - 2019-09-30 21:28 +0200
                                    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "Wolfgang Allinger" <all2001@spambog.com> - 2019-09-30 17:24 -0400
                                      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Klaus Butzmann <kb.usenet@butzomail.de> - 2019-10-01 22:40 +0200
                                        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-10-02 07:34 +0200
                                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "Wolfgang Allinger" <all2001@spambog.com> - 2019-10-02 04:08 -0400
                                            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-10-02 15:34 +0200
                                              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Klaus Butzmann <kb.usenet@butzomail.de> - 2019-10-02 21:22 +0200
                                              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Axel Berger <Spam@Berger-Odenthal.De> - 2019-10-02 21:56 +0200
                                                Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-10-02 23:29 +0200
                                                  Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Axel Berger <Spam@Berger-Odenthal.De> - 2019-10-03 11:58 +0200
                                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Klaus Butzmann <kb.usenet@butzomail.de> - 2019-10-02 21:04 +0200
                                            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-10-02 23:38 +0200
                                        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "Wolfgang Allinger" <all2001@spambog.com> - 2019-10-01 18:24 -0400
                                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Uhu <Euleuhu@nest.de> - 2019-10-02 10:12 +0200
                                            Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer markus philippi <markusphi.news@solinetcafe.org> - 2019-10-04 10:07 +0200
                                              Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Uhu <Euleuhu@nest.de> - 2019-10-04 10:09 +0200
                                                Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Josef Moellers <josef.moellers@invalid.invalid> - 2019-10-07 16:48 +0200
                                                  Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-10-07 15:12 +0000
                                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Klaus Butzmann <kb.usenet@butzomail.de> - 2019-10-02 20:59 +0200
                                    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Marte Schwarz <marte.schwarz@gmx.de> - 2019-10-01 10:45 +0200
                                      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Hanno Foest <hurga-news2@tigress.com> - 2019-10-01 12:18 +0200
                                        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Marte Schwarz <marte.schwarz@gmx.de> - 2019-10-01 20:46 +0200
                                      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Rainer Knaepper <rainerk@smial.prima.de> - 2019-10-02 00:19 +0200
                                        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Bernd Laengerich <Bernd.Laengerich@web.de> - 2019-10-02 09:48 +0200
                                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Marte Schwarz <marte.schwarz@gmx.de> - 2019-10-02 10:27 +0200
                                        Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Marte Schwarz <marte.schwarz@gmx.de> - 2019-10-02 10:21 +0200
                                          Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Rainer Knaepper <rainerk@smial.prima.de> - 2019-10-03 01:18 +0200
    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Michael Koch <astroelectronic@t-online.de> - 2019-09-24 01:38 -0700
      Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Matthias Weingart <mwnews@pentax.boerde.de> - 2019-09-24 14:39 +0000
    Re: mikrocontroller mit mehr als einem Quadrature-Decoder Timer Mark <mark.wolf@alumni.tu-berlin.de> - 2019-10-10 13:43 +0700

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#264219

On 21.09.19 14:43, Andreas Fecht wrote:
> Bei dem Youtube-Beispiel ging es wohl um den Knackpunkt, dass sie nur
> einen Draht zur Verfügung haben. Mit zwei Drähten hätten es
> wahrscheinlich alle geschafft.

Hm naja der eine, der es schafft, hat eine andere Birne -- ein typisches
Fahrradbirnchen. Die anderen sehen nach E14 aus und haben dann
vermutlich 110V, da könnte das gar nicht gehen. Wäre interessant, zu
wissen, ob das Absicht war.

Gruß,
Johannes


-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264269

Hi Andreas,
> Bei dem Youtube-Beispiel ging es wohl um den Knackpunkt, dass sie nur 
> einen Draht zur Verfügung haben. Mit zwei Drähten hätten es 
> wahrscheinlich alle geschafft.

Nicht wirklich. ein 1,5V Block an eine Netzspannungsglühbirne wird trotz 
allem nix, selbst wenn es eine amerikanische Glühbirne ist.

Marte

[toc] | [prev] | [next] | [standalone]

#264200

On 21.09.19 09:57, Volker Bartheld wrote:

> Man kann durchaus den Standpunkt vertreten, die bei Meltdown/Spectre
> mögliche Seitenkanalattacke hätte auch etwas mit einer (impliziten)
> Nebenläufigkeit zu tun. Die Möglichkeit ist ab 1995 seit Einführung der
> "Out-of-Order Execution" möglich, wurde erst über 20(!) Jahre später
> entdeckt und ich glaube nicht, daß die Entwickler bei Intel alles
> Armateure und "auf da Brennsuppn daherschwomma" sind.
> 
> Falls sich also jemand anmaßt, das Thema als trivial abzutun, möge er
> hoffentlich bald ein wenig Demut lernen.

Finde ich eine valide Interpretation. Wobei ich sogar so weit gehen
würde und Nebenläufigkeit in Hardware nochmal für einen Tick schwieriger
halte als in Software (z.B. Timing-Disparitäten weil die Clock
Distribution innerhalb eines Chips nicht gut funktioniert). Und
natürlich auch deutlich schwieriger zu debuggen.

Allerdings muss man auch sagen, dass die Spectre/Meltdown
Verwundbarkeiten wohl laut internen Dokumenten durchaus einigen
Ingenieuren dort bewußt waren, nur eben vom Management heruntergespielt
wurden und, im Interesse der Performance, dann eben ignoriert wurden.

Aber, ja, ich stimme dir zu: Nebenläufigkeit ist richtig schwer, selbst
für Experten. Und einfache Lösungen sind oft inkorrekt.

Viele Grüße,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264205

Am 21.09.2019 um 09:57 schrieb Volker Bartheld:
> On Sat, 21 Sep 2019 08:32:43 +0200, Johannes Bauer wrote:
>> On 21.09.19 03:20, Rainer Knaepper wrote:
>>> Äh, niemand schreibt dabei gleichzeitig auf dieselbe Variable. Sonst
>>> wäre es ja kein /doppelter/ Puffer.
>> Naja, aber was passiert denn dann, wenn zwei Threads gleichzeitig
>> schreiben wollen [...] Die Frage ist dann auch noch, was passiert wenn
>> beide Threads gelesen haben, einer [...] auf der (jetzt veralteten)
>> Schattenkopie weiterrechnet und dann zurückschreibt.

Dann gehört der Programmierer erschossen, und auch derjenige, der einen 
Ablauf so hirnrissig organisiert hat. In einem ordentlichen Design gibt 
es einen (Task, Job...) der Daten erzeugt, und einen oder mehrer die 
darauf zugreifen.


> Falls sich also jemand anmaßt, das Thema als trivial abzutun, möge er
> hoffentlich bald ein wenig Demut lernen.

Auf welchem Mikrocontroller ist es ein Problem, atomare Zugriffe durch 
Abschalten der Interrupts zu implementieren, und mit lokalen Kopien 
weiterzuarbeiten?

DoDi

[toc] | [prev] | [next] | [standalone]

#264212

On 21.09.19 12:35, Hans-Peter Diettrich wrote:
> Am 21.09.2019 um 09:57 schrieb Volker Bartheld:
>> On Sat, 21 Sep 2019 08:32:43 +0200, Johannes Bauer wrote:
>>> On 21.09.19 03:20, Rainer Knaepper wrote:
>>>> Äh, niemand schreibt dabei gleichzeitig auf dieselbe Variable. Sonst
>>>> wäre es ja kein /doppelter/ Puffer.
>>> Naja, aber was passiert denn dann, wenn zwei Threads gleichzeitig
>>> schreiben wollen [...] Die Frage ist dann auch noch, was passiert wenn
>>> beide Threads gelesen haben, einer [...] auf der (jetzt veralteten)
>>> Schattenkopie weiterrechnet und dann zurückschreibt.
> 
> Dann gehört der Programmierer erschossen, und auch derjenige, der einen
> Ablauf so hirnrissig organisiert hat. 

Solche Parolen sind gut für deinen AfD-Stammtisch geeignet, aber für
einen sachliche Diskurs nicht zielführend.

> In einem ordentlichen Design gibt
> es einen (Task, Job...) der Daten erzeugt, und einen oder mehrer die
> darauf zugreifen.

Ja, ne. Die Welt dreht sich nicht nur darum, wiedewiediewie du sie gern
hättest. In der Praxis gibt es durchaus Probleme, die mehrere Quellen
und Senken haben, die miteinander synchronisiert werden möchten.

>> Falls sich also jemand anmaßt, das Thema als trivial abzutun, möge er
>> hoffentlich bald ein wenig Demut lernen.
> 
> Auf welchem Mikrocontroller ist es ein Problem, atomare Zugriffe durch
> Abschalten der Interrupts zu implementieren, und mit lokalen Kopien
> weiterzuarbeiten?

Auf Jedem. Interrupts abschalten ist DER Holzhammer schlechthin, den man
nur im absoluten Notfall nutzen sollte. Funktioniert zuverlässig und
einfach, hat aber gegenüber anderen Synchronisierungsmethoden auch
erhebliche Nachteile, die man evtl. nicht in Kauf nehmen möchte. Das ist
vom verwendeten SoC *komplett* unabhängig.

Lokale Kopien nutzen im Übrigen auch nur dann etwas, wenn garantiert
ist, dass sie nicht veraltet sind bzw man das entsprechend handelt.
Interrupts nur zum Lesen und Schreiben von geteilten Daten zu sperren
führt ebenso zu Nebenläufigkeitsproblemen.

Gruß,
Johannes
-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264324

On Sat, 21 Sep 2019 12:35:14 +0200, Hans-Peter Diettrich wrote:
> Auf welchem Mikrocontroller ist es ein Problem, atomare Zugriffe durch 
> Abschalten der Interrupts zu implementieren, und mit lokalen Kopien 
> weiterzuarbeiten?

Auf allen Echtzeitsystemen, die in einem Zugriff mehr als nur ein Byte
(oder was auch immer der native Datentyp ist) wegschreiben müssen. Aber es
geht doch auch gar nicht darum, jetzt einen Fall zu konstruieren, der
trivial mit diesem oder jenem Ansatz lösbar ist. Es geht darum, zu
veranschaulichen, daß Multithreading und sonstige Nebenläufigkeiten
prinzipiell zu den schwierigeren Programmieraufgaben gehören. Denn sonst
wäre das nicht in einem von mir einigermaßen willkürlich gewählten Beispiel
danebengegangen und seit Jahren (wenn nicht Jahrzehnten) ohne Fix
geblieben.

Wer unter euch ohne Sünde ist, der werfe den ersten Stein!

Volker

[toc] | [prev] | [next] | [standalone]

#264326

Am 23.09.19 um 13:52 schrieb Volker Bartheld:

> 
> Wer unter euch ohne Sünde ist, der werfe den ersten Stein!
> 

Comic in dem Berliner Stadtmagazin Zitty, so vor 30 Jahren:

Rüdiger (Knollennase, doof): Kieselchen nehm - vorsichtig werf -

Publikum:  Oh, die arme Sau! Nicht mal eine klitzekleine Sünde!..

[toc] | [prev] | [next] | [standalone]

#264328

On 23.09.19 13:52, Volker Bartheld wrote:

> Auf allen Echtzeitsystemen, die in einem Zugriff mehr als nur ein Byte
> (oder was auch immer der native Datentyp ist) wegschreiben müssen.
Würde ich sogar noch einen Tick allgemeiner sehen: Auf Systemen, auf
denen Multiprozessor-Skalierbarkeit wichtig ist, gilt das ja nämlich
auch. Linux hat richtig hart gearbeitet, das BKL (Big Kernel Lock)
loszuwerden: https://de.wikipedia.org/wiki/Big_Kernel_Lock und es mit
Version 3.0 (oder 2.6.xx) dann endlich geschafft.

Gruß,
JOhannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264331

Am 23.09.19 um 13:52 schrieb Volker Bartheld:

> Wer unter euch ohne Sünde ist, der werfe den ersten Stein!
> 
> Volker
> 

Wer zuerst trifft, lebt länger.

-- 
---hdw---

[toc] | [prev] | [next] | [standalone]

#264339

Am 23.09.2019 um 13:52 schrieb Volker Bartheld:
> On Sat, 21 Sep 2019 12:35:14 +0200, Hans-Peter Diettrich wrote:
>> Auf welchem Mikrocontroller ist es ein Problem, atomare Zugriffe durch
>> Abschalten der Interrupts zu implementieren, und mit lokalen Kopien
>> weiterzuarbeiten?
>
> Auf allen Echtzeitsystemen, die in einem Zugriff mehr als nur ein Byte
> (oder was auch immer der native Datentyp ist) wegschreiben müssen.

... und anscheinend über keine Interrupt-Abschaltung verfügen? Die halte 
ich aber für essentiell für so kleine Systeme wie hier genannt, die 
einfach nur Encoder abfragen sollen. Wenn jemand für diese Aufgabe ein 
OS und weiteren Pipapo benötigt, dann kann er das gerne in einem neuen 
Thread diskutieren, unter "Mit Kanonen auf Spatzen schießen".

> Aber es
> geht doch auch gar nicht darum, jetzt einen Fall zu konstruieren, der
> trivial mit diesem oder jenem Ansatz lösbar ist. Es geht darum, zu
> veranschaulichen, daß Multithreading und sonstige Nebenläufigkeiten
> prinzipiell zu den schwierigeren Programmieraufgaben gehören.

Unbestritten, aber solche Systeme betrachte ich nicht als 
Mikrocontroller. Wenn ein Prozessor Multithreading etc. erlaubt, und 
gleichzeitig Anspruch auf Echtzeitfähigkeit erhebt, dann hat der 
gefälligst auch Befehle für atomare Zugriffe zu implementieren, sonst 
ist das alles nur Marketinggeschwätz.

Ich weiß nicht ob es Intel war, die ein LOCK Prefix eingeführt haben. 
Für die Tasksynchronisation etc. gibt es noch CMPXCHG und ähnlich 
komfortable Befehle für Semaphore etc. Und wenn es die schon auf 
ordinären Controllern gibt, die keinen Anspruch auf Echtzeitfähigkeit 
erhebenn dann sieht man, wie weit dieses Thema vom Topic und der 
hiesigen NG weg ist.

DoDi

[toc] | [prev] | [next] | [standalone]

#264369

On Mon, 23 Sep 2019 19:29:22 +0200, Hans-Peter Diettrich wrote:
> Am 23.09.2019 um 13:52 schrieb Volker Bartheld:
>> On Sat, 21 Sep 2019 12:35:14 +0200, Hans-Peter Diettrich wrote:
>>> Auf welchem Mikrocontroller ist es ein Problem, atomare Zugriffe durch
>>> Abschalten der Interrupts zu implementieren, und mit lokalen Kopien
>>> weiterzuarbeiten?
>> Auf allen Echtzeitsystemen, die in einem Zugriff mehr als nur ein Byte
>> (oder was auch immer der native Datentyp ist) wegschreiben müssen.
> ... und anscheinend über keine Interrupt-Abschaltung verfügen?

Du schaltest also den Interrupt ab. Und serialisierst eine etwas größere
Datenstruktur. Währenddessen kann Dein Echtzeit(!)system aber nicht mehr
zeitgerecht reagieren. Also zerhackst Du die Datenstruktur und führst
einen Mutex, eine Critical Section oder sonst einen
Synchronisierungsansatz ein. Das blockt dann aber die Threads, die
möglicherweise auf den Ablageort der Datenstruktur zugreifen müssen. Ergo
erfindest Du Schattenkopien, ein Dirty-Bit, grübelst über Write-Through
und Write-Back, usw. Ich will damit sagen: Multithreading ist schwierig.

Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz einfache
Lösung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
sonst abbildet. Ich bin ja ausbildungsmäßig Physiker und kein IT-Profi.

> Die halte ich aber für essentiell für so kleine Systeme wie hier genannt,
> die einfach nur Encoder abfragen sollen. Wenn jemand für diese Aufgabe
> ein OS und weiteren Pipapo benötigt, dann kann er das gerne in einem
> neuen Thread diskutieren, unter "Mit Kanonen auf Spatzen schießen".

Das Usenet ist aber leider kein Wunschkonzert. Für den Task
"Quadrature-Encoder abfragen" würde ich - verzeih - {Quadrature, Encoder,
Arduino} in der Suchmaschine meines geringsten Mißtrauens eingeben und mir
anschauen, wie das - vermutlich - schon 1001x gelöst wurde. Als da wären:

https://github.com/PaulStoffregen/Encoder
http://www.hessmer.org/blog/2011/01/30/quadrature-encoder-too-fast-for-arduino-with-solution/
https://www.rs-online.com/designspark/quadrature-encoder-basics-part-1-theory
https://playground.arduino.cc/Main/RotaryEncoders/
https://howtomechatronics.com/tutorials/arduino/rotary-encoder-works-use-arduino/
https://cdn.sparkfun.com/datasheets/Robotics/How%20to%20use%20a%20quadrature%20encoder.pdf

Anstatt mir über potentiell geniale Eigenkreationen das Hirn zu zermartern.
Weil ich nicht am Not-Invented-Here-Syndrom leide.

> Unbestritten, aber solche Systeme betrachte ich nicht als 
> Mikrocontroller. Wenn ein Prozessor Multithreading etc. erlaubt, und 
> gleichzeitig Anspruch auf Echtzeitfähigkeit erhebt, dann hat der 
> gefälligst auch Befehle für atomare Zugriffe zu implementieren, sonst 
> ist das alles nur Marketinggeschwätz.

Je nun. Ich baute mal einen Klon des Photoduino:
https://photoduino.com/documentation/hardware/photoduino-shield-3-0/
, fand heraus, daß das Display (präzise: die Hintergrundbeleuchtung) den
meisten Strom frißt. Was unpraktisch bei Langzeit-Zeitrafferaufnahmen an
der frischen Luft war. Ergo der naheliegendste Plan, einen Interrupt dafür
zu verwenden, die Hintergrundbeleuchtung nach einer gewissen Zeit
abzuschalten und bei Tastendruck oder sonstigen nennenswerten Ereignissen
wieder an.

Irgendwann ist mir aufgefallen, daß in einem anderen Anwendungsfall -
nämlich der Hochgeschwindigkeitsfotografie - ein gewisser Jitter vorhanden
ist, der das Timing zwischen Triggerevent und Auslösung des Blitzes
versaut. Der ADC vielleicht? Irgendwas in der Auslöselogik? Die
Verschlußsteuerung der Kamera selbst? Fragen über Fragen. Schließlich war
es von allem ein bißchen und natürlich auch der
Hintergrundbeleuchtungsinterrupt, wo eigentlich nur andere Interrupte
deaktiviert und ein simples Bit an den PWM-Ausgang des Arduino geschrieben
wurde.

Blöd gelaufen.

Volker

[toc] | [prev] | [next] | [standalone]

#264370

On 24.09.19 10:43, Volker Bartheld wrote:

> [...] Ich will damit sagen: Multithreading ist schwierig.
> 
> Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz einfache
> Lösung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
> sonst abbildet. Ich bin ja ausbildungsmäßig Physiker und kein IT-Profi.

Nicht verkopft, sondern den Nagel voll und ganz auf den Kopf getroffen.

Der unschlagbare Vorteil vom Sperren von Interrupts ist, dass es die
aller, allereinfachste Synchronisationsprimitive ist, die man verwenden
kann. Funktioniert absolut sicher. Die Nachteile sind aber eben genauso
gravierend und erfordern dann (wie in deinen Beispielen geschildert)
eventuell entsprechende Gegenmaßnahmen, die dann die Komplexität extrem
aufblasen können.

Viele Grüße,
Johannes

-- 
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

[toc] | [prev] | [next] | [standalone]

#264371

On 24.09.19 10:43, Volker Bartheld wrote:

> Du schaltest also den Interrupt ab. Und serialisierst eine etwas größere
> Datenstruktur. Währenddessen kann Dein Echtzeit(!)system aber nicht mehr
> zeitgerecht reagieren.

Kommt auf die Anforderungen an. "Echtzeit" heißt ja nur, daß man eine 
garantierte Antwortzeit hat, aber nicht, welche das ist. Wenn der 
kurzzeitig abgeschaltete Interrupt innerhalb einer klar definierten (und 
nicht zu großen) Zeit wieder da ist, und hardwaretechnisch gewährleistet 
ist, daß keine Interrupts verloren gehen, kann das schon mit geringem 
Aufwand zielführend sein.

Mit verschiedenen und überlappenden Interrupts wird es dann wieder 
schwierig. Allerdings in jedem Fall.

Hanno

[toc] | [prev] | [next] | [standalone]

#264373

Am 24.09.2019 um 10:43 schrieb Volker Bartheld:
> On Mon, 23 Sep 2019 19:29:22 +0200, Hans-Peter Diettrich wrote:
>> Am 23.09.2019 um 13:52 schrieb Volker Bartheld:
>>> On Sat, 21 Sep 2019 12:35:14 +0200, Hans-Peter Diettrich wrote:
>>>> Auf welchem Mikrocontroller ist es ein Problem, atomare Zugriffe durch
>>>> Abschalten der Interrupts zu implementieren, und mit lokalen Kopien
>>>> weiterzuarbeiten?
>>> Auf allen Echtzeitsystemen, die in einem Zugriff mehr als nur ein Byte
>>> (oder was auch immer der native Datentyp ist) wegschreiben müssen.
>> ... und anscheinend über keine Interrupt-Abschaltung verfügen?
>
> Du schaltest also den Interrupt ab.

Ja.

> Und serialisierst eine etwas größere Datenstruktur.

Nein. Interrupts ändern immer nur kleine Dateneinheiten, alles andere 
wäre Murks. Deine Einwände deuten offensichtlich in diese Richtung...

DoDi

[toc] | [prev] | [next] | [standalone]

#264375

Am 24.09.19 um 10:43 schrieb Volker Bartheld:
> On Mon, 23 Sep 2019 19:29:22 +0200, Hans-Peter Diettrich wrote:

> Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz einfache
> Lösung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
> sonst abbildet. Ich bin ja ausbildungsmäßig Physiker und kein IT-Profi.

Die Welt braucht mehr CPUs. Jede nur für einen überschaubaren Zweck.

Im BeagleBoneBlack hat das für mich sehr schön funktioniert.
Ein GHz-ARM für Linux und 2 PRUs für die Drecksarbeit. Die PRUs sind
andere RISCs ohne Pipeline, die man stallen könnte. Dafür nur 200 MHz,
aber man kann im 5 ns-Raster Flanken erzeugen. Alles geht taktgenau.
Jede PRU hat 32-Bit-Register mit denen man fast direttissima auf
einige Pins und Devices zugreifen kann. Interrupts gibt's nicht
wirklich für die PRUs, aber dual port buffers zum ARM.

Mit einem popeligen Coolrunner2-IF kann ich 3 LTC2500-32 ADCs mit
jeweils 100 MHz-SPI auslesen, ohne dass was verloren geht.


> Irgendwann ist mir aufgefallen, daß in einem anderen Anwendungsfall -
> nämlich der Hochgeschwindigkeitsfotografie - ein gewisser Jitter vorhanden
> ist, der das Timing zwischen Triggerevent und Auslösung des Blitzes
> versaut. Der ADC vielleicht? Irgendwas in der Auslöselogik? Die
> Verschlußsteuerung der Kamera selbst? Fragen über Fragen. Schließlich war
> es von allem ein bißchen und natürlich auch der
> Hintergrundbeleuchtungsinterrupt, wo eigentlich nur andere Interrupte
> deaktiviert und ein simples Bit an den PWM-Ausgang des Arduino geschrieben
> wurde.
> 
> Blöd gelaufen.

Passiert auch den Besten.
Tektronix hatte mal ein ultraschnelles sampling scope, wo der
Aperturjitter im Takte einer nicht sehr wichtigen Warn-LED
um ein paar ps herumgetanzt ist.

Gruß, Gerhard

[toc] | [prev] | [next] | [standalone]

#264386

news2019@bartheld.net (Volker Bartheld)  am 24.09.19 um 10:43:

> Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz
> einfache Lösung, wie man die Echtzeitanforderung bei abgeschalteten
> Interrupts sonst abbildet.

Echtzeit bedeutet nicht "jederzeit" oder "unfaßbar schnell" oder
"zwischen jedem einzelnen Professortakt reaktionsfähig", sondern nur
"stets mit vorhersagbarer maximaler Reaktionszeit".

Wenn eine Uralt-SPS einen eine ms langen oder gar noch langsameren
Zyklus schafft, diesen aber /garantiert/, dann ist das halt "Echtzeit"
mit einer ms Auflösung.

Wer mit einem 8-bit-AVR nun unbedingt 48-bittig rechnen will, der kann
halt keine "Echtzeit" zwischen jedem Registerzugriff bei einer
Plutimikation garantieren, sondern eben nur alle 384 (Hausnummer!)
Prozessortakte. Wenn der Zwerg halt fertig ist mit der
Bitumherschieberei. Gerät der Kleine ins Stottern, muß man was
dickeres nehmen und/oder schlauer programmieren.

Aber dieses Thema hatten wir hier schon dermaßen oft, daß mich
wundert, daß es da immer noch Verständnisprobleme gibt.

Rainer

-- 
Muss man denn wirklich, um den Geschmack von Milch zu kritisieren,
selber Kuh sein?           (Tom! Striewisch in de.rec.fotografie)

[toc] | [prev] | [next] | [standalone]

#264391

Am 24.09.2019 um 19:01 schrieb Rainer Knaepper:
> news2019@bartheld.net (Volker Bartheld)  am 24.09.19 um 10:43:
>
>> Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz
>> einfache Lösung, wie man die Echtzeitanforderung bei abgeschalteten
>> Interrupts sonst abbildet.
>
> Echtzeit bedeutet nicht "jederzeit" oder "unfaßbar schnell" oder
> "zwischen jedem einzelnen Professortakt reaktionsfähig", sondern nur
> "stets mit vorhersagbarer maximaler Reaktionszeit".

Letzteres gefällt mir noch nicht so richtig, denn man kann jedes System 
mit zu vielen häufigen Interrupts überlasten. Tatsächlich kann nur 
vorgegeben werden, wie lange die Bearbeitung eines Interrupts maximal 
dauern darf. Für länger dauernde Operationen muß die Priorität des 
Handlers heruntergesetzt werden, oder noch besser die lange Verarbeitung 
in eine normale Task ausgelagert werden, damit der Handler keine 
Probleme mit Reentrancy bekommt.


> Aber dieses Thema hatten wir hier schon dermaßen oft, daß mich
> wundert, daß es da immer noch Verständnisprobleme gibt.

Immer wieder gern ;-)

DoDi

[toc] | [prev] | [next] | [standalone]

#264440

DrDiettrich1@aol.com (Hans-Peter Diettrich)  am 24.09.19:

> Am 24.09.2019 um 19:01 schrieb Rainer Knaepper:
>> news2019@bartheld.net (Volker Bartheld)  am 24.09.19 um 10:43:
>>
>>> Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz
>>> einfache Lösung, wie man die Echtzeitanforderung bei
>>> abgeschalteten Interrupts sonst abbildet.
>>
>> Echtzeit bedeutet nicht "jederzeit" oder "unfaßbar schnell" oder
>> "zwischen jedem einzelnen Professortakt reaktionsfähig", sondern
>> nur "stets mit vorhersagbarer maximaler Reaktionszeit".

> Letzteres gefällt mir noch nicht so richtig, denn man kann jedes
> System mit zu vielen häufigen Interrupts überlasten. Tatsächlich
> kann nur vorgegeben werden, wie lange die Bearbeitung eines
> Interrupts maximal dauern darf. Für länger dauernde Operationen muß
> die Priorität des Handlers heruntergesetzt werden, oder noch besser
> die lange Verarbeitung in eine normale Task ausgelagert werden,
> damit der Handler keine Probleme mit Reentrancy bekommt.

Genau in so eine Falle bin ich ja mal in einem früheren Leben
hineingerannt. Das ganze System basierte auf einem Taktgeber aus einer
RTC und interruptete halt mit 64 Hz. Die komplette Ablaufsteuerung
steckte in der ISR.

Funktionierte auch gut, aber dann kam $Chefänderungswunsch1,
$Kundenerweiterungswunsch2 und "können wir nicht jene Funktion noch
hinzupacken" sowie "$GanzAnderesGerät können wir doch auch auf der
Basis steuern" - und schwupps reichten die 16ms nicht mehr zur
Abarbeitung.

Was dann einen großzügigen Umbau des gesamten Konzepts erforderte :-)

>> Aber dieses Thema hatten wir hier schon dermaßen oft, daß mich
>> wundert, daß es da immer noch Verständnisprobleme gibt.

> Immer wieder gern ;-)

Ich schaue halt aus Elektrikerperspektive auf die Thematik, nicht
informationstheoretisch.

Rainer

-- 
Man sollte überhaupt keine Tests mehr lesen...
(Stefan Krah in de.comp.hardware.kuehlung+laermdaemmung)

[toc] | [prev] | [next] | [standalone]

#264468

Am 24.09.2019 um 10:43 schrieb Volker Bartheld:
> On Mon, 23 Sep 2019 19:29:22 +0200, Hans-Peter Diettrich wrote:
>> Am 23.09.2019 um 13:52 schrieb Volker Bartheld:
>>> On Sat, 21 Sep 2019 12:35:14 +0200, Hans-Peter Diettrich wrote:
>>>> Auf welchem Mikrocontroller ist es ein Problem, atomare Zugriffe durch
>>>> Abschalten der Interrupts zu implementieren, und mit lokalen Kopien
>>>> weiterzuarbeiten?
>>> Auf allen Echtzeitsystemen, die in einem Zugriff mehr als nur ein Byte
>>> (oder was auch immer der native Datentyp ist) wegschreiben müssen.
>> ... und anscheinend über keine Interrupt-Abschaltung verfügen?
>
> Du schaltest also den Interrupt ab. Und serialisierst eine etwas größere
> Datenstruktur.

Ein Bekannter hat dafür noch eine Lösung aus BASIC Zeiten: verwendet 
wird ein Ringpuffer, in dem immer nur unterschiedliche Einträge gelesen 
und geschrieben werden. Das geht auch mit einem Wechselpuffer, wenn der 
Consumer via Flag den gerade beschriebenen Puffer auf read-only 
schaltet, und der Producer in den anderen - jetzt write-only - Puffer 
schreibt.

> Währenddessen kann Dein Echtzeit(!)system aber nicht mehr
> zeitgerecht reagieren.

Es muß ja nur derjenige Interrupt blockiert werden, der (s)einen Teil 
der Daten ändert. Das kann nicht zum Verlust von Interrupts führen, denn 
was könnte ein Interrupt-Handler in der Zeit erledigen, die der 
Hauptthread für das Kopieren von ein paar Bytes in Register braucht?


> Aber vermutlich überkopfe ich das auch nur und es gibt eine ganz einfache
> Lösung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
> sonst abbildet.

Es kann doch keinen großen Unterschied ausmachen, ob jetzt ein Interrupt 
von einer Kopieraktion oder einem anderen Interrupt vorübergehend 
blockiert wird? So viel Zeit muß in einem ausreichend schnellen 
Echtzeitsystem übrig sein.

DoDi

[toc] | [prev] | [next] | [standalone]

#264760

Hans-Peter Diettrich <DrDiettrich1@aol.com>:

>> Aber vermutlich berkopfe ich das auch nur und es gibt eine ganz einfache
>> L”sung, wie man die Echtzeitanforderung bei abgeschalteten Interrupts
>> sonst abbildet.
> 
> Es kann doch keinen groáen Unterschied ausmachen, ob jetzt ein Interrupt 
> von einer Kopieraktion oder einem anderen Interrupt vorbergehend 
> blockiert wird? So viel Zeit muá in einem ausreichend schnellen 
> Echtzeitsystem brig sein.

Gehen wir mal zum ursprünglichen Thema zurück: Abtastung eines 
Quadraturencoders. Den möchte ich so schnell wie eben möglich abtasten und da 
kommt man dann schon an seine Grenzen, wenn man sagt: ok Porzessortakt sind 8 
MHz, er schafft es in 8 Takten einen Interrupt abzuarbeiten, also könnte er 
theoretisch mit 1 MHz ein Portpin abtasten. Damit wäre er zu 100% 
ausgelastet. Wenn er dann doch noch (wenige) andere Dinge tun soll, wären 
vermutlich maximal 500kHz sinnvoll. Wenn das Restprogramm komplex ist und 
etliche andere Interrupts laufen und womoeglich auch noch eine DMA den 
Speicher blockiert, dann ist man ganz schnell bei nur 20kHz angelangt, die 
das System noch schafft. ;-) Da ist eine integrierte Hardwarelösung für den 
Encoder doch _deutlich_ programmiererfreundlicher. :-) :-)

M.
-- 

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | de.sci.electronics

csiph-web