Serielle Schnittstelle am GPIO ... der Raspi mauert?

  • Ich habe es auch erst beim 2. mal (vor #11) geschnallt: Beim TO ist bereit eine Fertigplatine mit MAX3232 auf die Pins am Pi aufgesteckt. Nur kommt kein V24 raus (weil vom Pi nichts reingeht ?).

    Aber dann wirds echt interessant. Das VT330 ist doch schon ein Grafikterminal, das müsste zunächst noch als VT100, also im Textmodus betrieben werden.

    Und ausser RX TX werden eigentlich keine weiteren Steuerleitungen gebraucht, oder vom Pi bereitgestellt.

    So ein Dec Terminal (nur VT100) habe ich auch noch irgenwo herumliegen. Nur die dazugehörige V24 Buchse, samt PDP-11, wurde leider entsorgt (mangels Platz und BS).


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Serielle Schnittstelle am GPIO ... der Raspi mauert?? Schau mal ob du hier fündig wirst!

  • Hallo Adrian,

    [...]die haben den Stecker gespiegelt. Keine Ahnung wieso. Wenn ich raten soll, dann damit man zum PC hin ohne Nullmodem-Kabel mit 1:1 auskommt. Also ich habs entweder nicht verstanden wie genial das ist oder die haben die Nummer versemmelt. In jedem Fall ist dann mein 9/25 Adapter aus dem Rennen.
    [...]

    Nur den Designer der HATs könnte ich grillen: warum sieht man nicht optionale Hardware-Protokoll-Leitungen vor? Für irgendein GPIO-Pin-Pärchen? Wenn doch der 232 schon 2 zusätzliche Konverter anbietet. Das wären nur ein paar extra Löcher in der Platine, kein Kostenfaktor.

    Tja, Chinaware eben.

    Auch wenn andere darauf schwören und/oder Glück haben: Wenn ich mir so etwas zulege, lange ich immer in den Dreck hinein und mir geht's damit wie Dir.

    Also dann,

    weiterhin viel Spaß mit dem RPi und dem daran angeschlossenen VT100-Terminal (oder artverwandt).:thumbup:

    EDIT:

    Ist der 9-polige D-SUB-Anschluss am HAT ein Stecker (wie am PC) oder eine Buchse? Bei einer Buchse wäre eine gekreuzte Belegung durchaus sinnvoll, um ein 1:1-Stecker-Buchse-Kabel zwischen PC und HAT verwenden zu können. Bei einem Stecker eher nicht. Der impliziert (zumindest für mich) eher ein Nullmodemkabel.

  • warum sieht man nicht optionale Hardware-Protokoll-Leitungen vor? Für irgendein GPIO-Pin-Pärchen? Wenn doch der 232 schon 2 zusätzliche Konverter anbietet

    ich tippe mal Sparwahn und weils nicht nötig ist, so viele Konverter hat der MAX ja nicht, es sind nur 2 raus und 2 rein

    Das reicht nicht für alle Signale an der RS232,

    lass mich mal aus dem Gedächnis ohne schummeln

    Tx Rx CTS RTS DTR DCD DSR RI GND da bin ich schon 9 eines D-Sub 9.

    Das reicht nicht für die 4 im MAX3232, da bräuchte man mindestens noch 1-2 MÄXE

    Beim TO ist bereit eine Fertigplatine mit MAX3232 auf die Pins am Pi aufgesteckt

    das wiederum hatte ich vermutet aber keinen Hinweiss darauf gefunden, die Fertigplatine hat für mich unglücklicherweise immer eine D-SUB 9 female bestückt, damit funktionieren meine Nullmodemkabel aber nicht und das nervt, deswegen habe ich nach den ersten 2 nie wieder welche gekauft oder benutzt, ich mache die mir lieber selber mit den Miniplatinchen die ich direkt in das D-Sub 9 Gehäuse baue, mit meinem gewählten D-Sub9 male, dann klappt es auch mit dem Nullmodemkabel zum PC

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (3. Mai 2019 um 21:56)

  • Tx Rx CTS RTS DTR DCD DSR RI GND da bin ich schon 9 eines D-Sub 9.

    Das reicht nicht für die 4 im MAX3232, da bräuchte man mindestens noch 1-2 MÄXE

    Naja, aber wenigstens die ungenutzten zwei hätten für RTS/CTS gereicht. Die ganze Schnittstelle verlangt ja keiner, aber wenigsten ein! Satz Protokoll-Leitungen. Ein paar optionale Jumper (selbst nachzulöten) hätten viel geholfen. Schliesslich hat der MAX 4 Treiber, warum nur 2 nutzen?

    So klemme ich leider auf XON/XOFF, was einen fundamentalen Nachteil hat:

    Theoretisch ist XON/XOFF eine feine Sache und sollte gut funktionieren. Praktisch hat das Grenzen: ein Serielles Terminal war zumindest damals kein Multi-Tasking-Device und hatte eine 8bit CPU. Wenn man also z.B. einen Delete-To-End-Of-Line abgesetzt hat, war die CPU damit einen Moment beschäftigt. In dieser Zeit wurde das Software-getriebene XON/XOFF nicht durchgeführt ... schwupp gehen Zeichen verloren.

    Also mit 19200 und sogar 38400 baud kann ich locker einen "ls -lrtR" laufen lassen, kein bit verloren. Aber wenn ich einen emacs starte, der jede Menge Cursor-Positionierungen macht (wobei die CPU da etwas Zahlen-parsen muss), sieht der untere Teil vom screen aus wie Datensalat. Vielleicht erreiche ich mit "screen" als Puffer etwas, aber ich rechne mir wenig Chancen aus. Mit 9600 baud ist alles hübsch, da scheint dann die CPU im Terminal hinreichend schnell zu sein um nichts zu verlieren. Eventuell muss ich für solche Kandidaten mal einen Arduino stricken, der Hardware-Protokoll von langsamen Devices auf XON/XOFF übersetzt. Klingt wie ein nettes Winter-Wochenende. Wäre ein Terminal mit einem kleinen Multi-Tasking-Kern ausgestattet (oder wenigstens richtig interrupt-getrieben, was wohl leider nicht der Fall war), dann ginge auch bei komplexen Operationenen nichts flöten.

    Da nun der Raspberry funktioniert und ich den HAT begriffen habe und die restlichen Probleme eben Probleme vom Terminal sind, versuch ich mal die anderen Terminals, ansonsten ist 9600 baud auch genug zum Arbeiten (nur eben nicht ... "atemberaubend"). Bei den DEC-Terminals ist jedenfalls mit XON/XOFF bei 9600 baud das Ende der Fahnenstange erklommen.

  • Und wo wir grad davon sprachen:

    WENN ich für den Raspi einen eigenen HAT stricke, der Hardware-Protokoll machen soll:

    ich habe gelesen dass man dann ein paar GPIO-Pins opfert um ein Hardware-Protokoll (CTS,RTS) zu emulieren. Da wäre natürlich Aufgabe des Treibers.

    Frage 1: hat der Treiber da konkrete Vorstellungen welche Pins man verwenden würde, oder wäre das nur applikations-seitig umzusetzen also für einen agetty nicht machbar?

    Frage 2: wenn es für 1 eine Antwort gibt ... wie konfiguriere ich den Treiber entsprechend?

  • Wenn es um Treiberprogrammierung für (embedded) Linux geht, kann ich die beiden Bücher

    Jürgen Quade: Embedded Linux lernen mit dem Raspberry Pi [Anzeige] und

    Jürgen Quade, Eva-Katharina Kunst: Linux-Treiber entwickeln [Anzeige]

    empfehlen

  • XON/XOFF

    habe ich nie gebraucht, aber ich habe auch kein Terminal, ausser PC Programme.

    PS. wenn nach dir noch keiner geantwortet hat wäre es schön (Forenregeln!) deine weiteren Beiträge in deinen letzten Beitrag zu editieren, das macht die Threads übersichtlicher.

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!