Mit Tachyonen und Gold-Chip gegen Handystrahlen...

[Gerd Kluger]

"Gerd Kluger" <gerd.kluger@yahoo.de> wrote in message news:fbp8m6$im4$1@news.sap-ag.de...

Hallo,

ich bin auf der Suche nach Schwachstromverbindern, im Prinzip
sowas wie die Scotchlok Verbinder von 3M, allerdings für
eindrähtige UND mehrdrähtige Leiter.
Gibts sowas? Das einzige, was ich kenne, und was dem nur ungefähr
nahe kommt, wären die Wago 222-413.

Nachdem den Leuten in d.s.i.e. dazu nix einfällt bleibt mir jetzt
wirklich nix anderes als in d.s.e. zu fragen, obwohl ich weiß, dass
die meisten beide Gruppen lesen ...

Gruß
Gerd

 

[JĂźrgen Appel]

Wolfgang Schrader schrieb:

Der CTS55 entpuppt sich bei näherem Hinsehen als ein 486er-PC mit MS-DOS
5.0. Wir möchten nun online bzw. ohne aus dem Mess- und
Darstellungsprogramm zu gehen eine Textdatei von außen via serieller
Schnittstelle auf das Gerät spielen (da steht der Text einer zu
versendenden SMS drin und den möchten wir von Fall zu Fall ändern).

Kurzes googeln lieferte:
ftp://ftp.eunet.bg/pub/simtelnet/msdos/commprog/rcomm-v2.zip

Wenn es hält, was es verspricht, dürfte das sein, was Du suchst.

Gruß,
Jürgen

--
GPG key:
http://pgp.mit.edu:11371/pks/lookup?search=J%FCrgen+Appel&op=get

 

[Jan Lucas]

Wolfgang Schrader schrieb:

Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.

In einer Interrupt Routine in eine Datei schreiben ist sehr
problematisch. Vielleicht geht ja auch eine andere Lösung? Bspw. per
Tastatur?

Jan

 

[MaWin]

"Wolfgang Schrader" <ws@woschrader.de> schrieb im Newsbeitrag
news:46e5bcff$1@news1.dts-online.net...

Schön wäre ein TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht
und Daten, die von dort reinplätschern, in eine Datei schreibt - FERTIG.

Geht nicht, weil Daten, die ein mal abgeholt wurden, nicht mehr da sind,
und unter DOS war es (bei funktionierenden Systemen) ueblich direkt mit
den Ports zu reden.
Das DOS TSR Programm muesste etwas tun, was unter DOS eigentlich nicht geht,
naemlich den Port virtualisieren, also in dn protected Mode schalten.

Daher hat man es damals anders gemacht: Man liest die Daten auf einem
seriellen port ein, schaufelt die durchs Programm was sie durchaus
auch sxchreiben kann, und das programm sendet sie gleich wieder ueber
ein zweites COM-Port raus, welches hardwaremaessig mit einem dritten
COM Port verbunden ist, welches das ist, was das eigentliche Programm
bedient (und mit Sendedaten dasselbe rueckwaerts).

Dazu nimmt man aber nicht ein TSR, sondern einen zweiten Rechner, das
spart die ueble Programmierung, vom TSR aus eine Datei zu schreiben
(geht, ist aber so tricky, dass darueber ein ganzes Buch geschrieben
wurde, TesSeRact ist eine Implementierung dazu).
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[gUnther nanonüm]

"Jan Lucas" <jan@lucas-berlin.de> schrieb im Newsbeitrag
news:fc4fav$fpf$02$1@news.t-online.com...

Wolfgang Schrader schrieb:
Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.

In einer Interrupt Routine in eine Datei schreiben ist sehr
problematisch. Vielleicht geht ja auch eine andere Lösung? Bspw. per
Tastatur?

Hi,
man könnte per Commandointerpreter die Serielle an LPT umleiten, dann hätte
man einen Ausdruck ;-)
Ansonsten eine PC-Karte in einen freien Slot, die per Telnet den
"Mutterrechner" steuert und mittels besserem OS dazu befähigt ist.

