Hallo, Ich wollte demnächst eine Software USART im synchronen Modus programmieren. (USRT) Und zwar nur den Empfängerteil. Hat das schon mal jemand gemacht? Prinzipiell stelle ich mir das viel einfacher vor als die asynchrone Version. Das ganze läuft ja gewissermaßen wie eine SPI-Übertragung, wo jedes Bit durch eine Clock-Flanke gesampled wird. Aber habt ihr einen Ansatz, wie ich herauskriege, ob gerade die Start/Stop Flanke oder der Rest gesampled wurde? Da bräuchte ich ja dann doch wieder eine Zeitmessung, oder nicht? PS: In einer AVR Note steht, dass der Idle-Pegel von RS232 logisch High ist. Stimmt das überhaupt? Soweit ich weiß ist doch der Idle-Pegel am Rechner bei +12V, was logisch Low ist... Oder verdenke ich mich gerade?
Die synchrone USART verwendet eine zusätzliche Clockleitung. Je nach
Einstellung der Polarität werden die Samples zur steigenden oder
fallenden Flanke der Clock genommen, und zwar gegensätzlich für RXD und
TXD.
>In einer AVR Note steht, dass der Idle-Pegel von RS232 logisch High ist.
Der UART-Idle-Ausgangspegel ist logisch High, was die Pegelwandler
daraus machen, interessiert wenig, weil nach 2 Wandlungen ist alles
genau so, wie es vorher war
Travel Rec. wrote: > Die synchrone USART verwendet eine zusätzliche Clockleitung. Je nach > Einstellung der Polarität werden die Samples zur steigenden oder > fallenden Flanke der Clock genommen, und zwar gegensätzlich für RXD und > TXD. Jup, das weiß ich. Steht exakto so im Datenblatt. :-) >>In einer AVR Note steht, dass der Idle-Pegel von RS232 logisch High ist. > > Der UART-Idle-Ausgangspegel ist logisch High, was die Pegelwandler > daraus machen, interessiert wenig, weil nach 2 Wandlungen ist alles > genau so, wie es vorher war Wieso interessiert das wenig? Mir hat man gesagt, dass bei RS232 die Pegel High -> -12V Low -> +12V sind. Und was für Wandlungen meinst du überhaupt? Wie gesagt, mein Problem ist eher, wie ich zu jedem Interrupt auf der Clock-Leitung sehen kann, ob ich gerade ein Start-Bit oder etwas anderes vor der Nase habe. Man stelle sich vor, ich verliere irgendwo ein Bit - Dann ist ja der ganze Empfänger dusselig :-)
>Wie gesagt, mein Problem ist eher, wie ich zu jedem Interrupt auf der >Clock-Leitung sehen kann, ob ich gerade ein Start-Bit oder etwas anderes >vor der Nase habe. Man stelle sich vor, ich verliere irgendwo ein Bit - >Dann ist ja der ganze Empfänger dusselig :-) ??? Was denn für einen Interrupt? Interrupts treten (wenn aktiviert) dann auf, wenn ein komplettes Byte in UART angekommen ist oder wenn eines komplett ´rausgeschoben wurde oder wenn das TX-Register leer ist. Um Start und Stoppbits muß man sich nicht im einzelnen kümmern. Willst Du 2 AVRs verbinden oder wie? Und ja, auf den Datenleitungen am RS232 ist logisch High -12V, bei den Handshake-Leitungen ist es umgekehrt. Mit Wandlungen meinte ich TTL/CMOS zu RS232 und RS232 zu TTL/CMOS.
Travel Rec. wrote: >>Wie gesagt, mein Problem ist eher, wie ich zu jedem Interrupt auf der >>Clock-Leitung sehen kann, ob ich gerade ein Start-Bit oder etwas anderes >>vor der Nase habe. Man stelle sich vor, ich verliere irgendwo ein Bit - >>Dann ist ja der ganze Empfänger dusselig :-) > > > ??? Was denn für einen Interrupt? Interrupts treten (wenn aktiviert) > dann auf, wenn ein komplettes Byte in UART angekommen ist oder wenn > eines komplett ´rausgeschoben wurde oder wenn das TX-Register leer ist. > Um Start und Stoppbits muß man sich nicht im einzelnen kümmern. Willst > Du 2 AVRs verbinden oder wie? Hm? Ich möchte eine USRT in Software schreiben. Also nicht das Hardware USART benutzen, da das nicht alle AVRs haben. Mit Interrupt meine ich einen Externen Interrupt an dem Pin, wo meine XCK Leitung am anderen Ende angeschlossen ist. Der Software USRT Code soll nur einen Empfänger beinhalten. Ich wollte bei jedem High->Low bzw. Low->High der Clock im Interrupt ein Bit von meinem RxD Pin samplen und das Byte zusammenbauen. Aber mein Problem ist, wie ich erkenne, ob das gerade gesamplete Bit ein Startbit war, oder nicht. Ich hoffe, dass es jetzt ein wenig klarer geworden ist. Dass ich das so unverständlich geschrieben hab, hätte ich nich gedacht.
Gast
#611531
Bei synchroner Übertragung gibt es eigentlich kein Startbit. Im allgemeinen scannt der Empfänger auf ein bestimmtes Bitmuster; wenn dieses erkannt wurde, kommt als nächstes das erst Bit der Nutzdaten. Zweitens ist es üblich entweder High->Low oder Low->High zur Datenübernahme zu verwenden, nicht beide.
Bobby wrote: > Bei synchroner Übertragung gibt es eigentlich > kein Startbit. Das ist schön, dass es das eigentlich nicht gibt. Aber vielleicht solltest du dir mal ein RS232-Frame angucken? > Zweitens ist es üblich entweder High->Low oder Low->High > zur Datenübernahme zu verwenden, nicht beide. Das ist mir auch klar, ich habe entweder/oder gemeint. (Je nach Einstellung des Masters) Ihr verkauft mich ja für dumm hier... Was ist denn daran so schwer? Wenn man schreibt "Software UART" weiß jeder bescheid. Aber nicht bei einem "Software USRT"? *Kratz
Zitat aus Wikipedia: "Im Gegensatz dazu sind synchrone serielle Schnittstellen durch einen bestimmten Bittakt ohne einen Rahmen aus Start-/Stopp-Bit aufgebaut." http://de.wikipedia.org/wiki/USART
Läubi Mail@laeubi.de wrote: > Zitat aus Wikipedia: > "Im Gegensatz dazu sind synchrone serielle Schnittstellen durch einen > bestimmten Bittakt ohne einen Rahmen aus Start-/Stopp-Bit aufgebaut." > http://de.wikipedia.org/wiki/USART Nungut, im Datenblatt steht leider nichts dazu. Deshalb bin ich davon ausgegangen, dass komplette RS232 Frames versendet werden. Dann lass ich's sein. Mach ich halt ne Software-SPI.
Gast
#611583
@Simon: Vielleicht hätte es geholfen/weniger verwirrt, wenn du "Soft-SPI(slave)" geschrieben hättest... ;-) Außerdem ist mir der Zusammenhang zwischen RS232 und einer synchronen Übertragung nicht ganz klar -- das entspricht ja AFAIK keinem Standard, also müssen ja Ruhepegel, Pinbelegung etc. 'willkürlich' festgelegt werden. scnr --Jörg
Gast
#611586
Oh Menno ;) da war ich dann doch zu langsam sry --Jörg
Jörg X. wrote: > @Simon: > Vielleicht hätte es geholfen/weniger verwirrt, wenn du "Soft-SPI(slave)" > geschrieben hättest... ;-) Ja, wenn ich gewusst hätte, dass es das gleiche ist. Siehe vorheriger Post... > Außerdem ist mir der Zusammenhang zwischen RS232 und einer synchronen > Übertragung nicht ganz klar -- das entspricht ja AFAIK keinem Standard, > also müssen ja Ruhepegel, Pinbelegung etc. 'willkürlich' festgelegt > werden. Wieso? Man kann doch ein RS232-Frame auch synchron übertragen? Und aus der Tatsache heraus, dass manche AVRs genau das vorsehen, habe ich abgeleitet, dass es dafür wohl irgendeinen Standard gibt. (Wonach es aber gerade irgendwie nicht aussieht)
Ich glaub der Syncronmodus ist damit 2 AVRs miteinder sprechen könne obwohl sie mit krummen werten getaktet sind oder so. Bei RS232 kenn ich normal nurnoch den Modus mit HardwareHandshake.
Läubi Mail@laeubi.de wrote: > Ich glaub der Syncronmodus ist damit 2 AVRs miteinder sprechen könne > obwohl sie mit krummen werten getaktet sind oder so. Das ist ja meine Absicht. Nur dass eine Seite keine Hardware-USART hat. (Tiny15)
Na dan kannst du das doch so machen wie das (hoffentlich) im Datenblatt angebeen Protokoll aussieht. Ich hatte das nur mal überflogen und meine (wurde glaub ich auch mal im Forum ausgemessen mitm Ozi) das sich Syncron und Asyncron beim AVR nur unterscheiden, das es halt die CLK Leitung zusätzlich gibt. Aber, meiner Meinung nach kann man dann auch gleich SPI nehmen, da hat man auch nur 3 Drähte, und das hat (fast) jeder AVR build in.
Läubi Mail@laeubi.de wrote: > Aber, meiner Meinung nach kann man dann auch gleich SPI nehmen, da hat > man auch nur 3 Drähte, und das hat (fast) jeder AVR build in. Aber keinen Hardware-Parity Generator ;)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.