Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #235875 > unrolled thread

"Filetransfer" via Terminalprogramm

Back to article view | Back to de.sci.electronics

Contents

  "Filetransfer" via Terminalprogramm Marte Schwarz <marte.schwarz@gmx.de> - 2017-11-22 19:17 +0100
    Re: "Filetransfer" via Terminalprogramm Stefan <df9bi@arcor.de> - 2017-11-22 19:33 +0100
    Re: "Filetransfer" via Terminalprogramm Rafael Deliano <rafael_deliano@arcor.de> - 2017-11-22 19:47 +0100
      Re: "Filetransfer" via Terminalprogramm Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-11-22 19:58 +0100
        Re: "Filetransfer" via Terminalprogramm Rafael Deliano <rafael_deliano@arcor.de> - 2017-11-22 20:14 +0100
          Re: "Filetransfer" via Terminalprogramm Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2017-11-22 20:34 +0100
            Re: "Filetransfer" via Terminalprogramm Rafael Deliano <rafael_deliano@arcor.de> - 2017-11-22 21:16 +0100
              Re: "Filetransfer" via Terminalprogramm Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2017-11-23 04:19 +0100
                Re: "Filetransfer" via Terminalprogramm Rafael Deliano <rafael_deliano@arcor.de> - 2017-11-23 05:17 +0100
                Re: "Filetransfer" via Terminalprogramm Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-11-23 08:10 +0100
                  Re: "Filetransfer" via Terminalprogramm Reinhardt Behm <rbehm@hushmail.com> - 2017-11-23 15:26 +0800
                    Re: "Filetransfer" via Terminalprogramm Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-11-23 08:31 +0100
                  Re: "Filetransfer" via Terminalprogramm Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2017-11-23 11:23 +0100
                Re: "Filetransfer" via Terminalprogramm Michael Bäuerle <michael.baeuerle@stz-e.de> - 2017-11-23 10:17 +0100
          Re: "Filetransfer" via Terminalprogramm Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-11-22 21:01 +0100
            Re: "Filetransfer" via Terminalprogramm Rafael Deliano <rafael_deliano@arcor.de> - 2017-11-23 05:30 +0100
    Re: "Filetransfer" via Terminalprogramm Bernd Laengerich <bernd.laengerich@web.de> - 2017-11-22 22:37 +0100
      Re: "Filetransfer" via Terminalprogramm Rafael Deliano <rafael_deliano@arcor.de> - 2017-11-23 05:23 +0100
      Re: "Filetransfer" via Terminalprogramm Marte Schwarz <marte.schwarz@gmx.de> - 2017-11-23 13:25 +0100
        Re: "Filetransfer" via Terminalprogramm Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-11-23 13:45 +0100
        Re: "Filetransfer" via Terminalprogramm Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2017-11-23 13:53 +0100
          Re: "Filetransfer" via Terminalprogramm Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-11-23 14:02 +0100
        Re: "Filetransfer" via Terminalprogramm Bernd Laengerich <Bernd.Laengerich@web.de> - 2017-11-23 17:42 +0100

Page 1 of 2  [1] 2  Next page →

#235875 — "Filetransfer" via Terminalprogramm

Hallo zusammen,

damals, als wir noch mit dem Modem und Terminalprogramm ins Netz gingen, 
da war das irgendwie so, dass man zum Dateien herunterladen xmodem bis 
zmodem angeworfen hatte, dann irgendwie den Dateinamen eingab und dann 
gewartet hatte, bis die Datei da war. Dann gings im Terminal weiter. So 
ähnlich sagen mir das meine grauen Zellen.
So ähnlich würde ich das nun gern mit einem (noch zu bauenden) 
Datenlogger machen. Also im Prinzip eine Benutzeroberfläche mit VT100 
Befehlen machen und dann bei Gelegenheit die gesammelten Daten in eine 
Datei schreiben. Kann mir jemand auf die Füße helfen?

Danke

Marte

[toc] | [next] | [standalone]

#235877

