Forum: PC Hard- und Software TELEDAT 100 Treiber/Quellcode


von TELEDAT 100 (Gast)


Lesenswert?

Ich suche für eine Teledat 100 einen Treiber beziehungsweise Quellcode 
um einen eigenen Treiber zu realisieren beziehungsweise um die Karte 
selber steuern zu können. Die Karte wird in einem ISA-Steckplatz 
betrieben und über die Adresse &H0108 - &H010F angesprochen.

Zum Einsatz soll die Datei INPOUT32.DLL kommen. Bisher lese ich die 
Adresse &H0108 und erhalte als Antwort den Wert &HE4. Mit diesem Wert 
kann ich bisher nichts anfangen.

Auf der Karte befindet sich ein Chip vom TYP PSB2186 welchen ich 
benutzen will um eine Rufnummernanzeige zu realisieren. Mir ist bewusst 
dass es hier bereits Software gibt. Ich will jedoch eigene Software 
entwickeln welche ich im Anschluss für einen ATMega umschreiben will.

Ich bin für Hinweise dankbar die mich zum erfolgreichen auslesen der 
Karte führen.

von Linus (Gast)


Lesenswert?


von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Wenn die Karte Interrupts erzeugen kann, dann lässt sie sich nicht mit 
simplen I/O-Zugriffen aus einem Usermode-Programm heraus ansteuern, 
sondern benötigt einen "richtigen" Devicetreiber. Eine Ansteuerung ohne 
Nutzung von Hardwareinterrupts dürfte bei einer passiven ISDN-Karte 
(also ohne eigenen Prozessor etc.) kaum sinnvoll möglich sein.

Bist Du Dir wirklich ganz sicher damit, einen ISDN-Treiber selbst aus 
einem Usermode-Programm (anscheinend auch noch in BASIC geschrieben) 
schreiben zu wollen? Hast Du Dir mal die zugehörigen Spezifikationen von 
der ETSI besorgt und bist Du firm in ASN.1 und dem D-Kanal-Protokoll?

Was genau hast Du vor, was die CAPI Dir nicht bietet?

von TELEDAT 100 (Gast)


Lesenswert?

@Rufus t. Firefly

Ich muss gestehen, mit ASN.1 habe ich mich besher nicht beschäftigt. In 
der wikipedia lese ich, dass ASN.1 in eine BNF ähnliche Syntax verwenden 
soll. Was BNF angeht, ich habe in VBScript bereits einen SMTP-Server und 
DNS-Server realisiert, wobei der DNS server noch nicht alltagstauglich 
ist, SMT wird hier hingegen schon seit einigen Jahren genutzt. Soviel 
dazu.

Was den Treiber angeht, so dachte ich mir, mich da "irgendwie" 
durchzubohren bis ich Daten erhalte. In VB6 habe ich bereits die CAPI 
angezapft und dort einen Anrufmonitor erzeugt, der alle ankommenden 
Anrufe protokolliert.

Mit Hilfe einer ASP-Seite auf meinem lokalen Webserver lese ich diese 
Datei aus und kann mir anzeigen lassen wer angerufen hat. In einem 
speziellen Verzeichnis gabe ich ein "weltweites" Telefonbuch realisiert:

d:\daten\phone\index.txt (enthält allen landesvorwahlen)
d:\daten\phone\49\index.txt (enthält allen deutschen vorwahlen)
d:\daten\phone\49\6439\index.txt (enthält "alle" Rufnummern des Ortes)
d:\daten\phone\49\6439\99.txt (enthält alle Durchwahlen einer Rufnummer)

Die ASP-Seite puffert alle bisher aufgelösten Rufnummern um die Anzeige 
zu beschleunigen.

Was das D-Kanal-Protokoll angeht muss ich zugeben mich damit noch nicht 
direkt beschäftigt zu haben. Ich muss dazu sagen, ich habe hier schon 
ganz andere dinge zum funktionieren gebracht, kann also nicht glauben, 
dass dies ein Problem darstellen sollte. Den ENC26J60 habe ich auch 
schon über den Druckerport angesteuert, ohne jetzt wirklich Daten ins 
netz gesendet zu haben. Ich kann bisher auf die Register zugreifen und 
dergleichen. Ich bin da noch lange nicht fertig.