--
mfg,
gUnther

 

[Joerg]

Hallo Wolfgang,

bei einem EBAY-Schnäppchenkauf sind wir zu einem ganz hervorragenden
GSM-Messplatz von Rhode&Schwarz gekommen:

Der CTS55 entpuppt sich bei näherem Hinsehen als ein 486er-PC mit MS-DOS
5.0. Wir möchten nun online bzw. ohne aus dem Mess- und
Darstellungsprogramm zu gehen eine Textdatei von außen via serieller
Schnittstelle auf das Gerät spielen (da steht der Text einer zu
versendenden SMS drin und den möchten wir von Fall zu Fall ändern).

Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.

Hat jemand noch so etwas rumliegen? LAPLINK und InterLink scheinen
ungeeignet, da diese Programme im Vordergrund laufen wollen ...

Aus grauer Erinnerung: Frueher hatten wir so etwas mit DOS-Multitaskern
gemacht. Dabei wurde allerdings das laufende Programm angehalten, was
nur bei Nicht-Realtime Chosen geht, d.h. das "laufende" Programm merkt
nichts davon, solange nicht genau dann irgendwoher ein Interrupt von
einer anderen Schnittstelle eintrudelt. Meiner war von Logitech, circa 1990.

--
Gruesse, Joerg

http://www.analogconsultants.com

 

[Rieker Flaik]

Am Mon, 10 Sep 2007 23:54:14 +0200 schrieb Wolfgang Schrader:

Der CTS55 entpuppt sich bei näherem Hinsehen als ein 486er-PC mit MS-DOS
5.0. Wir mĂśchten nun online bzw. ohne aus dem Mess- und
Darstellungsprogramm zu gehen eine Textdatei von außen via serieller
Schnittstelle auf das Gerät spielen

Ich weiß zwar nicht was ein CTS55 und GSM-Messplatz ist, aber es
sollte relativ leicht mĂśglich sein auf den 486er je nach RAM ein
2.2,2.4,2.6er Linux-Kernel nebst GNU-Klimbim und dosemu zum Laufen zu
bringen.

 

[Wolfgang Gerber]

Wolfgang Schrader schrieb:

<-->

Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.

Alte Netzwerkkarte und Netzwerktreiber! Gibt es nachgeschmissen.

Man hat auch früher schon PCs vernetzen können. Sogar eigentlich
einfacher als heute


Gruss Wolfgang

--
Achtung Spamfilter: Bei Mailantwort muss das Subjekt
das Wort NGANTWORT enthalten.

 

[Wolfgang Gerber]

Jan Lucas schrieb:

Wolfgang Schrader schrieb:
Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.

In einer Interrupt Routine in eine Datei schreiben ist sehr
problematisch.

Quatsch und NUHR!


Gruss Wolfgang

--
Achtung Spamfilter: Bei Mailantwort muss das Subjekt
das Wort NGANTWORT enthalten.

 

[Wolfgang Gerber]

Wolfgang Schrader schrieb:

Hallo Manfred,

ich bin mir ganz ganz sicher, dass das geht -

es geht auich - MaWine hat bloß die Aufgabe nicht verstanden.

Vernetz' das Dind doch einfach. Die Karten gibt es ab geschenkt. Die
Treiber bei MS zum Download.

Warum komplizierter wenn es einfach geht?


Gruss Wolfgang

--
Achtung Spamfilter: Bei Mailantwort muss das Subjekt
das Wort NGANTWORT enthalten.

 

[Henning Paul]

Wolfgang Gerber wrote:

Wolfgang Schrader schrieb:


Hallo Manfred,

ich bin mir ganz ganz sicher, dass das geht -

es geht auich - MaWine hat bloß die Aufgabe nicht verstanden.

Vernetz' das Dind doch einfach.

Und dann kann man im _Hintergrund_, unbemerkt von der
Vordergrundanwendung Kopieraktionen durchziehen? Oder meintest Du, er
soll ein Netzwerklaufwerk einrichten und die Anwendung dann davon
starten?

Gruß
Henning

 

[Michael Kutscher]