Am 22.11.2017 um 19:17 schrieb Marte Schwarz:
> Hallo zusammen,
> 
> damals, als wir noch mit dem Modem und Terminalprogramm ins Netz gingen, 
> da war das irgendwie so, dass man zum Dateien herunterladen xmodem bis 
> zmodem angeworfen hatte, dann irgendwie den Dateinamen eingab und dann 
> gewartet hatte, bis die Datei da war. Dann gings im Terminal weiter. So 
> ähnlich sagen mir das meine grauen Zellen.
> So ähnlich würde ich das nun gern mit einem (noch zu bauenden) 
> Datenlogger machen. Also im Prinzip eine Benutzeroberfläche mit VT100 
> Befehlen machen und dann bei Gelegenheit die gesammelten Daten in eine 
> Datei schreiben. Kann mir jemand auf die Füße helfen?
> 
> Danke
> 
> Marte
> 

Kommt drauf an, was dein lieblings Programmiertool ist.

Ich verwende für solche Sachen Delphi. Geht auch mit Lazarus. Dazu habe 
ich eine Komponente für die serielle Schnittstelle.

Aktuell hab ich einen Azubi dabei, G-Codes an eine kleine Fräse zu 
senden. Der macht das mit Lazarus.

Im Prinzip läuft das so, dass man die serielle Schnittstelle 
initialisiert und dann in einem Timer nachschaut, ob Daten im Puffer 
liefgen die man auslesen und auswerten kann. Dazwischen sendet man dann 
Daten raus.
Empfangene Daten werden in einem Textfenster (Memo) angezeigt.

Gruß

Stefan

[toc] | [prev] | [next] | [standalone]

#235880

Die meisten Terminalprograme haben Option "Mitschreiben in File".
Der Datenlogger muß dann auf Befehl nur Zeilen mit Zahlen in dezimal 
ASCII schicken. Ich habe bei z.B. Temperaturmessungen meist
mehrere Sensoren, also pro Zeile mehrere Zahlen. Mathcad oder Excel
haben wenig Probleme solche .txt-Files zu lesen.

 > xmodem bis zmodem

Zmodem ist mühsamst zu implementieren.
Xmodem ist simpel:
http://www.embeddedFORTH.de/temp/XMODEM.pdf
Vorteil ist die CRC die bei Modem nützlich aber auf kurzer V24
nicht nötig ist.

XMODEM wurde bei den EnergyMicro ARM-Controllern als Bootloader
für Firmware verwendet. Habe es dort aber nie stabil mit Teraterm
zum Laufen gebracht. D.h. inkompatible Varianten sind wohl
nicht selten.

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#235881

On 11/22/2017 07:47 PM, Rafael Deliano wrote:
> Die meisten Terminalprograme haben Option "Mitschreiben in File".
> Der Datenlogger muß dann auf Befehl nur Zeilen mit Zahlen in dezimal 
> ASCII schicken. Ich habe bei z.B. Temperaturmessungen meist
> mehrere Sensoren, also pro Zeile mehrere Zahlen. Mathcad oder Excel
> haben wenig Probleme solche .txt-Files zu lesen.
> 
>  > xmodem bis zmodem
> 
> Zmodem ist mühsamst zu implementieren.

Für zmodem gibts doch fertigen Source den man sich greifen kann. Ich hab 
in der Uni damals in der Shell immer 'sz' und 'rz' benutzt, der Source 
dazu ist verfügbar. Das Programm kann auch noch XModem und YModem.



> Xmodem ist simpel:
> http://www.embeddedFORTH.de/temp/XMODEM.pdf
> Vorteil ist die CRC die bei Modem nützlich aber auf kurzer V24
> nicht nötig ist.

Doch, nämlich wenn dein UART keinen FIFO hat und deshalb Bytes 
verschluckt. Ohne CRC-Test hast du dann nur Schrott.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#235883

 >> Zmodem ist mühsamst zu implementieren.
> Für zmodem gibts doch fertigen Source den man sich greifen kann.

Sourcecode war ehedem nur in C verfügbar. Schlimmer noch: die
Source war die Definition des Protokolls. Ich habe nie gesehen
daß jemand eine Beschreibung versucht hätte.

> Doch, nämlich wenn dein UART keinen FIFO hat und deshalb Bytes
> verschluckt. Ohne CRC-Test hast du dann nur Schrott.

Hätte ich für Job von XON/XOFF gehalten.

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#235884

Am 22.11.2017 um 20:14 schrieb Rafael Deliano:

>> Für zmodem gibts doch fertigen Source den man sich greifen kann.
> 
> Sourcecode war ehedem nur in C verfügbar. Schlimmer noch: die
> Source war die Definition des Protokolls. Ich habe nie gesehen
> daß jemand eine Beschreibung versucht hätte.

http://gallium.inria.fr/~doligez/zmodem/zmodem.txt

>> Doch, nämlich wenn dein UART keinen FIFO hat und deshalb Bytes
>> verschluckt. Ohne CRC-Test hast du dann nur Schrott.
> 
> Hätte ich für Job von XON/XOFF gehalten.

Bis das gesendet, empfangen und vom Gegenseite ausgewertet ist, sind 
bereits mehrere Bytes im Nirvana. Mit der Verzögerung durch ein Modem 
oder einen USB/seriell-Umsetzer in der Leitung sogar mehrere hundert Byte.
Davon abgesehen erfordert XMODEM eine transparente Verbindung, 
Software-Handshake kann also nicht verwendet werden.

Hergen

[toc] | [prev] | [next] | [standalone]

#235887

> http://gallium.inria.fr/~doligez/zmodem/zmodem.txt

Den Schrieb kenne ich. Ich habe ehedem mal versucht das Ding in
FORTH nochmal zu programmieren. Ungefähr nachdem ich die 
Wandlungsroutinen für Oktal dafür implementiert dafür hatte,
habe ich es aber dann sinnvollerweise aufgegeben.
Bei FORTH Inc. war man zäher und hat es wohl lauffähig gemacht,
aber angemerkt, daß Forsberg eine sehr kryptische Art der
C-Programmierung hat.

>> Hätte ich für Job von XON/XOFF gehalten.

> Bis das gesendet, empfangen und vom Gegenseite ausgewertet ist, sind
> bereits mehrere Bytes im Nirvana.

Üppige Aussage. Viele Anwendungen haben keine 
Hardware-Handshakeleitungen mehr und verwenden deshalb
flowcontrol a la XON/XOFF. Ich habe damit keine Probleme
Daten vom Teraterm in meinen 8 Bit Controller zu übertragen
der keine FIFO hat.
Mag sein, daß XMODEM damit Problem hat. Aber mag auch sein,
daß XMODEM genau deshalb eben kaum noch verwendet wird.

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#235922

Am 22.11.2017 um 21:16 schrieb Rafael Deliano:
> 
>> http://gallium.inria.fr/~doligez/zmodem/zmodem.txt
> 
> Den Schrieb kenne ich.

Ich denke, es gab keine formalen Beschreibungen, nur Beispielcode?

> Ich habe ehedem mal versucht das Ding in
> FORTH nochmal zu programmieren.

Nunja, nicht jede Programmiersprache eignet sich für jeden Zweck. :-P

>> Bis das gesendet, empfangen und vom Gegenseite ausgewertet ist, sind
>> bereits mehrere Bytes im Nirvana.
> 
> Üppige Aussage. 

Nein, Erfahrungswert. Ich hatte damals beruflich etliche Jahre mit 
Mehrfach-seriellen Karten in PCs zu tun, die in der konkreten Anwendung 
24/7 mit mehreren gleichzeitig aktiven Ports stabil laufen mussten.

In Hochsprache war das praktisch unmöglich. Und selbst mit sorgsam 
optimiertem Assemblercode, großzügig bemessenen Ringpuffern, und einem 
eigenen Tastaturtreiber (zur Entschärfung der IRQ1-Problematik) gab es 
spätestens ab 9600Baud immer wieder sporadische Verluste, weil der 
Handshake nicht immer rechtzeitig kam.

Mehr ging das erst, wenn man die 8250 durch 16450 (mit FIFO) tauschte. 
Die 8250 waren einfach zu primitiv, luden selbst Hardware-Handshake der 
CPU auf, und das verkorkste Interruptsystem des PC mit seinen vollkommen 
idiotisch vergebenen Prioritäten tat sein übriges.

> flowcontrol a la XON/XOFF. Ich habe damit keine Probleme
> Daten vom Teraterm in meinen 8 Bit Controller zu übertragen
> der keine FIFO hat.