Insgesamt versuche ich hier so viel wie möglich gleichzeitig zu lernen 
und auszuprobieren. Irgendwie hängt alles mit allem zusammen.

Ob die Teledat 100 Interrupts benutzt kann ich nicht mit bstimmtheit 
sagen. Die Karte nutzt jedoch IRY Anschlüsse. inwiefern die nun wirklich 
zwingend notwendig sind, entzieht sich derzeit meiner Kenntnis. ENC26J60 
und RFM12 benutzen auch einen INT Anschluss, müssen aber nicht 
zwangsläufig genutzt werden. Ich hoffe hier, den PSB2186 direkt 
ansteuern zu können, indem ich diesen kontionuierlich auslese, bis 
brauchbare Daten vorhanden sind. Ich könnte die IRQ Anschlüsse auch mit 
dem Druckerport verbinden um diese abzufragen.

Meiner Meinung nmach ist "alles" möglich. Ich will zumindest nicht 
glauben, dass es unmögluich ist den PSB über den Druckerport zu lesen. 
Da ich noch nicht ganz verstanden habe, wie weit der PSB geht kann ich 
noch nicht beurteilen wieviel Aufwand notwendig ist. Ich habe hier schon 
eine Threads wargenommen, die einen Anrufmonitor beschreiben. Die seiten 
sind jedoch grösstenteils nicht mehr vorhanden. Ich will mich da jetzt 
also durcharbeiten. Basic scheint mir die Sprache zu sein die jeder 
verstehen sollte. Das was ich hier herumwerke dürfte alle einigen von 
nutzen zu sein.

Und wenn diese Chip nur ansatzweise mit Basic und LPT funktioniert um 
dann weiter zu gehen um dann mit ATMega und Co zu arbeiten. Ich will 
mich überraschen lassen.

von TELEDAT 100 (Gast)


Lesenswert?

Und: "Was genau hast Du vor, was die CAPI Dir nicht bietet?"

Ich will das ganze unabhängig von einem Computer/LPT betreiben. Ein 
Anrufmonitor, den ich unter Umständen direkt in meine Telefonanlage 
einbauen kann oder an den S0 Bus anschliessen kann um eine 
Rufnummernanzeige auf dem Schreibtisch zu haben. die mein Telefon nicht 
hat.

Ich will einfach ein wenig tüfteln.

von TELEDAT 100 (Gast)


Lesenswert?

Im Zuge meiner Recherchen fand ich folgende Seite:

http://www.hacko.org/d-tracy/index.html

Dort steht geschrieben:

# Wo soll ich meine IRQs hinlegen?
* Garnicht. D-Tracy benutzt keine IRQs!!! Das Programm pollt (ja ich 
weiß das verdient Schläge) die Bausteine.

Das bestätigt eine meiner Vermutungen, dass IRQ's nicht zwangsläufig 
notwendig sind. Damit wäre das mit den IRQ's vorerst geklärt. Bis mich 
die Hardware eines besseren belehren wird.

Weiter geht's ...

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Schön. Dann lies Dir aber auch mal die Anforderungen an das System 
durch, das da verwendet wird. Sicher, ein 386er, also steinalt. Aber 
ohne jedwedes Betriebssystem (DOS ist keines). Und das Zeitverhalten 
eines 386ers ohne Betriebssystem ist auch mit einem heutigen 
Doppelkern-3-GHz-PC unter Windows und auch anderen 
nicht-Echtzeitbetriebssystemen nicht hinzubekommen.

von TELEDAT 100 (Gast)


Lesenswert?

Ich kann hier höchstens (oder mindestens) mit einem 486 dienen. DOS ist 
auch vorhanden und DEBUG bin ich auch in der Lage zu bedienen. Die 
entsprechenden Assembler Befehle IN und OUT sowie die Steuerung der 
entsprechenden Register sind mir auch möglich. Bildschirmausgaben und 
dergleichen habe ich auch schon hinbekommen. Alles Dinge im Rahmen des 
machbaren. Ich bin nicht an Windows gebunden um die IO-Ports und anderes 
bedienen/lesen/steuern zu können.