Hi,

Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.
Naja, solcherlei Sachen (TSR-Programme auf DOS-Basis) habe ich durchaus

gemacht, ist aber mehr als 10 Jahre her.
Dabei gibts aber zwei handfeste Probleme:
1. Das wäre eine Spezialentwicklung und die braucht ihre Zeit. Und Zeit
kostet Geld.
2. Obs am Ende funktioniert, kann niemand vorhersagen, denn es ist
durchaus denkbar, daß das "normale" Steuerungsprogramm des Geräts solche
Versuche dann blockiert oder selbst in seiner Funktion gestört wird.

Hat jemand noch so etwas rumliegen? LAPLINK und InterLink scheinen
ungeeignet, da diese Programme im Vordergrund laufen wollen ...
Es gab mal was fertiges, ich glaube es hieß "Sidekick" und etwas anderes

"DualDOS" oder so. Damit konnte man dann zwei Programme auf DOS
gleichzeitig laufen lassen. Allerdings sollte man nicht zuwenig Speicher
drin haben. Vielleicht findet man das ja noch irgendwo (ich habe es
nicht, aber vielleicht hilft ja google, wenn mans mit diesen
Stichwörtern füttert (naja, bei "Sidekick" dürften Millionen von
Fremdgehagenturen kommen)).

Gruß
Michael Kutscher

 

[Stefan Brröring]

Geht nicht, weil Daten, die ein mal abgeholt wurden, nicht mehr da sind,
und unter DOS war es (bei funktionierenden Systemen) ueblich direkt mit
den Ports zu reden.
Das DOS TSR Programm muesste etwas tun, was unter DOS eigentlich nicht geht,
naemlich den Port virtualisieren, also in dn protected Mode schalten.

Selbstverständlich geht das.
Hab vor ca. 20 Jahren mal was ähnliches gemacht. Ein
Turbo-Pascal-Programm, dass Daten von der seriellen Schnittstelle
eingelesen hat. Das Programm hat die Datenübergabe an das Hauptprogramm
allerdings über den Arbeitspeicher gemacht.
Dazu wurde die Anfangsadresse des Arrays, wo die Daten abgelegt wurden
in eine Textdatei geschrieben und das Hauptprogramm hat dann mit
Mem[xxxx:yyyy] darauf zugegriffen.

Dateizugriff sollte aber auch kein Problem sein.


Hier mal einige Codefragmente:

Das zweite Beispiel ist eine Einleseroutine für ein
Maschinendatenerfassungssystem. Dort werden alle 5 Sekunden Daten aus
einem Microcontrollersystem abgerufen.

Was der ASM-Code im ersten Beispiel genau macht, weiss ich nicht mehr...

-----------------------------------------------------------------------------------------


program speicherresi;
{$M $800,0,0}
uses crt,dos;
{ Test eines speicherresidenten Programmes
Wirkungsweise : Programmstart vom DOS, Rcksprung ber Keep(0) }

VAR Zeiger_w,Zeiger_r : word;
xx : array[0..32800] of byte;
t0,alpha : byte;
UhrIntVec : procedure;
dat : text;
abst,ofsx : word;
{$F+}
procedure Uhreninterrupt;
interrupt;
begin
asm
MOV AL,t0
DEC AL
MOV t0,AL
JNZ @weiter
MOV AX,zeiger_w
SUB AX,zeiger_r
JZ @ist_gleich
AND AX,32767
SUB AX,9
JNL @ist_gleich
MOV AX,zeiger_r
ADD AX,18
AND AX,32767

MOV zeiger_r,AX
@ist_gleich:
MOV BX,zeiger_w
MOV SI,ofsx

MOV DX,824
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV DX,826
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV DX,828
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV DX,808
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV DX,810
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV DX,812
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV DX,816
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV DX,818
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV DX,820
IN AL,DX
MOV DS:[SI+BX],AL
INC BX
AND BX,32767

MOV zeiger_w,BX
MOV AL,91
MOV t0,AL
@weiter: CALL UhrIntVec
end
end;