Moderne Mikrocontroller sind relativ unproblematisch. Selbst einfache 
8Bitter wie PIC und AVR reagieren so schnell auf Interrupts, das man 
problemlos einen FIFO in Software realisieren kann, der noch ein paar 
Bytes puffert, bis der Sender das XOFF verdaut hat.

> Mag sein, daß XMODEM damit Problem hat. Aber mag auch sein,
> daß XMODEM genau deshalb eben kaum noch verwendet wird.

XMODEM hatte viele Probleme und war eigentlich fast schlagartig tot, 
nachdem YMODEM/ZMODEM auf breiter Front verfügbar waren.

Hergen

[toc] | [prev] | [next] | [standalone]

#235923

 > Ich denke, es gab keine formalen Beschreibungen, nur Beispielcode?

Es ist die Dokumentation des Autors für sein Programm. Es ist keine 
Definition des Protokolls die eine andere Implementierung erlauben
würde.
Die Kompatibilität von ZMODEM beruht praktisch darauf, daß es nur eine
Implementierung in einer Programmiersprache gibt.

> XMODEM hatte viele Probleme und war eigentlich fast schlagartig tot,
> nachdem YMODEM/ZMODEM auf breiter Front verfügbar waren.

Wenn der Logger eine 8 Bit CPU haben sollte wird ZMODEM schon
wegen Umfang nicht attraktiv sein.

MfG JRD

[toc] | [prev] | [next] | [standalone]

#235928

On 11/23/2017 04:19 AM, Hergen Lehmann wrote:
> Am 22.11.2017 um 21:16 schrieb Rafael Deliano:
>>
>>> http://gallium.inria.fr/~doligez/zmodem/zmodem.txt
>>
>> Den Schrieb kenne ich.
> 
> Ich denke, es gab keine formalen Beschreibungen, nur Beispielcode?
> 
>> Ich habe ehedem mal versucht das Ding in
>> FORTH nochmal zu programmieren.
> 
> Nunja, nicht jede Programmiersprache eignet sich für jeden Zweck. :-P
> 
>>> Bis das gesendet, empfangen und vom Gegenseite ausgewertet ist, sind
>>> bereits mehrere Bytes im Nirvana.
>>
>> Üppige Aussage. 
> 
> Nein, Erfahrungswert. Ich hatte damals beruflich etliche Jahre mit 
> Mehrfach-seriellen Karten in PCs zu tun, die in der konkreten Anwendung 
> 24/7 mit mehreren gleichzeitig aktiven Ports stabil laufen mussten.
> 
> In Hochsprache war das praktisch unmöglich. Und selbst mit sorgsam 
> optimiertem Assemblercode, großzügig bemessenen Ringpuffern, und einem 
> eigenen Tastaturtreiber (zur Entschärfung der IRQ1-Problematik) gab es 
> spätestens ab 9600Baud immer wieder sporadische Verluste, weil der 
> Handshake nicht immer rechtzeitig kam.
> 
> Mehr ging das erst, wenn man die 8250 durch 16450 (mit FIFO) tauschte. 

Der 16450 unterscheidet sich nicht wirklich vom 8250. Du meinst den 
16550, speziell in der 'A'-Version (wenn er von National war, von denen 
stammt das Design). Die ohne A hatte noch einen kleinen Bug bei dem 
unter bestimmten Umständen ein Byte im FIFO hängenbleiben konnte.

Irgendwo hab ich noch zwei 16C550 von Goldstar rumliegen...


> Die 8250 waren einfach zu primitiv, luden selbst Hardware-Handshake der 
> CPU auf, und das verkorkste Interruptsystem des PC mit seinen vollkommen 
> idiotisch vergebenen Prioritäten tat sein übriges.

Auch der 16550 überlies das Handshaking der CPU. Aber dank FIFO war das 
nicht mehr wirklich ein Problem. Ideal war ein IRQ-Threshold von 8 
Bytes. Damit empfing der 16550 die Bytes ohne einen IRQ auszulösen bis 8 
Bytes im FIFO waren. Damit hatte man weitere 8 Bytes Zeit die 
einzusammeln bevor es zum Datenverlust kam. Wenn nicht genug Bytes 
einliefen um den Threshold zu erreichen gab es einen Timeout von 3 Bytes 
(bzw. der Zeit die es brauchen würde sie zu empfangen) nach dem dann 
trotzdem ein IRQ ausgelöst wurde.

