mikrocontroller mit mehr als einem Quadrature-Decoder Timer

Am 20.09.2019 um 07:50 schrieb Matthias Weingart:

Ahhh, da steckt das! Danke. Sogar der LowPower-Timer kann Encoder-Mode.
Damit kann dann z.B. sogar der nur 32 pinnige STM32L0 sogar 4 Encoder (sofern
man einen Timer nicht fĂźr andere Zwecke braucht).

Falls man neben den 4 Encodern noch weitere Timer benĂśtigt, nimmt man
halt einen STM32L0 mit mehr Timern. IM LQFP 32 sind maximal 7 verfĂźgbar.
 
On 20 Sep 19 at group /de/sci/electronics in article qm1nsd$pkj$1@news.albasani.net
<thorsten_nospam@gmx.net> (Thorsten Böttcher) wrote:

Am 19.09.2019 um 15:39 schrieb Matthias Weingart:

Naja mit Port-Interrupts - das hab ich schön bleiben lassen. Zuverlässig

Ich hab das vor Jahren mal so gemacht, 3 Drehgeber in einem System,
Interrupt auf die steigende Flanke. Im Interrupt den 2. Pin gelesen und
daran entschieden ob ich inkrmentieren oder dekrementieren muss.
Das hat immer Problemlos funktioniert, und ist IMHO noch heute im Einsatz.

me too :) encoder von hp



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! :p
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
 
On 20 Sep 19 at group /de/sci/electronics in article XnsAAD0510A4DA3DAlwLookOnTBrightSide@penthouse.boerde.de
<mwnews@pentax.boerde.de> (Matthias Weingart) wrote:

Naja das n?tzt ja nix, wenn in der Hauptschleife
DINT;
"tu was kritisches";
EINT;
gekapselt werden muss. Z.B. wenn man 64bit Variablen auf einem 8 bit System
sauber und sicher lesen will, die in einem Interrupt ver?ndert werden.

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


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! :p
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
 
On 20.09.19 13:04, Wolfgang Allinger wrote:

Naja das n?tzt ja nix, wenn in der Hauptschleife
DINT;
"tu was kritisches";
EINT;
gekapselt werden muss. Z.B. wenn man 64bit Variablen auf einem 8 bit System
sauber und sicher lesen will, die in einem Interrupt ver?ndert werden.

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

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

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.
 
On 19.09.19 16:52, Hans-Peter Diettrich wrote:
Am 19.09.2019 um 15:39 schrieb Matthias Weingart:

Naja mit Port-Interrupts - das hab ich schön bleiben lassen.

Ja wenn Du so ein Experte bist, kann ich diesen Thread ja killen.

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

Gruß,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.
 
mwnews@pentax.boerde.de (Matthias Weingart) am 20.09.19 um 05:58:

gekapselt werden muss. Z.B. wenn man 64bit Variablen auf einem 8
bit System sauber und sicher lesen will, die in einem Interrupt
verändert werden.

double buffer?

Rainer

--
Daten sind gasförmig. Sie nehmen binnen kürzester Zeit den
maximal verfügbaren Platz ein. Und nun die weniger gute
Nachricht: sie geben ihn nicht kampflos wieder her!
(Benedict Mangelsdorff in ger.ct)
 
On 20.09.19 16:26, Rainer Knaepper wrote:
mwnews@pentax.boerde.de (Matthias Weingart) am 20.09.19 um 05:58:

gekapselt werden muss. Z.B. wenn man 64bit Variablen auf einem 8
bit System sauber und sicher lesen will, die in einem Interrupt
verändert werden.

double buffer?

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

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.
 
On 20 Sep 19 at group /de/sci/electronics in article qm2ei5$m8r$1@dont-email.me
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

On 20.09.19 13:04, Wolfgang Allinger wrote:

Naja das n?tzt ja nix, wenn in der Hauptschleife
DINT;
"tu was kritisches";
EINT;
gekapselt werden muss. Z.B. wenn man 64bit Variablen auf einem 8 bit
System sauber und sicher lesen will, die in einem Interrupt ver?ndert
werden.

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

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.

Du bist und bleibst ein großmäuliger Schwätzer und Obermurkser.
Damit Du es besser verstehst: Arschloch, krummbohrtes!

Du fummelst an Hochspannungs Systemen, ohne die geringste Ahnung. Ich
erinnere an Deine Unfähigkeit, Datenblätter und Zeichnungen zu lesen, es
handelte sich um einen FET für 600V.

