Hallo Für ein neues Projekt suche ich ein paar Anregungen für einen geeigneten Mikrocontroller. Ich bin nicht ganz neu auf dem Gebiet der Mikrocontroller. Ich habe auf dem XE167 von Infineon eine 3-phasige PWM für einen Asychronmotor programmiert. Und darauffolgend mit dem Anschluss des in der Maschine integrierten Drehgebers eine einfache Drehzahlregelung realisiert. Damals habe ich jedoch den Versuchsaufbau komplett vorgesetzt bekommen und musste "nur" programmieren. Für dieses neue Projekt, was den Aufbau eines komplexen Messsystems beinhaltet, beginne ich quasi bei null und stehe vor der Auswahl eines Mikrocontrollers. Ich habe ca. 24 analoge Messsignale die digitalisiert werden wollen, dabei wäre eine Abtastrate im Mikrosekundenbereich wünschenswert. Desweiteren soll noch ein Triggersignal an eine externe Messbox geführt werden, um die Messwertaufnahme zu synchronisieren. Die Messwerte sollen dann im PC ausgewertet werden. Über was sollte ich mir noch Gedanken machen um einen geeigneten Mikrocontroller aus der unendlichen Fülle zu finden? Wie sind die Grenzen für Taktrate, SRAM und Programmspeicher zu finden? Vielen Dank für eure Hilfe!
gelenkeharald schrieb: > Ich habe ca. 24 analoge Messsignale die digitalisiert werden wollen, > dabei wäre eine Abtastrate im Mikrosekundenbereich wünschenswert. > Desweiteren soll noch ein Triggersignal an eine externe Messbox geführt > werden, um die Messwertaufnahme zu synchronisieren. Die Messwerte sollen > dann im PC ausgewertet werden. Was brauchst du für Schnittstellen Wieviele Daten fallen an Welche Bandbreite müssen die Schnittstellen haben Latenzzeiten .... Quantifiziere das mal. Solange du von "wünschenswert" sprichst und nicht sagen kannst xxx ist die untere Grenze ist das rumgequatsche.
gelenkeharald schrieb: > Ich habe auf > dem XE167 von Infineon eine 3-phasige PWM für einen Asychronmotor > programmiert. War das die einzige Anwendung die Du je programmiert hast? Wenn ja, dann wird es etwas schwierig, ein 'eigenes' System auf die Beine zu stellen. Kannst Du nicht beim XE167 oder anderen Derivaten bleiben?
> Ich habe ca. 24 analoge Messsignale die digitalisiert werden wollen, > dabei wäre eine Abtastrate im Mikrosekundenbereich wünschenswert. > Desweiteren soll noch ein Triggersignal an eine externe Messbox geführt > werden, um die Messwertaufnahme zu synchronisieren. Das schreit nach 24 ADCs und einem Bussystem an dem diese 24 ADCs hängen. Abtastrate im µs-Bereich... Das wird lustig... sagen wir mal Du willst alle 5µs abtasten. Macht wenn ich mich nicht verrechnet habe 200kHz. Mal 24 Kanäle und 8 Bit Auflösung macht das ein Datenvolumen von 4,8 MEGAbyte pro Sekunde... Da freut sich der USB. Mal ganz davon abgesehen, daß Du auch schnelle ADCs brauchst, die 200.000 Wandlungen pro Sekunde schaffen.
Angehängte Dateien:
m.n. schrieb: > War das die einzige Anwendung die Du je programmiert hast? > Wenn ja, dann wird es etwas schwierig, ein 'eigenes' System auf die > Beine zu stellen. > > Kannst Du nicht beim XE167 oder anderen Derivaten bleiben? Programmiert habe ich schon einiges, darüber mach ich mir keine Sorgen. Mir gehts halt erstmal nur darum wie ich an die Planung eines eigenen Systems herangehe. Welche Firma ist mir dann auch egal. Ben _ schrieb: > Abtastrate im µs-Bereich... Das wird lustig... sagen wir mal Du willst > alle 5µs abtasten. Macht wenn ich mich nicht verrechnet habe 200kHz. Mal > 24 Kanäle und 8 Bit Auflösung macht das ein Datenvolumen von 4,8 > MEGAbyte pro Sekunde... Da freut sich der USB. Mal ganz davon abgesehen, > daß Du auch schnelle ADCs brauchst, die 200.000 Wandlungen pro Sekunde > schaffen. du hast dich nicht verrechnet ;-) 5µs sind auf jedenfall gut, ob das dann die USB Schnittstelle auch schafft muss man dann halt am laufenden System checken, ansonsten muss eben doch die Abtastrate verändert werden (dann wäre es für eine andere lösung eh zu spät...) Ben _ schrieb: > Das schreit nach 24 ADCs und einem Bussystem an dem diese 24 ADCs > hängen. Muss ich unbedingt ein Bussystem verwenden? Der Versuchssaufbau ist relativ klein ca 400x400x700 (Wege zwischen Sensoren nicht sonderlich groß). Ich wollte alle Signale direkt auf die Platine vom µ-Controller führen. Natürlich noch geeignete Schaltungstechnik davor usw. Und dann vom Board per USB Anschluss zum PC. Stell ich mir das zu einfach vor? Was ich noch nicht ganz geschnallt hab ist der Einfluss der Latenzzeit. So wie ich das verstanden habe ist das die Zeit, die eine ADU benötigt um das analoge Signal in ein digitales umzusetzen. Also muss die Latenzzeit kleiner als ein Abtastintervall sein. Natürlich so klein dass ich noch Zeit für ein paar Rechenschritte habe. Ist das richtig? Was sind denn so übliche Latenzzeiten von ADUs? ich habe hier http://www.infineon.com/dgdl/xe167x_ds_v2.1_2008_08.pdf?folderId=db3a3043156fd5730115b3a665650d23&fileId=db3a3043156fd5730116100ef1b41b52 ein rechenbeispiel gefunden, habe ich auch nochmal angehangen Beispiel A mit 10-Bit wäre dann bspw. schnell genug?
Na irgendwie mußt Du ja die 24 ADCs die Du für eine synchrone Wandlung brauchst an den µC drankriegen. Wenn Du das ohne Bussystem schaffst okay, aber das wird 'ne heiße Nummer. Okay, es wird auch mit Bussystem eine heiße Nummer. Damit Dir der Spaß am Basteln nicht vergeht: Wenn Du 4,8 Mbyte über einen 8 bit breiten parallenen Bus schicken willst muß dieser bereits mit 4,8 MHz Taktfrequenz laufen. Störungsfrei wäre schön! Ein serieller Bus braucht minimal das 8fache, eher das 9fache wegen dem Protokoll... 9x4,8 sind 43,2 MHz. Uups, das ist doch ganz schön viel für selber bauen. Alles vorausgesetzt für 8 Bit ADCs... bei 10 Bit Auflösung machts halt noch ein wenig mehr Spaß.
gelenkeharald schrieb: > Ich wollte alle Signale direkt auf die Platine vom µ-Controller > führen. Wie soll der eine bzw. die zwei ADCs vom µC das synchron hinkriegen? Das geht nur seriell > um die Messwertaufnahme zu synchronisieren. Sicher, dass das wirklich synchron sein muss? Wenn ja, dann kauf dir lieber was. Ich glaub das wird sonst hart, wenn man wenig Plan hat (so wie ich z. B.). :-)
Ben _ schrieb: > Na irgendwie mußt Du ja die 24 ADCs die Du für eine synchrone Wandlung > brauchst an den µC drankriegen. Wenn Du das ohne Bussystem schaffst > okay, aber das wird 'ne heiße Nummer. Okay, es wird auch mit Bussystem > eine heiße Nummer. > > Damit Dir der Spaß am Basteln nicht vergeht: > Wenn Du 4,8 Mbyte über einen 8 bit breiten parallenen Bus schicken > willst muß dieser bereits mit 4,8 MHz Taktfrequenz laufen. Störungsfrei > wäre schön! > > Ein serieller Bus braucht minimal das 8fache, eher das 9fache wegen dem > Protokoll... 9x4,8 sind 43,2 MHz. Uups, das ist doch ganz schön viel für > selber bauen. > > Alles vorausgesetzt für 8 Bit ADCs... bei 10 Bit Auflösung machts halt > noch ein wenig mehr Spaß. Andi Ü. schrieb: > Wie soll der eine bzw. die zwei ADCs vom µC das synchron hinkriegen? Das > geht nur seriell Ich brauch doch theoretisch "nur" die spannungsangepassten Signale (24 in der Zahl) an die 24 Pins der 24 ADUs anschließen. Die ADUs sind pheriphere Einheiten, d.h. einmal durch einen Interrupt angestoßen arbeiten sie selbstständig und parallel. Das heißt sie setzen alle gleichzeitig, das am jeweiligen Pin anliegende Signal digital um. Wozu brauch ich da noch einen seriellen Bus?
Hi, Die Frage mit der Synchronisierung ist in der Tat eine "wichtige" Frage. Ein absolute Synchronität in der Form das alle 5µs Zeitgleich 24MEsssignale gewandelt werden müssen ist in der Tat mit hoher Wahrscheinlichkeit nur mit externen Wandlern zu erreichen. Mit viel Glück könnte es höchstens noch eine "Spezielle" Exotenlösung untern den hier eher weniger bekannten "Industriecontrollern" geben die ich aber noch nie gesehen habe und die man selber ja erst einmal finden muss. (Oki, NEC usw... einige Infinium Serien mal abgrasen) Wenn es aber auch einfach darum geht "feste" Messinterwalle zu haben, es also durchaus in Frage kommt die Messung in 3-6 Gruppen zu Unterteilen, dann sieht es viel besser aus. Wobei der Abstand zwischen zwei Messungen einer Gruppe natürlich immer gleich ist und auch unter 5µs liegen kann. Dann würde ich mal einen Blick entweder über diverse ARM Derrivate oder aber über die 16Bit PICs von Microchip schweifen lassen. (MC hat keinen 32Bitter mit mehr als 16ADC/IO) Der dsPIC33EP256MU810 hat z.B. 32 ADC Channels, von denen er jeweils 4 Gleichzeitig Samplen kann. Bei 10Bit Auflösung mit 1,1MSP/s. Damit bist du bei einem Zyklus von unter 6µs, kannst allso Kanäle zusammen mit 183KSP/s erfassen. Nur halt das du Kanal 5-9 immer erst eine µs nach KAnal 1-4 bekommst. Ob das reicht musst du selbst entscheiden. Die datenmenge zum PC bringt der aber über die integrierte USB Schnittstelle spielend. Und wenn wegen der Einsatzumgebung CAN sinnvoller erscheint, da hat er auch noch zwei Ports von. Gibt aber von Microchip noch einige mehr, hatte diesen nur gerade im Kopf. Bei den ARM musst du selber mal alles durchschauen, die gibt es von den verschiedensten HErstellern. Microchip hat aber den Vorteil das die HArdwaretools sehr günstig sind, (ab 30Euro geht es mit DEBUGFÄHIGEN Programmern los) und selbst wenn man dann statt der kostenlosen doch die etwas besser optimierende Compilerversion einsetzen will diese auch noch "Aus der Portokasse" zu bezahlen ist. Zudem kommt alles, incl Codebeispiele und gutem Support, aus einer HAnd. Bei den ARM gibt es entweder nur OpenSource sw mit teilweise recht umfangreich zu konfigurierbaren Toolchains udn verschiedenster freier HArdware zum NAchbauen oder günstig kaufen, -funktioniert, oder auch nicht- oder aber super geeignete IDEs fürs Kommerzielle Umfeld mit Professionellen Debug Tools, wobei das "Super" auch jeweils für den Preis dieser Hilfsmittel gilt. Und das nicht im "positiven" Sinn des Anwenders... Und wie schon erwähnt: Es gibt noch eine Menge anderer µC HErsteller, vielleicht hat da ja jemand noch einen "heißen" Tip für einen mit 24 "echten" ADCs Gruß Carsten
Hi, gelenkeharald schrieb: > Ich brauch doch theoretisch "nur" die spannungsangepassten Signale (24 > in der Zahl) an die 24 Pins der 24 ADUs anschließen. Die ADUs sind > pheriphere Einheiten, d.h. einmal durch einen Interrupt angestoßen > arbeiten sie selbstständig und parallel. Das heißt sie setzen alle > gleichzeitig, das am jeweiligen Pin anliegende Signal digital um. Wozu > brauch ich da noch einen seriellen Bus? Ich glaube da unterliegst du einem -nicht seltenen- Irrtum. Wie oben in meinem Beitrag schon angedeutet haben die µCs zwar teilweise weit über 20 AD-In, aber dahinter stecken keine 20+ Wandler. Oft hat so ein µC nur einen oder zwei Wandler, wenns umfangreich wird auch mal drei oder vier. Aber alles darüber hinaus findest du nur noch bei Exoten. Es ist so, das sich hinter diesen 20+ Pin nur ein Multiplexernetzwerk befindet, das all diese Eingänge auf ein und dasselbe Modul leitet. Du kannst also mit einem Modul problemlos 32 Signale wandlen, aber immer nur eines auf einmal. Bei zwei Modulen halt "zwei" auf einmal. -usw- Gruß Carsten
Wieviel darf das ganze den kosten? Ich denke einfacher wird das mit externen AD Wandlern, die könnte man dann auch alle zeitgleich anstoßen, und wenn es noch schneller sein muss, nimmt man flash wandler, dann wären auch 1µs kein Problem. Kann dann aber auch durchaus 5 Euro pro Wandler kosten. Außerdem braucht man trotzdem noch einen Controller, der das ganze schnell genug ausliest und weiter schickt. Da denke ich bräuchte man schon was oberhalb von 20 MHz, am besten mit direkter USB Unterstützung.
Carsten Sch. schrieb: > Ich glaube da unterliegst du einem -nicht seltenen- Irrtum. > > Wie oben in meinem Beitrag schon angedeutet haben die µCs zwar teilweise > weit über 20 AD-In, aber dahinter stecken keine 20+ Wandler. Oft hat so > ein µC nur einen oder zwei Wandler, wenns umfangreich wird auch mal drei > oder vier. Aber alles darüber hinaus findest du nur noch bei Exoten. > > Es ist so, das sich hinter diesen 20+ Pin nur ein Multiplexernetzwerk > befindet, das all diese Eingänge auf ein und dasselbe Modul leitet. > Du kannst also mit einem Modul problemlos 32 Signale wandlen, aber immer > nur eines auf einmal. Bei zwei Modulen halt "zwei" auf einmal. -usw- > > Gruß > Carsten Jetzt wo du mir das so erklärst klingt das natürlich voll und ganz logisch. Danke dafür:-) Die Sache ist die, dass es für die Messung von essentieller Wichtigkeit ist, dass wirklich alle Werte synchron aufgenommen werden. (Nebenbei, es sollen Mikrobürstenfeuer an Schleifringen untersucht werden, es handelt sich also um hochdynamische Vorgänge). Ich werde jetzt mal deine Tipps vom vorhergehenden Beitrag durchgehen, vielleicht finde ich einen µC mit 24 echten ADCs Mir fällt gerade noch ein, was haltet ihr von dieser Idee ADCs wird es doch sicher auch als einzelne ICs geben, wenn ich mir ein Board baue welches explizit 24 von diesen ICs aufweist und diese über I/O-Ports an den µC anschließe? Bleibt nur wieder die Frage, ob ein µC 24 parallele Eingänge hat...sonst würde ja das Problem auftreten was Ben _ geschildert hat oder?
Verwirrter Anfänger schrieb: > Wieviel darf das ganze den kosten? > Ich denke einfacher wird das mit externen AD Wandlern, die könnte man > dann auch alle zeitgleich anstoßen, und wenn es noch schneller sein > muss, nimmt man flash wandler, dann wären auch 1µs kein Problem. Kann > dann aber auch durchaus 5 Euro pro Wandler kosten. > Außerdem braucht man trotzdem noch einen Controller, der das ganze > schnell genug ausliest und weiter schickt. Da denke ich bräuchte man > schon was oberhalb von 20 MHz, am besten mit direkter USB Unterstützung. sry hab dein beitrag jetzt erst gelesen also Geld ist in diesem Fall zweitranging ;-)
Kann es sein, dass nicht ein AD-Wandler benötigt wird, sondern nur eine fest definierte Spannung als Trigger benutzt werden muss. In diesem Fall kann man an jedem Eingang ein Operationsverstärker setzten, dessen Vergleichspannung mit einem Spannungsteiler definiert wird. Ein ATMega32 könnte die 24 Pins pollen und mit UART zum Rechner die Events senden. Falls dem nicht so ist, sollte gelenkeharald mal genauer die Aufgabe beschreiben. Vielleicht liegt in der Aufgabenstellung das Problem. Also für was benötigst du die Schaltung? Was soll mit den Messwerten passieren. Ist es eine Steuerung von einer komplexen Maschine oder sollen Messdaten visualisiert werden? usw.
Hmm... Wozu die Schaltung benötigt wird ist nun klarer.
gelenkeharald schrieb: > sry hab dein beitrag jetzt erst gelesen > also Geld ist in diesem Fall zweitranging ;-) Bei deinem Hardware Kenntnisstand würde ich mal schauen was es da an fertigen Messsystemen oder Messkarten für den PC gibt. Weder 200kHz Signale sauber zu messen noch 24 Signale parallel zu verarbeiten und dann in Echtzeit an den PC zu senden sind nicht mehr ganz trivial.
Und wie lange soll gemessen werden? Wenn es nur um relativ kurze Zeiten (im Sekundenbereich) geht könnte man die Daten zwischenspeichern und dann langsamer an den Computer senden.
Hi, gelenkeharald schrieb: > Mir fällt gerade noch ein, was haltet ihr von dieser Idee > ADCs wird es doch sicher auch als einzelne ICs geben, wenn ich mir ein > Board baue welches explizit 24 von diesen ICs aufweist und diese über > I/O-Ports an den µC anschließe? Bleibt nur wieder die Frage, ob ein µC > 24 parallele Eingänge hat...sonst würde ja das Problem auftreten was Ben > _ geschildert hat oder? Natürlich gibt es ADCs als Einzelbausteine ;-) Lange Zeit war es der Einzige Weg um AD Wandler in sein µC System zu implementieren und auch bei hochspeziellen Anforderungen (Auflösung, Zeit/Geschwindigkeit, oder Genauigkeit) ist es auch heute noch der einzige Weg. Externe AD Wandler gibt es von ein paar Cent für 8Bit/100KSP Wandler aufwärts, über 1-2 Euro für 10Bit Wandler bis hin zu fast unbezahlbar wenn man 16Bit Aufwärts und sehr viel schneller als Schnell braucht. Es gibt auch Bausteine mit mehr als einem Wandler. Wobei man dann darauf achten muss ob der Baustein wirklich 2 Wandler, oder nur zwei umschaltbare Eingänge hat. Nach der Wandlung spielt die hochgenaue Parallelität ja nun nicht mehr wirklich die Rolle. Du musst nur dafür sorgen das du alle Messergebnisse vor der nächsten Wandlung "wegbekommen" hast. Ohne Einsteckkarte mit direktem Transfer auf den PCI bus würdest du eh niemals 24Messergebnisse direkt in den PC bekommen, das geht nur nacheinander... für den Kontakt zwischen µC und den Wandlern hast du zwei Möglichkeiten. Entweder nimmst du Wandler mit Parallelbus und Fragst die nacheinander ab, oder aber du nimmst (heute Üblicher) Wandler mit seriellem Bus. Bei Wnadler mit Seriellem BUS hast du wieder die Möglichkeit zwischen Paralleler Abfrage oder Serieller Abfrage zu wählen. Die "gängige" Methode währe es die Wandler alle Parallel z.B. an den SPI Bus zu hängen und dann mit einer hohen SPI_CLK Geschwindigkeit die Daten nacheinander auslesen. Die CS des Wandlers hängt natürlich für jeden Wandler an seinem eigenen Portpin. Das muss so schnell sein das man alle 24Ergebnisse vor der nächsten Wandlung eingelesen hat. (der Wandler muss das natürlich auch können) Als erste Idee würde ich das jetzt vielleicht etwas Trickreicher angehen: (Vorsicht, das ist ein Schnellschuss, nur 2minuten Nachgedacht, nicht verifiziert!) ICh würde einen "schnellen" µC mit USB nehmen, PIC32 wahrscheinlich. Evtl. geht aber sogar noch ein "kleiner" Pic18F4550, müsste man schauen. Als Wandler 24Gleiche Einfachwandler mit SPI. Die HArdware SPI des µC würde ich Links liegen lassen und eine "besondere" Soft-SPI routine schreiben: Es gibt EINEN Clk. Ausgang der an alle Wandler parallel geht. Es gibt EINEN Daten_Out, der an alle Wandler Parallel geht. Es gibt aber 24Daten_IN, jeder wadnler hat seinen Eigenen. (Evtl. gibt es noch einen Trigger für alle Parallel zum Anstossen der Messung) Die Wandler erwarten ja alle dieselben Komandos. Die gebe ich allen Gleichzeitig. Beim Auslesen werden dann ab einem bestimmten Punkt die Wandeldaten für jeden Wandler einzeln kommen. Die schiebe ich einach für jeden Pin/Wandler dann in eine Einzelne Variable (Wandler1-Wandler24). NAchdem ich dann alles Eingelesen habe kopiere ich die Variable Zusammen in den USB Ausgangsbuffer und Weg damit! Da aber im Extremfall das Device nur einmal alle 1ms seine USB Daten los wird hat man natürlich auf dem Übertragungsweg µC Rechner eine Verzögerung, überträgt die Daten mehrerer Messungen Gleichzeitig. Aber für eine Visiualisierung ist eine Latenz von 1ms ja egal, da man die Daten ja mit einem "Zeitstempel" versehen kann... Aber wie gesagt, das ist nur eine schnelle Idee. Bei einem 32Bit µC, oder aber einem 16Bit DsPic hätte man dabeit wenn möglich sogar noch die Zeit eine rudimentäte Aufbereitung/Auswertung der Daten schon im µC vorzunehmen! Gruß Carsten
P.S: Ob das oben geannte oder anderes für deine MEssanforderungen überhaupt funktionieren, das musst du aber selbst herausfinden. Zu dem Einsatzzweck kann ICH dir zumindest nichts genaues sagen, auch wenn das anderen da anscheinend anders geht. Bin halt "Schwachströmer" (NAchrichtentechniker) und habe daher mit Motoren und deren Verhalten naturgemäß eher wenig zu tun, zumindest nicht in der Tiefe das ich mir jemals über "Mikrobürstenfeuer" gedanken gemacht hätte ;-) (Ich weiß das es Funkenbildung an Bürsten/Kohen gibt, das dies "ungewollt" ist und auch das es bei verbrauchten Schleifern stärker ausgeprägt ist, aber das war es dann schon) Gruß Carsten
vielen vielen dank für euer feedback ich werd das alles mal in ruhe verdauen und mich nochmal melden sobald ich wieder ein problem habe :-)
Der STM32Fxxx hat 3 12-Bit AD-Wandler drin, die auf bis zu 24 IO-Kanäle gelegt werden können. Schaue Dir mal das Datenblatt näher an. Hier der Artikel: STM32
Carsten Sch. hat schon mal einen möglichen Zugang skizziert. Trivial ist das Problem aber nicht. Vor allem nicht vergessen: SPI hat fast immer einen bestimmten Overhead - z.B. zusätzliche Befehlsbytes, die dem ADC sagen, ob nun die Digitalisierung gestartet werden soll etc. Kannst also sicherheitshalbe annehmen, dass die Erfassung eines einzelnen 8-bit-Wertes mehrere Bytes an Datentransfer benötigt. Sagen wir einmal 4 Bytes total. Um dann z.B. 200 kHz Abtastrate zu erreichen, muesste man den Bus schon mal mit 0.2 MHz 4 Bytes 8 Bits/Byte = 6.4 MHz laufen lassen. Dazu kommt dann noch Overhead für Chip enable ein/aus, Daten ins Ram transferieren usw. Da muss der uC (und der SPI-Bus) schon ordentlich schnell laufen, um das zu bewältigen. Meiner Einschätzung mit einem 16- oder 32-Bitter aber noch machbar. Zum Thema USB, die Leute lassen sich immer von den spezifizierten MAXIMAL-Datenraten blenden. Bei USB gibt's aber keine Garantie, dass man diese Raten auch nur annäheren erreicht: Wenn mehrere Geräte am Bus hängen, teilen die sich die Bandbreite. Wenn der PC die Daten nicht schnell genug abholt weil er anderweitig beschäftigt ist, sinkt die effektive Datenrate. Usw usf. Je nach USB-Gerät ist die Datenrate auch viel geringer als das Maximum (HID z.B. kann bloss max. 64 kB/sec). Ausserdem ist bis USB2 der Bus gepollt, ein Gerät bekommt also u.U. (abhängig vom Übertragungsmodus) bloss einmal pro msec (oder seltener) die Chance, ein Datenpaket abzusetzen. Insgesamt ist also das Ansinnen, die Daten mit mehreren MByte/sec in Echtzeit zu übertragen, sehr sportlich. Machbar (siehe z.B. den Saleae-Logikanalysator), aber nix für Anfänger oder mäßig Fortgeschrittene. Viel besser wäre es daher, die Daten zwischenzuspeichern und dann nach Abschluß der Erfassung ohne Zeitdruck zu übertragen. Wolfgang
Hab nicht alles gelesen, aber an Stelle von synchroner Wandlung mit vielen externen A/Ds kann man auch synchron sampeln (S&H) und nacheinander wandeln.
Wäre es für dich nicht besser eine verteilte Applikation zu basteln? Evtl. nimmst du dir 24 kleine Controller die lokale Intelligenz besitzen und die AD-Wandlung vornehmen und den (einen) Großen Bruder nur im Bedarfsfall informieren ? Kommt ja ganz auf deine Anforderungen an! Gruß, THaala
Zum Update des Themas. Nach längerer Überlegung habe ich mich jetzt auf 8 Bit AD-Wandler und einer Abtastrate um die 50µs(!) festgelegt. Die Idee mit dem SPI-Bus zur Anbindung der 24 ADCs finde ich gut. Da jedoch bei 24 ADCs an einem Bus die Taktrate relativ hoch sein muss, ist mir noch was anderes eingefallen. Viele µ-Controller haben ja mehrere SPI-Module, man könnte doch dann bspw. an drei SPI-Busse jeweils 8 Kanäle/ADCs anschließen. Für dieses Beispiel würde sich jetzt ergeben: Datenaufkommen an einem ADC: 16kbit/s 20kByte/s Datenaufkommen aller Kanäle: 480kByte/s pro Bus wären das dann: 160kByte/s demnach müsste die taktfrequenz eines busses mindestens 1,2Mhz betragen praktisch ja noch mehr wegen overhead usw. (also vielleicht 3Mhz?) ist die ganze struktur sinnvoll? mit welcher tasächlichen taktfrequenz sollte ich den bus am besten betreiben? ab wann müsste ich dann auf die leiterlängen aufpassen (hf-design...)? vielen dank
gelenkeharald schrieb: > pro Bus wären das dann: 160kByte/s > demnach müsste die taktfrequenz eines busses mindestens 1,2Mhz betragen Das kann ich nicht nachvollziehen, die Rechnung ist ja wohl recht willkürlich :-) gelenkeharald schrieb: > Datenaufkommen aller Kanäle: 480kByte/s Du solltest Dir einen Prozessor aussuchen, der diese Datenmenge überhaupt verarbeiten kann. Simuliere doch einmal Deine Verarbeitungsroutinen auf einem Intel-ATOM, ob der das überhaupt schafft.
Hi, gelenkeharald schrieb: > Zum Update des Themas. Nach längerer Überlegung habe ich mich jetzt auf > 8 Bit AD-Wandler und einer Abtastrate um die 50µs(!) festgelegt. OK, das reduziert die zu übertragenen Datenraten erheblich... Damit kommen drei der vier Übertragungsarten in Frage. Musst halt aussuchen ob dir eine garantierte MAximallatenz oder aber eine Fehlerkorrektur wichtiger ist. gelenkeharald schrieb: > Die Idee mit dem SPI-Bus zur Anbindung der 24 ADCs finde ich gut. Da > jedoch bei 24 ADCs an einem Bus die Taktrate relativ hoch sein muss, ist > mir noch was anderes eingefallen. Nunja, müsste man schauen was "relativ hoch" bedeutet. Es gibt Bausteine die einen SPI Bus mit 20MHz schaffen. Allerdings müssen das natürlich beide seiten können, also µC und die AD Wandler. gelenkeharald schrieb: > Viele µ-Controller haben ja mehrere SPI-Module, man könnte doch dann > bspw. an drei SPI-Busse jeweils 8 Kanäle/ADCs anschließen. Hier musst du wieder aufpassen. Es gibt Controller mit mehreren SPI Modulen, aber auch welche die nur EIN SPI modul haben und die I/Os Multiplexen... Die verteilung auf drei SPI Module, sofern es eigenständige Module sind, KÖNNTE eine Minimale Geschwindigskeiterhöhung bedeuten, aber auch ein Ausbremsen. Das kommt ganz auf dein Programm an. Auf jeden Fall ist so etwas deutlich schwieriger Effizient zu Programmieren als nur ein Modul. An dieser Stelle würde ich jetzt noch einmal meinen Vorschlag weiter oben ins Spiel bringen: Carsten Sch. schrieb: > Als Wandler 24Gleiche Einfachwandler mit SPI. > Die HArdware SPI des µC würde ich Links liegen lassen und eine > "besondere" Soft-SPI routine schreiben: > Es gibt EINEN Clk. Ausgang der an alle Wandler parallel geht. Es gibt > EINEN Daten_Out, der an alle Wandler Parallel geht. > Es gibt aber 24Daten_IN, jeder wadnler hat seinen Eigenen. > (Evtl. gibt es noch einen Trigger für alle Parallel zum Anstossen der > Messung) > Die Wandler erwarten ja alle dieselben Komandos. Die gebe ich allen > Gleichzeitig. Beim Auslesen werden dann ab einem bestimmten Punkt die > Wandeldaten für jeden Wandler einzeln kommen. Die schiebe ich einach für > jeden Pin/Wandler dann in eine Einzelne Variable (Wandler1-Wandler24). > NAchdem ich dann alles Eingelesen habe kopiere ich die Variable Zusammen > in den USB Ausgangsbuffer und Weg damit! Wenn du hohe Taktfrequenzen vermeiden willst würde ich so vorgehen. Daher: Entweder ALLES PARALELL, oder aber ALLES SERIELL. Dieses von dir vorgeschlagene Mischverfahren bringt meiner Ansicht nach mehr Nachteile als Vorteile. gelenkeharald schrieb: > ab wann müsste ich dann auf die leiterlängen aufpassen (hf-design...)? > vielen dank Also von diesem Punkt bist du noch SEHR WEIT ENTFERNT. Einstellige MHz Zahlen sind doch im grunde nur etwas nervöser Gleichstrom... gelenkeharald schrieb: > vielen dank Keine Ursache ;-) Willi schrieb: > gelenkeharald schrieb: >> Datenaufkommen aller Kanäle: 480kByte/s > > Du solltest Dir einen Prozessor aussuchen, der diese Datenmenge > überhaupt verarbeiten kann. Simuliere doch einmal Deine > Verarbeitungsroutinen auf einem Intel-ATOM, ob der das überhaupt > schafft. Das ist jetzt nicht dein Ernst, oder? 480kBaud - Das schafft doch noch jeder heute übliche 8Bitter ohne sich anzustrengen... Bei einem IntelAtom würde das noch nicht einmal eine änderung der angezeigten Prozessorauslastung bewirken! Gruß Carsten
Carsten Sch. schrieb: > 480kBaud Das ist jetzt nicht Dein Ernst, oder? 480kB/s mit 480kBd zu übertragen bräuchte ein sehr gutes Kompressionsverfahren. Aber ich sehe gerade, dass die Daten extern auf einem PC ausgewertet werden sollen. Da wird wohl dann mehr als ein ATOM drin stecken :-)
so jetzt hab ich mich hier auch mal angemeldet ;-) ich war hier schon so oft unterwegs und jetzt wurde es endlich mal zeit Carsten Sch. schrieb: > OK, das reduziert die zu übertragenen Datenraten erheblich... > Damit kommen drei der vier Übertragungsarten in Frage. Musst halt > aussuchen ob dir eine garantierte MAximallatenz oder aber eine > Fehlerkorrektur wichtiger ist. insgesamt ist mir eine Fehlerkorrektur wichtiger ich hab dein (Carsten Sch.) vorschlag jetzt so verstanden, dass alles über die I/O ports läuft mit CLK: 1 pin MOSI: 1 pin MISO: 24 pin SS: 1 pin Trigger (zum Anstoßen der Messung): 1 pin macht 28 gesamt Das würde bedeuten, dass erst alle ADC durch den Trigger angestoßen werden zur Messung. Danach aktiviere ich SS, damit die Slaves im Takt von CLK die Daten an den µ-Controller schicken. Das geschieht parallel da ich ja 24 MISO Leitungen zum Controller habe. Mhh cool, das würde ja relativ flott gehen (Achtung Erkenntnis^^) Damit könnte CLK auch mit geringerer Taktfrequenz laufen oder aber das ganze System, mit einer höheren Abtastfrequenz. Ich glaub so mach ichs. Muss ich mich jetzt "nur" noch auf ADC und µ-Controller festlegen... Das ganze wäre also dann keine "übliche" Struktur, wie Kaskade oder Stern, wie man sie im Wikipediaartikel zu SPI finden kann. Grüße GH
Angehängte Dateien:
-
idee.png
85 KB
also insgesamt so wie im bild (trigger hab ich jetzt einfach mal weggelassen, würde wenn dann eh so aussehen wie clock, mosi oder ss)
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.