Später kamen die Nachbauten wie der erwähnte Startech 16C650 die mehr 
FIFO mitbrachten aber ansonsten kompatibel waren. Wenn der Treiber für 
den 16550 nicht hirntot implementiert war hatte er keine Probleme mit 
dem vergrößerten FIFO.


> Moderne Mikrocontroller sind relativ unproblematisch. Selbst einfache 
> 8Bitter wie PIC und AVR reagieren so schnell auf Interrupts, das man 
> problemlos einen FIFO in Software realisieren kann, der noch ein paar 
> Bytes puffert, bis der Sender das XOFF verdaut hat.

Hab ich mal in Assembler implementiert. Kann aber trotzdem problematisch 
werden wenn am selben Microcontroller noch ein LCD mit dem üblichen 
HDxxxxxx-Controller hängt welches hin und wieder Wartezeiten im 
Millisekundenbereich haben will. Da muss man den FIFO dann schon 
ausreichend groß gestalten.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#235931

AT Thursday 23 November 2017 15:10, Gerrit Heitsch wrote:

> Hab ich mal in Assembler implementiert. Kann aber trotzdem problematisch
> werden wenn am selben Microcontroller noch ein LCD mit dem üblichen
> HDxxxxxx-Controller hängt welches hin und wieder Wartezeiten im
> Millisekundenbereich haben will. Da muss man den FIFO dann schon
> ausreichend groß gestalten.

Oder gescheit programmieren. Es muss ja nicht das ganze Programm warten, nur 
weil ein I/O-Gerät lahm ist.

-- 
Reinhardt

[toc] | [prev] | [next] | [standalone]

#235932

On 11/23/2017 08:26 AM, Reinhardt Behm wrote:
> AT Thursday 23 November 2017 15:10, Gerrit Heitsch wrote:
> 
>> Hab ich mal in Assembler implementiert. Kann aber trotzdem problematisch
>> werden wenn am selben Microcontroller noch ein LCD mit dem üblichen
>> HDxxxxxx-Controller hängt welches hin und wieder Wartezeiten im
>> Millisekundenbereich haben will. Da muss man den FIFO dann schon
>> ausreichend groß gestalten.
> 
> Oder gescheit programmieren. Es muss ja nicht das ganze Programm warten, nur
> weil ein I/O-Gerät lahm ist.

Die Ausgabe war die eingegangenen Bytes auf dem Display darzustellen. Da 
wartest du dann trotzdem... Die IRQ-Routine kümmert sich um den Empfang 
und den Software-FIFO. Der muss aber eben groß genug sein.

Das war auf einem Attiny 2313, viel Platz für Code ist da nicht.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#235943

Am 23.11.2017 um 08:10 schrieb Gerrit Heitsch:

> Der 16450 unterscheidet sich nicht wirklich vom 8250. Du meinst den 
> 16550, speziell in der 'A'-Version (wenn er von National war, von denen 
> stammt das Design). 

Ja, sorry, ist 30 Jahre her... ^_-

> Hab ich mal in Assembler implementiert. Kann aber trotzdem problematisch 
> werden wenn am selben Microcontroller noch ein LCD mit dem üblichen 
> HDxxxxxx-Controller hängt welches hin und wieder Wartezeiten im 
> Millisekundenbereich haben will. Da muss man den FIFO dann schon 
> ausreichend groß gestalten.

