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.
> 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.
@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
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.
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.
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.
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)
> 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.
