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.
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?
@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.
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.
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 ...
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.
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.
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 :=-._
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.htmlhttp://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.
> 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.
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?
"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.
