mikrocontroller mit mehr als einem Quadrature-Decoder Timer

me too :) encoder von hp

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

Einfach 2x lesen und vergleichen, wenn ungleich, nochmal.

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

Der König der Pfuscher am Werk. Von Nebenläufigkeit offenbar nicht die geringste Ahnung, aber einen auf Meisterprogrammierer machen.

Nee, Wolfgang, so macht man es definitiv NICHT, wenn man deterministische Systeme baut.

Gruß, Johannes

Dein "Experten"rat wird sicherlich schmerzlich vermisst werden. Damit hast du's Matthias dann so richtig gezeigt.

Gruß, Johannes

snipped-for-privacy@pentax.boerde.de (Matthias Weingart) am 20.09.19 um 05:58:

double buffer?

Rainer

Nützt wirklich nur, wenn du atomisch hin- und herschalten kannst (in der zusätlichen Zeiger-Variablen) und immer klar ist, wer auf die geteilte Variable schreibt.

In den ganzen Fällen, in denen der Zugriff nicht atomar erfolgt, hast du eine Race Condition, egal was du machst -- man kann in Software die Wahrscheinlichkeit kleiner machen, dass sie ein Problem ist (z.B. mehrfacher Zugriff/Plausibilisierung), aber die Race Condition bleibt, deswegen ist das Pfusch.

Gruß, Johannes

snipped-for-privacy@gmx.de (Johannes Bauer) am 20.09.19 um 16:56:

Aber was weiß ich schon. Mache ja nur Bastelkram in Assembler, und da isses ziemlich einfach, zu verhindern, dass ein Interrupt einen Speicherbereich oder Register verändert, welche(n) ich gerade anderweitig benötige.

Rainer

Es ist egal, ob du an HPC Pfuschst oder bei einem Drehencoder-Code. Dein Tipp "einfach zweimal lesen und vergleichen" ist grotesker Müll. Pfusch, den ich schon hundertmal gesehen habe, bei Amateuren, und moniert. Pfusch, der in SIS-Systemen dazu führen kann, dass Leute sterben, weil so Dummköpfe wie du, denken, sie kapieren was die Maschine tut.

Das weiß jeder Informatik-Erstsemester, der eine Vorlesung über Systemprogrammierung gehört hat. Der mal das Leser/Schreiber Problem selber implementiert hat. Das Glück hattest du wohl nicht und postulierst also "Lösungen", die demonstrierbar defekt sind. Das könnte ich dir sogar als Klacks in Code beweisen, aber du ignorierst harte Evidenz ja ohnehin, deswegen spare ich mir die Mühe.

Tu dir was Gutes und les mal TAOCP, mein lieber Freund. Alles Gute, Johannes

Naja, aber was passiert denn dann, wenn zwei Threads gleichzeitig schreiben wollen bzw einer während des Schreibvorgangs verdrängt wird? Dann schreiben eben beide auf die "Schatten" Variable und es knallt.

Kann man natürlich z.B. als einfachste Variante verhindern, wenn man während des Schreibzugriffs den anderen Thread sperrt (z.B. sei/cli), aber gibt natürlich auch schickere Möglichkeiten.

Die Frage ist dann auch noch, was passiert wenn beide Threads gelesen haben, einer zurückschreibt und dann der erste Thread auf der (jetzt veralteten) Schattenkopie weiterrechnet und dann zurückschreibt. Dann knallt es evtl eben auch. Also muss man sich da auch was überlegen.

Hm naja ich würde sagen Nebenläufigkeit ist eines der schwierigsten Informatik-Probleme und führt selbst bei Programmieren mit jahrzehntelanger Erfahrung noch zu Bugs. Deswegen gibt es ja auch so viele Ansätze, das einfacher zu machen, die alle nur so mehr oder weniger gut funktionieren (Monitore z.B., im Embedded Umfeld dann eben deterministisches Scheduling von Coroutinen, z.B. Priority Ceiling Protocol, etc).

Viele Grüße, Johannes

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.

Vol"Oans-Zwoa-Drei-Gsuffa!"ker

Am 21.09.2019 um 09:57 schrieb Volker Bartheld:

Vielleicht haben sie ja am MIT studiert :-D

Gruß Andreas

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

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.

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

DoDi

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

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.

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

Hi Andreas,

Das ist sicher echt, wenngleich wahrscheinlich eben selektiert. Ich hab von einem MINT-Didaktiker mal eine Schulung bekommen. Die haben unter Studenten und Doktoranden verschiedener Fachrichtungen einen Test gemacht, in dem es um reihen und Parallelschaltungen von gleichartigen Glühlampen ging verbunden mit der Frage, welche der Lampen leuchten heller, bzw gleich hell. Die Ergebnisse haben die sehr fein ausgewertet, um auf die typischen Verständnisfehler vorzudringen. Die Quote von Falschaussagen war nahezu gleich hoch, egal, ob es Elektrotechnikstudierende oder angehende Physiker, Maschinenbauer ud andere waren.

Marte

Am 21.09.2019 um 13:39 schrieb Marte Schwarz:

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.

Gruß Andreas

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

Hallo Andreas,

Du schriebst am Thu, 19 Sep 2019 20:39:06 +0200:

...

Wieso heißt eine Funktion zum _De_kodieren eines Signal(paare)s bei diesen Dingern eigentlich _En_coder? Hat da jemand was verwechselt?

Hallo Thorsten,

Du schriebst am Fri, 20 Sep 2019 07:25:33 +0200:

Sicher geht das bei einem "richtigen" Encoder so, da prellt auch nichts. Es geht halt so nicht "so gut", wenn man das mit so einem Fingerdrehknopf machen soll, der einfach ein paar mechanische Kontaktfederlen mit einer Plastikscheibe auf- und zudrückt. Also solche Dinger, wie sie inzwischen in fast jedem neueren Meßgerät (Oszilloskop, z.B.) zum Einstellen der Meßparameter sitzen.