mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik >10 MHZ Software Defined Radio mittels Standard PC möglich


Autor: Pascal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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*

Autor: swr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Pascal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans Wilhelm (hans-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pascal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der TDA8714 hat je nur 8 Bit "8-bit high-speed analog-to-digital 
converter"
http://www.nxp.com/#/pip/cb=[type=product,path=508...]
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/Signalumwandl...
Farnell Best.Nr.: 9968989 ADS5542IPAPG4 — TEXAS INSTRUMENTS

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=H...
LTC2208 - 16-Bit, 130Msps ADC
mit Upgrademöglichkeit auf LTC2209 - 16-Bit, 160Msps ADC

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Kommasetzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Im übrigen werden Leerzeichen NACH und nicht VOR Satzzeichen
>geschrieben.

Richtig :-)

Autor: Pascal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Pascal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Pascal: Bitte, bitte, gewöhne Dir das Plenken ab. Das tut ja weh!

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
währe und verlohren schreibt man ohne h

Autor: Pascal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jungs, seid nicht so mißmutig, jeder hat mal klein angefangen und dann 
aus Fehlern gelernt.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: AxelR. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein 50-MHz-µC schafft das natürlich nicht, der hätte ja weniger als 3 
Takte pro Sample zur Verfügung.

Autor: AxelR. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beitrag "Geschwindigkeit der Druckerschnittstelle"
hatte ich schonmal hier in anderem Zusammenhang erwähnt (ist allerdings 
schon etwas her;-)) 20Mhz sind da allerdings nicht drinn.

Autor: Kommasetzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wärst du ordentlich eingeloggt, könntest du das jetzt selbst weglöschen 
und müßtest nicht nach der Kindergartentante rufen.

Autor: Kommasetzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-), Ja

Autor: Pascal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigens ist der TDA8714 kompletter Schrott. Den in den Griff zu kriegen 
ist selbst Profis nicht immer gelungen.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.