Wollte Fragen, ob zufällig jemand einen IC kennt, für einen getakteten 2 Flankendetektor. Sprich, was ich haben möchte, bei steigender Flanke des Taktsignals soll er prüfen, ob eine Änderung des Signals gegeben hat. Er soll allerdings keine Impulse am Ausgang abgeben sondern einfach ein positives Signal in der Länge des Signaltaktes. Sprich, der Signaltakt soll nur anzeigen, wie lang das Signal am Ausgang anliegen soll. Quasi ein Monoflop was so lange einen High-Impuls hält, bis der Takt wieder von high nach Low wechselt. Ich brauche das für einen Taktzähler. Ein einfaches Shiftrregister geht nicht. Weil ein Shiftregister, bzw. Zähler mindestens 1 Takt braucht um sich zurückzu setzen. sprich takt 1 - 8, bei acht soll das Signal kommen. Problem: Takt 1 Zählerstand = 1 Takt 8 Zählerstand = 8 Takt 9 Zählerstand = 0 Takt 17 Zählerstand = 8 damit kann ich es nicht so ohne weitere realisieren.
@ sebi Ich möchte Dir höflich und ebenso dringend empfehlen Deine Erklärung durch eine Skizze des Signalverlaufes zu ergänzen.
> Sprich, was ich haben möchte, bei steigender Flanke des > Taktsignals soll er prüfen, ob eine Änderung des Signals > gegeben hat. Hä? Wenn ein Signal eine Flanke aufweist, dann wird es sich auch zwischen zwei Zuständen geändert haben! > Quasi ein Monoflop was so lange einen High-Impuls hält, bis der > Takt wieder von high nach Low wechselt. Du meinst ein Stück Kupferdraht? Warum machste das nicht mit einem µC, irgendwas wird ja diese Daten verarbeiten wollen, oder? Externen Interrupt auf eine Flanke und los gehts, wenn die Frequenz nicht zu hoch für eine Software-Lösung ist. Ich fürchte aber, ich hab Dein Problem noch nicht gut genug verstanden...
Hi ich würd dir ja gern weiter helfen, aber ich versteh das auch nicht. Wenn du ein Signal solange haben willst, wie es ansteht, dann nimm es doch. Wozu eine Flankenauswertung ? Willst du nur zählen, ja, dann nimm halt einen µC, vergleiche alt mit neu (EXOR) und bilde eine Flanke bei steigendem oder fallendem Signalpegel. Dazu nimmt man ein Bit. Im Programm prüfst du, ob Bit gesetzt ist, wenn ja, zählst du und setzt das Bit zurück. Es wird erst wieder bei einem weiteren Wechsel gesetzt. Eine andere "Hardwarelösung" macht nicht wirklich Sinn. gruß oldmax
Angehängte Dateien:
-
takt.png
2 KB
Hmm schrieb: > @ sebi > > Ich möchte Dir höflich und ebenso dringend empfehlen Deine Erklärung > durch eine Skizze des Signalverlaufes zu ergänzen.
oldmax schrieb: > Hi > ich würd dir ja gern weiter helfen, aber ich versteh das auch nicht. > Wenn du ein Signal solange haben willst, wie es ansteht, dann nimm es > doch. Wozu eine Flankenauswertung ? Willst du nur zählen, ja, dann nimm > halt einen µC, vergleiche alt mit neu (EXOR) und bilde eine Flanke bei > steigendem oder fallendem Signalpegel. Dazu nimmt man ein Bit. Im > Programm prüfst du, ob Bit gesetzt ist, wenn ja, zählst du und setzt das > Bit zurück. Es wird erst wieder bei einem weiteren Wechsel gesetzt. Eine > andere "Hardwarelösung" macht nicht wirklich Sinn. > gruß oldmax Kein IC! Ich möchte halt eine Signaländerung feststellen. Eine Signaländerung tritt auf bei positiver Flanke, und negativer Flanke. Da Schaltung ist Synchron! Deswegen gibt es einen Takt, und ich brauche eine Schaltung die jeden 8. Takt einen 1 Takt langen Impuls ausgibt. Wie in der Zeichnung zu sehen.
Sebi2020 schrieb: > Hmm schrieb: >> @ sebi >> >> Ich möchte Dir höflich und ebenso dringend empfehlen Deine Erklärung >> durch eine Skizze des Signalverlaufes zu ergänzen. Noch was, das Bild stellt eher das Problem dar... das was ich eben nicht will... erst im neunten Takt sagt er mir das ich jetzt 8 Takte rum hab. aber ich möchte das er mir im 8. Takt sagt hey, jetzt sind 8. Takte rum. Grund dafür ist, das ich mit nem schieberegister seriell empfangen möchte... dafür muss ich feststellen, wann ein Byte angekommen ist. Eben nach 8 Takte. Aber hier bekomme ich es ein Takt zu spät angezeigt.
Sebi2020 schrieb: > wann ein Byte angekommen ist. Eben > nach 8 Takte. Das Teil nennt sich Binärzähler nimmst halt den Q3 Ausgang
Der Rächer der Transistormorde schrieb: > Das Teil nennt sich Binärzähler nimmst halt den Q3 Ausgang oder kombinierst mit UND Gattern jeden beliebigen anderen Wert (welchen du auch immer brauchen magst). s. Zählerschaltungen im Netz
Nimm einen 4Bit Komperator ala 74ls85, sofern due die Zustände 1-8 binär vorliegen hast. Ansonsten Binärzähler, wobei du allerdings bei deinen Datenstrom nicht weist wo der Anfang ist. Ralph Berres
Der Rächer der Transistormorde schrieb: > Sebi2020 schrieb: >> wann ein Byte angekommen ist. Eben >> nach 8 Takte. > > Das Teil nennt sich Binärzähler nimmst halt den Q3 Ausgang Schön wärs. Aber der soll immer 8 Takte zählen... wenn du mal nach rechnest merkst du, wie schon gesagt, das ein Binärzähler 1 Takt zum Resetten braucht! Das gibt eine ungerade Zählung! Takt 1 = 1, Takt 8 = 8, Takt 9 = 0, Takt 17 = 8... Was ich aber möchte ist Takt 1 = 1, Takt 8 = 8, Takt 16 = 8 usw...
Dann schalte eben einen 3Bit Binärzähler ( 74ls93 ) und einen Bitvergleicher (7485) zusammen. Der Vergleicher hat 3 Ausgänge Eingang A<B EingangA=B und EingangA>B Der Ausgang EingangA=B ist dein Freund. Ralph Berres
Ralph Berres schrieb: > Dann schalte eben einen 3Bit Binärzähler ( 74ls93 ) und einen > Bitvergleicher (7485) zusammen. Der Vergleicher hat 3 Ausgänge > Eingang A<B EingangA=B und EingangA>B Der Ausgang EingangA=B ist dein > Freund. > > Ralph Berres Könntest du mir das genauer erklären, ich kann gerade nicht folgen...
Schaue dir doch die Datenblätter der beiden ICs mal an 7493 ist ein 3bit und ein 1bit Zähler in einen Gehäuse Da nimmst du den 3bit zähler. Der zählt immer durch von 0-7 Die Ausgänge des Zählers gibst du auf einen BitVergleicher 7485 Eingang A Den Eingang B verdrahtest du auf Bit 7 also die ersten 3 Eingänge auf log1 Dann gibt er mit dem 7 schritt immer eine 1 am, Ausgang A=B aus. Wenn du bis 8 zählen willst, ( Vorsicht die 0 must du mitzählen ) Dann must du den 7493 als 4bit Zähler verschalten und am Eingang B des Vergleichers eine 0001 anlegen, weil es jtzt in Wirklichkeit 9 Schritte sind. Wenn dir das jetzt immer noch nicht klar ist , empfehle ich dir dringend das TTL Kochbuch von Texas Instruments, wo du die Grundlagen der Digitaltechnik nachlesen kannst. Ralph Berres
Sebi2020 schrieb: > Aber der soll immer 8 Takte zählen Na dann lässt du den Zähler halt frei durchlaufen und benutzt das Bitmuster am Ausgang Bitmuster und Zahl ------ 000 0 001 1 ... 111 7* * das ist dann der achte Takt ergo ein dreifach UND das exact den achten takt lang ansteht.
eine 0001 anlegen, weil es jtzt in Wirklichkeit 9 Schritte > sind. > > Wenn dir das jetzt immer noch nicht klar ist , empfehle ich dir dringend > das TTL Kochbuch von Texas Instruments, wo du die Grundlagen der > Digitaltechnik nachlesen kannst. > > Ralph Berres Weis nicht ganz, wenn es das bewirkt was icvh will... nämlich das der Zähler im ersten 8 Takt Zyklus von 0 bis 8 zählt und sich dann statt auf 0 zu reseten auf 1 resettet, dann hilft mir das weiter.
Der Rächer der Transistormorde schrieb: > Bitmuster und Zahl > ------ > 000 0 > 001 1 > ... > 111 7* vielleicht noch zur Erklärung: Bitmuster des Zählers und Wert ------ 000 0 001 1 ... 111 7 -> Überlauf nach 0 000 8 001 9 ... 110 14 111 15 -> der nächste Überlauf die Spanne ist immer 8 akte lang 000 001 010 011 ...
Der Rächer der Transistormorde schrieb: > Sebi2020 schrieb: >> Aber der soll immer 8 Takte zählen > > Na dann lässt du den Zähler halt frei durchlaufen und benutzt das > Bitmuster am Ausgang > > Bitmuster und Zahl > ------ > 000 0 > 001 1 > ... > 111 7* > > * das ist dann der achte Takt ergo ein dreifach UND das exact den achten > takt lang ansteht. Ja frage ist, wie bewirke ich, dass das ergebnis vom und aus dem 7. Takt im 8. Takt ein Takt lang ansteht. Ich muss ja quasi im siebten takt prüfen, liegt jetzt sieben an, also wenn ich 3 x 1 hab. und dann aber erst im 8. Takt die 1 ausgeben für diesen Takt.
Sebi2020 schrieb: > und sich dann statt auf > 0 zu reseten auf 1 resettet, dann hilft mir das weiter Dann nimmst du halt nen programmierbaren und stellst den auf -1 (bzw binär 111 bei 3bit oder 1111 bei 4 bit Zählern der Rest ist identisch)
Sebi2020 schrieb: > Korrigiere, keinen uC aus Geschwindigkeitsgründen. Zahlen? Daten? Fakten? Sebi2020 schrieb: > Ich brauche das für einen Taktzähler. Vielleicht solltest du mal zum eigentlichen Problem noch ein paar Worte verlieren, und nicht nur zu deiner halb fertig gedachten Lösung... Falk nennt das dann immer Netiquette Sebi2020 schrieb: > Grund dafür ist, das ich mit nem schieberegister seriell empfangen > möchte... dafür muss ich feststellen, wann ein Byte angekommen ist. Hört sich nach SPI oder sowas an... Wie auch immer: ich würde das einfach in ein CPLD packen. Inklusive Schieberegister.
Sebi2020 schrieb: > Ja frage ist, wie bewirke ich, dass das ergebnis vom und aus dem 7. Takt > im 8. Takt ein Takt lang ansteht Du legst die unteren 3 bit vom Zähler auf ein dreifach und Gatter und voila, der Ausgang vom Gatter bleibt so lange auf 1 bis der nächste Takt kommt (der neunte).
Der Rächer der Transistormorde schrieb: > Sebi2020 schrieb: >> und sich dann statt auf >> 0 zu reseten auf 1 resettet, dann hilft mir das weiter > > Dann nimmst du halt nen programmierbaren und stellst den auf -1 (bzw > binär 111 bei 3bit oder 1111 bei 4 bit Zählern der Rest ist identisch) Das ganze soll mit einfachen JK-FlipFlos oder D-FlipFlops realisiert werden... und Problem ist, wenn ich von Anfang an auf minus eins Stelle bekomme ich erst im 9. Takt gesagt, hey, jetzt sind wir im 8. Das mit dem Überlauf gefällt mir schon, nur hab ich keinen Plan, wie ich diese Überlauferkennung mache. Sprich, beim Wechsel von 111 auf 0 , sobald wieder 0 im zähler steht eine 1 als überlauf bit auszugeben. Hätte da jemand ein Schaltungsbeispiel. Das würde mir sehr weiter helfen!
Der Rächer der Transistormorde schrieb: > Sebi2020 schrieb: >> Ja frage ist, wie bewirke ich, dass das ergebnis vom und aus dem 7. Takt >> im 8. Takt ein Takt lang ansteht > > Du legst die unteren 3 bit vom Zähler auf ein dreifach und Gatter und > voila, der Ausgang vom Gatter bleibt so lange auf 1 bis der nächste Takt > kommt (der neunte). nop! Das Und-Gatter ist eben dan im 7. Takt = 1 : 1. Takt 000 & 111 = 0 2. Takt 010 & 111 = 0 3. Takt 011 ... 4. Takt 100 ... ... ... 7. Takt 111 & 111 = 1 8. Takt 000 & 111 = 0 Also geht nicht!
Sebi2020 schrieb: > Der Rächer der Transistormorde schrieb: >> Sebi2020 schrieb: >>> Ja frage ist, wie bewirke ich, dass das ergebnis vom und aus dem 7. Takt >>> im 8. Takt ein Takt lang ansteht >> >> Du legst die unteren 3 bit vom Zähler auf ein dreifach und Gatter und >> voila, der Ausgang vom Gatter bleibt so lange auf 1 bis der nächste Takt >> kommt (der neunte). > > nop! Das Und-Gatter ist eben dan im 7. Takt = 1 : > 1. Takt 000 & 111 = 0 Sorry im ersten Takt seht der Zähler ja dann auf 1! aslso 1. Takt 001
Sebi2020 schrieb: > Das Und-Gatter ist eben dan im 7. Takt = 1 : Dann nimmst du halt die null (Über ein NAND) Jacke wie Hose. So wie ich das verstanden habe willst du jeden achten Takt mit high speed zählen (jedenfalls jenseits von dem was ein Controller schafft). Wenndie erste nukk ein Problem ist unterdrückst du sie halt (oder spannst den Zähler vor etc. pp.)
Der Rächer der Transistormorde schrieb: > Sebi2020 schrieb: >> Das Und-Gatter ist eben dan im 7. Takt = 1 : > > Dann nimmst du halt die null (Über ein NAND) Jacke wie Hose. > > So wie ich das verstanden habe willst du jeden achten Takt mit high > speed zählen (jedenfalls jenseits von dem was ein Controller schafft). > > Wenndie erste nukk ein Problem ist unterdrückst du sie halt (oder > spannst den Zähler vor etc. pp.) Mh, vorspannen, sprich, ihn von anfang an auf 111 setzen eventuell über rs-flipflops?
> Sebi2020 schrieb: >> Grund dafür ist, das ich mit nem schieberegister seriell empfangen >> möchte... dafür muss ich feststellen, wann ein Byte angekommen ist. > Hört sich nach SPI oder sowas an... > Wie auch immer: ich würde das einfach in ein CPLD packen. Inklusive > Schieberegister. Würd ich gerne machen, hab leider noch keine billigen USB-CPLD Programmer gefunden der direkt mit der Toolchain vom hersteller Arbeitet. Nur über Drittprogramme wie sc3prog oder wiedas nochmal heißt... Und die vom Hersteller sind 100 mal so teuer, wie das was da an hardware drinne steckt..
Sebi2020 schrieb: > Mh, vorspannen, sprich, ihn von anfang an auf 111 setzen eventuell über > rs-flipflops? Besser mit nem RS Flipflop den ersten Takt catchen und den negierten Ausgang auf den 4. Eingang eines NANDS legen Das kriegste fast bis in den GHz Bereich zum funzen.
Angehängte Dateien:
-
Zaehler.PNG
425 Bytes
Hi
Ich weiß nicht, ob du schon bei "0" einen Ausgangsimpuls geben kannst
aber wenn, dann ist doch der 74LS93 oder dergleichen genau das richtige.
Wenn du den 74..93 nimmst, dann gibt es da einen dreistufigen
Binärzähler. Wenn du diese drei Ausgänge auf ein Nand schaltest, dann
ergibt sich genau das was du willst.
Zählfolge 0 Wert 0 Ausgang 1
1 1 0
2 2 0
3 3 0
4 4 0
5 5 0
6 6 0
7 7 0
8 0 1
9 1 0 usw.
Damit hättest du deinen 8 zu 1 Teiler mit genau dem gewünschten
Impulsverhalten. Allerdings, wie eben schon gesagt, er fängt mit einem
Impuls an. Im Anhang hab ich's mal Skizziert.
Gruß oldmax
Kann es sein das es so ist?
Zählfolge 0 Wert 0 Ausgang 1
1 1 1
2 2 1
3 3 1
4 4 1
5 5 1
6 6 1
7 7 0
8 0 1
9 1 1 usw.
Ralph Berres
Sebi2020 schrieb: > ich brauche > eine Schaltung die jeden 8. Takt einen 1 Takt langen Impuls ausgibt. Du brauchst zuerst mal einen Synchronisationsmechanismus. D.h. woran erkennst Du, welcher der 1. und welcher der 8. Takt ist? Ein SPI macht das z.B. mit der low-Flanke vom /SS (Slave Select). Peter
Peter Dannegger schrieb: > Sebi2020 schrieb: >> ich brauche >> eine Schaltung die jeden 8. Takt einen 1 Takt langen Impuls ausgibt. > > Du brauchst zuerst mal einen Synchronisationsmechanismus. > D.h. woran erkennst Du, welcher der 1. und welcher der 8. Takt ist? > > Ein SPI macht das z.B. mit der low-Flanke vom /SS (Slave Select). > > > Peter Naja meine Idee wäre gewesen sowas wie einen Edge-Trigger zu verwenden, der feststellt, wenn der Zähler von 111 auf 000 wechselt... Problem dabei ist nur, das ich ja den Impuls so gut wie unabhängig von der Frequenz (so gut wie!) ein Takt andauern lassen will...
Ralph Berres schrieb: > Kann es sein das es so ist? > > Zählfolge 0 Wert 0 Ausgang 1 > > 1 1 1 > > 2 2 1 > > 3 3 1 > > 4 4 1 > > 5 5 1 > > 6 6 1 > > 7 7 0 > > 8 0 1 > > 9 1 1 usw. > > Ralph Berres Nee, eher so: -1 8 0 0 0 0 1 1 0 2 2 0 3 3 0 4 4 0 5 5 0 6 6 0 7 7 0 8 8 1 9 0 0
Entweder versteht hier niemand wirklich dein Problem oder es ist so trivial, dass keiner versteht, wo hier eigentlich ein Problem besteht. Ein Zähler, der mit einer Zusatzlogik nach einer definierten Anzahl Pulsen auf 0 zurückgesetzt wird, ist ja nicht wirklich das große Problem. Mir kommt vor, dass eines deiner Probleme darin besteht, dass du unbedingt bei 1 anfangen willst zu zählen. Ist doch völlig egal, ob du bei 0 oder bei 1 anfängst. Fang bei 0 an, und deine Probleme lösen sich ganz einfach.
Sebi2020 schrieb: > Nee, eher so: > > -1 8 0 > > 0 0 0 > > 1 1 0 > > 2 2 0 > > 3 3 0 > > 4 4 0 > > 5 5 0 > > 6 6 0 > > 7 7 0 > > 8 8 1 > > 9 0 0 Es ist aber ein Nandgatter oder irrre ich mich? Ralph Berres
oldmax schrieb: > Hi > Ich weiß nicht, ob du schon bei "0" einen Ausgangsimpuls geben kannst > aber wenn, dann ist doch der 74LS93 oder dergleichen genau das richtige. > Wenn du den 74..93 nimmst, dann gibt es da einen dreistufigen > Binärzähler. Wenn du diese drei Ausgänge auf ein Nand schaltest, dann > ergibt sich genau das was du willst. > ... > Damit hättest du deinen 8 zu 1 Teiler mit genau dem gewünschten > Impulsverhalten. Allerdings, wie eben schon gesagt, er fängt mit einem > Impuls an. Im Anhang hab ich's mal Skizziert. > Gruß oldmax Sprich, auf Impuls fängt er im Takt an zu zählen?
Sebi2020 schrieb: > wenn der Zähler von 111 auf 000 wechselt Und wie wird denn dieser Zähler synchronisiert? Peter
> Mir kommt vor, dass eines deiner Probleme darin besteht, dass du > unbedingt bei 1 anfangen willst zu zählen. Ist doch völlig egal, ob du > bei 0 oder bei 1 anfängst. Fang bei 0 an, und deine Probleme lösen sich > ganz einfach. Ich muss mich entschuldigen... weil ich das Problem hatte, das ich T-FlipFlops verwendet habe, die erst bei negative Flanke ihren Zustand ausgeben... Sprich das Ding lief asynchron... Habe jetzt D-FlipFlops genommen, wobei ich den negativen ausgang auf den eingang gelegt habe, und hab jetzt nen Synchronzähler..., das war das große Problem... Darum wollte ich unbedingt bei 1 anfangen... Ein Problem besteht trotztdem noch. Das mit dem feststellen von 1. und 8. Takt. Und eine Daufrage, fängt jeder Synchronzähler an so zu zählen, das im ersten Takt 0 herauskommt? Der asynchronzähler hat mir 1 nach dem ersten takt geliefert was eben nicht so gut war...
Karl Heinz Buchegger schrieb: > Entweder versteht hier niemand wirklich dein Problem oder es ist so > trivial, dass keiner versteht, wo hier eigentlich ein Problem besteht. > > Ein Zähler, der mit einer Zusatzlogik nach einer definierten Anzahl > Pulsen auf 0 zurückgesetzt wird, ist ja nicht wirklich das große > Problem. Ein 4017, wobei der geeignete Ausgang an den Reset-Pin rückgeführt wird scheint mir das zu sein, was du eigentlich suchst. Das ganze ist doch nichts anderes als ein Zähler mit einem nachgeschaltetem Vergleicher, der bei einem bestimmten Zählerstand den kompletten Zähler auf 0 zurücksetzt. Mehr ist das doch nicht. Zumindest hab ich bisher aus dem gesagten noch nicht mehr herauslesen können. Ein 4017 hat halt den 'Vergleicher' insofern mit integriert, in dem er einen von 10 Ausgängen nacheinander auf 1 setzt. Aber ok. Das muss ja nicht so sein. Man kann natürlich auch einen Binärzähler mit einem dezidierten Vergleicher kombinieren.
Peter Dannegger schrieb: > Sebi2020 schrieb: >> wenn der Zähler von 111 auf 000 wechselt > > Und wie wird denn dieser Zähler synchronisiert? > > Peter Momentan noch garnicht, falls du damit meinst, das ich ihn resette bevor ich ihn zählen lasse. Also die Kommunikation soll so ablaufen, das ich ein Startimpuls vom Sender an den Empfänger sende bevor ich anfange zu senden. Der Sender liefert das Taktsignal. Also synchrone Übertragung.
Sebi2020 schrieb: >> Mir kommt vor, dass eines deiner Probleme darin besteht, dass du >> unbedingt bei 1 anfangen willst zu zählen. Ist doch völlig egal, ob du >> bei 0 oder bei 1 anfängst. Fang bei 0 an, und deine Probleme lösen sich >> ganz einfach. > > Ich muss mich entschuldigen... weil ich das Problem hatte, das ich > T-FlipFlops verwendet habe, die erst bei negative Flanke ihren Zustand > ausgeben... Sprich das Ding lief asynchron... Habe jetzt D-FlipFlops > genommen, wobei ich den negativen ausgang auf den eingang gelegt habe, > und hab jetzt nen Synchronzähler..., das war das große Problem... Darum > wollte ich unbedingt bei 1 anfangen... WOZU? Lass den Zähler doch bei 0 anfangen und wenn der Zähler 7 erreicht hat, dann wird er resettet und fängt wieder bei 0 an. Ich versteh ehrlich nicht, wo da jetzt das Problem ist. Eine Schaltung zu bauen, die 8 Pulse abzählen kann ist doch keine Raktentechnik. Und wenn das Resetten selbst einen Puls braucht, dann aktiviert man eben den Reset bereits einen Puls früher.
> WOZU? > > Lass den Zähler doch bei 0 anfangen und wenn der Zähler 7 erreicht hat, > dann wird er resettet und fängt wieder bei 0 an. > Ich versteh ehrlich nicht, wo da jetzt das Problem ist. Eine Schaltung > zu bauen, die 8 Pulse abzählen kann ist doch keine Raktentechnik. Und > wenn das Resetten selbst einen Puls braucht, dann aktiviert man eben den > Reset bereits einen Puls früher. Wenn ich den Reset nen Puls früher aktiviere zählt der statt bis nach 7 nur noch bis nach 6! oder bei einem 4 bit counter, stat bis 15 nur nach 14... wäre nicht sehr vorteilhaft. aktivierst du den reset bei, man muss den aktuellen zählerstand ja auch erst mal ablesen!... aber wie gesagt, ich hatte vorher einen Asynchronzähler, der läuft nun ma net im Takt sondern 1 verschoben dazu. hab ich ja jetzt geregelt bekommen. Damits noch mal klar ist Synchron: 1. Takt 0 2. Takt 1 ... usw. Asynchron 1. Takt 1 2. Takt 2 usw...
Sebi2020 schrieb: > Also die Kommunikation soll so ablaufen, das ich > ein Startimpuls vom Sender an den Empfänger sende bevor ich anfange zu > senden. Und wie soll der aussehen? Du fängst mitten in einer Problemstellung an und denkst, die Logik kann hellsehen. Überlege zuerst das Protokoll und dann kannst Du die Realisierung überlegen, nicht umgekehrt. Es ist auch nicht zielführend, nur einen Schritt zu machen, ohne das Ganze im Blick zu haben. Es kann durchaus sein, daß Du den Zähler garnicht brauchst. Das hängt nämlich von der Art der Synchronisation und von der weiteren Datenverarbeitung ab. Peter
Pe > Du fängst mitten in einer Problemstellung an und denkst, die Logik kann > hellsehen. > Überlege zuerst das Protokoll und dann kannst Du die Realisierung > überlegen, nicht umgekehrt. > > Es ist auch nicht zielführend, nur einen Schritt zu machen, ohne das > Ganze im Blick zu haben. Es kann durchaus sein, daß Du den Zähler > garnicht brauchst. Das hängt nämlich von der Art der Synchronisation und > von der weiteren Datenverarbeitung ab. Naja, ich hatte gedach,t ich arbeite mich das Schichtmodel hoch... von unten... und Schicht eins ist die phsysikalische Ebene... und ich möchte natürlich, das der Empfänger soviel wie möglich selber erkennt... z.B. wenn ein Register voll ist, also Daten angekommen sind. Ich könnt natürlich auch ein Bit als Inhaltsanzeigendes Bit reservieren. Aber alles das macht mehr Overhead...
Sebi2020 schrieb: > Schicht eins ist die phsysikalische Ebene Und die meinst Du, bräuchte kein Protokoll zur Synchronisation? Die nimmt also einfach das Hellseher-Bit und dann weiß sie, welches das Starbit und welches die Datenbits sind? Sebi2020 schrieb: > Aber > alles das macht mehr Overhead... Wenn Dir der Overhead zuviel ist, nimm einen MC. Protokolle in TTL-ICs zu gießen ist schon lange out. Peter
Hi Sorry, sollte ein NOR sein.... Geht aber auch mit Und. Ich bin scheinbar noch nicht richtig wach gewesen.... @ Sebi2020 Dein Fehler ist, das du immer bei "1" anfängst zu zählen. Wir sind halt so ... 1,2,3,4,5,6,7,8,1,2,3,4,5,6,78,1 etc. Die elektronischen Zähler kennen aber auch eine "0" und daher 0,1,2,3,4,5,6,7,0,1,2,3,4,5,6,7,0 etc. So ist die binäre Folge: 000,001,010,100,101,110,111,000,001,010,100,101,110,111,000,001 etc. nun kannst du mit einem UND die "111" auswerten Ergebnis 1 alle acht Takte oder ein Nor auf "000" dann ist eine "0" alle acht Takte oder oder oder... So wie deine Aufgabenstellung aussieht, ist es doch das, was du willst. Zumindest entnehme ich es deiner Skizze mit den Signalpegeln. Gruß oldmax
Peter Dannegger schrieb: > Sebi2020 schrieb: >> Schicht eins ist die phsysikalische Ebene > > Und die meinst Du, bräuchte kein Protokoll zur Synchronisation? > Die nimmt also einfach das Hellseher-Bit und dann weiß sie, welches das > Starbit und welches die Datenbits sind? > > Sebi2020 schrieb: >> Aber >> alles das macht mehr Overhead... > > Wenn Dir der Overhead zuviel ist, nimm einen MC. > Protokolle in TTL-ICs zu gießen ist schon lange out. > > > Peter Ein uC ist immer durch siene Taktfrequenz begrenzt... Anhand der Position im Register weist du was Datenbit und was Startbit ist!
Sebi2020 schrieb: > Ein uC ist immer durch siene Taktfrequenz begrenzt... Kein Mensch weiß, welche Frequenz du willst/brauchst/hast. Ich habe auf jeden Fall noch nichts dazu gefunden. Es ist noch nicht mal klar, ob das hier jetzt was mit SPI zu tun hat oder nicht. Und noch viel weniger, warum du da die Bits mitzählen musst... :-/ Sebi2020 schrieb: >> Wie auch immer: ich würde das einfach in ein CPLD packen. Inklusive >> Schieberegister. > Würd ich gerne machen, hab leider noch keine billigen USB-CPLD > Programmer gefunden der direkt mit der Toolchain vom hersteller > Arbeitet. Nur über Drittprogramme wie sc3prog oder wiedas nochmal > heißt... Und die vom Hersteller sind 100 mal so teuer, wie das was da an > hardware drinne steckt.. Was ist billig, was ist teuer? Ein Xilinx USB-Programmer Nachbau aus China kostet grade mal 30 Euronen. Da, z.B. das Ding bei EBAY: 320854520606
Lothar Miller schrieb: > tzählen musst... :-/ Lothar Miller schrieb: > Sebi2020 schrieb: >> Ein uC ist immer durch siene Taktfrequenz begrenzt... > Kein Mensch weiß, welche Frequenz du willst/brauchst/hast. Ich habe auf > jeden Fall noch nichts dazu gefunden. Es ist noch nicht mal klar, ob > das hier jetzt was mit SPI zu tun hat oder nicht. Und noch viel weniger, > warum du da die Bits mitzählen musst... :-/ Genau genommen zähle ich die Takte mit,um zu wissen, wann 8-Bit übertragen wurden, um dann das Byte aus dem Schieberegister ein ein Ausgangsregister zu kopieren.
Also wenn ich hier sehe, das geschlagene FÜNF Spezln, wie Peter D. K-H. B., L. M., R.B. und Oldmax, darunter K-H. der hier der ausgewiesene Versteher ist und L.M. der vermutlich auf einem (weichen) Haufen FPGAs schläft, die alle schon mal den einen oder anderen Fehler gemacht haben :-), nicht verstehen, was Du willst oder aus welchen Gründen Du die gemachten Vorschläge ablehnst, dann meine ich das Du Deine Erklärung und, noch wichtiger, Deinen Gedankengang wirlich nochmal gründlich abklopfen solltest. Es könnte vielleicht helfen wenn Du uns mal wirklich ganz primitiv, als wenn wir noch unerfahrener sind als Du erklärst worum es geht. Anders sehe ich keine Chance hier zum Erfolg zu kommen.
Sebi2020 schrieb: > Wollte Fragen, ob zufällig jemand einen IC kennt, für einen getakteten 2 > Flankendetektor. Sprich, was ich haben möchte, bei steigender Flanke des > Taktsignals soll er prüfen, ob eine Änderung des Signals gegeben hat. Er > soll allerdings keine Impulse am Ausgang abgeben sondern einfach ein > positives Signal in der Länge des Signaltaktes. Sprich, der Signaltakt > soll nur anzeigen, wie lang das Signal am Ausgang anliegen soll. Quasi > ein Monoflop was so lange einen High-Impuls hält, bis der Takt wieder > von high nach Low wechselt. Ich brauche das für einen Taktzähler. Ein > einfaches Shiftrregister geht nicht. Weil ein Shiftregister, bzw. Zähler > mindestens 1 Takt braucht um sich zurückzu setzen. sprich takt 1 - 8, > bei acht soll das Signal kommen. Ich hab das mal durch Babelfish geschickt: 想問是否機會不會有人知道的鐘控 2 IC 邊緣檢測器。換句話說，什麼我想要在不斷上升的邊緣 他將評估是否改變的信號返回的時鐘信號。他 要給但沒有脈衝輸出上，但只是 在信號欄的長度的積極信號。說，信號的時鐘 要顯示只是多長時間應該是在輸出信號。准 Monoflop 什麼持有高脈衝這麼長時間，直到再次的時鐘 高到低的變化。我需要這一個時鐘計數器。A 簡單 Shiftrregister 是不能接受的。作為一個 Shiftregister 或計數器 至少 1 週期需要把妥善保養。說每 1-8， 八點來的信號。 jetzt verstehe zwar immer noch nichts, aber es tut nicht mehr so weh es zu lesen.
Sebi2020 schrieb: > Ein uC ist immer durch siene Taktfrequenz begrenzt... Mit wieviel MHz sendest Du denn? Sebi2020 schrieb: > Anhand der Position im Register weist du was Datenbit und was Startbit > ist! Ich gebs auf. Du hast nur 2 Pins, Takt und Daten, da ist nirgends ne Position verfügbar. Der Master hat irgendwann mal mit Senden angefangen und Du schaltest den Slave bei irgendeinem zufälligen Bit an. Peter
Paul schrieb: > Ich hab das mal durch Babelfish geschickt: > > 想問是否機會不會有人知道的鐘控 2 IC > 邊緣檢測器。換句話說，什麼我想要在不斷上升的邊緣 > 他將評估是否改變的信號返回的時鐘信號。他 > 要給但沒有脈衝輸出上，但只是 > 在信號欄的長度的積極信號。說，信號的時鐘 > 要顯示只是多長時間應該是在輸出信號。准 > Monoflop 什麼持有高脈衝這麼長時間，直到再次的時鐘 > 高到低的變化。我需要這一個時鐘計數器。A > 簡單 Shiftrregister 是不能接受的。作為一個 Shiftregister 或計數器 > 至少 1 週期需要把妥善保養。說每 1-8， > 八點來的信號。 > > jetzt verstehe zwar immer noch nichts, aber es tut nicht mehr so weh es > zu lesen. Äh, ja.... KK Hmm schrieb: > > Es könnte vielleicht helfen wenn Du uns mal wirklich ganz primitiv, als > wenn wir noch unerfahrener sind als Du erklärst worum es geht. > > Anders sehe ich keine Chance hier zum Erfolg zu kommen. Hms, ich will Daten seriell über eine Leitung übertragen. Eine zweite dient als Taktleitung. Den Receiver dafür will ich in Hardware bauen. Nun, seh ich 3 möglichkeiten Festzustellen ob ein Byte in dem Schieberegister, in dem die Daten seriell reingeschoben werden, angekommen ist: 1. Ich zähle 8 Takte mit, weil 1 Byte = 8 Bits, dato nach acht Takten ist ein Byte angekommen. Dazu der Zähler! 2. Möglichkeit: Ich reserviere ein Bit im Schieberegister als Start/Empfangsanzeigendes Bit. Sprich, nach so und so vielen Takten erscheint das Startbit, welches eine eins sein muss am Ausgang und steuert damit das Ausgaberegister an und lädt die Daten dadurch in das Register. 3. Möglichkeit: Ich sage 0x0 = leer und alles > 0 = voll... Muss dann aber immer noch Mitzählen um zu wissen, wann das Byte drinne ist. Und außerdem hab ich dann nur noch 7 Bit für Daten wie bei Möglichkeit 2 zur verfügung. Darf ja die Zahl Null nicht mehr verwenden, müsste demnach die Datennull umkodieren. z.B. in das ASCII-Zeichen 0
Peter Dannegger schrieb: > Sebi2020 schrieb: >> Ein uC ist immer durch siene Taktfrequenz begrenzt... > > Mit wieviel MHz sendest Du denn? 24 Mhz, soviel schafft der uC aber nicht! > Ich gebs auf. > Du hast nur 2 Pins, Takt und Daten, da ist nirgends ne Position > verfügbar. > Der Master hat irgendwann mal mit Senden angefangen und Du schaltest den > Slave bei irgendeinem zufälligen Bit an. > > > Peter Das System befindet sich auf einer Platine, da setzt man einfach voraus, dass der "Slave" bereit zum Empfangen ist.
Sebi2020 schrieb: > da setzt man einfach voraus Das ist schlecht. Man sollte nie etwas voraussetzen, ohne sich sicher zu sein. Es ist nicht leicht ein exakt gleichzeitiges Power-on Reset von 2 Schaltungen zu garantieren, selbst auf der gleichen Platine. Einfacher ist es, ein Protokoll zu implementieren, was sich selber synchronisiert. Peter
Peter Dannegger schrieb: > Sebi2020 schrieb: >> da setzt man einfach voraus > > Das ist schlecht. Man sollte nie etwas voraussetzen, ohne sich sicher zu > sein. > > Es ist nicht leicht ein exakt gleichzeitiges Power-on Reset von 2 > Schaltungen zu garantieren, selbst auf der gleichen Platine. > > Einfacher ist es, ein Protokoll zu implementieren, was sich selber > synchronisiert. > > > Peter Naja, ich bin ja erstmal auf der physischen Ebene. Ich muss doch erstmal sicherstellen, das überhaupt Informationen korrekt übertragen werden können, das heißt, das die Schnittstelle funktioniert. Ich mein, wenn die nicht funktioniert, dann bringt auch jegliches Protokoll nichts... wenn sowieso nichts vernünftig ankommt.
Sebi2020 schrieb: > Peter Dannegger schrieb: >> Sebi2020 schrieb: >> Einfacher ist es, ein Protokoll zu implementieren, was sich selber >> synchronisiert. >> >> >> Peter > > Naja, ich bin ja erstmal auf der physischen Ebene. Ich muss doch erstmal > sicherstellen, das überhaupt Informationen korrekt übertragen werden > können, das heißt, das die Schnittstelle funktioniert. Ich mein, wenn > die nicht funktioniert, dann bringt auch jegliches Protokoll nichts... > wenn sowieso nichts vernünftig ankommt. Ich meien, z.B. dadurch das ich jetzt das Byte nach 8. Takten in ein Ausgaberegister schiebe, hat der Kontroller 8. lang zeit die Daten zu lesen, anstatt 1 Takt. Darum gehts mir, und wie soll ich den sonst automatisch zwischenspeichern,ohne mitzuzählen... Ich weis nciht was da jegliche Software umsetzung helfen kann. Mir geht es ja gerade darum zu überprüfen wann die Übertragung eines Bytes abgeschlossen ist. Bei einem uC der mit 16 Mhz getaktet ist.
Sebi2020 schrieb: > Naja, ich bin ja erstmal auf der physischen Ebene. Ich habe schon die transzedentale ereicht... ;-) Sebi2020 schrieb: > Das System befindet sich auf einer Platine, da setzt man einfach voraus, > dass der "Slave" bereit zum Empfangen ist. Und nicht zufälligerweise mal ein kleiner EMV-Impuls daherkommt, der dann als zusätzlicher Takt gesehen wird. Und für den Rest des Tages alles um 1 Bit verschoben ankommt? Mein Tipp: sieh dir einfach mal an, wie andere Bussystem dieses Problem gelöst haben. Da fallen mir noch ein paar Fragen ein: Läuft der Datenstrom kontinuierlich, oder sind da Pausen? Wieviel Bytes werden da am Block übertragen? BTW: 24MHz sind auch mit 4017&Co recht sportlich. Mit 5V kann der immerhin noch 2MHz. Und der HC4017 macht bei 6V gerade noch so die 24MHz... :-o
Lothar Miller schrieb: > Sebi2020 schrieb: >> Naja, ich bin ja erstmal auf der physischen Ebene. > Ich habe schon die transzedentale ereicht... ;-) > > Sebi2020 schrieb: >> Das System befindet sich auf einer Platine, da setzt man einfach voraus, >> dass der "Slave" bereit zum Empfangen ist. > Und nicht zufälligerweise mal ein kleiner EMV-Impuls daherkommt, der > dann als zusätzlicher Takt gesehen wird. Und für den Rest des Tages > alles um 1 Bit verschoben ankommt? > Mein Tipp: sieh dir einfach mal an, wie andere Bussystem dieses > Problem gelöst haben. > > Da fallen mir noch ein paar Fragen ein: > Läuft der Datenstrom kontinuierlich, oder sind da Pausen? > Wieviel Bytes werden da am Block übertragen? > > BTW: 24MHz sind auch mit 4017&Co recht sportlich. Mit 5V kann der > immerhin noch 2MHz. Und der HC4017 macht bei 6V gerade noch so die > 24MHz... :-o Es sind natürlich Pausen. Es werden nur Daten gesendet, wenn was zu senden ist... 2 Byte im Block, dann ist der Puffer gefüllt und der Controller kann zu lesen anfangen.
Sebi2020 schrieb: > 2 Byte im Block, Und wie lang dauert die Pause danach? Welche effektive Datenrate hast du? Wenn du 100 mal pro Sekunde 2 Bytes mit 100MHz überträgst, hast du trotzdem nur 200 Bytes/sec übertragen... Ehrlich: es ist wirklich unwahrscheinlich mühsam, dir jedes noch so kleine Fitzelchen Information aus der Nase ziehen zu müssen. > 2 Byte im Block, > dann ist der Puffer gefüllt und der Controller kann zu lesen anfangen. Dann lies doch 16 Bits in dein Schieberegister ein...
Lothar Miller schrieb: > Sebi2020 schrieb: >> 2 Byte im Block, > Und wie lang dauert die Pause danach? > Welche effektive Datenrate hast du? > Wenn du 100 mal pro Sekunde 2 Bytes mit 100MHz überträgst, hast du > trotzdem nur 200 Bytes/sec übertragen... > > Ehrlich: es ist wirklich unwahrscheinlich mühsam, dir jedes noch so > kleine Fitzelchen Information aus der Nase ziehen zu müssen. > >> 2 Byte im Block, >> dann ist der Puffer gefüllt und der Controller kann zu lesen anfangen. > Dann lies doch 16 Bits in dein Schieberegister ein... Naja, aber dann hat der Controller doch wieder weniger Zeit die Daten auszuwerten, und dann kommt noch hinzu, das ich wiederum diese 2 Bytes auch wieder weiter schieben muss. und unendlich I/O Ports hat son kleiner IC ja auch nicht. DIL IC!
Gerald H. schrieb: > Sowas programmiert man in einen PAL/GAL oder ein PLD. Ja, wenn ich nur die nötigen Programmer für PALS / GALS oder PLDs hätte... kostet auch alles Geld... den billigsten PAL / GAL Programmer den ich gefunden ahbe kostet 50 €.
Sebi2020 schrieb: >> Ich möchte Dir höflich und ebenso dringend empfehlen Deine Erklärung >> durch eine Skizze des Signalverlaufes zu ergänzen. Als unbeteiligter Beobachter würde ich vorschlagen, die Pulse nicht von 1 bis 8, sondern von 0 bis 7 durchzunummerieren. Dann kann man fürs Gating einfach einen 3-Bit Binärzähler mit Takt auf der steigenden Flanke verwenden und das Gate über eine Und-Verknüpfung der 3 Ausgänge freigeben.
Sebi2020 schrieb: > Ja, wenn ich nur die nötigen Programmer für PALS / GALS oder PLDs > hätte... kostet auch alles Geld... den billigsten PAL / GAL Programmer > den ich gefunden ahbe kostet 50 €. Wer spricht hier von GALs? Wie war das nochmal im Beitrag "Re: Getakteter Zweiflankendetektor"
> Wer spricht hier von GALs? > Wie war das nochmal im > Beitrag "Re: Getakteter Zweiflankendetektor" Antwort?! Gerald H.: Gerald H. schrieb: > Sowas programmiert man in einen PAL/GAL oder ein PLD.
Vorüberziehender Gast schrieb: > Sebi2020 schrieb: >>> Ich möchte Dir höflich und ebenso dringend empfehlen Deine Erklärung >>> durch eine Skizze des Signalverlaufes zu ergänzen. > > Als unbeteiligter Beobachter würde ich vorschlagen, die Pulse nicht von > 1 bis 8, sondern von 0 bis 7 durchzunummerieren. Dann kann man fürs > Gating einfach einen 3-Bit Binärzähler mit Takt auf der steigenden > Flanke verwenden und das Gate über eine Und-Verknüpfung der 3 Ausgänge > freigeben. Ja so hab ichs jetzt auch letztendlich gelöst..., aber trotztdem danke! > Lothar Miller schrieb: >> 2 Byte im Block, >> dann ist der Puffer gefüllt und der Controller kann zu lesen anfangen. > Dann lies doch 16 Bits in dein Schieberegister ein... Frage mich jetzt nur noch immer, was ich damit erreichen soll, wenn ich in einem Zug 2 Byte einlese, was ich für einen Vorteil davon habe. Bitte erkläre mir das mal. Und warum es nicht sinnvoll ist das durchzuzählen. Wie soll ich den sonst das ganze in Einheiten (Bytes / Symbole etc pp. ) aufteilen, wenn ich nich mitzähle? Es muss ja auch irgendwie ersichtlich sein. Wenn ich einen takt aufs Schieberegister gebe muss ich ja wohl sicherstellen, das die Daten gesichert werdne, bevor sie rausgeschoben werden und weg sind. Also wie gesagt, wie den sonst? Und nochmal, hier geht es nicht um irgendein Protokoll etc. das Protokoll setzt eins drüber auf. Sprich Fehlerüberprüfung, Intigritätsprüfung etc. Ich meine, was schlägst du denn sonst vor? Ohner jetzt auf eine höhere Ebene zu gehen!
Du wirst in der Praxis keine einzige serielle Übertragung ohne Synchronisationsmechanismus finden. Wenn Du es aber trotzdem versuchst, wirst Du Dich nur ärgern, wie unzuverlässig das ist. Jedes System muß nach dem Einschalten oder nach einer Störung von alleine in einen bekannten Zustand zurück finden können. Peter
Sebi2020 schrieb: > Frage mich jetzt nur noch immer, was ich damit erreichen soll, wenn ich > in einem Zug 2 Byte einlese, was ich für einen Vorteil davon habe. Geht mir genau so, hab nicht den blassesten Schimmer wo der Vorteil liegen könnte. Das liegt meiner Meinung nach an den wirren Fragestellungen (die Datenrate weiß ich z.B. immer noch nicht vom Sinn und Zweck des ganzen ganz zu Schweigen). Typisch für 16 Bit Synchron sind SSI Interface. Die arbeiten teilweise mit sehr hohen Daten- und Wiederholraten an (weit jenseits von dem was ein Prozessor verarbeiten kann). Für die gibt es spezielle Chips oder man kann mit 2 SPI Slaves in Reihe ne Trickschaltung basteln. Wenn der µC 2 SPIs hat. > Bitte > erkläre mir das mal. Und warum es nicht sinnvoll ist das durchzuzählen. Das reicht vielleicht in deinem Fall, aber es ist schlicht instabil. Eine Störung auf der Taktleitung und das ganze ist out of Sync. Wenn du Pausen hast ist doch alles klar. Ein Monoflop getriggert von der Taktleitung resettet deine Schaltung wenn der Clock ausbleibt. Das ist stabil und kostet keine 50 Euro für den Progger (aber n mherfaches an Zeit zum basteln, die holst du selbst bei McDo hinterm Tresen schneller wieder rein).
Der Rächer der Transistormorde schrieb: > Sebi2020 schrieb: > >> Bitte >> erkläre mir das mal. Und warum es nicht sinnvoll ist das durchzuzählen. > > Das reicht vielleicht in deinem Fall, aber es ist schlicht instabil. > Eine Störung auf der Taktleitung und das ganze ist out of Sync. > > Wenn du Pausen hast ist doch alles klar. Ein Monoflop getriggert von der > Taktleitung resettet deine Schaltung wenn der Clock ausbleibt. > > Das ist stabil und kostet keine 50 Euro für den Progger (aber n > mherfaches an Zeit zum basteln, die holst du selbst bei McDo hinterm > Tresen schneller wieder rein). Wie machen es denn dann andere Interfaces? Eine Pause ist nicht garantiert. Ich meine, woher wissen den andere Synchrone Interfaces, wann 16 Bit angekommen sind, wenn sie nicht mitzählen. Ich meine Interfaces, die ohne Taktrückgewinnung arbeiten...
>Ich meine Interfaces, die ohne Taktrückgewinnung arbeiten...
Wieso fügst Du als Bedingung hinzu: ohne Taktrückgewinnung?
Bezieht sich das noch auf Deine ursprüngliche Anfrage?
Bei Deiner Anfrage gehen wir doch davon aus, das ein Takt vorliegt. Also
ist ohnehin keine Rückgewinnung nötig.
Die einfachste Methode wäre, Sender und Empfänger über einen gemeinsamen
Reset zurückzusetzen. Damit beide auch mit einer gewissen Sicherheit in
dem jeweils komplementären Zustand sind (also der Sender sendebereit,
der Empfänger empfangsbereit) wartet man eine gewisse Mindestzeit ab.
Diese Methode hat gewisse Grenzen. Z.B. die Frage ob, wie hier erwähnt,
nicht evtl. Störimpulse auf der Taktleitung oder Datenleitung auftreten
können. Das muss entweder akzeptabel oder wenigstens erkennbar sein.
Weiter muss solch ein Fehlerzustand vom Empfänger dem Sender mitgeteilt
werden können. Als Variante kann der Takt vom Sender abgeschaltet
werden.
Eine einfache Erweiterung dieser Methode ist eine zusätzliche Leitung,
die vom Sender ausgehend, den Empfänger mit einem Impuls jeweils vor
Sendebeginn zwangsweise in den empfangsbereiten Zustand versetzt. Der
Empfänger muss dann ggf. bereits teilweise empfangene Daten verwerfen.
Ein anderer Weg ist z.B. der bei RS232 begangene. Um den Anfang eines
Blocks aus 8, 7 oder 6 Bit zu kennzeichnen wird das sog. Start-Bit
übertragen. In dem Fall wird kein Takt übertragen. Vielmehr ist der Takt
durch die Konstruktion mit einer gewissen Genauigkeit gleich.
Allen diesen Methoden ist gemeinsam, das die Takte (im letzten Fall eben
der vom Empfänger selbst erzeugte) gezählt werden und damit die
empfangenen Bits. Einige Antworten hier könnten Dir suggeriert haben,
das zählen an sich falsch oder fehleranfällig ist, und deswegen nicht
verwendet wird. Das ist so nicht richtig. Vielmehr ist das in
Zusammenhang mit möglichen Störungen auf der Taktleitung zu sehen.
Kann man aber solche Störungen nicht ausschliessen, so muss man andere
Methoden anwenden.
Einfaches Beispiel ist die Verwendung von redundanten Bits im
Datenstrom. Z.B. kann bei RS232 ein Paritätsbit übertragen werden.
Stimmt die Parität nicht, verwirft der Empfänger die Daten. Ausserdem
kann der Empfänger noch dem Sender mitteilen, das er einen Fehler
erkannt hat.
In der Praxis werden oft Kombinationen aus mehreren der oben genannten
einfachen Methoden verwendet.
Da Du das OSI-Schichtenmodell zur Sprache gebracht hast, wäre es
sinnvoll das bisher gesagt dort einzuordnen.
1. Die einfache Sendung/der Empfang von Symbolen über eine
physikalisches Medium ist die unterste Schicht. Dabei wird entweder
vorausgesetzt, das diese Übertragung funktioniert oder einer höheren
Schicht überlassen diese Übertragung zu sichern.
2. Die Sicherungsschicht übernimmt die eben erwähnte Sicherung der
Übertragung. Nach meiner Ansicht ist RS232, abweichend von der
Darstellung in Wikipedia, insofern ein Zwitter, als das es Elemente der
1. und der 2. Schicht enthält. Das erwähnte Paritätsbit ist so ein Teil
der Sicherung die sich allerdings nicht auf einzelne Bits sondern auf
Bytes bezieht.
Die Sicherungsschicht ist nicht notwendigerweise Software. Sie kann auch
durch Hardware realisiert werden.
Weitere Beispiele für Übertragungsmethoden sind I2C, oder SPI. Lies Dir
das mal durch.
Wenn ich das richtig sehe, wird dir Sicherung aber meistens auf Byte-Ebene vorgenommen, oder? Also sprich, die Synchronisation erfolgt Byteweise. Ich denke Nach jedem-Bit ist nen bisschen schwer festzustellen, ob der Takt noch stimmt.... Ich mein, bei RS-232 Synchronisiert er sich ja auch erst nach einem Byte wieder neu. Sprich beim nächsten Startbit.
Sebi2020 schrieb: > Wenn ich das richtig sehe, wird dir Sicherung aber meistens auf > Byte-Ebene vorgenommen, oder? Was meinst Du mit "meistens"? > Also sprich, die Synchronisation erfolgt > Byteweise. Ich denke Nach jedem-Bit ist nen bisschen schwer > festzustellen, ob der Takt noch stimmt.... Wieso "sprich"? _Sicherung und Synchronisation sind nicht das selbe._ Üblicherweise prüft man während des Betriebs nicht "ob der Takt noch stimmt". Das wird durch die Konstruktion innerhalb bestimmer Rahmenbedingungen sichergestellt. Es wird einfach mit dem Takt gesampelt. > Ich mein, bei RS-232 Synchronisiert er sich ja auch erst nach einem Byte > wieder neu. Sprich beim nächsten Startbit. Nicht im Wortsinn. Der Takt wird nicht synchronisiert. Sondern es wird begonnen zu sampeln. Wenn der Takt genügend genau übereinstimmt, dann reicht auch einmal sampeln pro Bit. Es wird aber oft auch mehrfach gesampelt. Aber das kannst Du alles im Netz nachlesen. Das solltest Du erstmal tun.
Ich hab jetzt nicht alles gelesen, aber das Impulsdiagramm scheint mir ein Fall für den 74HC40103 zu sein. Der ist als Teiler durch 3...256 einstellbar und hat einen TC-Ausgang (terminal count) der genau einen Takt lang low ist, und auf den PresetEnable-Eingang rückgeführt werden muss. http://www.nxp.com/products/logic/counters_frequency_dividers/binary_counters/series/74HC40103.html
Hmm schrieb: > Was meinst Du mit "meistens"? Ich weis es nicht genau >> Also sprich, die Synchronisation erfolgt >> Byteweise. Ich denke Nach jedem-Bit ist nen bisschen schwer >> festzustellen, ob der Takt noch stimmt.... > > Wieso "sprich"? _Sicherung und Synchronisation sind nicht das selbe._ > > Üblicherweise prüft man während des Betriebs nicht "ob der Takt noch > stimmt". Das wird durch die Konstruktion innerhalb bestimmer > Rahmenbedingungen sichergestellt. Es wird einfach mit dem Takt > gesampelt. Und wie stellt man das an? In dem man einen Takt für das Sampeln erzeugt. Schließlich kann der Receiver nicht hellsehen. >> Ich mein, bei RS-232 Synchronisiert er sich ja auch erst nach einem Byte >> wieder neu. Sprich beim nächsten Startbit. > > Nicht im Wortsinn. Der Takt wird nicht synchronisiert. Sondern es wird > begonnen zu sampeln. Wenn der Takt genügend genau übereinstimmt, dann > reicht auch einmal sampeln pro Bit. Es wird aber oft auch mehrfach > gesampelt. > > Aber das kannst Du alles im Netz nachlesen. > Das solltest Du erstmal tun. Nein, nciht der Takt wird Synchronisiert, aber der interne Takt wird damit synchronisiert, irgendwie musst du ja auch wissen wann du Sampeln musst, oder? Und da die interne Frequenz ca. das 16x Fache der Baudrate ist, kannst du dir ja ausrechnen, anhand des Startbits, wann du sampeln musst. Nämlich erst nach 8 Takten und dann alle 16 Takte. Ich kenne RS232... Und irgend eine Form von Synchronisation muss ja stattfinden. Schließlich ist das Ding asynchron. Eigentlich sollte der Receiver nur einmal pro Bit sampeln und zwar in der Mitte. > Synchronisation ist nicht dasselbe wie Sicherung Naja, wieso den nicht? Für mich ist das eine Form der Sicherung, um durch Impulse, die auf der Taktleitung entstehen können, dafür zu sorgen das man nicht nur noch Mist empfängt. Es ist keine Überprüfung, ob die Daten richtig sind, aber es ist ein Ansatz zu vermeiden das die Daten falsch sind.... zumindest in meinen Augen. Korrigiere mich, wenn ich falsch liege.
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.