ACK. Speziell bei PC-Gegenstellen können nach dem "XOFF" wie gesagt noch 
etliche Bytes kommen. :-(

Hergen

[toc] | [prev] | [next] | [standalone]

#235941

Hergen Lehmann wrote:
> Am 22.11.2017 um 21:16 schrieb Rafael Deliano:
> > 
> [9600Baud]
> Mehr ging das erst, wenn man die 8250 durch 16450 (mit FIFO) tauschte. 
> Die 8250 waren einfach zu primitiv, luden selbst Hardware-Handshake der 
> CPU auf, und das verkorkste Interruptsystem des PC mit seinen 
> vollkommen idiotisch vergebenen Prioritäten tat sein übriges.
> 
> > flowcontrol a la XON/XOFF. Ich habe damit keine Probleme
> > Daten vom Teraterm in meinen 8 Bit Controller zu übertragen
> > der keine FIFO hat.
> 
> Moderne Mikrocontroller sind relativ unproblematisch. Selbst einfache 
> 8Bitter wie PIC und AVR reagieren so schnell auf Interrupts, das man 
> problemlos einen FIFO in Software realisieren kann, der noch ein paar 
> Bytes puffert, bis der Sender das XOFF verdaut hat.

Speziell bei AVR muss man dann aber aufpassen, dass die ISRs der
anderen Interrupts (mit höherer Priorität) nicht zu viel Latenz
erzeugen (im worst-case alle in Summe). Die RX-Interrupts der beiden
USARTs haben z.B. bei einem ATmega128 die Prioritäten 19 und 31 und
man kann das nicht umkonfigurieren. Im worst case kann alleine das
herumspringen zu den ISRs schon ordentlich Zeit kosten:
5 Takte bis der Befehl am IV ausgeführt wird, ist das JMP weitere
3 bis zur ISR. Angenommen diese tut nichts und kehrt sofort zurück,
nochmal 4 für RETI. Plus 1 Takt zwischen der Ausführung zweier ISRs.
13 Takte mal 29 Interrupts höherer Priorität (ohne RESET) können schon
377 Takte Latenz für den USART1 RX Interrupt bedeuten.

Die USARTs haben zwar RX-FIFOs aber auch nur 2 Byte plus das Schiebe-
register.

[toc] | [prev] | [next] | [standalone]

#235886

On 11/22/2017 08:14 PM, Rafael Deliano wrote:
>  >> Zmodem ist mühsamst zu implementieren.
>> Für zmodem gibts doch fertigen Source den man sich greifen kann.
> 
> Sourcecode war ehedem nur in C verfügbar. Schlimmer noch: die
> Source war die Definition des Protokolls. Ich habe nie gesehen
> daß jemand eine Beschreibung versucht hätte.
> 
>> Doch, nämlich wenn dein UART keinen FIFO hat und deshalb Bytes
>> verschluckt. Ohne CRC-Test hast du dann nur Schrott.
> 
> Hätte ich für Job von XON/XOFF gehalten.

Zu langsam. Die alten UARTs hatten nur 1 Byte Puffer. Sobald der IRQ für 
'Daten angekommen' kam musstest du in der Zeit, in der das nächste Byte 
ankommt das Empfangsregister auslesen. Hast du das nicht gemacht war das 
Byte futsch da überschrieben.

XON/XOFF war füer deutlich gröbere Steuerungen gedacht, aber nicht bei 
jedem Byte.

Typischerweise war die CPU schnell genug dafür, es sei denn es kamen 
andere Dinge in den Weg, z.B. ein Floppy- oder HD-Zugriff um die Daten 
wegzuschreiben. Das war auf dem PC damals ein großes Problem, andere OS 
konnten das besser.

Ich hatte damals in meinem Amiga eine Adapterkonstruktion um PC 
I/O-Karten verwenden zu können. Auf der steckte dann ein Startech 16C650 
mit 32 Byte FIFO, der IRQ-Threshold stand auf 16 Bytes oder so. War sehr 
entspannt, auch bei 57600 Bps keine verlorenden Bytes mehr und, da 
weniger IRQs, auch keine spürbare Verlangsamung mehr.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#235925

> Das war auf dem PC damals ein großes Problem,

Für Datenlogger geht die Masse der Daten von Controller
Richtung PC. Ich hatte heutzutage nie das Problem dass
in die Richtung Flowcontrol nötig wäre, soweit man keine
extremen Versuche mit der Baudrate der V24 macht.

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#235901

Am 22.11.2017 um 19:17 schrieb Marte Schwarz:

> da war das irgendwie so, dass man zum Dateien herunterladen xmodem bis 
> zmodem angeworfen hatte, dann irgendwie den Dateinamen eingab und dann 

kermit gab es auch noch.

> gewartet hatte, bis die Datei da war. Dann gings im Terminal weiter. So 
> ähnlich sagen mir das meine grauen Zellen.

Richtig, für den Transfer sind 2 Programme aktiv: Zum einen das auf dem 
entfernten Computer, welches beim download die Sendeseite implementiert, 
es kommuniziert dazu über stdin/stdout, und das Terminalprogramm mit dem 
man sich eingeloggt hat, welches üblicherseise die magische Sequenz von 
zmodem im Datenstrom erkennt und dann automatisch aktiv wird.
xmodem hat zu viele Schwächen, das würde ich nicht implementieren, es 
sollte mindestens ymodem sein.

> So ähnlich würde ich das nun gern mit einem (noch zu bauenden) 
> Datenlogger machen. Also im Prinzip eine Benutzeroberfläche mit VT100 
> Befehlen machen und dann bei Gelegenheit die gesammelten Daten in eine 
> Datei schreiben. Kann mir jemand auf die Füße helfen?

Dazu muß die Oberfläche dann nur die Befehle implementieren. Aber 
aktuelle "Terminal"programme die telnet/ssh implementieren können oft 
kein x-,y- oder zmodem mehr. Immerhin gibt es für PuTTY einen Zusatz: 
ExtraPuTTY. Oder man nimmt Tera Term Pro.

Bernd

[toc] | [prev] | [next] | [standalone]

#235924

> kermit gab es auch noch.

Gibts dickes Buch dazu:
https://www.amazon.com/Kermit-Transfer-Protocol-Frank-Cruz/dp/0932376886

Komplexität wohl zwischen XMODEM und ZMODEM.
Für embedded war es weniger populär,
TeraTerm hätte es aber auch noch,
andere Terminalprogramme seltener.

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#235952

Hi Bernd,

> kermit gab es auch noch.

Ja, aber nicht wirklich lange in meinem Umfeld. Zmodem lief auf den 
386ern schon recht ordentlich.

> es kommuniziert dazu über stdin/stdout, und das Terminalprogramm mit dem 
> man sich eingeloggt hat, welches üblicherseise die magische Sequenz von 
> zmodem im Datenstrom erkennt und dann automatisch aktiv wird.

Jetzt dämmerts, also brauchte man das gar nicht gesondert aktivieren. 
Deshalb kann ich mich an die Sequenz nie erinnern :-(

> xmodem hat zu viele Schwächen, das würde ich nicht implementieren, es 
> sollte mindestens ymodem sein.

AFAIR wird xmodem in den AVR Bootloadern und nicht nur da eingesetzt. 
Ich hab mich schon oft gewundert, warum man Arduinos einfach mit 
115kBaud flashen kann, obwohl man damit keine vernünftige 
Datenverbindung hinbekommt. Anscheinend gehts mit xmodem dann doch 
irgendwie. Bräuchte ich jetzt aber nicht wirklich in meinem Logger. So 
viele Daten braucht der sich nicht zu merken, dass es sich lohnen würde, 
solche Kniffs zu machen. Aber wenn es xmodem sein muss, damit das 
TeraTerm mitbekommt, dass jetzt Daten ins File zu schreiben sind, wirds 
möglicherweise doch auf xmodem hinaus laufen...

>> So ähnlich würde ich das nun gern mit einem (noch zu bauenden) 
>> Datenlogger machen. Also im Prinzip eine Benutzeroberfläche mit VT100 
>> Befehlen machen und dann bei Gelegenheit die gesammelten Daten in eine 
>> Datei schreiben. Kann mir jemand auf die Füße helfen?
> 
> Dazu muß die Oberfläche dann nur die Befehle implementieren. Aber 
> aktuelle "Terminal"programme die telnet/ssh implementieren können oft 
> kein x-,y- oder zmodem mehr. Immerhin gibt es für PuTTY einen Zusatz: 
> ExtraPuTTY. Oder man nimmt Tera Term Pro.

TeraTerm war vorgesehen, aber Danke für den Hinweis mit ExtraPuTTY

CU Marte

[toc] | [prev] | [next] | [standalone]

#235954

On 11/23/2017 01:25 PM, Marte Schwarz wrote:
> Hi Bernd,
> 
>> kermit gab es auch noch.
> 
> Ja, aber nicht wirklich lange in meinem Umfeld. Zmodem lief auf den 
> 386ern schon recht ordentlich.

Das lief auch schon auf einem Amiga, also 68000@7.xMHz in benutzbar. So 
verwendet mit NComm.

  Gerrit

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.sci.electronics

csiph-web