begin
zeiger_w := 32000; zeiger_r := 32000;
ofsx := ofs(xx);
port[830] := 155;
port[814] := 155;
port[822] := 155;
t0 := 91;
writeln(seg(zeiger_w),' ',ofs(zeiger_w),' ',ofs(zeiger_r),' ',ofs(xx));
assign(dat,'R_ausw.par');
rewrite(dat);
writeln(dat,seg(zeiger_W));
writeln(dat,ofs(zeiger_W));
writeln(dat,seg(zeiger_r));
writeln(dat,ofs(zeiger_r));
writeln(dat,seg(xx));
writeln(dat,ofs(xx));
close(dat);
getintvec($1C,@UhrIntVec);
setintvec($1C,addr(Uhreninterrupt));
keep(0);
end.


---------------------------------------------------------------------------------------

hier noch was mit Einlesen über COM-Schnittstelle:


program speicherresi;
{$M $800,0,0}
uses crt,dos;
{ Test eines speicherresidenten Programmes
Wirkungsweise : Programmstart vom DOS, Rcksprung ber Keep(0) }
type s12 = string[12];

VAR Zeiger_w,Zeiger_r : word;
xx : array[0..32800] of byte;
t0,alpha : byte;
UhrIntVec : procedure;
dat : text;
abst,ofsx : word;
i : integer;
c : char;
s : s12;
PIO : array [0..8] of byte;

Var EinZeiger,Auszeiger : byte;
const com : word = $3f8; { com2: $2f8/$0b com1: $3f8/$0c}
comint : byte = $0c;

Var altcom : pointer;
exitalt : pointer;
InBuff : array [0..255] of byte;

procedure ReadCom;
interrupt;
var b,z,msb,lsb : byte;
i : integer;
t : string;
begin
inc(EinZeiger);
b := port[com];
inbuff[einzeiger] := b;
port[$20] := $20;
if b=25 then {wenn Endmarke erreicht, '#PaFFbFFcFF'+ chr(25) }
begin
t := '*';z := EinZeiger; for b := 0 to 8 do PIO := 0;
repeat {komplette Zeile nach t, z.B. '#PaFFbFEcFD*' }
dec(z);
t := chr(inbuff[z])+t;
until (z=EinZeiger) or (t[1]='#');
z := 0;
if (t[1] = '#') and (t[2] = 'P') then
{ '#P' an Anfang, asc(25) am Ende, => Datenblock ok }
repeat
z := z + 3;
b := ord(t[z]);
if (b > 96) and (b < 106) then { 'a' bis 'i' }
begin
b := b - 97; { 0 <= b <= 8, Adresse in PIO, a-i }
val('$'+t[z+1]+t[z+2],PIO,i);
end;
until (z+3 >= length(t)) or ((t[z+3])='*');
end;
end;

procedure sende(c:byte);
begin
while (port[com+5] and $20 = 0) do;
port[com] := c;
end;

function ichar:char;
begin
if auszeiger <> einzeiger then;
begin
inc(auszeiger);
auszeiger := auszeiger and 255;
ichar := chr(inBuff[auszeiger]);
end;
end;

{$F+} procedure exitcom; {$F-}
begin
exitproc := exitalt;
port[$21] := (port[$21] or $18);
einzeiger := port[com];
setintvec(comint,altcom);
end;

procedure initcom(pport:integer;baud:real);
var a : integer;
i : byte;
begin
com := $3f8; comint := $0c;
if pport = 2 then begin com := $2f8; comint := $0b; end;
exitalt := exitproc;
exitproc := @exitcom;
port[$21] := (port[$21] or $18);
getintvec (comint,altcom);
a := round(115200.0/baud);
port[com+3]:= $80;
port[com] := lo(a);
port[com+1] := hi(a);
port[com+3] := 3;
port[com+1] := 1;
port[com+4] := $0b;
i := port[com];
setintvec(comint,@readcom);
einzeiger:=0;
auszeiger:=0;
Port[$21] := (port[$21] and $e7);
end;

