Getakteter Zweiflankendetektor

@ sebi

Ich möchte Dir höflich und ebenso dringend empfehlen Deine Erklärung 
durch eine Skizze des Signalverlaufes zu ergänzen.

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

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:
> Kein IC!
Korrigiere, keinen uC aus Geschwindigkeitsgründen.

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

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...

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...

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:
> 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.

Der Rächer der Transistormorde schrieb:
> den ersten Takt catchen

den zweiten natürlich ;-).

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

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

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?

> 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...

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.

> 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...

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...

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!

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.

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.

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.

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.

Sowas programmiert man in einen PAL/GAL oder ein PLD.

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.

> 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!

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.

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.