|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > RTS DTR Amiga/PC unterschiede? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- | [ - Beitrag schreiben - ] |
|
19.03.2007, 10:02 Uhr MaikG Posts: 5172 Nutzer |
Ich habe einen 74HCT595, das ist ein 8-Bit serial-in/serial oder parallel-out shift register with output latches;3-State. Der Takt läuft über DTR, die Daten über RTS. Nun habe ich ein Protokoll zur ansteuerung vom PC, da heisst es z.B. SETRTS CLRDTR SETDTR CLRRTS CLRDTR SETDTR CLRRTS das ist nur ein kleiner ausszug. Nun weiss ich nicht wie ein PC das ausgiebt. Beim Amiga scheint die direkte ansteuerung nur per Interne Schnittstelle via Hardwarezugriff zu Funktionieren. Also Poke ich die werte entsprechend, nacheinander in BFD000 mit einem Delay dazwischen. Soweit ich mich erinnere sind diese Register aber so das der zustand bleibt bis zur der nächsten änderung. Der Chip reagiert darauf nicht korrekt. CLRRTS CLRDTR SETDTR CLRRTS währe auf dem Amiga dann das RTS die ganze Zeit HIGH bleibt. Ich stelle mir vor das beim PC das nur ein Low-High-Low vermutlich im Syncronen Takt mit der Baudrate(9600), ist das richtig? Wie baut man das dann auf dem Amiga nach? Kann man externe Schnittstellen wie die Hypercom auch irgendwie damit betreiben? Ich habe gehört die können irgendwie keine echte Hardware Fehlerkontrolle. [ - Antworten - Zitieren - Direktlink - ] |
|
20.03.2007, 10:22 Uhr DieterG Posts: 164 Nutzer |
Bei PCs werden ganz andere Schnittstellenchiups eingesetzt als beim Amiga. Und auch heute noch ist der vom Amiga flexibler zu programmieren, wäre da nicht der technische Fortschritt vorbei gegangen, wären die heute mit sicherheit Standard.... Gut, beim PC läuft das so ab, das wirklich jedes einzelne Bit einzeln gesetzt werden muss, also dtr und rts jeweils in einem eigenmem zugriff geändert werden müssen. Beim Amiga passiert das ganze Byteorientiert, das heisst, du musst immer im ganzen Byte angeben, wie die einzelnen Flags stehen sollen, und dazu muss natürlich auch noch die Richtung (ein- oder ausgabe) stimmen. Dann solte das ganze einfacher sein. Übleicherweise hält man die Schnittstellen in einem Byte in einer variablen, ändert dort die Bits ab, und sendet dann das komplette Byte an die Schnittstelle. Sollte kein problem darstellen, sonst frag nochmals nach. [ - Antworten - Zitieren - Direktlink - ] |
|
20.03.2007, 18:07 Uhr MaikG Posts: 5172 Nutzer |
>Gut, beim PC läuft das so ab, das wirklich jedes einzelne Bit einzeln gesetzt werden muss, >also dtr und rts jeweils in einem eigenmem zugriff geändert werden >müssen. Mh, okay. >Beim Amiga passiert das ganze Byteorientiert, das heisst, du musst >immer im ganzen Byte angeben, wie die einzelnen Flags stehen sollen, >und dazu muss natürlich auch noch die Richtung (ein- oder ausgabe) >stimmen. Dann solte das ganze einfacher sein. Übleicherweise hält >man die Schnittstellen in einem Byte in einer variablen, ändert dort >die Bits ab, und sendet dann das komplette Byte an die Schnittstelle. Ja, auf Ausgang hab ich. Die befehle hab ich entsprechend zusammengesetzt. Aber funktionieren tut das trotzdem nicht wirklich... Vielleicht hängt das mit den anderen sachen im Protokoll zusammen, GetModemStatus ist aber nur eine Abfrage und PurgeComm hab ich mit CMD_Clear gemacht. Ansonsten ist da noch ClearCommError was aber wohl auch nur eine abfrage ist die nichts weiter zu sagen hat. Dann währe noch das Timing, jetzt hab ich 5000 tv_micros was zumindest überhaupt werte ergibt. 9600 Baud sind aber 1200 khz also 19 tv_micros oder hab ich da was falsch gerechnet? [ - Antworten - Zitieren - Direktlink - ] |
|
20.03.2007, 19:58 Uhr Holger Posts: 8116 Nutzer |
Zitat:Mich würde wirklich interessieren, was Du da gerechnet hast. n Baud sind n Objekte (hier Bits) pro Sekunde, also n Baud == n Hz. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
20.03.2007, 20:03 Uhr whose Posts: 2156 Nutzer |
@MaikG: Ganz gewaltig sogar... hast Du Dir schon mal überlegt, was Baud überhaupt bedeutet? Es bedeutet "Bits pro Sekunde". Microsekunden wiederum sind millionstel Sekunden, nicht tausendstel. tv_Micros kann demnach Werte von 0 - 999999 aufnehmen. Deswegen kriegst Du mit tv_Micros = 5000 eher was halbwegs Brauchbares von der seriellen Schnittstelle als mit tv_Mircos = 19  104 sollte aber besser passen. Grüße -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
20.03.2007, 21:51 Uhr MaikG Posts: 5172 Nutzer |
>Mich würde wirklich interessieren, was Du da gerechnet hast. n Baud >sind n Objekte (hier Bits) pro Sekunde, also n Baud == n Hz. 9600/8=1200 Durch 8 weil ja nicht 8 Bits gesetzt werden sondern ein Bit. >104 sollte aber besser passen. hilft auch nicht. Irgendwas muss da nicht stimmen, vielleicht gibt Portmon auch nur mist aus. Manchmal fehlen da Zeilen-Blocks, aber erst später noch nicht am Anfang wo ich jetzt bin. [ - Antworten - Zitieren - Direktlink - ] |
|
20.03.2007, 23:05 Uhr whose Posts: 2156 Nutzer |
@MaikG: Du setzt aber trotzdem jeweils nur ein Bit, auch wenn Du dafür ein ganzes Byte in das Register schreiben mußt. Im Endeffekt setzt Du nur CIA-Register-Bits auf 1 oder 0, somit in der Folge die Signalleitungen auf dem seriellen Port. Wie sich das genau verhält weiß ich nun nicht, aber ich glaube, daß da noch ein bißchen mehr zu machen ist für eine serielle Verbindung, als nur Portbits setzen. Ich erinnere mich ganz dunkel an ein Schieberegister im CIA, aber ob das für den seriellen Port eine Bedeutung hat? Einfach mal ins Hardware-Manual schauen, falls verfügbar, oder googlen. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 09:37 Uhr DrNOP Posts: 4118 Nutzer |
Zitat: Ähem ... ich hätt noch eine Alternative anzubieten (wir können ja dann demokratisch abstimmen...  ):die 9600 solltest du mindestens durch 10 teilen, sonst hast du Start- und Stopbit unterschlagen. "Baud" heißt halt "Bits pro Sekunde", nicht "Nutzdaten pro Sekunde", da sollte der Rahmen dann auch dabei sein. Mit tv_micros kommst du nicht weit, weil du keine Mikrosekunden brauchst sondern Millisekunden. Da sind drei Nullen weniger bis zum Komma. Und die vorgeschlagenen 104 kann ich auch nicht bestätigen, ich komme auf 1041. Nochmal in Zahlen: 9600 / 10 = 960 (Für den Fall, daß du ohne Parity, mit je einem Start- und Stopbit arbeitest) 1 / 960 = 0,001041 Sekunden pro Bit, entsprechend 1,041 Millisekunden, entsprechend 1041 Mikrosekunden. Vielleicht sollt' sich mal jemand melden der wirklich weiß wie's geht ...  -- Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker [ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 10:01 Uhr MaikG Posts: 5172 Nutzer |
>Du setzt aber trotzdem jeweils nur ein Bit, auch wenn Du dafür ein ganzes Byte >in das Register schreiben mußt. jein: code: >Wie sich das genau verhält weiß ich nun nicht, aber ich glaube, daß >da noch ein bißchen mehr zu machen ist für eine serielle >Verbindung, als nur Portbits setzen. Über RTS und DTR erfolgt wohl eine art Konfiguration oder auch Initalisierung. Die Kommunikation läuft dann weitestgehends ganz normal per TX, RX ab. >Und die vorgeschlagenen 104 kann ich auch nicht bestätigen, ich >komme auf 1041. Okay werde ich nachher mal probieren. >9600 / 10 = 960 (Für den Fall, daß du ohne Parity, mit je einem Start- und Stopbit arbeitest) 8N1 ohne Parity, Parity wird nur für die Kommunikation mit dem 595 benutzt. [ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 10:27 Uhr whose Posts: 2156 Nutzer |
@MaikG: Dir ist aber schon klar, daß Du Dich um ALLE Bits selbst kümmern mußt, wenn Du direkt in die CIA-Register POKEst, um die Signale des seriellen Ports zu steuern? Da kannst Du nicht normal vorgehen nach dem Motto "Ich benutze 8n1-Kommunikation, ich muß mich aber nur um die Datenbits kümmern". Das funktioniert nur dann so, wenn Du das serial.device benutzt. Das kümmert sich dann um das Timing für die gewünschte Baudrate und auch um die Start- und Stopbits. Wenn Du direkt auf die Hardware zugreifst, mußt Du wirklich alles selbst machen, was sonst das entsprechende Device für Dich erledigt. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 10:49 Uhr MaikG Posts: 5172 Nutzer |
>Und die vorgeschlagenen 104 kann ich auch nicht bestätigen, ich >komme auf 1041. geht auch nicht. >Dir ist aber schon klar, daß Du Dich um ALLE Bits selbst kümmern >mußt, wenn Du direkt in die CIA-Register POKEst, um die Signale des >seriellen Ports zu steuern? Du missverstehst mich glaub ich. Für die Initialisierung ist nur RTS und DTR erforderlich, alles andere sollte aus sein. Es findet in dem Moment keine Kommunikation per RX/TX statt. DTR ist der Takt für den HC595, RTS sind die Daten die hineinlaufen in diesem Chip. Und alle Bits ausser RTS+DTR lasse ich im CIA Register gleich. >Da kannst Du nicht normal vorgehen nach dem Motto "Ich benutze 8n1-Kommunikation, >ich muß mich aber nur um die Datenbits kümmern". Ja, 8N1 ist später das läuft ganz normal mit CMD_Write+CMDRead ganz Systemkonform. >Das funktioniert nur dann so, wenn Du das serial.device benutzt. benutze ich auch, ich weiss doch gar nicht wie man RTS+DTR auf anderer Hardware setzen kann. [ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 11:53 Uhr whose Posts: 2156 Nutzer |
@MaikG: Ich denke, ich habe Dich schon ganz richtig verstanden. Ich wollte Dir nur sagen, daß die Rechnerei per "8N1" Dir in diesem Fall wenig hilft. Du mußt, um die "korrekte" Baudrate zu erhalten RTS/DTR und was weiß ich noch mit einem Timing von 1000000µs/9600 setzen, was 104µs und n paar Zerquetschte ergibt. In diesem Fall werden die Signale mit einer Geschwindigkeit von 9600 Baud geändert. Zitat:Zitat: Und wozu pokest Du dann in feste Speicheradressen?? Da Du so oder so zusätzlich mit dem serial.device arbeitest, kann ich mir langsam denken, wo Deine Probleme herkommen. Dir funkt das serial.device dazwischen. Du mußt Dich entscheiden, ob Du direkt auf der Hardware (sprich: CIA-Register) arbeiten willst oder aber über das Device (sprich: IORequest). Beides zur gleichen Zeit geht bei fast allen Devices in die Hose. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 12:55 Uhr Holger Posts: 8116 Nutzer |
Zitat: Wenn man in Basic programmiert, sollte die Entscheidung eigentlich auf der Hand liegen... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 16:35 Uhr MaikG Posts: 5172 Nutzer |
>Ich denke, ich habe Dich schon ganz richtig verstanden. Ich wollte >Dir nur sagen, daß die Rechnerei per "8N1" Dir in diesem Fall wenig >hilft. Du mußt, um die "korrekte" Baudrate zu erhalten RTS/DTR und >was weiß ich noch mit einem Timing von 1000000µs/9600 setzen, was >104µs und n paar Zerquetschte ergibt. In diesem Fall werden die >Signale mit einer Geschwindigkeit von 9600 Baud geändert. So 5000 micros ergibt die sinnvollsten werte. >Und wozu pokest Du dann in feste Speicheradressen?? Weil man RTS und DTR meiner meinung nach ohne das Senden von Daten über Tx/Rx anders nicht ändern kann. >Da Du so oder so zusätzlich mit dem serial.device arbeitest, >kann ich mir langsam denken, wo Deine Probleme herkommen. >Dir funkt das serial.device dazwischen. Du mußt Dich entscheiden, >ob Du direkt auf der Hardware (sprich: CIA-Register) arbeiten willst >oder aber über das Device (sprich: IORequest). Über IORequest geht doch mit RTS/DTR nichts oder doch? Beim PC ist die Serielle Schnittstelle auch offen, wenn RTS/DTR geändert werden - nur beim PC geht dieses über Library aufrufe. >Wenn man in Basic programmiert, sollte die Entscheidung eigentlich >auf der Hand liegen... Wieso? Da gibts für mich in C/Basic/Assembler keine unterschiede, ich kann das untereinander austauschen. In Assembler kann man einfacher einzelne Bits setzen. [ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 20:29 Uhr whose Posts: 2156 Nutzer |
@MaikG: Ich denke, Holger wollte Dir damit sagen, daß Du bei direktem Hardware-Zugriff wegen des recht kritischen Timings mit BASIC in ziemliche Schwulitäten kommst. Ich weiß nicht, ob man via serial.device auch die anderen Signalleitungen steuern kann, ich habe mich damit nie tiefer beschäftigt und derzeit auch wenig Gelegenheit dazu. Ich schlage mich mit den Geheimnissen des Blittens herum, das ist zeitraubend genug Lies Dich mal in die Dokumentation ein, die zum serial.device und dessen Abkömmlingen erhältlich ist, evtl. ergibt sich doch eine Möglichkeit, das Ganze per IORequest zu erledigen... Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Antworten - Zitieren - Direktlink - ] |
|
21.03.2007, 22:22 Uhr MaikG Posts: 5172 Nutzer |
>Ich denke, Holger wollte Dir damit sagen, daß Du bei direktem Hardware-Zugriff wegen des recht >kritischen Timings mit BASIC in ziemliche Schwulitäten kommst. Das ist ein Compiler, der ist genauso schnell wie C in den meisten sachen. Prinzipell kann der Chip direkt 100 MHZ verarbeiten, aber ob er das auch in dieser Schaltung tut weiss ich nicht. Da sind ja noch 2 weitere Chips, einer ist ein NAND gatter wo ein Quarz mit 3,xxx dranhängt. >Lies Dich mal in die Dokumentation ein, die zum serial.device >und dessen Abkömmlingen erhältlich ist, evtl. ergibt sich doch >eine Möglichkeit, das Ganze per IORequest zu erledigen... Hab ich schon am Anfang, da gibt es nichts weiter mit RTS/DTR etc. [ - Antworten - Zitieren - Direktlink - ] |
|
23.03.2007, 09:56 Uhr MaikG Posts: 5172 Nutzer |
Hab es jetzt nochmal mit Forbid/Permit probiert, damit das serial.device zwischendurch nichts machen kann - ist das selbe. Dann wollte ich komplett auf Hardware zugriff umstellen, und lese den SERDATR Register (DFF018) aber da bekomme ich irgendwie immer das gleiche Zeichen. Muss ich dem Register nicht irgendwie mitteilen das ich die Daten gelesen habe? Ich meine woher soll er das wissen... [ - Antworten - Zitieren - Direktlink - ] |
|
23.03.2007, 12:28 Uhr DrNOP Posts: 4118 Nutzer |
Womöglich liest er ja gar nicht aus dem Register? In C muß man solche Adressen als "volatile" (veränderlich) deklarieren, damit der Compiler nicht etwa nur den ersten Zugriff ins Register selbst macht und den Rest immer wieder vom Stack liest oder so. -- Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker [ - Antworten - Zitieren - Direktlink - ] |
|
23.03.2007, 17:57 Uhr MaikG Posts: 5172 Nutzer |
>Womöglich liest er ja gar nicht aus dem Register? Doch doch, ich frage ja auch andere Register ab und die verändern sich. [ - Antworten - Zitieren - Direktlink - ] |
|
26.03.2007, 12:03 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wer sagt Dir, dass das serial.device nicht über interrupts auf die Hardware zugreift? Die korrekte Vorgehensweise ist es, die zugehörige Ressource zu locken, und nicht das Multitasking auszuschalten. Aber für jemanden, der am Anfang noch über "externe Schnittstellen wie die Hypercom" nachgedacht hat, bist Du mit dem direkten Hardwarezugriff irgendwie auf dem falschen Weg... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
26.03.2007, 18:23 Uhr MaikG Posts: 5172 Nutzer |
>Wer sagt Dir, dass das serial.device nicht über interrupts auf die Hardware zugreift? Keiner... >Die korrekte Vorgehensweise ist es, die zugehörige Ressource zu locken, >und nicht das Multitasking auszuschalten. Oh je, ich hab keinen schimmer wie man das macht. >Aber für jemanden, der am Anfang noch über "externe Schnittstellen >wie die Hypercom" nachgedacht hat, bist Du mit dem direkten >Hardwarezugriff irgendwie auf dem falschen Weg... Schon, aber besser überhaupt als gar nicht. Über das System kann man nicht direkt auf RTS/DTR zugreifen lt. NDK3.9 Es sei denn du weisst da mehr als ich. Beim PC geht das wohl über eine Library Funktion namens EscapeCommFunction. BTW. kennt jemand einen besseren Serial-Logger als Portmon? Könnte ein Timing Problem sein, aber Portmon liefert da scheinbar zufallswerte. [ - Antworten - Zitieren - Direktlink - ] |
|
28.03.2007, 09:51 Uhr MaikG Posts: 5172 Nutzer |
Ich hab das jetzt mal auf Winuae laufen lassen und Portmon dazu. Tatsächlich gibts da einträge die nicht dort hingehören, könnte allerdings an Winuae liegen - das Prog gibt ja dort auch nix aus. Trotzdem hab ich jetzt mittels misc.resource die Seriellport Pins vor dem öffnen des serial.device allociert. Das Programm macht leider trotzdem nur das selbe wie vorher. [ - Antworten - Zitieren - Direktlink - ] |
|
28.03.2007, 23:02 Uhr MaikG Posts: 5172 Nutzer |
Ich hab jetzt auf dem Amiga auch mal Parallel die RTS/DTR adresse auslesen lassen. Das serial.device spielt definitiv mit den Register rum, obwohl ich das mit der misc.resource allociert habe. Also bleibt scheinbar nur das direkte arbeiten mit den Customchips, aber ich weiss nicht wie. Irgendwie braucht man wohl einen Interrupt dafür aber davon hab ich keinen schimmer. [ - Antworten - Zitieren - Direktlink - ] |
| -1- | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > RTS DTR Amiga/PC unterschiede? | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|