{$F+}
procedure Uhreninterrupt;
interrupt;
var zz : word;
i : integer;
begin
if t0 <= 20 then
begin
if t0=20 then sende(ord('#'));
if t0=19 then sende(ord('P'));
if t0=18 then sende(25);
if t0=0 then
begin
zz := zeiger_r-zeiger_w;
if zz <> 0 then
begin
zz := zz and 32767;
if zz <= 9 then
begin
zeiger_r := zeiger_r + 18;
zeiger_r := zeiger_r and 32767;
end;
end; {if zz <> 0 then}
for i := 0 to 8 do
begin
xx[zeiger_w] := PIO;
inc(Zeiger_w);
Zeiger_w := Zeiger_w and 32767;
end;
t0 := 91;
end; {if t0=0 }
end; {if t0 <= 20}
dec(t0);
asm
CALL UhrIntVec
end
end;

procedure bufl;
begin
while einzeiger <> auszeiger do
begin
c := ichar;
if c in [#7,#10,#13,#25] then
case c of
#7 : begin
sound(1000);
delay(100);
nosound;
end;
#13: writeln;
#25: begin
write(c);
writeln(PIO[0]:5,zeiger_w:8,zeiger_r:8);
end;
end {case}
else write(c);
end; {while }
end; {procedure}

begin
initcom(1,9600);
sende(25);
delay(100);
sende(ord('#'));
sende(ord('I'));
sende(25);
delay(100);
bufl;
zeiger_w := 32000; zeiger_r := 32000;
ofsx := ofs(xx);
getintvec($1C,@UhrIntVec);
setintvec($1C,addr(Uhreninterrupt));
t0 := 91;
writeln(seg(zeiger_w),' ',ofs(zeiger_w),' ',ofs(zeiger_r),' ',ofs(xx));
assign(dat,'R_ausw.par');
rewrite(dat);
writeln(dat,seg(zeiger_W));
writeln(dat,ofs(zeiger_W));
writeln(dat,seg(zeiger_r));
writeln(dat,ofs(zeiger_r));
writeln(dat,seg(xx));
writeln(dat,ofs(xx));
close(dat);
keep(0);
{
repeat
bufl;
until keypressed;
setintvec($1C,@UhrIntVec);
exitcom;}
end.

 

[Stefan Brröring]

Mir ist wieder eingefallen, wofür die erste Programmversion mit dem
ASM-Code war:

Vermutlich ist das eine Version, bei der die Signale über eine PIO-Karte
mit 8255 in den PC eingelesen wurde. Nachdem die Fabrik dann abgebrannt
ist, wurde dann auf eine Version mir serieller Schnittstelle und
verteilten Microcontrollern umgestellt, die bis heute läuft, allerdings
inzwischen unter Windows in Delphi.

Gruß

Stefan DF9BI

 

[Peter Heitzer]

Wolfgang Schrader <ws@woschrader.de> wrote:

Hallo Leute,

bei einem EBAY-Schnäppchenkauf sind wir zu einem ganz hervorragenden
GSM-Messplatz von Rhode&Schwarz gekommen:

Der CTS55 entpuppt sich bei näherem Hinsehen als ein 486er-PC mit MS-DOS
5.0. Wir möchten nun online bzw. ohne aus dem Mess- und
Darstellungsprogramm zu gehen eine Textdatei von außen via serieller
Schnittstelle auf das Gerät spielen (da steht der Text einer zu
versendenden SMS drin und den möchten wir von Fall zu Fall ändern).
Wie schon Wolfgang G. schrieb, ist die einfachste Methode, den Rechner

zu vernetzen. Das Meßprogramm greift dann einfach auf eine Datei auf einem
Netzlaufwerk zu.
Eine weitere Möglichkeit wäre ein Gerätetreiber, z.B. $SMS$, der dann
via serieller Schnittstelle auf den SMS Text zugreift. Auf der anderen Seite
muß aber der Text bereits vollständig abrufbar sein, asynchrones Einspielen
ist also nicht.
Vielleich bietet ja das Meßprogramm die Möglichkeit, eine DOS Shell aufzu-
rufen und danach ins Programm zurückzukehren. Dann wäre die Sache noch
einfacher.

BTW: Soll die SMS automatisch versendet werden oder durch den Bediener des
Meßprogrammes? Im letzteren Falle wäre auch eine Übertragung via
"Diskettenweitwurf" möglich.

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.

 

[Marcel Müller]

Wolfgang Gerber wrote:

Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.

Alte Netzwerkkarte und Netzwerktreiber! Gibt es nachgeschmissen.

Ja, das haben wir in den 90gern auch mit alten Mess-DOSen gemacht.
Allerdings ist es keineswegs trivial, denn es wird hierfür
Server-Funktionalität benötigt. MS-LAN-Client installieren und die
Patches für den DOS-Basierten MS-LAN-Server drüberbügeln ist die
klassische Lösung. Ob das die laufende Software nicht stört muss man
aber gut testen. Außerdem ist es natürlich Lizenzrechtlich nicht
zulässig, da der MS-LAN-Server nicht frei ist und auch nicht mehr
wirklich erworben werden kann. Gleichwohl wird das bei 20 Jahre alter
Software wohl kaum noch jemanden interessieren.

Man hat auch früher schon PCs vernetzen können. Sogar eigentlich
einfacher als heute

Allerdings streuben sich neuere Windowsversionen zunehmend und vehement
per NETBEUI zu kommunizieren. Kurzum DOS <-> W2k3-Server ist z.B.
definitiv nicht. Und für Vista dürfte das Gleiche gelten.

Die Alternative, einen TCP/IP-Stack unter DOS hochzuziehen, scheitert in
der Regel am Adressraum unter 1MB. Selbst bei Benutzung von LOADHIGH.


Dann bleibt wirklich nur noch die Alternative, die Software in einer VM
hochzuziehen. Am besten geht das erfahrungsgemäß noch mit OS/2 Warp 3
oder 4. Aber auch die DOS-Emu ist nicht schlecht, braucht aber i.A. dann
stärkere Hardware, während es bei OS/2 reicht, etwas mehr (alten)
Speicher zu besorgen. 16MB Minimum. Die Hardware Komplett zu wechseln
scheitert gerne an speziellen I/O-Steckkarten.

Die größten Softwareprobleme gibt es dabei an folgenden Stellen:
- Oft treten schon immer vorhandene Programmfehler in den Emulationen
mit um Größenordnungen höherer Wahrscheinlichkeit auf. Das kann ein KO
werden.
- Die emulierten I/O-Komponenten verhalten sich im Timing anders, was
das Programm u.U. aus dem Tritt bringt. COM-Ports und Timer-Bausteine
sind so ein Kandidat. Unter OS/2 kann man einer DOS-Sitzung in geweisen
Grenzen exklusiven Zugriff auf diese Komponenten erlauben. Damit geht es
meistens auch bei Echtzeit-Anwendungen.
- Die ständig wechselnde effektive CPU-Geschwindigkeit der VM bringt
Programme, die mit Zählschleifen Timings realisieren aus dem Tritt.


Marcel

 

[Stefan Brröring]

Wie schon Wolfgang G. schrieb, ist die einfachste Methode, den Rechner
zu vernetzen. Das Meßprogramm greift dann einfach auf eine Datei auf einem
Netzlaufwerk zu.

Glaub ich nicht. Wenn ich mich an die Zeiten mit DOS-PCs in
Novell-Netzen erinnere, graust es mir. Da hat Windows einen echten
Fortschritt gebracht.

Hab auch mal nach TCP/IP für DOS gesucht und dann aufgegeben, weil das
entweder nicht ausreichend dokumentiert, oder zu aufwendig war.

Die Idee des OP, über die serielle Schnittstelle etwas einzulesen,
erscheint mir deshalb gar nicht so schlecht.

Man kann in DOS speicherresidente Programme schreiben und auch die
serielle Schnittstelle per Interrupt auslesen. Die Compiler, die man
dafür benötigt, z.B. Turbo Pascal V. 5.5 gibt es wohl inzwischen zum
kostenlosen Download bei Borland.

Ich würde mir zutrauen, sowas in wenigen Stunden zu realisieren. Die
Beispiele, die ich weiter oben gepostet habe, machen zwar was anderes,
aber die wichtigsten Punkte, d.h. speicherresidentes Programm, Uhrenint
und Daten vom COM-Port einlesen sind da schon drin.

Gruß Stefan DF9BI

 

[Andreas Lobinger]

Aloha,

Wolfgang Schrader wrote:

Der CTS55 entpuppt sich bei näherem Hinsehen als ein 486er-PC mit MS-DOS
5.0.

Der CTS55 sieht bei ungenauem Hinsehen wie ein 486er-PC mit MS-DOS und
einem RIESIGEN angeschlossenen Meßgerät aus...

Wir möchten nun online bzw. ohne aus dem Mess- und
Darstellungsprogramm zu gehen eine Textdatei von außen via serieller
Schnittstelle auf das Gerät spielen (da steht der Text einer zu
versendenden SMS drin und den möchten wir von Fall zu Fall ändern).

Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.

Hat jemand noch so etwas rumliegen? LAPLINK und InterLink scheinen
ungeeignet, da diese Programme im Vordergrund laufen wollen ...

Super, das hier jeder im Thread sofort seltsamste Ideen aufbietet,
wie man am System des CTS herumpfuschen kann, anstatt den OP
im Handbuch lesen zu lassen, das man die SMS mittels Kommando
über die serielle Schnittstelle (ich geh' davon aus, das die
eingebaut ist, sonst ist's nämlich auch schwierig andere SW
in's Gerät zu bringen) ändern kann.

Einen fröhlichen Tag wünschend,
LOBI

 

[Jan Lucas]

Wolfgang Gerber schrieb:

Jan Lucas schrieb:

Wolfgang Schrader schrieb:
Steckt jemand noch so richtig in der DOS-Materie? Schön wäre ein
TSR-Progrämmchen, dass an der seriellen Schnittstelle lauscht und Daten,
die von dort reinplätschern, in eine Datei schreibt - FERTIG.
In einer Interrupt Routine in eine Datei schreiben ist sehr
problematisch.

Quatsch und NUHR!

Das "sehr" mag vielleicht übertrieben sein. Problematisch ist es aber
auf jeden Fall. Einfach so Datei IO im TSR nutzen klappt zumindest nicht
(bzw. klappt vielleicht ein paar Mal bis es dann irgendwann
schiefgeht.). Du musst zumindest sicherstellen, das dein DOS oder dein
BIOS nicht gerade dabei sind irgendeinen anderen Aufruf abzuarbeiten.
Falls doch mußt du die Daten zwischenpuffern und dafür sorgen, das sie
zu einer anderen Zeit weggeschrieben werden. Dazu eigenet sich der
Timerinterrupt, der sollte aber während der Datei IO weiterlaufen, also
in der Routine wiederzurückbiegen, Interrupts anschalten und wenn man
mit der Datei IO fertig ist wieder auf die eigene Timerroutine biegen.
Datei IO macht das ganz eindeutig deutlich kompliziert als das reine
Annehmen von Daten über die serielle Schnittstelle. Da biegt man nur
einen Interrupt um und kann auch gleich alles direkt nach Empfang eines
Zeichens erledigen.

Jan

 

[Peter Heitzer]

Stefan Brröring <stefan___@broering.de> wrote:

Wie schon Wolfgang G. schrieb, ist die einfachste Methode, den Rechner
zu vernetzen. Das Meßprogramm greift dann einfach auf eine Datei auf einem
Netzlaufwerk zu.

Glaub ich nicht. Wenn ich mich an die Zeiten mit DOS-PCs in
Novell-Netzen erinnere, graust es mir. Da hat Windows einen echten
Fortschritt gebracht.
MS-DOS 6.22 mit VLMs ist sehr zuverlässig. War bei uns jahrelang im Einsatz.

Problematisch ist, daß als Protokoll IPX verwendet wird, was mittlerweile
nicht mehr so recht unterstützt wird. TCP/IP unter DOS ist da um einiges
wackeliger.

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
HTML mails will be forwarded to /dev/null.