Ich muss für einen Projekt eine Compare Schaltung bauen. Ich habe eine 10 bit Parallele digitale Signal Leitung, und das muss ich mit eine 10 bit Value vergleichen und sobald übereinstimmt eine einzige on/off Signal generieren. Also eine AND Schaltung mit 2x10 Eingängen und 1 Ausgang. Problem dabei ist, dass es mit absolut möglichst kürzeste Verzögerungszeit laufen soll. Wie kann man es verwirklichen, mit transistor, igbt, cpld,fpga,..?
Alaatdin Ö. schrieb: > mit absolut möglichst kürzeste Verzögerungszeit Millisekunden, Mikrosekunden oder Nanosekunden? Es macht schon Sinn, sich wenigstens mal grob zu den Rahmenbedingungen zu äußern.
:
Bearbeitet durch User
Joe F. schrieb: > Alaatdin Ö. schrieb: >> mit absolut möglichst kürzeste Verzögerungszeit > > Millisekunden, Mikrosekunden oder Nanosekunden? > Es macht schon Sinn, sich wenigstens mal grob zu den Rahmenbedingungen > zu äußern. Auf jeden Fall Unter nano Sekunden. Es geht nicht darum um eine bestimmte Zeit zu erreichen sondern maximal mögliche kürzeste Schaltzeit zu erreichen. Egal micro nano pico, wenn möglich sogar 0 Zeit :-)
Naja, komm. Wo kommt denn das 10-Bit Signal her? Das hat ja auch seinen Takt und damit eine bestimmte Verzögerung. Wenn es z.B. von einem 100 KHz ADC kommt, macht es kaum Sinn, die nachfolgende Verarbeitung auf Nano-Sekunden zu trimmen.
Und welche Logik denn diese 10 Bit liefert. CMOS, ECL, LVCMOS, LVECL ..
Alaatdin Ö. schrieb: > Es geht nicht darum um eine > bestimmte Zeit zu erreichen sondern maximal mögliche kürzeste Schaltzeit > zu erreichen. Egal micro nano pico, wenn möglich sogar 0 Zeit :-) Gut, dann nimmst Du am besten einen mit flüssigem Helium gekühlten, supraleitenden ASIC, der in einem für dieses Problem speziell entwickeltem Halbleiterprozess hergestellt wurde. Damit dürftest Du die mit der aktuell verfügbaren Technik besten Schaltzeiten erreichen. Du musst halt einfach nur ein paar Milliarden Euro in die Entwicklung des Prozesses und den Bau der passenden Fab investieren.
Ich habe eine Parallele Digital Encoder mit 10 bit Auflösung. Da ist kein Takt Signal. Der Encoder stellt die aktuelle Position ständig auf die Leitung ohne Takt. Wenn eine bestimmte Position erreicht wird, soll durch ein Signal eine FPGA eingestaltet werden und FPGA soll bestimmte Messungen durchführen , bis eine andere Position erreicht wird. Deshalb ist die Aufgabe mit heutige Komponenten machbar kürzeste Schaltzeit zu erreichen.
Alaatdin Ö. schrieb: > Ich habe eine Parallele Digital Encoder mit 10 bit Auflösung. Da > ist > kein Takt Signal. Der Encoder stellt die aktuelle Position ständig auf > die Leitung ohne Takt. > Wenn eine bestimmte Position erreicht wird, soll durch ein Signal eine > FPGA eingestaltet werden und FPGA soll bestimmte Messungen durchführen > , bis eine andere Position erreicht wird. Deshalb ist die Aufgabe mit > heutige Komponenten machbar kürzeste Schaltzeit zu erreichen. Einen 10bit-Vergleicher im FPGA, sollte sogar ein Anfaenger hinbekommen. Die externe Variante habe ich gepostet.
Alaatdin Ö. schrieb: > Auf jeden Fall Unter nano Sekunden. Also unterhalb der Flankenanstiegszeit. Aha. Mit anderen Worten: Du hast Dich kein Stück mit den realen Anforderungen beschäftigt und keinen E-technik Background. Alaatdin Ö. schrieb: > Ich habe eine Parallele Digital Encoder mit 10 bit Auflösung. Da ist > kein Takt Signal. Der Encoder stellt die aktuelle Position ständig auf > die Leitung ohne Takt. Ich schmeiss mich wech ... Erkennung in 0Zeit und kein Taktsignal. D.H. jeder Momentanwert der unterschiedlich schnell ansteigenden 10 Flanken soll einen gültigen Trigger ergeben. Fang noch mal bei Null an. Beschreibe Dein Problem, das reale Umfeld, die harten Anforderungen und frage dann hier nach der besten Art das Ziel zu erreichen.
Michael K. schrieb: > Fang noch mal bei Null an. > Beschreibe Dein Problem, das reale Umfeld, die harten Anforderungen und > frage dann hier nach der besten Art das Ziel zu erreichen. Ich warte noch auf den Hinweis das es nix kosten darf;-) Alaatdin Ö. schrieb: > Auf jeden Fall Unter nano Sekunden. > Egal micro nano pico, wenn möglich sogar 0 Zeit :-) Ja was denn nun...micro pico ist schon mal Faktor 1000000. Du solltest schon konkrete und realistische Anforderungen stellen. Wie groß darf der Aufwand sein, wie sieht dein eigener Lösungsansatz aus?
STK500-Besitzer schrieb: > Alaatdin Ö. schrieb: >> Ich habe eine Parallele Digital Encoder mit 10 bit Auflösung. Da >> ist >> kein Takt Signal. Der Encoder stellt die aktuelle Position ständig auf >> die Leitung ohne Takt. >> Wenn eine bestimmte Position erreicht wird, soll durch ein Signal eine >> FPGA eingestaltet werden und FPGA soll bestimmte Messungen durchführen >> , bis eine andere Position erreicht wird. Deshalb ist die Aufgabe mit >> heutige Komponenten machbar kürzeste Schaltzeit zu erreichen. > > Einen 10bit-Vergleicher im FPGA, sollte sogar ein Anfaenger hinbekommen. > > Die externe Variante habe ich gepostet. Die externe Variante(weil die Schaltsignal ausserhalb FPGA-Board generiert werden muss) ist perfekt und ausreichend. Ich habe durch deine Verweis auch diesen IC (74FCT521CT) gefunden, mit A=B Vergleich und 4.5ns durchlaufzeit. Ich bedanke mich an euch allen die so schnell Hilfe angeboten haben. lg
:
Bearbeitet durch User
Wie schnell dreht sich denn der Encoder maximal (Umdrehungen pro Sekunde oder Minute)?
6.000 rpm maximal. Eine SICK ARS60. Und noch eine Frage bitte: Ich bin neu in diesem Forum, das war mein erste Beitrag. Wenn eine Lösung gefunden ist soll ich den Beitrag schließen damit ich die Menschen nicht um sonst beschäftige oder bleiben die immer offen(ich habe keine Möglichkeit gefunden zu sagen das die Lösung gefunden ist).
:
Bearbeitet durch User
Alaatdin Ö. schrieb: > 6.000 rpm maximal OK. Damit ergibt sich dann auch, dass sich dein Encoderwert nicht öfter als 6000 / 60 * 1024 = 102400 pro Sekunde ändert. Also alle 10 us (oder seltener). Da schein mir eine praxisnahe Verarbeitungszeit von 1 us durchaus angemessen. Dazu kommt, dass die Drehbewegung ja im kleinen Zeitraum recht gleichmäßig sein wird und daher für einen Prozessor gut "vorhersagbar" ist. Das kann man sich für eine präzise Positionsauswertung zu Nutze machen.
:
Bearbeitet durch User
Alaatdin Ö. schrieb: > Ich habe eine Parallele Digital Encoder mit 10 bit Auflösung. Da ist > kein Takt Signal. Der Encoder stellt die aktuelle Position ständig auf > die Leitung ohne Takt. > Wenn eine bestimmte Position erreicht wird, soll durch ein Signal eine > FPGA eingestaltet werden und FPGA soll bestimmte Messungen durchführen > , bis eine andere Position erreicht wird. Deshalb ist die Aufgabe mit > heutige Komponenten machbar kürzeste Schaltzeit zu erreichen Aha, sogar weitere Salamischeiben. Bei einem Encoder weiss man, was als nächstes Signal kommt, entweder vorwärts oder rückwärts (und vermutlich gray-codiert). So bald sich also das Signal auf der für die relevanten Spur vorwärts oder rückwärts ändert, kann man das Vergleichssignal liefern, ohne überhaupt die anderen Bits vergluchen zu haben. Man hat also als set-up Zeit die ganze Periode des Incrementalsignals Zeit und muss nur 1 Gatterlaufzeit delay einrechnen. Aber das überfordert heutige Jungentwickler wohl
Alaatdin Ö. schrieb: > Auf jeden Fall Unter nano Sekunden. Damit bewegst du dich im Mikrowellen Bereich. Geht das überhaupt durch normale Kabel?
New C. schrieb: > Ich bin neu in diesem Forum, das war mein erste Beitrag. Wenn eine > Lösung gefunden ist... Du hast noch keine endgültige Lösung. Du hast ein IC genannt welches 8 Bit miteinander vergleicht. Du hast aber 10 Bit. Es sind also weitere ICs notwendig die miteinander verknüpft werden müssen. Gibt es bei Händlern nicht mehr. Ggf. eBay etc. http://www.ic72.com/pdf_file/d/dm74ls460.pdf > soll ich den Beitrag schließen damit ich die > Menschen nicht um sonst beschäftige oder bleiben die immer offen(ich > habe keine Möglichkeit gefunden zu sagen das die Lösung gefunden ist). Nein, ein Thread bleibt immer offen, es sei den ein Mod schließt oder löscht ihn.
New C. schrieb: > Wenn eine > Lösung gefunden ist soll ich den Beitrag schließen damit ich die > Menschen nicht um sonst beschäftige oder bleiben die immer offen(ich > habe keine Möglichkeit gefunden zu sagen das die Lösung gefunden ist). Wenn du eine Lösung gefunden hast, dann schreib das und nenne, was du gemacht hast. So dass andere mit einem vergleichbaren Problem das später nachlesen können. Das wäre ein richtiger Abschluss für einen Thread; es findet leider eher selten so statt.
Jörg R. schrieb: > New C. schrieb: >> Ich bin neu in diesem Forum, das war mein erste Beitrag. Wenn eine >> Lösung gefunden ist... > > Du hast noch keine endgültige Lösung. Du hast ein IC genannt welches 8 > Bit miteinander vergleicht. Du hast aber 10 Bit. Es sind also weitere > ICs notwendig die miteinander verknüpft werden müssen. > > Gibt es bei Händlern nicht mehr. Ggf. eBay etc. > http://www.ic72.com/pdf_file/d/dm74ls460.pdf > > >> soll ich den Beitrag schließen damit ich die >> Menschen nicht um sonst beschäftige oder bleiben die immer offen(ich >> habe keine Möglichkeit gefunden zu sagen das die Lösung gefunden ist). > > Nein, ein Thread bleibt immer offen, es sei den ein Mod schließt oder > löscht ihn. Du bist ein Schatz. Danke Ich habe gesehen dass ich die Sache selbst umsonst kompliziert habe. Deshalb habe ich mich für eine andere Lösung entschieden. Ich werde einmalig mit der Encoder genauen Position ermitteln, und eine Photodiode installieren. Wie ich herausgefunden habe die schalten ja schon in Picosekunden bereich. Wo ich danach nicht den Positionszahl sondern nur erreichen des Position brauche und nur an diese Stelle eine ein/aus Signal brauche. Ich bedanke mich nochmal an euch alle lg
New C. schrieb: > Picosekunden Wie klein wirst du die Schaltung aufbauen können? In einer Nanosekunde kommt der Strom gerade mal 30cm weit, in einer Picosekunde 0.3mm. Selbst das Licht, das die Fotodiode schalten lässt, wird vom Filter zur Diode mehrere Picosekunden unterwegs sein. Mit Verlaub... du bist ein Troll oder total ahnungslos.
Georg G. schrieb: > In einer Nanosekunde > kommt der Strom gerade mal 30cm weit, Nicht mal das, bei einer Leiterplatte darf man eher mit 15cm rechnen! Da geht √eps_r mit ein!
New C. schrieb: > Photodiode installieren. Wie ich herausgefunden habe die schalten ja > schon in Picosekunden bereich. Du solltest mal an deinem Zeitgefühl und dem Verständnis von Vorsätzen von Maßeinheiten arbeiten. picosekunden - da hätte ich mich gerade beinahe verschluckt.
Georg G. schrieb: > New C. schrieb: >> Picosekunden > > Wie klein wirst du die Schaltung aufbauen können? In einer Nanosekunde > kommt der Strom gerade mal 30cm weit, in einer Picosekunde 0.3mm. Selbst > das Licht, das die Fotodiode schalten lässt, wird vom Filter zur Diode > mehrere Picosekunden unterwegs sein. > > Mit Verlaub... du bist ein Troll oder total ahnungslos. Ich bin leider kein Profi, sondern nur ein Hobbyelektroniker und von Beruf softwareentwickler. Ich bin in diese Forum gekommen, nicht meine perfektes Wissen zu demonstrieren sondern um Hilfe zu holen weil meine Kenntnisse nicht ausreichend ist. Weil ich keine experten Ahnung habe dachte ich , ich mache es mit Encoder, aber durch Hilfe von netten Kollegen habe ich gesehen dass diese Weg Irre ist. Wie ich vorher geschrieben habe, es geht nicht um in eine bestimmte Zeit , sondern möglichst schnell einzuschalten, damit FPGA möglichste maximale Zeit bekommt um seine Arbeit zu erledigen. Ich habe die schnellste Photodiode deshalb genannt weil, je schnellere Elemente ich verwende am Ende wird maximal so schnell. Treiberschaltung, Signalleitung, ... usw am Ende wird doch in ca. Nano- oder Microsekundenbereich liegen denke ich. Ich will ja nicht unbedingt in picosekunden einschalten, sondern möglichst schnell.
:
Bearbeitet durch User
New C. schrieb: > Wie ich vorher geschrieben habe, es geht nicht um in eine bestimmte > Zeit, sondern möglichst schnell einzuschalten Möglichst schnell ist zwangsläufig maximal teuer. Ich denke nicht, dass du daraus einen wissenschaftlichen Versuch mit einem Budget in Millionenhöhe machen willst. Also bleibe auf dem Teppich. Für Bastler wie dich und mich beginnt die reale Welt im Bereich zwischen 10 und 100ns.
New C. schrieb: > Ich habe eine 10 bit Parallele digitale Signal Leitung, und das muss ich > mit eine 10 bit Value vergleichen und sobald übereinstimmt eine einzige > on/off Signal generieren. > ... > Problem dabei ist, dass es mit absolut möglichst kürzeste > Verzögerungszeit laufen soll. Heißt das, dass beide Signale im Grey-Code vorliegen und dein Encoder hoch- oder runter laufende Werte ausgibt?
Stefanus F. schrieb: > New C. schrieb: >> Wie ich vorher geschrieben habe, es geht nicht um in eine bestimmte >> Zeit, sondern möglichst schnell einzuschalten > > Möglichst schnell ist zwangsläufig maximal teuer. Ich denke nicht, dass > du daraus einen wissenschaftlichen Versuch mit einem Budget in > Millionenhöhe machen willst. Also bleibe auf dem Teppich. > > Für Bastler wie dich und mich beginnt die reale Welt im Bereich zwischen > 10 und 100ns. Wollen ist ja kostenlos. Nachdem ich jetzt auch die Preise für solche Bauelemente gesehen habe gebe ich dir völlig recht. Bleibe lieber auf dem Teppich. Nano ist mein neues Motto, dank dir :-)
Beitrag #5899548 wurde vom Autor gelöscht.
Wolfgang schrieb: > New C. schrieb: >> Ich habe eine 10 bit Parallele digitale Signal Leitung, und das muss ich >> mit eine 10 bit Value vergleichen und sobald übereinstimmt eine einzige >> on/off Signal generieren. >> ... >> Problem dabei ist, dass es mit absolut möglichst kürzeste >> Verzögerungszeit laufen soll. > > Heißt das, dass beide Signale im Grey-Code vorliegen und dein Encoder > hoch- oder runter laufende Werte ausgibt? Ja, genau so war am Anfang geplant
Stefanus F. schrieb: > New C. schrieb: >> Wie ich vorher geschrieben habe, es geht nicht um in eine bestimmte >> Zeit, sondern möglichst schnell einzuschalten > > Möglichst schnell ist zwangsläufig maximal teuer. Deshalb ist nicht sinnvoll, es so schnell wie mölgich zu machen, sondern immer nur so schnell wie nötig.
New C. schrieb: > Wie ich vorher geschrieben habe, es geht nicht um in eine bestimmte Zeit > , sondern möglichst schnell einzuschalten, damit FPGA möglichste > maximale Zeit bekommt um seine Arbeit zu erledigen. Was wird der FPGA denn dann genau machen? Für meinen Geschmack schießt du gerade mit einer Kanone auf einen Spatzen. Ich versuche es mal anhand eines Beispiels zu verdeutlichen: Wenn du versuchen möchtest ein Auto genau an einem Geschwindigkeitsschild auf eine bestimmte Geschwindigkeit abzubremsen, kannst du natürlich warten, bis du am Schild bist, und musst dann extrem schnell auf die (sehr starke) Bremse treten. Der andere (und bessere) Weg ist, das Schild schon von einer gewissen Entfernung zu erkennen. Dadurch hat man bequem Zeit, das Auto bis zum Schild abzubremsen und erreicht genau am Schild die gewünschte Geschwindigkeit. Dieses Prinzip kannst du auch auf deinen Anwendungsfall übertragen, da die Position, die dein Vergleicher erkennen soll, ja nicht urplötzlich und unerwartet auftaucht. Der Encoder gibt dir schon vorher Auskunft über die Drehgeschwindigkeit und den Abstand zur gewünschten Position. Wenn man diese Informationen auswertet, weiss deine Steuerung schon lange vorher, wann der Zeitpunkt erreicht sein wird, deine "FPGA-Aktion" auszulösen. Auf diese Weise lassen sich sogar Positionen triggern, die zwischen 2 Encoder-Schritten liegen. Oder auch Signal-Verzögerungen kompensieren (z.B. propagation delays oder rise-/fall Zeiten).
:
Bearbeitet durch User
Joe F. schrieb: > New C. schrieb: >> Wie ich vorher geschrieben habe, es geht nicht um in eine bestimmte Zeit >> , sondern möglichst schnell einzuschalten, damit FPGA möglichste >> maximale Zeit bekommt um seine Arbeit zu erledigen. > > Was wird der FPGA denn dann genau machen? > > Für meinen Geschmack schießt du gerade mit einer Kanone auf einen > Spatzen. Ist da überhaupt ein Spatz, oder ist da reinweg garnichts? Der OP hat ein Signal von einem Encoder, 10 Bit parallel, was eigentlich schon Overkilll ist, denn das geht vermutlich auch seriell mit weniger Strippen. Dieses Signal wird in einem FPGA verarbeitet. Was das FPGA macht, wurde uns bisher nicht erzählt. Aber was auch immer - die Erkennung einer Signaländerung kann es bestimmt auch noch erledigen. Die Aufgabe geht also zurück an den FPGA-Entwickler, statt irgendwas darum herum zu basteln.
New C. schrieb: > Ich habe eine Parallele Digital Encoder mit 10 bit Auflösung. Da ist > kein Takt Signal. Dann kannst du auch nichts zuverlässig vergleichen. Denn du hast da laufend Glitches. Dieter R. schrieb: > Aber was auch immer - die Erkennung einer Signaländerung kann es > bestimmt auch noch erledigen. Dazu muss "es" aber wissen, wann denn die Daten überhaupt gültig sind. New C. schrieb: > Ja, genau so war am Anfang geplant Allerdings wird der Vergleicher am Ausgang Glitches zeigen, auch wenn sich am Eingang nur 1 Bit ändert und (jetzt kommts!) sogar dann, wenn beide Eingänge paralel geschaltet wären und tatsächlich immer das gleiche Eingangssignal hätten. Und genauso wird der Ausgang glitchen, wenn sich nur 1 Bit ändert und beide Eingänge immer unterschiedlich sind. Das ist hart, aber das reale Leben... New C. schrieb: > ich habe keine Möglichkeit gefunden zu sagen das die Lösung gefunden ist Ich sehe vorrangig Probleme mit dieser "Lösung". Bau die "Lösung" auf, dann siehst du diese Probleme auch.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Dazu muss "es" aber wissen, wann denn die Daten überhaupt gültig sind. Irgendwann in diesem unseligen Thread wurde ein Typ genannt, SICK ARS60. Der hat einen "Store"-Eingang. Darüber sagt "es", also die angeschlossene Logik bzw. das geheimnisvolle FPGA dem Encoder, dass er die Daten mal einen Moment still halten soll. Irgendwo in den technischen Unterlagen wird wohl auch stehen, dass man dies Signal benutzen muss, wenn man stabile Daten haben will. Irgendwie wird das wohl auch so gemacht sein, falls/wenn das FPGA bisher überhaupt etwas sinnvolles tut. Bloß davon hat der OP wohl keine Ahnung, oder schon der Entwickler des FPGA. Was wissen wir schon davon?
Ich wuerde annehmen, dass ein Parallelencoder mit Grey Codes arbeitet, und die haben keine Glitches. Denn da aendert sich immer nur ein einzelnes Bit.
Megatroll schrieb: > Ich wuerde annehmen, dass ein Parallelencoder mit Grey Codes arbeitet, > und die haben keine Glitches. Denn da aendert sich immer nur ein > einzelnes Bit. Genau so ist es, da glitcht absolut nichts. Bei lahmarschigen 10µs max Änderungsgeschwindigkeit würde niemand F-Logik oder FPGAs nehmen. Das macht z.B. ein Cortex-M3 im 1µs Timerinterrupt und gähnt vor Langeweile.
Megatroll schrieb: > Ich wuerde annehmen, dass ein Parallelencoder mit Grey Codes arbeitet, > und die haben keine Glitches. Frank hieß Gray. Und wenn man ein wenig nachdenkt, dann hat zwar "im Prinzip" der Encoderund die Übertragung an sich dank Gray-Code keine Glitches, ABER der Vergleicher intern wird aufgrund untershiedlicer Laufzeiten durch die Logik garantiert Glitches erzeugen. Bau einfach mal einen Vergleicher mit Logik auf, gib jedem Gatter eine um ein paar ps unterschiedliche Laufzeit und probier einfach mal die beiden Fälle aus, die ich beschrieben habe: 1. am einen Eingang ständig 0 und am anderen Eingang sich ständig ändernde Gray-Werte ungleich 0. Obwohl dabei immer am "=" Ausgang immer 0 herauskommen sollte, wirst du dort ab und zu für ein paar ps mal eine 1 sehen. 2. beide Eingänge werden mit dem gleichen Wert versorgt. Obwohl da am "=" ausgang ständig 1 herauskommen müsste, wirst du bei Anschluss eines Gray-Codes an beiden Eingängen am Ausgang ab&zu für ein paar ps eine 0 sehen. Das sind dann die besagten Glitches. Und das sind in FPGA-Desings dann auch die beliebtesten und zähesten Fehler. Die tauchen nämlich absolut unreproduzierbar auf der selben Platine gestern nur 1 mal pro Tag oder heute alle 10 Minuten auf... Man kann mit ein wenig Glück so einen Glitch auch "fangen" und zählen. Dort mal eine Betrachtung zur Problematik "asynchrone Signale": http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren Peter D. schrieb: > Genau so ist es, da glitcht absolut nichts. Ganz richtig: der Code an sich nicht. Aber der Vergleicher, der dann hinterher kombinatorisch ausgewertet wird. > Bei lahmarschigen 10µs max Änderungsgeschwindigkeit würde niemand > F-Logik oder FPGAs nehmen. Das macht z.B. ein Cortex-M3 im 1µs > Timerinterrupt und gähnt vor Langeweile. Damit ist das Signal zeitlich diskretisiert und die "interne Programmlogik" arbeitet mit einem stabilen Signal. Genauso macht man das auch mit einem FPGA: man tastet den Eingang schnell genug ab, speichert ihn für einen Takt und arbeitet mit dem dadurch "stabilisierten" Signal. Dann kann der ingerne Vergleicher auch mal vor sich hin glitchen, er muss einfach nur zum nächsten Taktimpuls stabil sein. Und das läuft locker mit 100MHz...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > ABER > der Vergleicher intern wird aufgrund untershiedlicer Laufzeiten durch > die Logik garantiert Glitches erzeugen. Die FPGA-Entwickler waren aber nicht dumm und haben deshalb interne Taktgeneratoren und Latches erfunden. Damit lassen sich die Ein- und Ausgänge prima synchronisieren. Auch ein MC latcht erstmal alle Eingänge mit dem CPU-Takt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.