Den es zu vermeiden gilt. Au=DFer "hab ich schon gemacht" gibt es keine=20 weiteren Hinweise, nicht einmal auf App-Notes. Aber macht ja nix, ich=20 habe ja meinen eigenen Kopf. Ich werde das schon hinkriegen. Im Prinzip=20 habe ich das ja schon, werde ich hier aber nicht besprechen.
Wieder ein Thema mehr, das man hier nicht mehr besprechen kann. Schade.=20 Was waren das noch f=FCr Zeiten, wo zum Beispiel ein Oliver Bartels=20 seitenlang erkl=E4ren konnte, wie digitale Filter funktionieren ....
Du hast den Hinweis bekommen, daß der interne Wandler der AVRs für Audiozwecke nicht taugt.
Du hast weiterhin den Hinweis bekommen, daß man auch mehr als 8Bit via SPI einlesen kann, und die meisten Chips dafür ein Synchronisationssignal bereitstellen. Welches das ist, ist dem Datenblatt unschwer zu entnehmen.
Was willst du mehr?
Du machst wiederholt den Fehler, hier eine Support-Hotline für technische Probleme zu erwarten. Tatsächlich ist das Usenet aber ein Diskussionsmedium, in dem jeder Teilnehmer selbst entscheidet, worüber er schreiben möchte.
Es ist schön, wenn man nach Schilderung einer Bastel-Idee spontan jemanden findet, der davon so begeistert ist, dass er sich näher damit auseinandersetzen und Hilfsstellung bieten will. Aber sehr wahrscheinlich ist das nicht.
Sehr viel wahrscheinlicher ist, dass man Hinweise auf andere Lösungsmöglichkeiten erhält, mit denen der Tipgeber sich schon befasst hat (in diesem Fall Microcontroller mit internen Audio-DA-Wandlern). Diese Hinweise solltest du nicht pauschal abtun.
Und mitunter gleitet eine Diskussion auch in völlig andere Sphären ab. Wenn diese dich nicht interessieren, lies' sie halt eimfach nicht. Aufregen bringt nix, und die beleidigte Leberwurst noch weniger.
Nein, ich erwarte keinen Support, sondern Diskussion. Aber da ich mein=20 technisches Problem gel=F6st sehe, so schwer ist das nicht, aus synchrone= n=20 Bin=E4rz=E4hlern und ein paar Gattern und Schieberegistern was passendes = zu=20 zaubern, ist f=FCr mich diese Frage wirklich gekl=E4rt. Ich fand die=20 Antworten nur etwas gereizt. Das Thema ist ansich l=F6sbar. Meine L=F6sun= g=20 w=E4re diese: Wir haben ein synchrones Schieberegister, das 24 Bits=20 zwischenspeichert. FIFO-Architektur. Nach 24 Bits wird der Bittakt des=20 Audiosignals auf den Bittakt f=FCr den AVR umgeschaltet, der sich in=20 wesentlich h=F6herer Geschwindigkeit die 24 Bits byteweise l=E4dt und sic= h=20 im internen RAM rekonstruiert. Bis zum n=E4chsten Pegelwechsel vom=20 L/R-Takt, der alle 32 Pulse auf der Bittaktleitung des Audiosignals=20 erscheint. Kann man mit TTL-Chips bauen.
ab.=20
Da stimme ich dir zu. Ich bin ja auch nicht beleidigt. Nur manchmal=20 etwas verwundert.
Kann man sicher. Ist nur überflüssig. Man kann doch die Bits auch gleich per SPI in den Atmel schieben. Was soll da ein zusätzliches Schieberegister vor dem Schieberegister des Atmel? Und die Kontroll-Logik kann man höchstwahrscheinlich auch noch ganz sparen und durch Software ersetzen.
Wie hoch ist denn der Audio-Bittakt der Quelle eigentlich?
8byte mit 48kHz einzulesen ist (heutzutage) kein grosses Kunststück. BTW UARTs mit Fifo gabs schon in den 80ern des vergangenen Jahrtausends.
Ich hab in den 80ern schon 1Mbyte/sec eingelesen, und zwar IR gesteuert mit 20kHz Folgefrequenz immer 48byte mit einem 10MHz RTX2000 und damit
256 8051 ersetzt. Gräber mit 256 8051 hab ich nicht machen wollen.
Nebenbei noch Terminals mit 9600Bd bearbeitet
In grossen Anlagen waren bis zu 24 dieser RTX2000 drin. Und es durfte garantiert nicht ein einzige Byte verschlabbert werden.
So what?
Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang
--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)
Wer von der Hoffnung lebt, wird wenigstens nicht dick (jap. Sprichwort)
Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang
--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)
Hast du nicht geschrieben, du h=E4ttest das alles schon gebaut? Und dann =
fragst du noch? Naja, bei 48000 kHz Samplingrate wollen insgesamt 64 Bit =
pro L/R-Takt r=FCbergeschoben werden, macht 3072000 kHz f=FCr den Bittakt= =2E
Du wei=DFt aufgrund deiner Erfahrung mit solchen Schaltungen ja nun, da=DF= =20 die je nach Polarit=E4t des Taktsignals fallende oder steigende Flanke=20 nach dem 8. Datenbit signalisiert, da=DF ein Byte komplett im Register=20 ankam und sofort gelesen werden mu=DF, du hast 300 ns Zeit daf=FCr. Zweit= ens=20 mu=DF ein L/R-Signal ausgelesen werden, damit der Rechner =FCberhaupt wei= =DF,=20 wie diese eingehenden Bytes zusammengeh=F6ren, der Blocksync dient der=20 Synchronisation des Bittaktes mit den Datenbits. Solche Sachen kann man=20 mit Schieberegistern und Latches machen, zum Beispiel dem 74HC595, was=20 ich =FCbrigens schon tat. Von daher wei=DF ich, was ich schreibe.
Und nun kannst du mir mal aufschreiben, wie du das immer gemacht hast.
Hast du nicht geschrieben, du h=E4ttest das alles schon gebaut? Und dann =
fragst du noch? Naja, bei 48 kHz Samplingrate wollen insgesamt 64 Bit=20 pro L/R-Takt r=FCbergeschoben werden, macht 3072 kHz f=FCr den Bittakt.
Du wei=DFt aufgrund deiner Erfahrung mit solchen Schaltungen ja nun, da=DF= =20 die je nach Polarit=E4t des Taktsignals fallende oder steigende Flanke=20 nach dem 8. Datenbit signalisiert, da=DF ein Byte komplett im Register=20 ankam und sofort gelesen werden mu=DF, du hast 300 ns Zeit daf=FCr. Zweit= ens=20 mu=DF ein L/R-Signal ausgelesen werden, damit der Rechner =FCberhaupt wei= =DF,=20 wie diese eingehenden Bytes zusammengeh=F6ren, der Blocksync dient der=20 Synchronisation des Bittaktes mit den Datenbits. Solche Sachen kann man=20 mit Schieberegistern und Latches machen, zum Beispiel dem 74HC595, was=20 ich =FCbrigens schon tat. Von daher wei=DF ich, was ich schreibe.
Und nun kannst du mir mal aufschreiben, wie du das immer gemacht hast.
Holger
PS: Fehler korrigiert. Hoffe, Supersedes funktioniert bei AIOE.
Hast du nicht geschrieben, du h=E4ttest das alles schon gebaut? Und dann =
fragst du noch? Naja, bei 48 kHz Samplingrate wollen insgesamt 64 Bit=20 pro L/R-Takt r=FCbergeschoben werden, macht 3072 kHz f=FCr den Bittakt.
Du wei=DFt aufgrund deiner Erfahrung mit solchen Schaltungen ja nun, da=DF= =20 die je nach Polarit=E4t des Taktsignals fallende oder steigende Flanke=20 nach dem 8. Datenbit signalisiert, da=DF ein Byte komplett im Register=20 ankam und sofort gelesen werden mu=DF, du hast 300 ns Zeit daf=FCr. Zweit= ens=20 mu=DF ein L/R-Signal ausgelesen werden, damit der Rechner =FCberhaupt wei= =DF,=20 wie diese eingehenden Bytes zusammengeh=F6ren, der Blocksync dient der=20 Synchronisation des Bittaktes mit den Datenbits. Solche Sachen kann man=20 mit Schieberegistern und Latches machen, zum Beispiel dem 74HC595, was=20 ich =FCbrigens schon tat. Von daher wei=DF ich, was ich schreibe.
Und nun kannst du mir mal aufschreiben, wie du das immer gemacht hast.
Holger
PS: Fehler korrigiert. Hoffe, Supersedes funktioniert bei AIOE.
Ich sehe das schon so, da=DF man sowas per Newsgroup nicht besprechen=20 kann. Vor allem dann, wenn man auch noch einen Tippfehler mit drin hat.=20 Okay, war mein letzter Versuch in dieser Hinsicht. Wenn eine Schaltung=20 mal nicht tut, was sie soll, komme ich damit besser klar als mit diesen=20 Antworten hier. Also frage ich meine Schaltungen, was sie von meinen=20 Ideen halten, aber keine Experten mehr.
Ich habe da einfach keinen Bock drauf, vor allem auf den Zeitverlust=20 nicht. Bringt einfach nix.
Nein. Ich schrieb, daß ich schon vielfach die SPI-Schnittstellen des Atmel verwendet hätte.
Du hast bisher nirgendwo erwähnt, daß die Quelle 48kHz Samplerate verwendet. Wenn ich diese Information gehabt hätte, hätte ich das auch allein ausrechnen können.
Wenn ich nun aber die USART im SPI-Mode verwende, habe ich satte 2,6µs Zeit, um dieses lausige Byte zu lesen, da ist das Schieberegister nämlich gepuffert. Stört eigentlich bloß noch die Tatsache, daß der Takt von außen kommt, was den SPI-Slavemode erfordert, den die USARTs leider nicht können.
Da bietet sich als allereinfachste Lösung an, die gesamte Hardware mit Takten zu versorgen, die aus einem gemeinsamen Muttertakt abgeleitet sind. Dann sind der Atmel und die Quelle von Hause aus synchron und diese Beschränkung spielt keine Rolle mehr. Es ist nur einmalig eine Synchronisation der SPI-Schnittstelle auf die Phase des Quelltaktes erforderlich. Je nachdem, was die Quelle für einen Systemtakt erfordert, kann der ggf. durch den Atmel bereitgestellt werden. Jeden ganzzahligen Teiler seines Systemtaktes mit n>=2 kann jeder Atmel per Timerausgang bereitstellen, bei vielen Atmels ist es auch möglich, den Systemtakt selber via CLKO-Pin nach außen zu liefern.
Alternativ könnte man auch was ähnliches machen, wie du es für deine Hardwarelösung geplant hast, bei der du ja auch nur 24 der 32 Bits eines Wortes nutzen willst. Dann braucht man keinen gemeinsamen Muttertakt mehr, sondern nur ein hinreichend genaues Vielfaches des Taktes der Quelle und kann dann die 8 ungenutzten Bitzeiten zur Synchronisation verwenden, danach müssen dann für die Dauer von 24Bits die Taktfrequenzen hinreichend genau übereinstimmen.
Man würde also für den Atmel einen 18,432MHz-Quarz nehmen. Das erlaubt eine Detektion des Flankenwechsels des Quelltaktes mit einem Jitter von
56ns innerhalb von etwas über einer Bitzeit des Quelltaktes, sprich: locker genau genug und locker schnell genug.
Hier kommt es weniger auf die Genauigkeit an, der Jitter muß nur deutlich unterhalb einer Bitdauer des Quelltaktes liegen. Da könnte man eine Variante des Sync-Codes verwenden, die zwar 108ns Jitter hat, aber auch innerhalb von maximal 108ns nach dem Ereignis ein Ergebnis liefert.
...
Also nur ein bissel nachdenken, und dein TTL-Verhau wird komplett überflüssig, wie ich schon sagte.
So kann mans auch nennen :) Bin/war reiner Anwendungsprogrammierer, um die Forth internas habe ich mich nur gekümmert, wenn mal was nicht so lief, wie ich es gedacht habe.
Mit dem RTX2000 hab ich Ultraschall Prüfanlagen gemacht. So ein speziell für US Anwendungen entwickeltes RTX2000 Board lag damals in den 80ern bei rund 4000DM, also schon ein heftiger Brocken, aber eben sauschnell. Leere IR-Service Routine in 100ns(?) feddich.
Nie von einem Max Dietz gehört. Verrätst Du welche Fa und für was?
Die RTX2000 boards wurden später auch für pillepalle Aufgaben eingesetzt. Ich hab zuerst geflucht: was für eine Verschwendung, wenns auch (mit echtem knoffhoff) mit ein paar 8031 geht! Kundenjeffe: nö, selbst der dämlichste Programmierer schafft es nicht, dass eine Anwendung mit dem RTX2000 zu langsam ist. D.h. der braucht schlimmstenfalls 1 Tag und das Problem ist vom Tisch. Mit der 8051 Lösung versagt er u.U. nach 1 Woche und ich muss externe Spezis wie Dich anheuern. RTX2000 `verballern` ist unterm Strich deutlich billiger.
Auch so kann man Kunden verlieren :(
Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang
--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)
Vielen Dank f=FCr deine Ausf=FChrungen. Ich werde mir die Sache noch einm= al=20 genauer ansehen und denke gerade daran, das FIFO-Schieberegister, das=20 mir vorschwebt, Richtung Wandler langsam zu lesen und zu schreiben, und=20 Richtung Atmel schnell zu lesen und zu schreiben; ganz ausgegoren ist=20 das noch nicht, aber ich habe den Eindruck, das Problem l=F6sen zu k=F6nn= en.=20 Das mu=DF ich nochmal in Ruhe durchrechnen, mal sehen. Auf jeden Fall=20 k=F6nnte ich Zeit f=FCr den Atmel rausschinden, wenn das SPI nicht mit de= m=20 Takt der Wandler arbeiten mu=DF, was dann eventuell doch ein TTL-Grab=20 erfordert.
Der hat das Ding für Harris bekannt gemacht, Artikel in der Fachpresse geschrieben und mit Präsentationen versucht den Firmen den Prozessor schmackhaft zu machen. Tolle Kiste, aber für uns (Sorcus) zu Z80 Zeiten damals etwas oversized.
Du hast ja inzwischen zu deine AVR-Variante entsprechendes Feedback bekommen. Natürlich kann der UDA1345TS (oder ein anderer) keine Karten fertig beschreiben. So ein CODEC hat aber den Vorteil, dass die gesamte Analogverarbeitung (Filter, Volume, Mute, ADC usw.) bereits vom Hersteller fertig integriert wurde. Der UDA1345TS z.B., und das verät ein Blick ins Datenblatt, hat ein Interface für Mikrocontroller, auf dem neben 20bit, 18bit auch 16bit ausgegeben werden können.
Üblicherweise würde man dann einen Mikrocontroller mit 2 DMA-Kanälen auswählen. Der eine Kanal liest von der SPI kontinuierlich in einen Zwischenpuffer im RAM, wärend der zweite gleichzeitig vom Zwischenpuffer auf einer zweiten SPI auf die Memory-Card schreibt (512b-Block auf SD-Card im SPI-Mode). Der Controller hat die Karte entsprechend vorher mit einem "WRITE_BLOCK(24) command" vorbereitet und schickt der Card nach dem Transfer noch die CRC.
Habe ich bei Digikey gefunden, scheint sogar lieferbar zu sein.=20 Allerdings bin ich mir nicht sicher, ob Digikey auch Privatkunden=20 bedient? Mindermengen scheinen lt. AGB nicht das Problem bei denen zu=20 sein. Hast du da n=E4here Informationen?
Der UDA1345TS war jetzt nur ein Beispiel. Es ist nicht mein Lieblings-IC. Vermutlich gibt es tausende andere, die eine ähnliche Funktion anbieten.
BTW. wenn du das L/R-Signal auf SSEL der SPI legst (SPI als Slave evtl. mit Takt über Timer-Ausgang) wird auch nur ein Kanal in den Controller eingelesen => halbe Daten-Bandbreite (kann bai Mikro sinnvoll sein). Falls du vorhast immer noch diesen AVR zu verwenden und die SPIs per ISR zu bedienen springst du bei 48KHz und 16bit ca 200.000 pro Sekunde in die ISR (lesen + schreiben). Ein Controller mit DMA ist da schon sinnvoll.
Wir hatten einen RTX2000 noch bevor Harris D sowas hatte. Einer meiner Mitgesellschafter hatte einen auf einer Forth Konferenz in Rochester/NY gewonnen, samt allen Unterlagen...
Irgendjemand von Harris (Name vergessen) kam dann bei uns in Köln vobeigedackelt, um sich das Teil mal im Orijinol anzusehen :)
Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang
--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.