Moin Zusammen, ich möchte 16 Kanäle mit jeweils effektiv 1Ksample mit 12bit abtasten. Um möglichst wenig externe Bauteile für Filter zu verwenden, dachte ich daran, jedem Kanal einen möglichst einfachen Anti-Aliasing-Filter zu spendieren und dann hoch abzutasten und auf 1Ksample digital runterzufiltern. Der ARM soll allerdings nebenher noch die resultierenden Daten auf eine CF-Karte mit FAT-Partition schreiben, Daten vom CAN ebenfalls dort ablegen und ein wenig über UART kommunizieren. Hat jemand ein ähnliches Projekt schon realisiert und kann mir grob sagen, ob die Performance eines ARM7TDMI reicht, um die 16 Kanäle entsprechend nachzufiltern und noch genug Zeit für den Rest übrig hat? Gruß Tobi
Hallo Tobias, guck mal hier : http://www.winfilter.20m.com/ Mit diesem Programm kannst Du Filter erstellen, es generiert sogar den C-Code dafür. Dieser ist allerdings nicht das gelbe vom Ei, und noch optimierungswürdig. Aber zum Abschätzen des Zeitbedarfs und um so ein Gefühl dafür zu bekommen ist er sicherlich mehr als ausreichend. Frank.
Hallo, ich bin gerade auf der Suche nach einem ARM7-TDMI-Emulator, der eine Clock-Prediction macht, wenn man ihm C-Code gibt. Das würde die Abschätzung erheblich vereinfachen. Ich habe mal angenommen, dass ich etwas um die 14ksamples brauche, wenn ich nur mit nem RC-Glied vor jedem Kanal gegen Aliasing filtere oder alternativ zwischen Mux und AD-Wandler mit nem Besselfilter, der schnell genug einschwingt. Kommt beides auf etwa 14KSamples raus. Ich habe mir mal C-Code generieren lassen mit dem von Frank genannten Tool. Herauskam Folgendes: #define NCoef 6 float iir(float NewSample) { float ACoef[NCoef+1] = { 0.00000000015295209542, 0.00000000091771257251, 0.00000000229428143127, 0.00000000305904190836, 0.00000000229428143127, 0.00000000091771257251, 0.00000000015295209542 }; float BCoef[NCoef+1] = { 1.00000000000000000000, -5.79923266699539570000, 14.01526652929172900000, -18.06765396213400300000, 13.10372775041749400000, -5.06939560461618830000, 0.81728796143312221000 }; static float y[NCoef+1]; //output samples static float x[NCoef+1]; //input samples int n; //shift the old samples for(n=NCoef; n>0; n--) { x[n] = x[n-1]; y[n] = y[n-1]; } //Calculate the new output x[0] = NewSample; y[0] = ACoef[0] * x[0]; for(n=1; n<=NCoef; n++) y[0] += ACoef[n] * x[n] - BCoef[n] * y[n]; return y[0]; } Das entspricht nach meiner Rechnung 13 Multiplikationen pro Sample. Bei 14ksamples und 16 Kanälen ergibt das immerhin 2912000 Multiplikationen. Bei 60 MHz Takt dürfte man nur maximal 20 Takte brauchen pro Multiplikation, wenn man den ARM komplett auslasten dürfte. Inklusive dem ganzen Datenoverhead usw. ist das nicht machbar, denke ich. Schon gar nicht, wenn man nebenher noch mit FAT auf ne CF-Karte schreibt und per UART kommuniziert. Bitte korrigiert mich, wenn ich falsche Annahmen getroffen habe! Gruß Tobi
Ein IIR ist hier sicher nicht die richtige Wahl, der macht dir den Phasengang krumm. Für Downsampling kannst du ein FIR-Filter in Polyphasenstruktur verwenden, das spart Multiplikationen, oder wenn's ganz hart wird ein CIC-Filter gefolgt von einem FIR-Filter (siehe benachbarten Beitrag hier im Forum). Float-Rechnung kannst du allerdings vergessen, der ARM7 hat keine FPU.
Leider haben die ARM7TDMI-Kerne keine MAC-Einheit. Das macht die ganze Filterei nichttrivial weil man dann auf CIC-Filter, deren Phasen- und Frequenzgang dann wieder durch FIR Filter gerade gebogen werden muss oder ähnliche Spielchen zurückgreifen muss. (Ist aber - gerade mit Festkomma - etwas fies im Entwurf.) Ich würde mir, wenn es um eine geringe Stückzahl geht, die Mühe sparen und richtige Antialiasingfilter - bei den Frequenzen sicher als aktive Filter - vorsehen. Alternativ kann man auch ein ARM9E-Kern benutzen welcher eine MAC-Einheit besitzt. (Es gibt theoretisch auch ARM7 Kerne mit DSP Erweiterung aber ich habe bisher noch kein käufliches Produkt mit diesen gesehen.) Viele Grüße, Martin L.
Mahlzeit, bisher habe ich in meinen Layouts genau das verfolgt. Also jeden Eingang entsprechend gefiltert. Aber bei 16 aktiven Filtern 4.Ordnung ist der Platinenplatz nicht unerheblich, den das ganz verbraucht, selbst wenn man SC-Filter nimmt, da man da ja noch auf jeden Fall mit RC-Gliedern vor- und nachfiltern muss. Da der Datenlogger in einem Rennfahrzeug verbaut werden soll, sind Bauraum und Gewicht vierfach kritisch. Aus diesem Grund bin ich überhaupt auf die Idee gekommen, digital zu filtern. Aber so, wie es aussieht, werde ich wohl doch in den sauren Apfel beißen. Das spart außerdem Zeit, da ich die Filterlayouts schon liegen habe und mich in digitales Filtern erst einarbeiten müsste. Dann stecke ich die Zeit wohl lieber in ein platzoptimales Layout. Gruß Tobi
Und wenn Du vor dem Filter umschaltest? Setzt natürlich vorraus, dass der Filter schnell genug einschwingt. Man kann, wenn das nicht schnell genug ist, ja auch einen Filter auf jeweils zwei Kanäle schalten womit man nur noch acht braucht. Auch wäre zu überlegen ob man einen Filter 2. Ordnung verwendet und den Rest Digital macht. Und dann fragt sich natürlich auch noch, ob man in den zu messenden Signalen wirklich noch so starke hohe Frequenzanteile hat. (Normalerweise schätzt man den Filtergrad ja mit einem gleichverteilten Spektrum ab - damit ist man auf der sicheren Seite. Aber oft haben die Signale ja schon Tiefpasscharakteristik.) Wenn der Phasengang nicht so wichtig ist kann man ja auch (inverse) Chebyshev- oder elliptische Filter anstatt Bessel o.ä. verwenden. Und: sind Alias mit ein oder zwei LSB wirklich so schlimm? Viele Grüße, Martin L.
Hi Martin, ich habe hier zu diesem Thema schon einen Thread laufen: Beitrag "Signalweg-AD-Wandlung- Multiplexer und Filter vertauschen?" Meine Abschätzungen haben dabei ergeben, dass das Einschwingen bei meiner Abtastrate zu lange dauert. Daher dachte ich ja an digitales Nachfiltern. Da der ARM aber mit dem Rest schon ganz gut beschäftigt sein dürfte, habe ich das ja weiter oben wieder verworfen. Das größte Problem ergibt sich dabei dadurch, dass die Abtastrate bei der geforderten Einschwingzeit des Filters durch die gestiegene Grenzfrequenz um den Faktor 14 hochgeht. Bezüglich des Alias...ich brächte ja nicht mit 12bit zu digitalisieren, wenn ich die unteren beiden Bits eh wegschmeiße. Leider liegt außerdem die Zündung von der Frequenz und der Höhe der Störung recht nahe am interessierenden Frequenzbereich, weshalb ich steil filtern muss, sonst habe ich immer schön die Zündung mit im Signal, was natürlich Mist ist. Vielen Dank für deine Denkanstöße, ich bin bin für jeden Vorschlag offen, der mit 16 aktive Filter erspart. Gruß Tobi
Unkonventioneller Vorschlag: Filter weglassen, die Daten "roh" wegschreiben - notfalls eine größere Speicherkarte nehmen. Das Filtern kann dann "in Ruhe" der PC beim auslesen der Karte machen. Geht das ? Frank
Rein vom Prinzip her habe ich auch schonmal daran gedacht, die Daten einfach nach dem Download vom System downzusamplen. Allerdings war ich mir nicht sicher, welche Datenrate der ARM7 inklusive FAT32-Verwaltung effektiv auf die CF-Karte schreiben kann. Denn das wären dann ja im schlimmsten Fall 16bit x 15KSamples x 16 Kanäle= ca. 470kbyte/s plus nochmal das gleiche an Overhead, denke ich. Dann sind wir bei fast 1MByte/s. Mir fehlt die Erfahrung mit ARM7+CF+FAT32 um darüber eine Aussage treffen zu können. Ich bin mir auch noch nicht ganz sicher, wie ich die Hardware-Anbindung der CF-Karte realisieren soll. Der LPC2378, den ich nutze, hat auch DMA-Funktionalität und ich würde natürlich gerne direkt Daten schaufeln. Weiß aber noch nicht, ob ich den externen Memorybus des ARM nutzen soll oder einfach die normalen IO-Ports nehme. Für die IO-Ports gibts nämlich schon Implementierungen, aber dann ist mit DMA natürlich Essig. Gruß Tobi
Also als kleinen Anhaltspunkt.. mit nem SAM9260, einer SanDisk Ultra-III CompactFlash Karte schaffe ich mit FAT rund 8MB/Sekunde am externen Bus. Der SAM9260 läuft dann mit rund 70MHz externem Bus und 140MHz internem Takt. Also sollte ein ARM7 mit externem Bus (z.B. AT91SAM7SE256) die 1MB/Sek. ohne Probleme bringen. Aber der LPC2378 hat doch ein SD-Karten Interface mit DMA Unterstützung. Das sollte auch nicht grade langsam sein.. und spart dir zudem einiges an Platinenplatz..
Ich zitiere mal aus dem Buch "ARM System Developer's Guide". ARM7TDMI (filter benchmark): 16-bit-dot-product 7.6 (cycles/tap) 16-bit block FIR filter 5.2 (cycles/tap) 32-bit block FIR filter 9.0 (cycles/tap) 16-bit IIR Filter 22.0 (cycles/biquad) ARM7TDMI (fft benchmark): 16-bit complex FFT (radix-4) 64 point 3524 (cycles/FFT) 256 point 19514 (cycles/FFT) 1024 point 99946 (cycles/FFT) 4096 point 487632 (cycles/FFT) Im Buch befinden sich auch diverse Beispiele.
hey, je nach aufzeichnungsdauer(menge) der daten könnte man ja die rohdaten auch in einem externen RAM zwischenspeichern, das filter rechnen und die aufbereiteten daten dann auf die sd-card schreiben ?!? .... wenns nicht in echtzeit passieren muss.. Neubi
Hi, das geht leider nicht, da die Aufzeichnungsdauer durchaus mehrere Stunden betragen kann. Gruß Tobi
Bitte 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.