ZitierenHast du schonmal gestaffelte LUT probiert?Zitat von yaro
Das sieht dann in etwas so aus:
Bild hier
Und damit kann man schon recht hohe Genauigkeiten bei kleinem Speicherbedarf realisieren.
Ich habe mich nochmal gründlich über diese ganzen Co-Prozessoren informiert, und bin zu dem Entschluss gekommen, dass sie kaum Zeitgewinn mit sich bringen. Wenn ich mehr Leistung brauche, werde ich einfach einen zweiten AVR anschließen (vllt sogar über einen Parallelprort), und mir keinen großen Aufwand machen, mich mit diesen Dingern zu beschäftigen.
Danke für die vielen und schnellen Antworten
Gruß Yaro
Hast du schonmal gestaffelte LUT probiert?
Das sieht dann in etwas so aus:
Bild hier
Und damit kann man schon recht hohe Genauigkeiten bei kleinem Speicherbedarf realisieren.
Sowas habe ich (aber nicht ganz so extrem) bei einer arccos-funktion angewendet.
Wie hast du die nötigen Werte dann rausgelesen? ich habe das mit Intervallschachtellung gemacht, das ging recht schnell.
Gruß, Yaro
Ich würd auch sagen am allereinfachsten ist es einen zweiten AVR zu benutzen. Du schreibst ja nicht viel über dein Problem da ist es auch etwas schweirig einen konkreten tip zu geben. Ich denke prinzipiell musst du dir erstmal überlegen ob ein AVR die komplette rechnung schafft und du nur das Problem hast das er sich um nichts anderes kümmern kann. In diesem Fall würde ich den Sensor oder was sonst die Datenquelle ist wenn möglich gleich an den AVR hängen der rechnet und dann nur die Ergebnisse übertragen. Wenn du die Aufgaben aufteilen willst und die Daten schnell zwischen einem AVR zum anderen übertragen willst würd ich mir auch einen Parallelport bauen, sofern der Datendurchsatz nicht zu hoch ist. Du musst immerhin alles in Software machen...
musst halt mal überlegen wieviel Rechenzeit die Datenübertragung im Vergleich zur Rechnung frisst. In der Regel lohnt sich sowas immer dann, wenn du zwei drei Werte zur berechnung brauchst, mit denen ewigkeiten rumrechnest und die Ergebnise zurückgibst. Wenn du einen Hohen Datendurchsatz mit einfachen Rechnungen hast wie Beispielsweise Bildverarbeitung, wird das so nicht Funktionieren
wenn man die flankenzeiten der controller und die empfindlichkeit hernimmt, kommt man bei ca. 4 notwendigen rechenzyklen raus, um eindeutige pegelstände zu erkennen, das sind dann 0,5µS, also 2µS für 32bit bei 8bit parallel ... wenn man jetzt davon ausgeht, dass die prozessoren synchron takten, könnte man sich mit assembler ein paar ganz ausgefuchste mathematische funktionen schreiben, die quasi mehrkern berechnet werden
mh ... ich merke gerade dass ich mein assembler wieder auffrischen müsste
Also der verlinkte Coprozessor könnte dem AVR zwar etwas Arbeit abnehmen...
aber wenn man floats wirklich schnell verarbeiten möchte, braucht man was anderes, wie z.B. einen CPLD auf dem man eine FPU implementiert. Das wäre dann extrem schnell, hat aber den gravierenden Nachteil, daß man dafür erstmal VHDL lernen muss.
So viele Treppen und so wenig Zeit!
von vornherein intelligent programmieren wird
am effektivsten sein.
Einsparungspotential nutzen wo möglich, z.B.
Muss wirklich float verwendet werden oder reicht
Ganzzahl,
Mittelwertbildung über arrays in Zweierpotenzen (2/4/8/16 ...)
sodass man die Summe nur shiften muss.
Muss bei jedem Programmzyklus berechnet werden oder reicht alle
x Zyklen oder gar x Millisekunden
daraus folgt dann die Verwendung von State Machine, Timer etc.
Ich hatte mit der Rechenleistung des AVRs bisher nur einmal
Engpässe, da gings um verarbeitung von Bilddaten und es wurden
Megabytes/sec. durchgeschaufelt.
Vor den Erfolg haben die Götter den Schweiß gesetzt
Da dieser "Coprozesssor" auch nur ein µC ist, könnte man auch gleich das ganze Prorgamm auf solch einem µC laufen lassen. Ein 2 ter µC hilft nur dann, wenn man nicht zu viel Zeit für die Datenübertragung verliert.
Hallo!
Es ist genauso, wie der Besserwessi geschrieben hat. Fur mich wäre es am einfachsten, wenn der "Coprozessor" ("Co") und "Hauptprozessor" ("Haupt") einen externen Speicher (Puffer) nutzen würden.
Der "Haupt" könnte die alle Daten und die Funktion zum Berechnen in den Puffer reinschreiben und den "Co" wie ein Timer starten. Wenn es berechnet ist, könnte der "Co" sich per Interrupt melden und der "Haupt" das Ergebnis einlesen. Ich finde solche Lösung am schnellstem, da die Prozessoren paralell mit schnelstmöglichem Datenaustausch arbeiten sollen. So wurde es früher in PCs realisiert.
MfG
So ähnlich habe ich das auch realisiert. Ich habe einfach 2 ATmegas zur berechnung verwendet. Allerdings brauche ich keinen Puffer, sondern übertrage nie nötigen Daten direkt, rechne dann auf beiden Controllern und lese dann, nachdem der "Co-Prozessor" gerechnet hat, die Ergebnisse in den eigentlichen Prozessor ein.
Dass er fertiggerechnet hat, signalisiere ich mit einer Signalleitung.
Gruß, Yaro
Berechtigungen
Lesezeichen