Hi, ich bin auf der Suche nach einem mikrocontroller, FPGA oder arduino mit ADC\DAC. Ich möchte einige analoge Schaltungen digitalisieren und neuen Funktionen hinzufügen. Es kann auch sein, dass ich für die verschiedenen Funktionen verschiedenen boards brauche. Es muss also nicht alles mit einem Board realisiert werden aber es wäre schon schön. Aufgabe 1: Ich habe zwei analoge Signale. Das eine wird in Abhängigkeite von der anderen verändert. Dabei muss das Timing unbedingt gleichbleiben. Also es sollte keine Verzögerung entstehen. Das liegt daran, dass es noch ein drittes Signal gibt welches synchron mit dem zu veränderden Signal ist. Die geschwindigkeit der adc und dac muss nicht so groß sein. 100ksps sollte ausreichen. Allerdings überlege ich ob ich zusätzlich eine Mittelung machen soll um das Rauschen zu minimieren. Aufgabe 2: Ich möchte einen PID Regler für einen Galvo motor digitalisieren. Da sich der Hebel des Motors manchmal ändert muss man die konstanten anpassen. Ist eine automatische optimierung der PID konstanten möglich. Als erstes dachte ich an den arduino due weil er bereits DAC hat und mehr power wie die normalen. aber wegen der synchronisation dachte ich an einen FPGA.Oder halt einen anderen mikrocontroller. Wäre über Vorschläge dankbar. Und guten Rutsch ;)
J. E. schrieb: > Ich habe zwei analoge Signale. Das eine wird in Abhängigkeite > von der anderen verändert. Dabei muss das Timing unbedingt > gleichbleiben. Also es sollte keine Verzögerung entstehen. (...) >Die geschwindigkeit der adc und dac muss nicht > so groß sein. 100ksps sollte ausreichen. Denke darüber nochmal nach. Tipp: 100ksps = 0.01ms (x2)
erstmal danke für die Antwort. Aber ich verstehen sie nicht :-D :-D was (...) bedeutet ist mir schleierhaft. Ich dachte ich hätte es recht eindeutig beschrieben. und 100ksps = 0,01ms ist mir auch klar. Hätte ich das noch extra dazuschreiben müssen? oder meinst du, dass ich das nicht für schnell halte? ich kenne adc die Gsps machen.... Es wäre super wenn du deine Antwort ein wenig ausführlicher schreiben könntest denn im Moment kapier ich die gar nichts. Danke
J. E. schrieb: > Ich habe zwei analoge Signale. Das eine wird in Abhängigkeite > von der anderen verändert. Dabei muss das Timing unbedingt > gleichbleiben. Also es sollte keine Verzögerung entstehen. Es soll also keine Verzögerung geben. Andererseits ist dir offenbar bewusst, dass in der digitalen Variante min. 0.02ms Verzögerung entstehen müssen (ADC/DAC). Mir ist unklar, was du unter "keine" Verzögerung vestehst. Ist 1 ms auch noch okay?
Joe F. schrieb: > Tipp: 100ksps = 0.01ms Seltsame Rechnung. Kann mir das mal jemand plausibel machen?
Mathe-Anfänger schrieb: > Joe F. schrieb: > Tipp: 100ksps = 0.01ms > > Seltsame Rechnung. Kann mir das mal jemand plausibel machen? Das ist die Periodensauer nicht die Verzögerung!
Peter schrieb: > Das ist die Periodensauer nicht die Verzögerung! Das ist eine seltsame Erklärung .... und schon gar keine Rechnung.
J. E. schrieb: > Als erstes dachte ich an den arduino due weil er bereits DAC hat und > mehr power wie die normalen Ich würde hier nicht auf einen uC mit unbekannter Klassenbibliothek setzen, sondern ziemlich "bare" in C programmieren. > aber wegen der synchronisation dachte ich > an einen FPGA.Oder halt einen anderen mikrocontroller. Es gibt ADC, die von extern gestartet werden können. Nimm 2 solche und du kannst die Signale sogar gleichzeitig wandeln. > Oder halt einen anderen mikrocontroller. Der ARM Cortex 3 reicht bei halbwegs durchdachter Programmierung locker aus.
Mathe-Anfänger schrieb: > Peter schrieb: >> Das ist die Periodensauer nicht die Verzögerung! > > Das ist eine seltsame Erklärung .... und schon gar keine Rechnung. 100ksps = 100kilo samples per second = 100000 Datenpukte pro sekunde 1/100000 s= 0.01 ms Es ist die Periodendauer. Einfach den Quotienten ziehen würde ich nicht mal richtig als Rechnung bezeichnen. Lothar M. schrieb: > J. E. schrieb: >> Als erstes dachte ich an den arduino due weil er bereits DAC hat und >> mehr power wie die normalen > Ich würde hier nicht auf einen uC mit unbekannter Klassenbibliothek > setzen, sondern ziemlich "bare" in C programmieren. Boar das klingt aber nahc sehr viel Arbeit. Sind die Biliotheken nicht zuverlässig? >> aber wegen der synchronisation dachte ich >> an einen FPGA.Oder halt einen anderen mikrocontroller. > Es gibt ADC, die von extern gestartet werden können. Nimm 2 solche und > du kannst die Signale sogar gleichzeitig wandeln. Ok das verstehe ich nicht so ganz. Wie meinst du das von extern gestartet werden? Die clock? Das problem sind nicht die zwei Signale sondern das Dritte, welches nicht durch den µC geht(zumindest war es nicht vorgesehen) >> Oder halt einen anderen mikrocontroller. > Der ARM Cortex 3 reicht bei halbwegs durchdachter Programmierung locker > aus. Also ein arduino due? oder kannst du ein anderes board empfehlen?
Schau dir mal den PSoC5LP von Cypress an, speziell das CY8CKIT-059: http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit-onboard-programmer-and Ist ein Cortex-M3 mit zusätzlichen analogen und digitalen Blöcken, ähnlich CPLD. ADC, DAC, Filter usw. lassen sich richtig gut damit machen, die IDE (PSoC Creator) ist exzellent gemacht. Dürfte für deine Zwecke genau das richtige sein.
J. E. schrieb: > Boar das klingt aber nahc sehr viel Arbeit. "Wenig Arbeit" stand nicht in deinem Anforderungsprofil. Und wenn das Schreiben einer effizienten Wandlerroutine bei dir eine solche Reaktion hervorruft, dann kannst du das Thema FPGA komplett vergessen. Denn dort musst du tatsächlich ALLES selber machen. > Sind die Biliotheken nicht zuverlässig? Es geht nicht darum, ob die zuverlässig sind, sondern ob sie effizient und schnell sind. Und das letztere ist garantiert der unkomplizierten und universellen Anwendung zum Opfer gefallen... J. E. schrieb: > Das problem sind nicht die zwei Signale sondern das Dritte, welches > nicht durch den µC geht(zumindest war es nicht vorgesehen) Wenn das dritte Signal eine relevante Information enthält, die nicht auch in einem der beiden ersten steckt, dann muss es eben auch ausgewertet werden. Und was bedeutet denn "durch den uC gehen"? Fehlen uns da noch relevante Informationen?
:
Bearbeitet durch Moderator
Joe F. schrieb: > J. E. schrieb: >> Ich habe zwei analoge Signale. Das eine wird in Abhängigkeite >> von der anderen verändert. Dabei muss das Timing unbedingt >> gleichbleiben. Also es sollte keine Verzögerung entstehen. > > Es soll also keine Verzögerung geben. > > Andererseits ist dir offenbar bewusst, dass in der digitalen Variante > min. 0.02ms Verzögerung entstehen müssen (ADC/DAC). Also im ADC sollte keien Verzögerung entstehen. Sobald der einen Messwert hat gibt er ihn weiter. > Mir ist unklar, was du unter "keine" Verzögerung vestehst. Ist 1 ms auch > noch okay? keine Verzögerung ist natürlich nicht möglich. Entschuldige wegen des unpräzisen Ausdrucks. also 0.02 ms Verzögerung ist grenzwertig. Aber der arduino due läuft doch mit 84MHz da sollte doch eine Verzögerung von 1 MHz möglich sein.(ja ich weiß das kommt auf meine Verarbeitung an) Lothar M. schrieb: > J. E. schrieb: >> Boar das klingt aber nahc sehr viel Arbeit. > "Wenig Arbeit" stand nicht in deinem Anforderungsprofil. Und wenn das > Schreiben einer effizienten Wandlerroutine bei dir eine solche Reaktion > hervorruft, dann kannst du das Thema FPGA komplett vergessen. Denn dort > musst du tatsächlich ALLES selber machen. sorry sollte nicht so blöd klingen. Natürlich bin ich bereit die Wandlerroutine selber zuschreiben. Falls du mit Wnadlerroutine das verarbeiten des analogen Signals meinst. Ich dachte irgendwie an eine ganze DSP bilbiothek selber schreiben. Bei den FPGA dachte ich einfach, dass ich meine analogen Schaltkreise relativ einfahc digital darstellen lassen(Gates, counter usw.) >> Sind die Biliotheken nicht zuverlässig? > Es geht nicht darum, ob die zuverlässig sind, sondern ob sie effizient > und schnell sind. Und das letztere ist garantiert der unkomplizierten > und universellen Anwendung zum Opfer gefallen... Hm ja das klingt logisch. Habe eben mal geschaut: vll ist ein M4 besser weil er schon ein paar DSP Funktionen dabei hat und die CMSIS von ARM relativ schnell läuft.
Lothar M. schrieb: > Wenn das dritte Signal eine relevante Information enthält, die nicht > auch in einem der beiden ersten steckt, dann muss es eben auch > ausgewertet werden. Das wird so nicht gehen. Wieso ist erstmal egal. > Und was bedeutet denn "durch den uC gehen"? Fehlen uns da noch relevante > Informationen? Nicht durch den µC gehen bedeutet, das das dritte Signal nicht an den µC angebunden ist. Also alle Infos habe ich extra nicht geschrieben, da die eigentlich irrelevant sind und dann irgendjemand schreibt ich solle es doch bitte auf das relevante Zusammenfassen. Zum Beispiel von wo die Signale herkommen und so. Ich werde morgen mal ein wenig ausführlicher beschreiben in wie weit die Signale verarbeitet werden sollen und ob Sie vo Sensoren oder so kommen.
J. E. schrieb: > Also im ADC sollte keien Verzögerung entstehen. Sobald der einen > Messwert hat gibt er ihn weiter. Das geht nur mit einem Flash-Wandler - die üblichen Wandler in Microcontrollern sind aber Successive approximation ADCs. Die brauchen erstmal eine gewisse Aquisitions-Zeit um den internen Sample-Kondensator zu laden, und dann noch min. einen A/D-Wandlertakt pro Bit für die Wandlung. Der A/D-Wandlertakt darf auch nicht beliebig hoch sein - meist ein Bruchteil des CPU-Taktes. Manchmal kann man den Takt erhöhen und/oder die Auflösung verringern, um die Wandlungsrate auf Kosten der Genauigkeit zu erhöhen. Auf jeden Fall muss man sich die ensprechenden Daten vom jeweiligen Wandler genau angucken und entscheiden, ob das für die Anwendung als "keine Verzögerung" betrachtet werden kann...
:
Bearbeitet durch User
J. E. schrieb: > keine Verzögerung ist natürlich nicht möglich. Entschuldige wegen des > unpräzisen Ausdrucks. also 0.02 ms Verzögerung ist grenzwertig. > Aber der arduino due läuft doch mit 84MHz da sollte doch eine > Verzögerung von 1 MHz möglich sein.(ja ich weiß das kommt auf meine > Verarbeitung an) Nunja, wenn du mit 100 ksps abtastest willst, und auch Nyquist erfüllen willst/musst, dann hast du ganz automatisch eine Verzögerung von 0.02 ms. Erklärung hierzu: Das Signal kommt an den ADC an, er beginnt die Wandlung. Nach 0.01 ms ist die Wandlung beendet und der Wert liegt für die Mikrocontroller bereit. Gemäß Nyquist brauchst du aber mindestens einen 2. Wert (genauer: man tastet mit einer Frequenz > 2 mal der maximalen Signalfrequenz ab, also eigentlich soll man min. 5-10 mal schneller abtasten), also musst du umgehend die 2. Wandlung starten. Das dauert auch wieder 0.01 ms. Bis du also irgend etwas mit den gewandelten Werten machen kannst sind 0.02 ms vergangen. Daher: Ist keine Verzögerung erlaubt ist das mit Digitaltechnik schlicht nicht umsetzbar (ich hab das bisher allerding auch noch nicht erlebt, dass wirklich keine Verzögerung erlaubt war). Du hast dir ja schon Gedanken darum gemacht und gesagt, dass die 100 ksps in deinem Fall grenzwertig aber noch OK sind. Hast du bedacht, dass bei Rechenaktionen im Mikrocontroller (oder FPGA usw.) auch noch Zeit verstreicht? Daher kommt die Frage: Welche Verzögerung wäre denn in deinem Falle noch OK? ;)
Angehängte Dateien:
-
Mikrocontroller.png
300 KB
So nun mal etwas genauer zu dem Aufbau: Ich habe mal eine kleine Zeichnung gemacht da ist die Verdrahtung abgebildetet und hier noch ein paar Eckdaten: DAQ ist eine Datenerfassungskarte die mit dem Computer gekoppelt ist. Dort kommen das "Trigger"signal und das Motorsignal synchron raus. Das Triggersignal sorgt im System für eine Änderung im Sensor. Das Sensorsignal steigt. Ab einem bestimmten Schwellenwert des Sensorsignal soll nun durch den µC das Motorsignal verändert werden. Das Motorsignal kommt mit 50ksps aus dem DAQ mit 12 bit( Deswegen auch 100ksps in meinem vorherigen post; wegen nyquist; Danke M. Köhler für den Hinweiß) Das Sensorsignal ist also das direkte Resultat von Triggersignal und Motorsignal. Also im Moment sind 0.02ms Verzögerung das Maximum was ok wären. Wenn ich das richtig sehe ist die µC Geschwindigkeit nicht das Problem sondern die ADC/DAC. Also alle boards die ich bis jetzt gesehen habe haben immer nur einen flash oder sigma delta ADC/DAC oder die Auflösung ist zu geringer. Danke Alexander S. der PSoC5LP von Cypress ist ein cooles Ding aber er hat lediglich 8 bit DAC und auch nur einen sigma delta ADC. Die anderen sind SAR ADCs.
J. E. schrieb: > Das Motorsignal kommt mit 50ksps aus dem DAQ mit 12 bit( Deswegen auch > 100ksps in meinem vorherigen post; wegen nyquist; Danke M. Köhler für > den Hinweiß) Das hast du aber noch nicht richtig verstanden. Interessant ist nämlich überhaupt nicht, wie "schnell" das Signal aus dem "DAQ" kommt, sondern welche Frequenz es höchstens enthält...
Lothar M. schrieb: > J. E. schrieb: >> Das Motorsignal kommt mit 50ksps aus dem DAQ mit 12 bit( Deswegen auch >> 100ksps in meinem vorherigen post; wegen nyquist; Danke M. Köhler für >> den Hinweiß) > Das hast du aber noch nicht richtig verstanden. > Interessant ist nämlich überhaupt nicht, wie "schnell" das Signal aus > dem "DAQ" kommt, sondern welche Frequenz es höchstens enthält... Das habe ich schon verstanden ;) Ist aber hier völlig egal, da das Signal bereits digitalisiert ist. ich könnte sogar 50ksps nehmen und hätte keinerlei Verlust aber ich könnte eine Verschiebung erhalten wenn der adc vom µC um fast eine Periodendauer verschoben ist. Deswegen die 100ksps. Damit ist die max Verschiebung nur halb so groß. Das "wegen nyquist" bezog sich nur auf den Post von Köhler(vll ein wenig blöd geschrieben von mit)
So ganz verstehe ich das nun nicht mehr: Ist die DAQ schon Fix, oder Teil der Entwicklung? Du solltest also schreiben, - was für eine Signal aus dem Motor kommt (vermutlich ein Analoges, mit einer Grenzfrequenz zwichen 20kHz..50kHz, je nach Filter) - welche Verarbeitung notwendig ist (einfach Multiplikation/Addition oder komplexer) - welche zeitlichen Abhängigkeiten es gibt, also wie schnell ein (verändertes) Motorsignal sich über den Sensor zurück im µC auswirkt. Gleiches Gilt für das Triggersignal (also: macht es evt. Sinn, das Triggersignal auch an den µC zu legen, damit dieser die Info früher hat?) Wenn DAQ und µC parallel das Sensorsignal auswerten...kann die DAQ den Wert nicht digitla an den µC senden?
Achim S. schrieb: > So ganz verstehe ich das nun nicht mehr: > > Ist die DAQ schon Fix, oder Teil der Entwicklung? Das DAQ ist fix. > > Du solltest also schreiben, > - was für eine Signal aus dem Motor kommt (vermutlich ein Analoges, mit > einer Grenzfrequenz zwichen 20kHz..50kHz, je nach Filter) Jap ein analoges. ich kenne aber die Grenzfrequenz nicht ist nicht bei dem Servotreiber angegeben. > - welche Verarbeitung notwendig ist (einfach Multiplikation/Addition > oder komplexer) etwas komplexer ist es schon. Aber das schlimmste sind e funktionen > - welche zeitlichen Abhängigkeiten es gibt, also wie schnell ein > (verändertes) Motorsignal sich über den Sensor zurück im µC auswirkt. fast sofort. Also genauer gesagt liegt das am Objekt zwischen Motor und Sensor. Dieses reagiert aber sofort auf das veränderte Motorsignal. Somit ist der begrenzente Faktor hier eher der adc. > Gleiches Gilt für das Triggersignal (also: macht es evt. Sinn, das > Triggersignal auch an den µC zu legen, damit dieser die Info früher > hat?) der kann es zwar "sehen" aber nicht weiter senden. Ansonsten müsste das gesamte System umkonstruiert werden. > Wenn DAQ und µC parallel das Sensorsignal auswerten...kann die DAQ den > Wert nicht digitla an den µC senden? Die DAQ nimmt es nur auf und stellt es im pc dar. Wenn die Verarbeitung aber über den pc läuft ist die Verzögerung riesig. Und vorallem nicht konstant.
Wie genau schaut denn das Motorsignal aus? Ich nehme mal an es wird was Sinus-förmiges sein. Ich würde hier Richtung 1 Msps zum abtasten des Motorsignals aus dem DAQ gehen, dann hat man mehr Abtastpunkte ( = Signal lässt sich besser rekonstruieren ) und man hat auch mehr Zeit zum Rechnen bezogen auf die 0.02 ms zulässige Verzögerung. Ein ATXMega könnte deinen Anforderungen wohl genügen. J. E. schrieb: > Die DAQ nimmt es nur auf und stellt es im pc dar. Wenn die Verarbeitung > aber über den pc läuft ist die Verzögerung riesig. Und vorallem nicht > konstant. Ah, ein Windows-Rechner... :D
:
Bearbeitet durch User
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.