Ich möchte Daten von einem AD2S90 mitlesen, der mit 2 MHz ausgelesen wird, so das das naheliegendste Board, I2C and SPI to UART Interface https://www.sparkfun.com/products/9981, zu langsam ist. Ein USB-Adapter kommt nicht in Frage, weil ich die Daten mit einer Auflösung von einer Millisekunde oder besser brauche. Welche SPI - RS-232 - Adapter bis 2 MBaud können die Experten hier empfehlen? Weil serielle Schnittstellen, zumindest die onboard, bis 4 MBaud verwendet werden können, sollte der Adapter möglichst auch 4 MBaud können. Daneben stellt sich auch die Frage welche Alternativen mit geringer Latzen (< 1 ms) es gibt. Wäre beispielsweise eine PCI-Karte wie die DMX-10 Low Cost PCIEx I2C/SPI/GPIO Interface Adapter, http://www.xdimax.com/pciex/dmx10.html geeignet?
Willst Du das an einem PC betreiben? Etwa noch mit Windows? Vergiss es. Richtige Echtzeitbetriebssysteme wie vxWorks oder QNX wären eher zielführend. fchk
Frank K. schrieb: > Willst Du das an einem PC betreiben? Ja. > Etwa noch mit Windows? Nein. Ich verwende einen Linux Realtime-Kernel (https://www.linutronix.de/index.php?page=echtzeit). Vielleicht reicht auch ein Lowlatency-Kernel, aber ich nehme erstmal einen RT-Kernel.
Hallo, wie viel kostet denn die DMX-10? Hast du da schon angefragt?
W. M. schrieb: > Hallo, > > wie viel kostet denn die DMX-10? > Hast du da schon angefragt? Nein, aber weil es eine "low-cost" Karte ist, sollte sie unter 1000 Euro kosten. Allerdings kann ich die wohl nur nutzen wenn die als COM-Port bzw. TTY ansprechbar ist, wie eine serielle Schnittstelle, denn da kann ich einfach Parameter wie Baudrate, Parität usw. setzen/auslesen, u. a. per stty, und per select() auf die Daten warten. Daher bräuchte ich neben dem Preis erstmal die Information wie man auf sie zugreifen kann. Aber ein Adapter nach RS-232 wäre mir lieber, denn dazu habe ich schon ein Logging-Programm.
Muss es denn ein PC sein? Ich denke, ein leistungsstärkeres Mikrocontrollerboard ohne Betriebssystem wäre einfacher, und Latenzen wären dort kein Problem. Wenn Du weißt, wie viele Kilobytes ein moderner x86-Prozessor bei einem Interrupt an Segmentcaches etc rein- und rausladen muss, und Dir auch bewusst ist, das ARM, MIPS und PPCs das nicht müssen, dann kannst Du vielleicht verstehen, warum ich hier etwas skeptisch bin. Und ein vergurkter Treiber im System ist für viele lange Nächte gut. fchk
Frank K. schrieb: > Muss es denn ein PC sein? Ja, denn ich habe hier einen RT-Kernel und ein gut funktionierendes Logging-Programm. Etwas mit einem Mikrokontroller müsste ich erst zusammenbasteln, progammieren, debuggen etc. und ich will eigentlich morgen losmessen und keine Bastel-Woche machen bevor ich losmessen kann. Zudem müsste ich den Kram erstmal bestellen und dann die Daten später auch auf einen PC transferieren, da ich die geloggten Daten ja nicht als Morse-Code einer blinkenden LED haben will sondern als Datei. Und Aufzeichnen über Monate muss auch ohne weiteres möglich sein, also gigabyte-große Logdateien. Auf dem PC ist das kein Problem.
:
Bearbeitet durch User
Update: Der Status der DMX-10 ist: "This product is not manufactured from a long time ago.". Anscheinend gibt es nichts mehr um SPI mit 2 MHz von einem PC einzulesen.
Rolf F. schrieb: > Weil serielle Schnittstellen, zumindest die onboard, bis 4 MBaud > verwendet werden können Die Onboard-Schnittstellen eines PCs kannst Du nicht meinen, die können maximal 115200 Baud. Vergiss', was irgendwelche "Terminalprogramme" o.ä. in ihren Dropdownlisten als Baudrate anzeigen, diese Listen werden nicht durch Abfrage beim Betriebssystem erstellt, sondern sind rein willkürlich zusammengestellte Listen von Baudratenkonstanten. Die 8250/16450/16550, die im PC als Onboard-Schnittstellenbaustein verwendet wird, erzeugt ihre Baudrate aus einem 1.8432-MHz-Takt. Mit einem Vorteiler von 16 (der bei UARTs implizit nötig ist) ergibt sich so das erwähnte Maximum von 115200 Baud. Und das ist völlig unabhängig vom verwendeten Betriebssystem, das ist Hardware.
Rufus Τ. Firefly schrieb: > Rolf F. schrieb: >> Weil serielle Schnittstellen, zumindest die onboard, bis 4 MBaud >> verwendet werden können > > Die Onboard-Schnittstellen eines PCs kannst Du nicht meinen, die können > maximal 115200 Baud. Nein, ich habe vor 10 Jahren mal einen MSP430 programmiert und den über eine serielle Schnittstelle angesprochen. Er war mit den maximalen 8 MHz getaktet, also relativ langsam. Die Kommunikation funktionierte bis 4 Mbaud, ohne Datenverlust aber nur bis 1,5 Mbaud. Da kam der MSP430 nicht mehr mit bei höheren Baudraten.
:
Bearbeitet durch User
Rolf F. schrieb: > Nein, ich habe vor 10 Jahren mal einen MSP430 programmiert und den über > eine serielle Schnittstelle angesprochen. Das kann keine normale Onboard-Schnittstelle eines PCs gewesen sein. Definitiv nicht. Das dürfte eine Schnittstelle auf irgendeiner Steckkarte gewesen sein.
Rufus Τ. Firefly schrieb: > Die Onboard-Schnittstellen eines PCs kannst Du nicht meinen, die können > maximal 115200 Baud Den PC muss man heute erstmal finden, der Onboard noch eine RS232-Schnittstelle hat. Solche Boards stehen inzwischen ziemlich wei oben auf der Roten Liste.
Nö, so kompliziert ist das gar nicht. Aktuelle Desktopboards von Gigabyte haben häufig immer noch eine -- nur nicht auf der ATX-I/O-Blende herausgeführt, sondern auf einer Stiftleiste, so daß man ein Kabel anschließen muss. Beispiele: GA-Z97-D3H http://www.gigabyte.de/products/product-page.aspx?pid=4961#ov GA-Z97X-UD7 TH http://www.gigabyte.de/products/product-page.aspx?pid=4995#ov GA-Q87M-D2H http://www.gigabyte.de/products/product-page.aspx?pid=4595#ov (mit zwei Schnittstellen auf Stiftleiste) Auch Kinderspielzeug hat so etwas: G1.Sniper A88X http://www.gigabyte.com/products/product-page.aspx?pid=4918#ov Und als Mini-ITX-Variante mit sogar zwei herausgeführten Schnittstellen auf der ATX-I/O-Blende: GA-J1900N-D3V http://www.gigabyte.com/products/product-page.aspx?pid=4918#ov
Must du die Daten ein "Echtzeit" verarbeiten oder reicht es zu wissen wenn genau die Daten entstanden sind, also jeden Datensatz noch mit einem Zeitstempel versehen?
Peter II schrieb: > Must du die Daten ein "Echtzeit" verarbeiten oder reicht es zu wissen > wenn genau die Daten entstanden sind, also jeden Datensatz noch mit > einem Zeitstempel versehen? Erstmal genügt es die Daten mit einem Zeitstempel zu bekommen.
Rolf F. schrieb: > Erstmal genügt es die Daten mit einem Zeitstempel zu bekommen. dann würde es mit externer Hardware mache. Jedem Messwert einen Zeitstempel geben und dann in alle ruhe zum PC übertragen. Dort ist man dann nicht mehr abhängig von Bus oder eine RT-Betriebssystem.
Nachtrag: auf einen aktuellen PC, kann meines Wissens auch eine RT-Betriebssystem nicht die Echtzeit garantieren, dann das Bios (DMI oder so) kann sich für eigene Dinge die CPU einfach eine Zeitlang nutzen.
Peter II schrieb: > Nachtrag: > > auf einen aktuellen PC, kann meines Wissens auch eine RT-Betriebssystem > nicht die Echtzeit garantieren, dann das Bios (DMI oder so) kann sich > für eigene Dinge die CPU einfach eine Zeitlang nutzen. Das ist bekannt und abstellbar: https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application#System_Management_Interrupt_.28SMI.29_on_Intel_x86_ICH_chipsets
:
Bearbeitet durch User
Und was haeltst du von einem Raspi mit Xenomai-Kernel? https://github.com/kinsamanka/PICnc-V2 und eine Abwandlung von mir hier: https://github.com/tinkercnc/spi-fpga-driver/tree/master/RaspberryPi Ist fuer LinuxCNC, aber mit ein "bisschen Basteln" muesste man es schon hinkriegen.
Rufus Τ. Firefly schrieb: > Rolf F. schrieb: >> Nein, ich habe vor 10 Jahren mal einen MSP430 programmiert und den über >> eine serielle Schnittstelle angesprochen. > > Das kann keine normale Onboard-Schnittstelle eines PCs gewesen sein. > Definitiv nicht. > > Das dürfte eine Schnittstelle auf irgendeiner Steckkarte gewesen sein. Dazu habe ich ein kurzes Skript gemacht, für das schon einfache User-Rechte reichen:
1 | #!/bin/bash
|
2 | |
3 | DEVICE=$1 |
4 | |
5 | OKRATE=0 |
6 | |
7 | for RATE in 50 75 110 134 150 200 300 600 1200 1800 2400 4800 9600 19200 38400 57600 115200 230400 460800 500000 576000 921600 1000000 1152000 1500000 2000000 2500000 3000000 3500000 4000000 |
8 | do
|
9 | stty $RATE -F /dev/$DEVICE |
10 | if [ $? -eq 0 ] |
11 | then
|
12 | OKRATE=$RATE |
13 | else
|
14 | break |
15 | fi |
16 | done
|
17 | |
18 | echo Highest possible rate: for device /dev/$DEVICE: $OKRATE |
Damit komme ich tatsächlich bei den onboard-Ports auf lächerlich langsame 115200 Baud, bei zwei billigen USB-RS-232-Adapter auf immerhin 3 Mbaud. Das Problem beim USB sind die großen Latenzen im Bereich von Millisekunden, so das man die 3 Mbaud nicht richtig nutzen kann.
Erwin Meyer schrieb: > Das Problem beim USB sind die großen Latenzen im Bereich von > Millisekunden, so das man die 3 Mbaud nicht richtig nutzen kann. das kommt ja wohl auf das Protokoll an. Wenn man große blöcke überträgt und die Bestätigung noch asynchron mach, dann kann man sie voll ausnutzen.
Na dann wandle doch nach Ethernet. Es gibt preiswerte RS232 nach Ethernet Wandler welche solche Baudraten locker verpacken. Dazwischen vielleicht UDP als Protokoll.
Ethernet schrieb: > Es gibt preiswerte RS232 nach Ethernet Wandler welche solche Baudraten > locker verpacken. er will es aber Millisekunden genau haben, und das wird bei Ethernet und Wandle auch nicht mehr möglich sein. Deswegen habe würde ich mit einen µC den Daten einen Zeitstempel verpassen und sie dann in Ruhe übertragen, dann kann man sich auch den Krampf mit dem RT-OS sparen.
Erwin Meyer schrieb: > Das Problem beim USB sind die großen Latenzen im Bereich von > Millisekunden, so das man die 3 Mbaud nicht richtig nutzen kann. Das ist ja wohl der Unsinn des Jahrhunderts. Wir sprechen von lächerlichen ~ 1,9 Mb/s. Möglich mit USB2.0 Highspeed. Damit gehen bis zu 60 Mb/s = 480 Mbit/s (brutto).
>Das Problem beim USB sind die großen Latenzen im Bereich von Millisekunden, so das man die 3 Mbaud nicht richtig nutzen kann. Die Latenzen kommen erst zum Zug wenn man sofort eine Antwort haben will, zum Beispiel fuer schnelle Controlloops. Wenn man einen schnellen Regler auf den PC auslagern moechte. Das ist sowieso eine schlechte Idee, denn der PC ist nicht fuer solche Dinge gebaut oder noch optimiert. Fuer Regelungen ist zB ein AVR bereits schneller, sofern man mit Integern klarkommt. Falls nicht, sollte man eine andere Hardwareloesung, zB einen DSP oder so verwenden
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.