Hallo! Ich arbeite momentan intensiv an meiner Studienarbeit und habe eine ISA Karte gebastelt mit einem 8Mhz µC (68HC12) und will nun diese Karte mit Sounddaten füttern in einer Geschwindigkeit von mind. 44,1 Khz (über den ISA Bus natürlich). Ich habe mich schon etwas mit der Treiberprogrammierung auseinandergesetzt, jedoch ist mir das Schreiben eines Soundtreibers (Kernel Streaming), der ja den DMA Controller anspricht, etwas zu anspruchsvoll und vor allem zeitaufwendig. Deshalb die Frage an euch: Kann ich das Problem umgehen (vereinfachen) indem ich einen Trick anwende und den PIT auf eine höhere Basisfrequenz programmiere (ich weiss wie das geht) und dann auf die WinAPI Funktion SetTimer() zurückgreife, die ja standardmäßig nur bis zu 1ms einstellbar ist ?? (ich geh mal davon aus dass SetTimer() über IRQ0 gesteuert wird) Nachteil: Sehr benutzerunfreundlich da ganzes Betriebssystem um Faktor 44 schneller läuft :P (wäre mir aber im schlimmsten falle egal) Oder den Prozessortakt auslesen (geht das über CLK_TCK ? siehe time.h ??) und dann ein manuelles delay programmieren in abhängigkeit des Taktes ? Oder habe ich da unter Windows 0 chance ohne DMA egal wie ichs hinbieg... was meint ihr ?? MFG Stephan
Nein, keine Chance. Den Systemtimer kannst Du nicht umprogrammieren, das lässt das OS nicht zu. Auch Delay ist keine gute Idee - W2K ist ein Multitasking-OS, das Dir hinterrücks die Rechenzeit wegnehmen wird. Selbst wenn dieser Ansatz möglich wäre, über den zum Ansteuern Deiner Hardware erforderlichen Devicetreiber verfügst Du? Dein Hardwaredesign ist das grundlegende Problem. Um timingkritische Hardwarezugriffe zu entkoppeln, wird in solchen Fällen Fifo-Hardware verwendet; der PC kann am Stück größere Datenblöcke in den Hardwarepuffer schreiben, den am anderen ende der µC mit einer ihm genehmen Geschwindigkeit ausleert. Nähme man beispielsweise 1 kByte-Blöcke, dann müssten diese knapp 50 mal pro Sekunde übertragen werden, was wesentlich unproblematischer zu realisieren ist (Ich gehe hier jetzt vereinfachend von 8-Bit-Monosamples aus). Ein Beispiel für just Deine Anwendung wurde vor etlichen Jahren mal in der Zeitschrift elrad veröffentlicht - das war zu der Zeit, zu der elrad noch im Heise-Verlag erschien. Das muss Anfang der 90er Jahre gewesen sein oder so. Unter dem Namen "take 5" wurde eine ISA-Steckkarte als Selbstbauprojekt vorgestellt, die dem PC eine - damals noch äußerst unübliche - S/PDIF-Schnittstelle verpasste. Über die konnte mit 44.1 kHz Samplerate aufgenommen und wiedergegeben werden, und das ganze wurde mit FIFO-Bausteinen vom ISA-Bus entkoppelt. Prinzipiell: Auch wenn das ganze eine Studienarbeit ist, halte ich hier einiges für etwas fragwürdig. Warum wird für den ISA-Bus entwickelt? Den gibt es doch in kaum noch einem PC, und damit gewonnene Erkenntnisse sind nicht auf andere Bussysteme umsetzbar. Außerdem hat der ISA-Bus etliche Probleme - die bei I/O-Zugriffen erreichbare Datenrate ist nicht besonders hoch, Adressdecodierung ist ziemlich gurkig (wenn es um 16-Bit-Zugriffe geht, erst recht) und obendrein ist Interruptsharing aufgrund der hirnverbrannten Active-High-Interrupts eh' nicht möglich. Wenn es nur darum geht, Audiodaten zu verarbeiten, wäre die Nutzung einer eh' vorhandenen Audioschnittstelle sinnvoller - viele PCs verfügen heutzutage über einen S/PDIF-Ausgang, an dem sich recht unkompliziert ein 44.1 kHz-16-Bit-Stereosample-Datenstrom abgreifen lässt. Geht es sogar nur darum, Daten relativ schnell aus dem PC 'rauszubekommen, wäre eine USB-Lösung mit FT245 angesagt. Ein grundlegendes Problem vieler Studien-/Diplomarbeiten scheint die Wahl eines völlig ungeeigneten Hardwareansatzes zu sein, der dann dafür sorgt, daß keine normale Betriebssystemumgebung verwendet werden kann - beim ursprünglich geschilderten Ansatz muss das OS effektiv komplett lahmgelegt werden. Daß die bei solcher Ansteuerung von Hardware gewonnenen Erkenntnisse niemals in dieser Form in einem realistischen Produkt umgesetzt werden könnten, scheint den Betreuern der entsprechenden Arbeiten entweder völlig egal zu sein oder aufgrund massiver Inkompetenz noch nicht mal klar zu werden. Und im Vorfeld unrealistische Hardware- oder Softwareanforderungen zu erkennen, sollte eigentlich schon zu deren Aufgabenbereich gehören.
hallo! erstmal paar sachen vorweg: - Doch ich habe die Möglichkeit den PIT unter Win2k zu programmieren, da ich über einen bereits fertigen treiber verfüge, der mir zugriff auf alle IO Ports zulässt. (selbst schon getestet) - einen Standard IO treiber für die isa karte habe ich moment zwar noch nicht, wäre für mich aber noch im bereich des Schaffbaren ! Den Treiber für Streaming zu erweitern würde mich zu sehr in Zeitnot bringen. Warum ISA ? - einfacher... Dass ich überhaupt nichts von dem Wissen über den ISA bus auf andere Bussysteme wie PCI z.b. übertragen kann kann ich noch nicht beurteilen, aber finde ich trotzdem etwas übertrieben.. Ich habe mich halt vebockt was das thema angeht, jetzt muss ich halt in den sauren apfel beissen und das beste draus rausholen ! zumal eine einfache IO karte ohne streaming als studienarbeit für mich völlig ausgereicht hätte ! (vom umfang her) Naja mein Prof meinte, dass muss jeder selbst beurteilen ob die aufgabe ok ist und vor allem für im bereich des Machbaren steht ... mfg Stephan
Wenn Du darauf bestehst, Dein Hardwarekonzept zu nutzen, was hieltest Du davon, wie folgt vorzugehen: Deine Hardware erzeugt einen 44.1 kHz-Interrupt und ein von Dir zu schreibender Devicetreiber bedient diesen und überträgt aus einem Puffer Daten an Deine Hardware. Das erscheint mir sowieso sinnvoller als das Verwenden eines Timers, weil ja schließlich Deine Hardware eh' am besten weiß, wann sie Daten benötigt. Damit dürfte Dein Konzept noch ansatzweise realisierbar sein; Du musst halt einen Interrupthandler im Devicetreiber programmieren und eine abartig hohe Interruptrate bedienen - das aber müsstest Du beim Umficken des Systemtimers auch (Der etwas derbe Begriff ist bewusst gewählt). Ausserdem ist nicht gewährleistet, daß ein W2K auf einem Rechner mit derart "übertaktetem" Timer überhaupt sinnvoll laufen kann - da kann potentiell so einiges schiefgehen, da für den Rechner plötzlich sämtliche Hardware sehr "träge" zu sein scheint ... Das bedeutet allerdings, daß Du nicht einfach einen der beliebten "giveio.sys"-Treiber verwenden kannst, die für den Usermode die Überwachung von I/O-Zugriffen abklemmen, sondern schon einen echten Devicetreiber selber programmieren musst - oder aber eine Softwarekomponente einsetzt, die auch das Programmieren von Interrupthandlern zulässt. Ein Beispiel für sowas wäre hier zu finden: http://www.kithara.de/ge/prod.php?sub=khdw (Das ist eine in Berlin ansässige Firma, was bei Supportanfragen etc. wohl von Hilfe sein mag). Ob es vergleichbares auch im nicht kommerziellen Bereich gibt, entzieht sich meiner Kenntnis. Dennoch "schreit" diese Anwendung nach einem Interrupt, der von der Hardware ausgelöst wird - der Systemtimer liefe ja zwangsweise asynchron zu Deiner Hardware, was zu Datenverlust oder anderen Probleme führte. Die Auswirkung des Gebrauchs eines 10 kHz-Interrupts kannst Du leicht selber testen - Serielle Schnittstelle auf 115.2 kBit/sec stellen, Hardware-FIFOs abschalten und Datenübertragung damit machen. Sollte prinzipiell funktionieren, wenn vielleicht auch etwas wackelig. Im Performance Monitor kannst Du Dir ja auch die Interruptbelastung des Systems anzeigen lassen.
http://www.c-plusplus.de/forum/viewtopic.php?t=90362 http://www.c-plusplus.de/forum/viewtopic.php?t=90364 Man kann es auch übertreiben mit Crossposts. Wenn du schon in mehreren Foren posten willst, dann bitte nacheinander. Und schreib in deine späteren Beiträge rein, in welchen Foren du bereits gepostet hast.
@Guard: naja ich wollte halt nur die sache beschleunigen und von mehreren leuten gleichzeitig ein statement bekommen, da ich möglichst schnell zu einer entscheidung kommen wollte. Wie heisst es immer beim Bund: "Wir haben doch keine Zeit!" ... übrigends hab ich bei c-plusplus.de gut unterstützung bekommen als ich vor nem jahr einen eigenen kernel geschrieben hab... du bist aber nicht zufällig ein Admin von dort ? fg @Rufus: rat mal was ich grade vorschlagen wollte... ;) der HC12 hat glücklicherweise einen Pulsgenerator, den ich an die IRQ leitung hängen kann! Eigentlich dürfte das ohne Probleme in Echtzeit funktionieren, vorrausgesetzt ich bekomme auch den isa bus mit dieser Frequenz zur verfügung ohne große delays, die sich dann hörbar bemerkbar machen würden! Aber hey! Danke trotzdem nochmal ! :) mfg
Noch eine Anmerkung zu Kithara: Deren Tools kann man sich als 30-Tage-Testversion herunterladen; damit man das nutzen kann, muss man sich einen Lizenzschlüssel zuschicken lassen, was aber problemlos funktioniert und nicht mehr Informationen als einer einfachen Email-Adresse bedarf.
thanks!! find ich voll nett wie du dir da gedanken machst für mich ! :) ich denke ich hab jetzt genug futter fürs erste was die software angeht. mfg
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.