Wenn ich die Anwendung T-TRACY gedanklich ausblende und ich davon 
ausgehe, das ich die IO-Ports unter Windows mit 
INPOUT32.DLL/INPOUT32.OCX steuern kann, so dürfte das, was D-TRACY 
veranstaltet, also das lesen und schreiben von IO-Adressen durchaus auch 
mit VBScript möglich sein.

Ich habe die Erfahrung gemacht, dass ich an den IO-Ports wackeln kann, 
auch unter Windows. Sofern Windows nicht zeitgleich auf diese zugreift. 
Das lässt sich arrangieren. Ich arbeite hier noch immer mit Windows 98 
und dies ist bei weitem nicht so restriktiv wie diese "ich muss das 
neuste haben" Betriebsysteme. Ich muss nicht modern haben um 
festzustellen dass gewisse Dinge dann nicht mehr funktionieren. Da bin 
ich dann lieber altmodisch. MingW und ähnliches funktioniert hier mit 
Windows 98 auch wunderbar. Ich habe keinen Grund da Geld für etwas 
auzugeben was mir hinterher etwas verbieten will.

Ach weisst, ich lass mich jetzt mal entmutigen und schmeiss die Brocken 
hin. Der Tag wird kommen an dem ich das auch ohne dieses Forum und ohne 
Fragen hinbekomme. Hier fingen schon oft genug Dinge an zu funktionieren 
die ich in die Ecke schmiss, weil andere selbst erstellte Komponenten 
plötzlich reif genug waren um mit den in der Ecke liegenden Dingen 
eingesetzt zu werden.

Kommt Zeit kommt Rat.

von Markus -. (mrmccrash)


Lesenswert?

Kennst du den Thread schon:
Beitrag "ISDN Atmel"

Ich nehme an, das Datenblatt zum PSB2186 hast du schon?

ansonsten:
http://www.iele.polsl.pl/elenota/Infineon/sam_41d.pdf

Da stehen eigentlich alle Register beschrieben. Du müsstest nur noch mal 
checken, ob du auch Version 4.1 von dem Chip hast, sonst musst du noch 
mal googlen..

Ausserdem: schaue dir doch mal die Sourcen der ISDN-Treiber im/zum 
Linux-Kernel an. Dort findest du garantiert auch für deine Karte 
sämtliche Informationen. Den Treiber dann in einen Mikrocontroller 
umzusetzen ist dann auch keine so enorm große Aufgabe mehr, genügend 
Zeit vorausgesetzt.

_.-=: MFG :=-._

von TELEDAT 100 (Gast)


Lesenswert?

Datenblätter habe ich, jou.

Zur Seite die es hier gibt: Ja, die fand ich bereits. Der Link auf der 
Seite zeigt auf ein Archiv wobei die ZIP-Dateien nicht mit archiviert 
wurden. Ich suchte nun in einer glas-google nach eben diesen Dateien und 
fand eine andere Seite auf der die Codes vorhanden sind:

http://www.jeepthing.de/elek/isdn/index.html
http://www.jeepthing.de/elek/isdn/download.html
...

Ich habe mir nun eine Kopie von allen Dateien inklusive den Bildern und 
dergleichen angefertigt, damit das nicht irgendwann wieder alles flöten 
geht.

Ich verkneife mir nun das von mir archivierte hier anzuhängen, das ist 
mir eine Nummer zu mächtig (inkl. Datenblätter ca 12 MB) ... und wegen 
urheberrechtlichen Aspekten will ich da niemanden Probleme bereiten.

Ich werde mich nun doch noch ein wenig belesen und das ganze etwas 
sacken lassen und einige Nächte darüber schlafen.

Ich danke dir, dass du mich dazu brachtest nach einer Ersatzseite zu 
suchen. Bis die Tage dann.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

> Ich habe die Erfahrung gemacht, dass ich an den IO-Ports wackeln kann,
> auch unter Windows.

Das wird auch nicht bestritten. Nur kannst Du das unter den 
ernstgemeinten Windows-Versionen nicht ansatzweise mit der 
Geschwindigkeit, wie es ohne Betriebssystem funktioniert.