Hier geht es um Drehencoder an einen ľC, nicht um irgendeinen Scheiß in
Deiner hochperformanten Engstirnigkeit.

Latürnich wird das auslesen eines 64bit Wertes der IR Ebene nur an einer
Stelle gemacht und dann nur an einer Stelle in den Variablenspeicher für
das Backgroundprogramm geschrieben.
FORTH und Kooperatives Multitasking macht da nicht die geringsten
Probleme, vor allem, wenn man MultiLevel und Multisources IR in harter
Echtzeit programmieren kann.
Aber das kannst Du auch nicht, geschweige denn es begreifen.

BTW ein Teil meiner so (mit)entwickelten Geräte (HW&SW) sind vom TÜV, Eex-
Prüfstellen, UL usw. abgenommen und werden/wurden u.a. weltweit verwendet
in Hochsichertheitsbereichen wie KKW, Brennelemente Fertigung, Offshore,
Pipeline, Raffinerien, Chemiewerken (Bayer, BASF...), Intensivmedizin,
Aerospace (NASA Space Shuttle, NortonThiokol, Bell Helicopter, Ariane,
Airbus...), Stahlindustrie, USMC, Bundeswehr, Rheinmetall, KMWeg,
BritishRail, Verkehrsteuerungen etc.pp. In über 40a kam da einiges
zusammen. Nein brauchst nicht nach Einzelheiten zu fragen, fast 100% NDA.

Und diese Firmen und Vereine schauen sich jede Zeile des Quellcodes x-mal
an, bevor sie das ok geben. Und wehe die stellen fest, dass Du was von
600V fabulierst, ohne einen Hauch von Hintergrund.

Hast Du eine Ahnung, was UL zB. für einen Zirkus macht? Die zeichnen sich
aus durch absolut null Kreativität und ersetzen Kompetenz durch Popanz.

Ich stand schon 2x vor Gericht. Bevor Du Dich jetzt freust: um als
Gutachter so Schablonenschwätzer wie Dich zu entlarven :p


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! :p
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot
 
dfnsonfsduifb@gmx.de (Johannes Bauer) am 20.09.19 um 16:56:

On 20.09.19 16:26, Rainer Knaepper wrote:
mwnews@pentax.boerde.de (Matthias Weingart) am 20.09.19 um 05:58:

gekapselt werden muss. Z.B. wenn man 64bit Variablen auf einem 8
bit System sauber und sicher lesen will, die in einem Interrupt
verändert werden.

double buffer?

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.

Äh, niemand schreibt dabei gleichzeitig auf dieselbe Variable. Sonst
wäre es ja kein /doppelter/ Puffer.

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

--
(damals...) Wer Spitzenleistung braucht, kauft SCSI. Wem SCSI zu
teuer ist, der braucht keine Spitzenleistung.
(Richard Könning in d.c.h.l.f)
 
On 21.09.19 00:15, Wolfgang Allinger wrote:
Nee, Wolfgang, so macht man es definitiv NICHT, wenn man
deterministische Systeme baut.

Hier geht es um Drehencoder an einen µC, nicht um irgendeinen Scheiß in
Deiner hochperformanten Engstirnigkeit.

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

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.
 
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 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.

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.

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


--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.
 
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. [...] ich würde
sagen Nebenläufigkeit ist eines der schwierigsten Informatik-Probleme
und führt selbst bei Programmieren mit jahrzehntelanger Erfahrung noch
zu Bugs. [...]

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:

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.

Vielleicht haben sie ja am MIT studiert :-D

https://www.youtube.com/watch?v=aIhk9eKOLzQ

Manche halten das fĂźr'n fake.
Ich denke, es ist echt.

Gruß Andreas
 
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.
 
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
 
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.
 
Hi Andreas,

Vielleicht haben sie ja am MIT studiert :-D

https://www.youtube.com/watch?v=aIhk9eKOLzQ

Manche halten das fĂźr'n fake.
Ich denke, es ist echt.

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:
Hi Andreas,

Vielleicht haben sie ja am MIT studiert :-D

https://www.youtube.com/watch?v=aIhk9eKOLzQ

Manche halten das fĂźr'n fake.
Ich denke, es ist echt.

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.

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
 
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.
 
Hallo Andreas,

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

Register ich ver�ndern muss, um einen Timer auf Quadrature-Modus zu
bekommen. Was hast Du da eingestellt?
....
Klick auf einen Timer, der das unterstĂźtzt (z.B. TIM2).
Bei Combined Channels kann man dann "Encoder Mode" auswählen.

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

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

Welcome to EDABoard.com

Sponsor

Back
Top