Hallo zusammen, folgende Teilaufgabe möchte ich derzeit lösen: Eine beliebige Anzahl von 16bit-ADCs sollen zeitlich synchron Signal"fetzen" ausgeben. Die Signalfetzen sollen bei 2ksps 2s lang sein, also werden pro Kanal 16bit 2ksps 2s = 8kByte benötigt. Im Sinne der "beliebigen" Anzahl an Kanälen soll das System modular aufgebaut werden, also vllt. sowas wie ein Steuermodul und dann Kanalmodule mit je 4, 6 oder 8 Kanälen, mal sehen, was draufgeht. Mein Gedanke war auch wegen der beliebigen Kanalanzahl, die Komplexität in die einzelnen Kanäle zu verlagern. Sprich 1 RAM zum Speichern der Signal"fetzen" und 1 ADC pro Kanal. Das Beschreiben der RAMs ist zeitlich unkritisch. Beim "Abspielen" sollen sie dann synchron sein. So, nun die Frage: Ich habe noch nie mit externen RAMs gearbeitet, habe aber schon gesehen, dass man das Interface entweder ziemlich separat in SW programmieren kann oder n bisschen tiefer in die Architektur des µC einzubetten, sodass sie in dessen Adressraum liegen. Das könnte z.B. die AT32UC3A-Serie von ATMEL Auszug aus Datenblatt: SDRAM / SRAM Compatible Memory Bus (16-bit Data and 24-bit Address Buses) Mit 24bit Adressbus hätte ich bei Verwendung eines 4k x 16bit RAM mit 12 Bit auch genug Überschuss, um eine hinreichend beliebige Anzahl an RAMs/Kanälen abzudecken. Für meine Anwendung wäre diese Einbettung ja nicht notwendig, da ich den RAM ja nicht als Arbeitsspeicher benötige oder sehe ich da was falsch? Ist es denn sinnvol, das dann zu machen oder lieber per SW selbst programmieren? Bei einem konventionellen RAM sind m. E. nach für das separate schreiben vom µC und synchrone Lesen in Richtung der jeweiligen DACs ein paar Puffer-ICs notwendig, um Buskonflikte zu vermeiden. Eine Alternative wäre die Verwendung von Dual-Port-RAMs. Hat da jemand Erfahrung? Hat jemand ne ganz andere Idee? Erzähle ich hier vllt. sowieso nur Blödsinn? Vielen Dank schon mal für eure Antworten! VG Robert
nen kleiner Tipp : nimm nen billig FPGA und pack da deine Gesammte Schaltung rein. z.B. EP3C5 bis EP3C25
Uwe schrieb: > Das Beschreiben der RAMs ist zeitlich unkritisch. Beim "Abspielen" > sollen sie dann synchron sein. Hallo, die Daten synchron zu den DACs zu befördern, kann sehr aufwendig werden, z.B. mit DMA-Kanal zu jedem DAC, aber man sollte vorher prüfen, ob das überhaupt notwendig ist. Selbst einfache DACs wie DAC0830 haben eine Doppelregisterstruktur, bei ausreichend Zeit kann daher der Prozessor über den Bus die Daten nacheinander in eine ganze Reihe von DACs schreiben, am Ausgang aktiv werden die neuen Daten erst mit einem (gemeinsamen) XFER-Puls. D.h. ich würde versuchen, ADCs, Speicher und DACs direkt im Speicherbereich eines geeigneten Prozessors unterzubringen, alles an einem gemeinsamen Adress/Daten-Bus. 20 Bit Adresse sollten schon reichen. So waren Prozessorsysteme schon im vorigen Jahrhundert strukturiert, aber deswegen ist das noch lange nicht veraltet. Gruss Reinhard
Bei dieser niedrigen Geschwindigkeit sollte eigentlich auch ein einfacher Atmega reichen - genügend Pins zur Steuerung des RAMs vorausgesetzt. Entscheidende Fragen sind wie Reinhard sagte, die geforderte Gleichzeitigkeit und auch das Interface zu den DAC. PS: Du schreibst mehrmals ADC in deinem Post, ich nehme an, das ist ein Tippfehler?
Hallo, noch zur Ergänzung: du kannst da ein RAM-IC 1Mx8 einsetzen, das kostet ein paar Euro und hat schon mal Platz für 128 Kanaldaten. Gruss Reinhard
Hallo zusammen, erstmal vielen Dank für eure Antworten und Anregungen. @Jan: Vollkommen korrekt. Das sind Tippfehler. Sorry dafür! Das System beinhaltet keine ADCs, lediglich DACs. Das System hat noch einige Komponenten um die beschriebene Problemstellung herum, für die mir ein Controller schon sinnvoll erscheint. Hauptsächlich User Interface und Kommunikation. Deswegen gefällt mir die FPGA-Lösung erstmal nicht so gut. Aber vllt. kann man mich noch überzeugen. Bin da allerdings auch total ahnungslos, was das angeht. Bzgl. der anderen Vorschläge: Wie gesagt, mein Gedanke war der, dass das ganze nicht mit zunehmender Kanalzahl kritisch wird. Zeitlich, wie auch speichertechnisch. Dass, die DACs erst "geladen" werden und dann per systemweitem DAC-Takt an den Ausgang übernommen werden, ist soweit klar, hatte ich mir auch so gedacht. Die DACs per DMA in die Controllerarchitektur einzubinden, klingt erstmal ganz gut, allerdings hat der oben zitierte Controller z.B. nur 15 DMA Kanäle. Das Sysstem soll zunächst mit 32 Kanälen aufgebaut werden, jedoch beliebig erweiterbar sein (ich denke mal 128 sollten reichen, mehr machen wohl keinen Sinn, ohne näher daruaf eingehen zu wollen, warum). Bzgl. des ATMEGA: Hmm... Wenn die Daten von vornherein schon ein 16-Bit-Struktur haben, ist es da der richtige Weg, von vornherein einen 8-Bit-Controller zu verwenden? Schon klar, ich muss nix rechnen oder so, von daher brauche ich keine "großen" Controller, aber ich könnte mir vorstellen, dass das beim Programmieren nur unnötig kompliziert werden würde. Energie-, Platz- oder thermische Probleme gibt es nicht. Haltet ihr meinen Vorschlag mit mehreren RAMs/DualPort-RAMs für nicht machbar oder nicht adäquat? VG Robert
Noch ne Überlegung zum Thema einen 1MB RAM Chip, statt viele kleine RAM-Chips: Nehmen wir mal an, der RAM ist per DMA an den Controller angebunden, die DACs parallel. Dann muss der Controller pro Kanal 2k mal in der Sekunde - 128 x 16Bit über DMA aus einem externen RAM holen, - diese über ein paralleles Interface an einen DAC zu schicken und - die Wörter per systemweiten DAC-Takt ausgeben Wie viele Takte braucht er dafür etwa (einen 16- oder 32-Bit Controller vorausgesetzt)? Ich denk mal, wenn man mal mit 16 Systemtaktzyklen rechnet, sind das nicht zu wenige oder? Das führt mich zu folgender überschlägigen Berechnung:
Klingt eigentlich in Ordnung. Wenn man das System vllt. mit 16 MHz betriebt, ist man auf der sicheren Seite denk ich. Voruasgesetzt, mit den 16 Taktzyklen bin ich nicht völlig daneben. Dann wäre das auf jeden Fall mal eine gangbare Möglichkeit, die auch die Kanalmodule ziemlich vereinfacht, weil sie keinen RAM benötigen. Was meint ihr? Hat das, was ich da gerechnet habe, was mit der Realität zu tun? VG Robert
Klingt soweit vernünftig, vielleicht zur Sicherheit eher 30 Takte einplanen. Allerdings musst du bei 128 DACs an einem Bus schon wieder mit Problemen wie Buslängen, Kapazitäten der I/O und so weiter rechnen. So teuer sind die Controller und RAMs ja nicht - warum nicht auf 32 Kanäle pro Controller beschränken und dafür noch ein wenig Code in die Kaskadierbarkeit dieser Module investieren. Entweder als serielle Kette per SPI oder auch SPI als multi-slave System mit einem zentralen Master. Die genaue Umsetzung hängt dann natürlich wieder von der geplanten Menge an Kanälen ab.
Naja, das wäre ja ein unidirektionaler Bus vom µC zum DAC und da ich auf diese Art ohne dedizierten RAM pro Kanal bestimmt 8 Kanäle in einem Modul unterkriegen würde, könnte ich das auf 16 Busteilnehmer reduzieren, wenn ich jedem Modul einen Treiber spendieren würde, oder? Weiß jemand zufällig oder noch besser hat schon Erfahrung, wie viele Eingänge welchen Typs so ein Controller, z.B. die AT32UC3A-Serie von ATMEL treiben kann? Habe auf die Schnelle im DB nichts gefunden. VG Robert
Robert B. schrieb: > Haltet ihr meinen Vorschlag mit mehreren RAMs/DualPort-RAMs für nicht > machbar oder nicht adäquat? Das kommt drauf an, ob du Geld zum Wegwerfen hast. Ein 1kx8 Dual-Port-RAM kostet etwa soviel wie ein 1M x 8 Static RAM, ist also pro Byte 1000mal so teuer. Deshalb werden auch kaum noch solche Bauteile hergestellt, bei den heutigen schnellen Prozessoren sind sie auch zu 99,9% überflüssig. Jeder Verkäufer will dir natürlich einen 16 oder besser 32bit-Prozessor einreden, aber was nützt dir bitte ein so breiter Datenbus, wenn der ADC byteweise organisierte Register hat?? Es gibt auch andere, aber jedenfalls muss man das im Zusammenhang betrachten. Es ist auch ein Unterschied, ob du x16 RAMs brauchst. Ein Hardwareentwurf mit x DMA-Kanälen in einem Prozessor hilft dir auch nicht weiter, weil die ja genausowenig gleichzeitig auf den Speicher zugreifen können. Wenn DMA was bringen soll, brauchst du für jeden Kanal völlig getrennte Hardware, oder du kannst es gleich bleiben lassen. Wenn natürlich dein Problem darin besteht, soviel Geld wie möglich unters Volk zu bringen, dann sag das gleich, dann machen wir keine Sparvorschläge mehr. Du könntest aber auch direkt einen Scheck schicken, geht schneller. Gruss Reinhard
Hallo Reinhard, danke für deine Antwort! Ich hoffe, du bist nicht so genervt, wie das jetzt klang. Ich war nur etwas verwundert, dass sich zu meinem initialen Vorschlag niemand geäußert hat, sondern ausschließlich Alternativvorschläge kamen. Ehrlichgesagt habe ich über den Kostenaspekt wirklich noch nicht nachgedacht, aber da ist natürlich was dran. Hat jemand ne Idee, wo ich was zum Fanout von Controllern finden kann. Ggf. auch, wie man sich das aus anderen Größen ableiten kann? Man könnte ja theoretisch Leitungswiderstände und Leitungs- und Eingangskapazitäten verrechnen, aber kann da vllt. jemand mit Erfahrungswerten weiterhelfen? Das ganze soll kein allzu sehr verteiltes System werden. Alles in einem 19"-Gehäuse wäre der Plan. VG Robert
Deine Angaben sind mir noch nicht klar. Was bedeutet "zeitlich synchron"? Geht es hier um ns oder 10µs? Dann, welche DACs sollen zum Einsatz kommen? Grob gesagt, würde ich einen Prozessor für ein paar Kanäle verwenden, der dafür die notwendigen Innereien schon mit bringt: beispielsweise acht Kanäle/µC und das zusammen auf eine Platine/Baugruppe. Bei 8KB/Kanal braucht er 64KB freies internes RAM und nur einen DMA-Kanal, der den burst-mode beherrscht. Die DACs liegen im externen Speicherbereich des µC an aufeinanderfolgenden Adressen (bei 16bit Busbreite). Die Kanal-Daten liegen verschachtelt im RAM, sodass die ersten acht 16bit-Werte den 1. Wert für Kanal 0, 1, 2,... liefern. Ein ext. DMA-request startet die Ausgabe eines "Fetzens". Da der Preis der 16bit-DACs wohl den Hauptanteil der Kosten ausmacht, würde ich beim µC nicht geizen. Mein Vorschlag wäre ein RX621 von Renesas. Andere hier werden Dir einen µC mit Cortex-M3 Kern empfehlen, wie z. B. den LCP178x, dessen DMA-Eigenarten ich aber nicht kenne. Robert B. schrieb: > Hat jemand ne Idee, wo ich was zum Fanout von Controllern finden kann. Im Datenblatt. Bustreiber (xx245 z. B.) erhöhen das fanout.
Robert B. schrieb: > Hat jemand ne Idee, wo ich was zum Fanout von Controllern finden kann. Technisch gesehen steht das im Datenblatt, aber ganz allgemein kann man sagen: auf dem Board sind keine Treiber wegen zu geringen Fanouts nötig, einen Board zu Board Bus sollte man aber über Treiber ansteuern. Abgesehen vom Fanout ergibt sich das auch aus der Struktur, wenn du z.B. 8 Leiterplatten direkt zusammenschaltest, hast du als Bus sehr lange und auch noch seitwärts verzweigte Leiterbahnen, die hi-speed-mässig kaum noch zu beherrschen sind. Bei Systemen mit 2..3 LP, die mit weniger als 10 MHz laufen und direkt benachbart gesteckt werden, verwende ich allerdings auch den Bus des Prozessors direkt. Aber bei deiner möglichen Systemgrösse wird das nicht mehr klappen. Gruss Reinhard PS Entschuldigung für den etwas genervten Ton, aber ich bin es gewohnt, als erstes Preise und Verfügbarkeit zu checken, dann scheiden nämlich viele Varianten ohne weiteres Nachdenken sofort aus. Ich habe z.B. gerade einen absolut idealen Magnet- und Neigungssensor für einen Kompass gefunden, der völlig abgeglichen geliefert wird, nur leider leider kostet das Stück 300 Euro und damit mehr als der Verbraucherendpreis des ganzen Geräts betragen darf.
Da du sowieso sequentiell auf deinen Speicher zugreifen möchtest, kannst du 12/13 I/O-Leitungen am µC sparen, indem du einen Zähler (z.B. im FPGA) für die Adressierung innerhalb der Kanäle verwendest.
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.