Ich wollte mal fragen ,ob folgendes realisierbar ist: Ich möchte mittels eines TDA8714 Flashwandlers über den Paralellport eines Standard PC 's ein 10 MHZ breites Signal Samplen und in Echtzeit auswerten. Das Ergebnis möchte ich dann an einem weiterem Port(Seriell oder Paralell) zur verfügung stellen. Natürlich ist das ausgehende Signal nicht 10 Mhz Breit, sondern hat eine Datenrate von etwa 98K Baud. Mit einem 3 GHZ PC währe dies rein von der Rechenleistung möglich, das Signal zu bearbeiten. Es gibt 2 mögliche Hürden die zu überwinden sind. 1) Die Schaltzeiten der IO Ports könnten zu langsam sein.Währe nett wenn mir jemand diesbezüglich Erfahrungswerte sagen kann. Könnte mir gut vorstellen ,das sich bei den heutigen Mainboards, die Pins mit 20 Mhz "wackeln" lassen. Das ein solches PC - Mainboard keine direkten IO's wie ein Mikrokontroller hat sollte wohl jedem klar sein. 2) Die Ansteuerung muß mittels eines Betriebssystemes erfolgen, welches extremste Echtzeitanforderungen genügen muß. Das soetwas mit Windows XP nicht geht, ist wohl jedem klar. Ein RT-Linux scheidet auch aus ,da es nur Echtzeitanforderungen im Mikrosekundenbereich garantiert und Multitheaded arbeitet. Ich denke mal, das ein gutes altes MS - Dos und ein Assembler/C- programm, welches mittels Cli() und Sti() in dem Zeitkritischem Teil die Interrupts abschaltet und dann die Ports pollt soetwas hinbekommen müßte. Ich frage mich nur ,ob nach dem Absetzen eines Sti() auch wirklich ein ununterbrochener(und zeitlich vorhersehbarer) Programmablauf möglich ist. Vermutlich sind die Boards und die heutigen CPU 's so komplex ,das es in der Praxis dann doch nicht so funktionieren wird. Wenn ja doch,dann währe es ziemlich genaial. Dann dann könnte man auf Standardhardware wirklich breitbandiges SDR machen und müßte sich nicht mit exotischen FPGA Boards herumschlagen*g*
Danke ,aber das reicht für meine Zwecke nicht. Die Elektor- Lösung stellt mir immer nur einen max. 44 Khz Ausschnitt zur Verfügung ,denn ich dann natürlich per Software auswerten kann. Ich will aber ein etwa 10 Mhz Breites Signal direkt durch ne DSP jagen. Und 10 Mhz Soundkarten(auch PC Messkarten genannt) kosten fast soviel wie ein Kleinwagen.
mit der parallelen bekommst imho max 1Mhz hin... dann hast du bei aktuellen prozessoren das problem von jump-prediction units, out-of-order execution,pipelines,waitstates um teile aus den l2 in den l1 cache zu bringen bzw gar aus dem ram in den l1 zu ziehen, der ram hat typisch extrem schräges zugriffsverhalten (also nix mit einfach bytes reinschieben),... d.h. du weist defakto nicht wann welcher befehl abgearbeitet wird.. auch nicht in asm.... das hat gute gründe warum man da einen fpga vorsetzt.. den brauchst du einfach um das ganze zu entkoppeln... der fpga schreibt einfach blöcke in einen sram (weil anderer ram garantiert dir 1. keine zugriffszeiten und 2. ist zu langsam) und dann muss das zeug auf den pc... ich würd das aber mittlerweile per usb machen... dein rechenknecht hinten kann ohne probs windoof laufen haben... nur deine sampling-unit wird ohne fpga nicht auskommen... 73
Sicher ,das die Paralelle nur 1Mhz kann? Könnte mir gut vorstellen, das das von Kontrollerkarte zu Kontrollerkarte verschieden ist. Oder gibt es eine Spezifikation ,die besagt ,das der Paralellport nur bis 1 Mhz getacktet werden kann. Soweit ich weis kann man über den Paralellport bis zu 10 Megabytes und mehr pro sekunde schicken. Das mit den Waitstates und Out of order Exceptions müßte man genauer untersuchen. Schließlich gibt es ja die Möglichkeit zu jeder Zeit die vergangenen CPU Ticks abzufragen. Man müßte also zuerst herausfinden, wie lange die Worst Cast Verzögerung ist. Es muß hierbei nicht für 3 Ghz koninutät ,sondern nur für 20 Mhz gewährt sein. Das bedeutet, das pro Sample maximal 150 Zyklen durch solche Waitstates verlohren gehen dürfen. Alles was darunter liegt kann man durch Verzögerungschleifen ausgleichen. Mir ging es ja darum ,die Sampling - Einheit gerade ohne FPGA Einheit zu lösen. FPGA 's sind eben nicht ganz so einfach zu handhaben und wieder extrem Herstellerabhängig. Zudem lassen sich solche FPGA Boards hier in Deutschland nur sehr schwehr beschaffen. Mein Wunsch ist es eben ,dieses Problem mit Standardhardware/Komponenten zu lösen ,die fast an jeder Ecke schnell und unkompliziert zu einem günstigem Preis erhältlich sind.
Der TDA8714 hat je nur 8 Bit "8-bit high-speed analog-to-digital converter" http://www.nxp.com/#/pip/cb=[type=product,path=50804/50935/53500/42898,final=TDA8714_6]|pip=[pip=TDA8714_6][0] dazu kommt noch "This product has been discontinued" Ich habe mal zum selben Thema die Einzelhändler durchsucht, 16 Bit ist noch etwas teuer, kaum unter 100 €. Aber Farnell hatte 14 Bit 80 MS für 43,94 €, inzwischen leider auf 59,30 € gestiegen. Andere 14 Bit-Wandler mit >20 MS liegen preislich ähnlich. http://de.farnell.com/jsp/Halbleiter/Signalumwandlung/TEXAS+INSTRUMENTS/ADS5542IPAPG4/displayProduct.jsp?sku=9968989&_requestid=416831 Farnell Best.Nr.: 9968989 ADS5542IPAPG4 — TEXAS INSTRUMENTS
Im "High-Performance SDR-Project" wird ein LTC2208 benutzt http://hpsdr.org/wiki/index.php?title=MERCURY http://www.linear.com/pc/productDetail.jsp?navId=H0,C1,C1155,C1001,C1150,P13693 LTC2208 - 16-Bit, 130Msps ADC mit Upgrademöglichkeit auf LTC2209 - 16-Bit, 160Msps ADC
> Sicher ,das die Paralelle nur 1Mhz kann? Könnte mir gut > vorstellen, das das von Kontrollerkarte zu Kontrollerkarte > verschieden ist. Der Standard-Parallelport ist nach wie vor über den ISA-Bus angeschlossen (auch wenns den nur noch virtuell innerhalb irgendwelcher vielbeinigen ICs gibt) und der wird mit 8 MHz getaktet. Ein 8-Bit-I/O-Zugriff dauert mindestens vier Taktzyklen. Das ist aber vollkommen wurscht, selbst wenn der Parallelport auch "bit-banging" mit 10 MHz zulassen würde, würde es nicht funktionieren, weil übliche PC-Betriebssysteme einen Taskwechsel bestenfalls im Millisekundentakt zulassen und zum "Befummeln" der Hardware ein Taskwechsel erforderlich ist (Wechsel User Mode in Kernel Mode und zurück). Selbst bei Verwendung von Frickellösungen wie "giveio.sys", mit denen zwar die Taskwechsel umgangen werden, funktionierts nicht, da das Betriebssystem das für das "bit-banging" zuständige Programm des öfteren unterbricht. Nee, PC-Hardware ist für derartige Aufgaben gänzlich ungeeignet. Im übrigen werden Leerzeichen NACH und nicht VOR Satzzeichen geschrieben.
>Im übrigen werden Leerzeichen NACH und nicht VOR Satzzeichen >geschrieben. Richtig :-)
@Rufus t. Firefly Ich rede ja nicht von einem Normalem Betriebssystem mit Taskwechesln, sondern von einem Realtime - Betriebssystem ohne Taskwechseln. Wenn es hart auf hart kommen würde ,dann kähme für mich auch ein Mini OS in Betracht ,welches komplett für diesen Zweck geschrieben wird. Dazu gibt es tausende von Beispielen im Internet. Dieses Mini OS startet dann von einem USB Stick und schaltet in den Protected Modus. Von dort kann man dann munter mit x86 Assembler losprogrammieren. Ein Hello World hab ich auf diese weise schon hinbekommen. Ich bin mir auf jedenfall zu 100% sicher ,das IQR 's und Taskwechesel mit einer solchen Variante ausgeschloßen sind. Aber Hans Wilhelm hat ja angedeutet ,das es außer IRQ's und Taskwechel unterbrechungen von Höherer Ebene gibt(Wait States,Pipelines, Cachewechesl e.t.c). Gegen diese Unterbrechungen kann man halt softwaretechnich garnichts unternehmen. Es gibt Projekte ,da hat jemand auf diese Art und Weise die 1 Mhz Grenze locker geknackt. Aber ich möchte 10 Mhz (20 Millionen Samples / sek.). Wenn bei Paralellports wirklich nicht mehr als 1Mhz geht, villeicht gibt es auf einem Standard PC, noch andere Komponenten ,die man dazu mißbrauchen könnte. Der PCI Bus z.B. ist jedenfalls weit höher getacktet als der ISA Bus. Villeicht gibt es auch eine Versteckte Möglichkeit ,ähnlich wie beim Mikrokontroller direkt IO Ports auf einem PC Mainboard zu nutzen. Ich denke mal ,das hier das Hauptproblem ist ,eine schnelle IO Schnittstelle am PC zur Verfügung zu stellen. Kann man eigendlich auf dem IDE port Bit-Banging betreiben? Wie sieht es mit billigen TTL- IO Kontrollerkarten aus? Die gibt es auch als PCI Steckkarten und sind an keinen altlastigen Standard gebunden.
Der Ansatz ist Unsinn. Dafür ist die PC-Hard-und Software in KEINSTER Weise geeignet. Man braucht auf jeden Fall einen unabhängige Datenerfassung, also AD-Wandler + Mininalverarbeitung. Das ganze kannman dann üer eine halbwegs schnelle Schnittstelle (USB 2.0, PCI, Firewire, whatever) in den PC stopfen und verarbeiten. MfG Falk
Und ein 'Mini-OS' müßte man für sowas auch nicht schreiben. Dazu reicht DOS völlig aus, wenn man denn die Daten schnell genug durch die Hardware bekommt.
> Von dort kann man dann munter mit x86 Assembler losprogrammieren.
Das ist natürlich das Allheilmittel für alle Probleme, bei denen es auf
Geschwindigkeit ankommt, weil das ja klar ist.
Der Ansatz ist Unfug, wie Falk schon sehr richtig geschrieben hat.
Dann werde ich wohl eine wenig Arbeit inverstieren müßen das jetzt mal selber ausprobieren, villeicht klappt es ja doch irgendwie*g*. Ich hatte mir halt erhofft ,das mir jemand ein Projekt nennen könnte, bei dem es auf diese oder ähnliche Art und Weise funktioniert hat. Aus diesem Projekt (wenn es denn so eins gäbe), hätte ich mir dann ein paar Anreize nehmen können. Ok ,aber nochmals danke das Ihr mich darauf hingewiesen habt ,das meine Vorstellungen wohl eher in Richtung Wunschdenken gehen. Ich kann mir einfach nicht vorstellen ,das ein System ,welches mit über 3 Gigaherz getacktet ist, es nicht schafft im 20 Mhz Bereich harte Echtzeitanforderung gerecht zu werden. Das ist ein Verhältnis von ca. > 1:200 !!!! Ok ,wenn villeicht 500 Mhz auf diese Art und Weise zu Samplen sind , dann sieht jeder Blinde mit Krückstock das hier keiner harten Echtzeitanforderung gerecht werden kann.
@ Pascal (Gast) >Ich kann mir einfach nicht vorstellen ,das ein System ,welches mit über Liegt am Mangel von Fachwissen und Vorstellungskraft . . . >3 Gigaherz getacktet ist, es nicht schafft im 20 Mhz Bereich harte >Echtzeitanforderung gerecht zu werden. Das ist ein Verhältnis von Dafür ist es schlicht nicht gebaut. Stichwort Latenz. Die Latenzen in deinem PC sind ziemlich hoch, im Vergleich zu den 3 GHz Prozessortakt. Ein Kampfjet der MACH 2 schafft wird auch kein Formel 1 Rennen gewinnen, weil er dafür nicht gebaut ist. >ca. > 1:200 !!!! Ok ,wenn villeicht 500 Mhz auf diese Art und Weise zu >Samplen sind , dann sieht jeder Blinde mit Krückstock das hier keiner >harten Echtzeitanforderung gerecht werden kann. Man kann das Problm locker mit einem 50 MHz uC oder FPGA lösen, das dafür gedacht ist. Dicke GHz sind bei weitem nicht alles! MFG Falk
@Pascal: Bitte, bitte, gewöhne Dir das Plenken ab. Das tut ja weh!
Natürlich kann man einen PC als große 3GHz-Mikrocontrollerplatine benutzen. MSDOS war soweit ich weiß nirgends im Hintergrund in Betrieb, wenn man es nicht ausdrücklich wollte ( TSR terminate and stay resident hieß das), also würde das nicht dazwischenfunken. Ob das so sinnvoll ist ist eine andere Frage. FreeDOS vielleicht zweckmäßiger, das wird noch gepflegt und ist problemlos weiterzugeben, kennt auch eher Festplatten und CD/DVD-Laufwerke sowie z.B. Linux-Partitionen. Man könnte die Software von Diskette, USB-Stick oder CD booten. Timingprobleme sehe ich beim DRAM, für die Parallelschnittstelle sowieso. Die Chipsatzeinstellungen dürfte das BIOS komplett erledigt haben bevor DOS bootet, oder gibts da noch Spezialitäten, die erst Windows bedient?
@Falk Brunner Also ein 50 Mhz uC schafft das bestimmt nicht. Habe mir die Phillips LPC Reihe angeschaut und keiner von denen hätte das auch nur Ansatzweise geschafft.
Christoph, das ist zwar theoretisch richtig, aber bereits die PC-Hardwarearchitektur (Anbindung diverser Schnittstellen) ist für eine solche Aufgabe denkbar ungeeignet. Und Du willst nicht wirklich mit DOS-Programmen mit PCI-Karten kommunizieren, oder gar mit Firewire/Ethernet/USB ...
@ Pascal (Gast) >Also ein 50 Mhz uC schafft das bestimmt nicht. Habe mir die Phillips >LPC Reihe angeschaut und keiner von denen hätte das auch nur Ansatzweise >geschafft. Na wenn DU das mit deinem grossen Wissen und Erfahrungsschatz so sagst, muss es wohl stimmen. MfG Falk P.S. Wer Ironie findet darf sie behalten.
Jungs, seid nicht so mißmutig, jeder hat mal klein angefangen und dann aus Fehlern gelernt.
Wenn du den ADC komplett mit "Bitwackeln" steuern willst brauchst du ein vielfaches von 20 MHz, das kannst du sofort vergessen. Hohe Transferraten schafft der Parallelport nur mit EPP/ECP, aber auch da kommt man nicht so weit hinauf (DeLOCK PCI-Parallelport-Karten werden mit 2 MB/s beworben). Es hat schon einen Grund warum für sowas normalerweise FPGAs mit PCI/USB/Firewire verwendet werden. Mit $700 bist du dabei: http://www.ettus.com/custom.html
jaja - und takten ohne "ck" Es gab seinerzeit im "Funkamateur" eine Applikation mit einem mittlerweile steinalten CA3306(?) 6BitADC, welcher als Videograbber am Parallelport betrieben werden konnte. Evtl. kann man sich den Quelltext mal ansehen, war damals mit dabei, vielleicht geht da was... Gruß AxelR.
Ein 50-MHz-µC schafft das natürlich nicht, der hätte ja weniger als 3 Takte pro Sample zur Verfügung.
Beitrag "Geschwindigkeit der Druckerschnittstelle" hatte ich schonmal hier in anderem Zusammenhang erwähnt (ist allerdings schon etwas her;-)) 20Mhz sind da allerdings nicht drinn.
An @Löschbolzen, das: >>Im übrigen werden Leerzeichen NACH und nicht VOR Satzzeichen >>geschrieben. > >Richtig :-) ist jetzt aus dem Zusammenhang gerissen und damit von mir auch zum Löschen freigegeben.
Wärst du ordentlich eingeloggt, könntest du das jetzt selbst weglöschen und müßtest nicht nach der Kindergartentante rufen.
So ich habe gerade mit der Intel x86 RDTSC Instruction ein wenig herumgespielt und eine Schleife programiert ,die alle 50 Nanosekunden einmal durchlaufen wird. Die Schleife macht eigendlich nichts anderes, als die Ergebnise der RDTSC Instruktion mit <= Letztem Index zu prüfen. Wenn ja ,dann springt er in eine bestimmte Section und Incrementiert am Schluß den Letzten Index um einen festen Wert ,der abhängig vom CPU Takt die Samplerate einstellt. Wenn Nein ,dann wird die Schleife solange wiederholt, bis eben diese Bedingung eintrifft. http://en.wikipedia.org/wiki/RDTSC Ich habe allerdings zum Programmstart in ganz unterschiedlichen Abständen "Aussetzer", in denen der Counter vermutlich durch CPU Waitstates "überläuft" und aus dem gewünschten Rhythmus geworfen wird. Diese "Aussetzer" habe ich jedoch nur beim starten der Schleife und pendeln sich nach einer einer Zeit von etwa einer Hundertstel Sekunde ein. Vermutlich weil bis zu diesem Zeitpunkt alle Instruktionen im L2 Cache der CPU liegen und die Waitstates dadurch abnehmen. Glücklicher weise kommen diese Waitstates so selten vor, das sie keine großen negative Auswirkungen haben. Der 64 Bit Timestamp der in den Registern EDX und EAX liegt ist jedenfalls absolut(bis auf 1 Hz !!!) genau. Diesen könnte ich direkt als ArrayIndex(in Verbindung mit Modulo!!) benutzen. Dann habe ich bei einem Waitstate(der schätzungsweise einmal alle 10 Millionen Samples,wenn überhaupt vorkommt) an der zu samplenden Stelle lediglich einen falschen Wert. Der fällst statistisch gesehen nicht ins gewicht. Beim Samplen bin ich NOCH nicht. Ihr Erfahrt später wie es gelaufen ist. ABER: Mit dem Paralellort habt Ihr alle Recht. Der geht tatsächlich nicht über 1 Mhz. Hab ich gerade ausprobiert, es waren bei mir etwa 800 Khz drinn :-(. Damit habe ich die erste Hürde eigendlich beseitigt. Jetzt fehlt mir nur noch eine geignete Methode um ein schnelles Bitbanging zu realisieren. Dazu brauche ich eine IO Komponente ohne den Flaschenhals wie beim Paralellport. Den PCI Bus unter x86 Asm anzusteuern ist kein Problem. Werde mir wohl eine billige PCI TTL-IO Karte zulegen und damit weiterprobieren. Damit müßte jedenfalls schnelles Bitbanging möglich sein. (Ich benutze gerade ein FreeDOS, alle Routinen laufen mit abgeschaltetem Interrupt CLI)
Übrigens ist der TDA8714 kompletter Schrott. Den in den Griff zu kriegen ist selbst Profis nicht immer gelungen.
> Den PCI Bus unter x86 Asm anzusteuern ist kein Problem.
Doch, denn Du scheinst nicht verstanden zu haben, was ein Bus ist.
Du kannst allenfalls PCI-Devices ansteuern, aber das geht erst dann,
wenn die PCI-Devices initialisiert sind, wenn sie also im I/O- und
Speicheradressraum des Wirtsrechners auftauchen.
Da das eine Plug&Play-Geschichte ist, also mitnichten feststeht, daß
sich die Adressräume nicht ändern, müsstest Du in Deinem Assemblercode
die installierten PCI-Karten identifizieren und dann die jeweils
genutzten Adressbereiche bestimmen.
Und dann solltest Du Dich auch noch mit der Kommunikation mit dem
PCI-Bus beschäftigen - denn der lässt im Gegensatz zum ISA-Bus nicht ein
dauerhaftes Belegen durch den Prozessor zu, da das ein
Multiple-Master-Bus ist, der ein gewisses Eigenleben entwickelt.
Sowas ist nicht deterministisch und nicht sinnvoll.
Nimm einen schnellen µC, mache die primitiven Bitbanging-Geschichten in
Hardware (FPGA, per SPI an den µC anzuschließen), speichere das nötige
Geraffel zwischen und verbinde den µC über eine geeignete Schnittstelle
mit dem PC. Auf dem kann dann ein Programm laufen, um den ganzen Krempel
zu steuern, um irgendwelche Dinge anzuzeigen oder was auch immer zu tun.
Dazu kommt, daß Dein Prozessor zwar vielleicht in 50ns irgendwelche
Befehle durchführen kann, die aber liegen im Cache des Prozessors und
sehen noch lange kein "Land" in Form irgendwelcher externen Busse.
Auch ist die Busarchitektur von Desktopprozessoren auf eine möglichst
große Speicherbandbreite ausgerichtet, aber die wird nur mit
sequentiellen Speicherzugriffen gewisser Größe überhaupt erreicht (Laden
des Caches mit 64 Bit breitem Datenbus in ganzen Pages, meist à 4 kByte
etc.).
Einzelne aufeinanderfolgende I/O-Zugriffe sind viel langsamer. Und immer
noch viel langsamer als die 33 MHz Taktrate des PCI-Busses.
Was ich noch nicht verstanden habe: Willst Du geringe Latenzzeiten, a) damit du kene Samples verlierst oder b) muss das vom PC ausgerechnete Resultat latenzarm vorliegen, weil du z.B. damit was reaktonsschnell steuern willst Im Falle a) wie Hans Wilhelm schon schrieb, grosses SRAM mit ein bisschen Hardware oder FPGA und mit USB in den PC. Bei b) wirst du keine kürzere Gesamt-Latenz hinkriegen als die Rechenzeit des PC :-)
Bzgl. RDTSC Instruction: Bei modernen PCs, die z.B. aus Stromspargründen den CPU-Takt variieren sowie bei Multi-Core CPUs kann es hier zu Problemen kommen. Aus diesem Grund wird davon abgeraten dies z.B. für Multimedia-Anwendungen als Zeitreferenz zu nehmen.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.