Ich will Dich gar nicht entmutigen, nur darauf hinweisen, daß der 
Versuch, so etwas unter Windows (oder einem vergleichbaren 
Betriebssystem) anzustellen, sehr problematisch ist, da dort ein 
Programm keine Kontrolle über das Zeitverhalten hat. Die Granularität 
des Windows-Schedulers beträgt halt bestenfalls 1 msec, und das ist für 
viele zeitkritische Aktionen viel zu langsam.

von TELEDAT 100 (Gast)


Lesenswert?

Was meinst du bitte mit "ernstgemeinten Windows-Versionen"?

Mal unter uns Bastelbrüdern: Du willst mir doch wohl nicht erzählen 
wollen, dass du ein Betriebssystem, egal welches, ernst nimmst und dir 
da etwas verbieten oder gestatten lässt?!

Bei mir ist es wie auf einer Baustelle: Was nicht passt wird passend 
gemacht. Bei dir nicht?

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

"Ernstgemeint Windows-Versionen" - damit ist Windows NT gemeint. 
"Windows 2000", "XP", "2003", "Vista", "2008" und auch "7" sind 
verschiedene Versionen von Windows NT, die von den Marketing-Drohnen von 
Microsoft nur umbenannt wurden.

Das Gegenteil sind die Frickel-DOS-Windows-Versionen, die von manchen 
Leuten immer noch eingesetzt werden, "95", "98" und "Me".

> Mal unter uns Bastelbrüdern: Du willst mir doch wohl nicht erzählen
> wollen, dass du ein Betriebssystem, egal welches, ernst nimmst und dir
> da etwas verbieten oder gestatten lässt?!

Das verträgt sich nicht mit der Architektur echter Betriebssysteme, ob 
sie nun Windows, Linux oder sonstiges Unix genannt werden. 
User-Mode-Programm haben keinen Hardwarezugriff und müssen Devicetreiber 
verwenden, statt direkt die Hardware zu befummeln.
Unter Windows ließ sich bis vor "Vista" die Überwachung von 
Hardware-I/O-Zugriffen mit einem Devicetreiber namens "giveio.sys" 
aushebeln, was technisch gesehen großer Pfusch ist, und deswegen sehr 
gerne verwendet wurde. Die Möglichkeit aber, auf Interrupts zu 
reagieren, ist dennoch nur Devicetreibern gegeben.
Obendrein ist das Zeitverhalten von üblichen Betriebssystemen alles 
andere als vorhersagbar, es ist eben nicht möglich, zuverlässig mit 
beispielsweise 1 msec Abstand irgendwelche Aktionen auszuführen.
Das sieht unter Echtzeitbetriebssystemen wie OS-9000 oder QNX anders 
aus, und es gibt auch ein paar echtzeitfähige Erweiterungen von Linux. 
Sogar für Windows gibt es entsprechende Zusätze (kithara), aber ohne die 
ist nichts deterministisches zu erreichen.

Ein PC ist ein vielfältiges Werkzeug, das aber gerade bei 
Low-Level-Hardwareansteuerung sehr ungeeignet ist.

Wesentlich mehr Erfolg wirst Du haben, wenn Du den Schritt mit dem PC 
sein lässt und direkt mit dem AVR die ISDN-Karte ansteuerst, denn beim 
AVR bist Du "Herr der Hardware", mehr, als Du es auf einem PC jemals 
sein kannst (denn gerade die ISA-Bus-Ansteuerung neuerer PCs ist 
zeitlich auch nicht sehr präzise, da der ISA-Bus über etliche 
Zwischenschichten mit dem eigentlichen Prozessor verbunden ist). Und 
obendrein ist so ein AVR bei Hardwarezugriffen erheblich schneller als 
ein PC und kann vor allem auch viel schneller auf Hardwareinterrupts 
reagieren.

> Bei mir ist es wie auf einer Baustelle: Was nicht passt wird
> passend gemacht. Bei dir nicht?

Nein, ich verwende einfach das zur Aufgabe passende Werkzeug.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.