Hallo, die Idee tanzt schon eine ganze Weile mit meinen grauen Zellen Samba und ich habe inzwischen genug gegurgelt, um die prinzipielle Machbarkeit abgeklopft zu haben. Das Teil soll 2 SD-Karten bekommen und an Schnittstellen stelle ich mir Ethernet und USB vor. Externe Spannungsversorgung soll 12V DC betragen. Kern soll irgendwas von Atmel sein. Ein Mega wäre toll, wenn dessen Geschwindigkeit reichen sollte, ansonsten könnte ich mich auch mit etwas Größerem anfreunden. FPGA und Co. würde ich nur sehr ungern mit ins Boot nehmen. Einen netten Zerhacker habe ich auch gefunden, sodass langsam Freude aufkommt. Angepeilte Bandbreite ist ca. 1,5 Mb/s, d.h. ohne schnellen, externen Speicher wird wohl nicht viel gehen. Messgeber (Mikro o.ä.) sollen differentiell angesteuert werden, mit optionaler Phantomspeisung. Das Projekt stufe ich jetzt als nicht so klein ein, dass man es mal eben an einem Nachmittag zusammenlötet, weshalb ein Fred hier wohl nicht das adäquate Kommunikationsmittel für eine solchen Entwicklung ist. Deshalb die Frage nach einem/mehreren Tutoren. Kommerzielle Interessen schließe ich aus. Von meiner Seite besteht eher die Bereitschaft, im Erfolgsfalle das Projekt zu veröffentlichen. Budget ist sehr klein, was die Laufzeit um Einiges vergrößern könnte. Wer hat Interesse an der Thematik, kennt sich im Audiobereich aus und besitzt ein dickes Fell, um meine ggf. dummen Fragen nicht nur zu ertragen, sondern auch zu beantworten? Email wäre mir das liebste Medium für den Austausch von braindumps :) Gruß Santi
@Santiago m. H.
>Email wäre mir das liebste Medium für den Austausch von braindumps :)
Dann veröffentliche sie doch.
>> Email wäre mir das liebste Medium für den Austausch von braindumps :) > Dann veröffentliche sie doch. Nun, ich dachte, die könnte man per PN austauschen.
mir irgendwie unklar: was soll das ganze denn machen? zweck?
> was soll das ganze denn machen? zweck?
Naja, es gibt viele Situationen, in denen man Audio-Daten mit
meßtechnischem Hintergrund erfassen will, sei es um einen Raum
auszumessen, oder Equipment zu kalibrieren, etc.
Das ganze soll wie eine Soundkarte ohne Rechner funktionieren, sodass
man Messung und Auswertung unabhängig von einander durchführen kann
(z.B. auch im Outdoor Einsatz - deshalb auch die 12V extern).
Also die autarke Verwendung steht im Vordergrund. Wenn die Datenmenge
vom Durchsatz handhabbar ist, könnte auch eine Online-Anbindung wie z.B.
bei einem Oszilloskop, oder als hochwertiger AD-Eingang nachgedacht
werden.
Hier gibt es sicher viele Interessenten, mit denen du dich austauschen könntest: http://zora.raetselnasen.de/forum/
Hallo, weiß nicht, vielleicht habe ich einen falschen Eindruck vermittelt?!? Die Tatsache, dass ich mein Anliegen etwas salopp formuliert habe bedeutet nicht, dass ich mich nicht ernsthaft der Aufgabe widmen will. Ich suche auch niemand, der mir Arbeit abnimmt, eher einen "sensei", der mich zurückholt, wenn ich mich verlaufe. Ich habe nix dagegen, wenn jemand mitmachen möchte, gehe aber davon aus, dass ich das Projekt eher "alleine" durchziehe. Allerdings erachte ich die Aufgabe als zu groß, als dass ich sie bereits lösen könnte... ... und zu den Nasen, die vor lauter Langeweile nicht wissen, was sie machen sollen, gehöre ich mit Sicherheit nicht. Ganz im Gegenteil. Deshalb würde ich mich freuen, wenn ich, bzw. mein Anliegen etwas ernster genommen würde. Oder ist dies Forum nicht dazu da, um Hilfe zu ersuchen? Gruß Santi
Und warum hast du ein Problem damit, deine konkreten Fragen hier im Forum zu stellen?
Also wenn ich mich nicht irre dann willst du so etwas wie einen Audio-Spectrumsanalyzer bauen ? Das Signal mit einem Mikro aufnehmen per AD-Wandler digitalisieren und dann Graphisch auf einem Display ausgeben. B.z.w. mit intergierten Funktiongenerator um ein Signal zu erzeugen um damit die Raum Akustik auszumessen. Gruss Helmi
Naja, nenn das Kind doch einfach beim Namen: Es geht um einen transportablen digitalen (Mehrspur-?) Audiorecorder. Worte wie "Zerhacker" statt A/D-Wandler etc. verwirren und es macht keinen Spaß raten zu müssen was du damit ausdrücken willst. "nicht an einem Nachmittag entwickelt" ist eine amüsante Verniedlichung, mehrere Mannjahre dürfte man für eine anständige Lösung da wohl schon einplanen. Solche Dinge kannst du bereits fixfertig und in hervorragender Qualität kaufen/besichtigen bei: - Sounddevices - Fostex - Aaton - Zaxcom Tageweise erhältlich bei jedem gutsortiertem Filmequipmentverleiher.
In einem Forum wird es ja meistens nicht so gerne gesehen, wenn sich Leute verabreden, interessante Informationen im Hintergrund per E-Mail auszutauschen. Außerdem macht man sich selten die Mühe, einem Unbekannten ganze Romane mit Know-How zu schreiben. In der Öffentlichkeit, wo jeder sieht, was für ein schlaues Kerlchen man ist, schon viel lieber ;) Außerdem haben so alle mit gleichen Interessen etwas davon. Also sprich dich aus... Was genau möchtest du bauen? Und was ist die erste Frage?
Wieviele Kanäle? Welche Bandbreite, bzw. Abtastrate? (Nein, um Himmels willen, ich werfe es nicht in einen Topf) Welcher Dynamikumfang bzw. Abtastbreite? Irgendwie wirst Du ja auf die 1.5Mb/s gekommen sein. 1.5MBits/s, richtig? Sollen die Daten einfach nur weggespeichert werden? Der Typ mit den Mannjahren hat übertrieben. Auf diese Weise hält er sich in der Firma immer die Arbeit vom Leib :-)
Hallo zusammen, herzlichen Dank für Eure Antworten. > Und warum hast du ein Problem damit, deine konkreten Fragen hier im > Forum zu stellen? Habe ich nicht. Nur da ich ein Kwereinsteiger bin, weiß ich oft nicht, wie man konkret richtig fragt - und schon habe ich einen Thread voll mit Getrolle und Dummgelaber - zum Einen ärgert es mich, zum Anderen ist es lästig, dann zwischendrin die wertvollen Beiträge zu finden. Bei email habe ich einen Spamfilter und die Möglichkeit Beiträge zu löschen - ist also einfacher Ordnung zu halten und der einzige Grund, warum ich emails gegenüber den Threads hier vorziehe. > Also wenn ich mich nicht irre dann willst du so etwas wie einen > Audio-Spectrumsanalyzer bauen ? Der Spectrumanalyzer wäre für mich ein SW-Paket ganz am Schluss. Da gibt es sicher schon Fertiges, was man verwenden könnte, bzw. wenn nicht, vor dem SW-Part habe ich am wenigsten Angst - da bin ich eher zuhause. Windoz gibt es bei mir nur in einer vmware und meine Mehrkanal-Soundkarte (M-Audio Delta 1010LT) wird unter Linux nicht als Eingang erkannt, bzw. ich bekomme es einfach nicht gebacken. Das war der erste Anstoß. Dann ergab sich in der Diskussion, dass Soundkarten unter 100Hz nur eingeschränkt tauglich sind, also für Messungen im Bass- bzw. Infraschallbereich bräuchte man dann sowieso eine andere Lösung. Dann beschäftige ich mich auch mit LS-Bau und in der Diskussion mit einem Hobbykollegen kamen wir drauf, dass für "Freifeldmessungen" ein mobiles Messgerät nicht schlecht wäre - und ich zähle noch zu den wenigen, die kein Schläppable haben. Schließlich habe ich einige Musiker im Freundeskreis - sodass mich Raumakustik und Aufnahme auch sehr interessieren. > Es geht um einen transportablen digitalen (Mehrspur-?) Audiorecorder. Diese Lösung halte ich definiv als unlösbar (zu groß) für mich. Deshalb wollte ich kleiner anfangen. Habe inzwischen einige doppelseitigen Platinen geschnitzt und manche von denen funktionieren sogar. Die Scheu vor SMD habe ich auch schon reduzieren können - es ist also durchaus an der Zeit, mit einem sinnvollen Projekt anzufangen. > Solche Dinge kannst du bereits fixfertig und in hervorragender Qualität > kaufen/besichtigen wie ich bereits schrieb, ist mein Budget sehr schmal. Der Wunsch, Dinge zu wollen, die ich mir nicht leisten kann, haben mich schon früh zum Selbstbau getrieben. > Wieviele Kanäle? > Welche Bandbreite, bzw. Abtastrate? (Nein, um Himmels willen, ich werfe > es nicht in einen Topf) > Welcher Dynamikumfang bzw. Abtastbreite? > Irgendwie wirst Du ja auf die 1.5Mb/s gekommen sein. 1.5MBits/s, > richtig? Wenn ich mich nicht verrechnet habe, sind es 1,2 Megabyte/s - danach habe ich aufgerundet. Aktueller Stand ist der, dass ich gerne einen PCM1804 bei 192kHz Abtastrate einsetzen würde. Wie beim Evalboard des PCM1804 möchte ich den Opa2134 in der Vorstufe verwenden. Die 1,5Mb/s ergeben sich aus 192kHz mal 2 (stereo) mal 3 Byte (24Bit) Ich vermute mal, dass dies bereits grenzwertig für einen mega wird. Bei Akustikmessungen ist ein sinnvolles Messfenster ca. 2-5s lang, d.h. die 5s wären für mich Minimum, was ich Datentechnisch bewältigen können möchte. Mein Kenntnisstand ist der, dass SD-Karten zu langsam für diese Datenrate sind. Vielleicht könnte man jeden Kanal einzeln wegspeichern und in Zusammenhang mit ext. Speicher als Puffer die Datenmenge bewältigen. Dann wären es 3 SD-Karten: eine für Lesedaten (Konfiguration bzw. auszugebende Messmuster) und die anderen beiden für die Schreibdaten (Messdaten). Ich hatte auch einen schönen Speicher bei Ramtron gefunden, dem ich die Daten vom PCM1804 direkt hätte geben wollen - allerdings sprengt der bereits mein Budget (ca 40 Teuronen pro Stück) Wenn sich die Daten vom Durchsatz auf Dauer handlebar herausstellen würden, würde ich gerne Ethernet, bzw. den WIZ830 von Wiznet einsetzen. Auf PC-Seite habe ich einen entsprechenden Prototypen (in Java) geschrieben, um die Machbarkeit zu überprüfen - Konzept funktioniert soweit sehr zufriedenstellend. USB ist für mich rel. unwichtig - ich verwende es höchstens für den Datenaustausch zwischen Linux und Windows. Könnte man aber als Option mit konzipieren. > Der Typ mit den Mannjahren hat übertrieben. Auf diese Weise hält er sich > in der Firma immer die Arbeit vom Leib :-) Das sehe ich auch so, aber mehrere Wochen halte ich für mich für durchaus realistisch. Allein die Herstellung einer doppelseitigen Platine dauert bei mir so 3-5 Tage bis sie einsatzbereit ist. Gruß Santi
>Ich vermute mal, dass dies bereits grenzwertig für einen mega wird.
1,5 MByte/s sind nicht ohne,
ich würde sagen das das für einen Atmega unlösbar ist...
aber ich würde mich über eine Lösung freuen :)
Ein ARM9 mit ausreichend SDRAM langweilt sich zu Tode, während die Daten vom A/D-Wandler per DMA durchgereicht werden. Nach dem Zwischenspeichern das ganze gemütlich auf eine SD-CARD zu speichern, sollte auch nicht das Problem sein. Die kleineren Controller ohne ein vernünftiges Interface für externen Speicher würde ich ausschließen. Ist vielleicht nicht unmöglich, aber vermutlich eine ziemliche Bastelei.
@ Santiago m. H Ich wäre interessiert. Schreib mir mal eine mail auf: a1n2o3n4y5m@gmx.at
Hallo, > 1,5 MByte/s sind nicht ohne, > ich würde sagen das das für einen Atmega unlösbar ist... Ja, ich habe das auch mal überschlagen, d.h. wenn die Daten mit ca. 13 MHz anpurzeln, sollte der µC mit min. 26MHz laufen, um (ohne Interrupts und sonstige Störungen) die Daten von A nach B kopieren zu können. > Ein ARM9 mit ausreichend SDRAM langweilt sich zu Tode, während die Daten > vom A/D-Wandler per DMA durchgereicht werden. Das mag wohl sein. Nur habe ich bislang nur mit megas und seinen kleineren Geschwistern hantiert - also keinen Plan von Arm oder Fuß. Über 20MHz gibt es ja verschiedene Alternativen: - AVR32 - ATXmega (irgendwann) - ARM Jetzt stellt sich für mich die Frage, welche Baureihe bietet für den geplanten Einsatzzweck das beste Preis-/Leistungs-Verhältnis und ist dabei auch noch (relativ) leicht zu erlernen?!? Wenn ich richtig informiert bin, haben alle ein QFP-Gehäuse mit 0.5er Pitch, d.h. der Entwurf und die Bestückung eines passenden Boards wird eine fette Blutpisserei. Wahrscheinlich kann ich die CPU gleich doppelt kaufen, weil die erste beim Versuch sie einzulöten verbrennt ... Also alles in allem nix für mal eben nebenbei. Deshalb wäre es schön, wenn ich vor den Fallstricken gewarnt würde, bevor sie Geld kosten. Die Planung nimmt ja auch einen ordentlichen Zeitraum in Anspruch. Würde es Sinn machen, mit dem XMega zu planen und darauf zu hoffen, dass er erhältlich ist, wenn die Planung soweit abgeschlossen ist? Bzw. reicht ein Xmega überhaupt für das Datenvolumen aus? Er hat zwar auch DMA-Kanäle aber Systemtakt ist nur 32 MHz... @Anonym (Gast) no chance ! Ich bin japanophil und "sensei" ist für mich nicht nur ein Wort, sondern eine Weltanschauung im urtraditionellen Sinne (siehe http://de.wikipedia.org/wiki/Sensei). Nicht jeder kann die Mentor-Rolle ausfüllen. Ein Mentor sollte zumindest die Erfahrung haben, die mir fehlt :) Gruß Santi
>Wahrscheinlich kann ich die CPU gleich doppelt >kaufen, weil die erste beim Versuch sie einzulöten verbrennt ... Einen 2. dazu haben ist im Grunde nie verkehrt. Aber so schlimm ist das aufloeten von Fine Pitch Gehauesen nun aber auch wieder nicht. Du must nur die Pads etwas laenger machen als die normal in den Bibliotheken sind dann geht das ziemlich einfach. Wenn du die Pads etwa 2.5 mm lang machst geht das einfacher als wenn die kuerzer sind. Du kannst dann beim aufloeten das ueberfluessige Loetzinn nach der Seite wegziehen. Gruss Helmi
Die TQFP-Gehäuse mit 0,5mm sind eigentlich kein Problem. Sogar mit einem nicht ganz so feinen Lötkolben. Ich flute das Bauteil immer mit einem guten Flußmittel, benetze eine relativ große Lötkolbenspitze mit einem Tropfen Lötzinn und ziehe diesen dann an der senkrecht gehaltenen Platine über eine Pinreihe. Durch die Oberflächenspannung werden die Zwischenräume zwischen den Pins automatisch wieder frei. Das Ergebnis ist nach der Reinigung von überflüssigem Flußmittel von einer maschinellen Lötung nicht zu unterscheiden. Man muß nur bei der Bestückungsreihenfolge aufpassen, daß man sich den Zugang nicht verbaut, und die Qualität der Platine ist sehr wichtig für das Ergebnis. Lötstopplack hilft ungemein, d.h. eine professionelle (preiswerte Prototypen-) Fertigung ist unbedingt empfohlen. Man könnte auch ein ARM9-CPU-Board kaufen, oder auch eines von den preiswerten AVR32-Boards... Diese führen die meisten Ports auf eine handelsübliche Stiftleiste und lassen sich dann sogar auf Lochrasterplatinen verarbeiten.
Autor: Oliver Döring (odbs) schrieb: >Die TQFP-Gehäuse mit 0,5mm sind eigentlich kein Problem. >Lötstopplack hilft ungemein, Macht der Lötstopplack hier wirklich viel aus? Bei Fine-pitch ist doch in der Regel eh kein Lötstopplack zwischen den einzelnen Pads. Und selbst wenn, perlt das Lot von der nackten Platine nicht ebenso gut wie vom Stopplack ab? @ Santiago m. H. (mausschubser) >Nur da ich ein Kwereinsteiger Quer -- jedenfalls bis zur nächsten Rechtschreibreform.
Der Lötstopplack hilft nicht zwischen den Pins (da ist eh keiner), sondern auf dem Rest der Platine. Mit gutem Flußmittel fließt das Zinn ja an den Leiterbahnen entlang sonstwohin. Gilt insbesondere für passive Bauteile. Je nach Komplexität des Layouts kann man da schonmal den Humor verlieren :)
Hallo zusammen. > Du must nur die Pads etwas laenger machen als die normal in den Bibliotheken > sind dann geht das ziemlich einfach. Das hört sich nach einem guten Tip an :) ... denn genau das empfand ich als Problem, dass das Lötzinn nicht mitkam. > d.h. eine professionelle Fertigung ist unbedingt empfohlen. Hm, damit habe ich mich auch schon beschäftigt, bin dann aber zu dem Schluss gekommen, dass sich die professionelle Fertigung erst ab 4 Lagen für mich lohnen würde. Dazu müsste ich dann erst wieder in CAD-SW investieren - also ne ziemliche Hürde. Bei der Produktion der Platine hatte ich bislang keine Probleme. Gut, das Bohren ist nicht wirklich angenehm, aber ich kenne meine Schwächen und konnte denen schon beim Entwurf begegnen. Der Prozess ist eingespielt und zuverlässig - ich hatte noch keinen Bedarf für Lötstoplack. Das Bestücken empfinde ich persönlich als viel schlimmer und das nimmt mir ja auch bei einer prof. Platine keiner ab. > Quer -- jedenfalls bis zur nächsten Rechtschreibreform. Meine Rechtschreibfehler sind beabsichtigt :) - meine Form eines Augenzwinkerns. Mit fertigen Boards von ARM und So konnte ich mich bislang nicht anfreunden. Ich denke, wenn der Aufwand mit ADC und so einen Wert haben soll, müssen die Leitungen auch recht kurz und gut geschirmt sein. Weiß nicht, ob sich hier ein Platinenwechsel so gut macht. Deshalb würde ich das Layout gerne wegeoptimiert bezüglich der analogen Signale machen. Das heißt dann aber, dass ich ein eigenes Layout entwerfen muss. Ich möchte aber nochmal die Frage nach der "CPU" aufwerfen. Habe nochmal nachgelesen und zumindest bei den Atmel-Armen sind die richtig interessanten Steinchen noch in Entwicklung (d.h. für mich nicht erhältlich?!?) Wenn ich richtig geschaut habe, ist der AT91RM9200 der Einzige mit 3stelligem Systemtakt, Speicherschnittstelle und FP-Gehäuse. Bei den AVR32 wäre der AT32AP7001 wohl der Kandidat der Wahl. Wie sieht es denn mit Blackfin aus? Der ist zwar nicht von Atmel, aber wäre der für die Aufgabe ein Mittel der Wahl? Wie seht Ihr die Einarbeitungszeit in den jeweiligen Prozessortyp? Jetzt hat ja keiner mehr Flash als Programmspeicher, d.h. die Firmware muss von extern geladen werden. Tutorials gibt es für die Kandidaten wohl keine. Hätte Ihr mir ein paar Links zur Einarbeitung (die Wicky Abschnitte habe ich bereits gelesen)? Gruß Santi
Hallo, ich habe nochmal Datenblätter gewälzt und dabei ist folgendes rausgekommen: Der ADC liefert ja die Daten mit 12.288.000 Bit/s. Bei Atmel heißt es, dass bei SPI im Slave-Modus der Systemtakt 2mal so schnell sein müßte, wie der Datentakt: also ca. 25 Mhz. Die Daten werden ja nur byteweise weggeschrieben, also alle 8 Takte bräuchte ich 1-2 Extratakte. Dazu kommt, dass das Protokoll des PCM1804 16 Bit Overhead beinhaltet. Pro Samplevorgang entstehen immer 32 Bit, die übertragen werden (auch wenn davon nur 24 Bit Daten sind). Daraus könnte man ableiten, dass man alle 3 Byte 8 Takte Zeit für Schiebereien hätte. Was meint Ihr? Ob das mit einem XMega (bei 32 MHz) zu schaffen wäre? Ich denke mal, dass bei dem die Ein- / Umarbeitung nicht ganz so groß wäre, wie bei einer komplett anderen Prozessorfamilie. Ich glaube, wenn ich mir so Aufwand und Nutzen anschaue, wäre ich langsam bereit, mich mit einer Samplerate von 96 kHz zu begnügen, wenn ich die Daten dadurch besser verarbeiten könnte :/ Gruß Santi
>Was meint Ihr? Ob das mit einem XMega (bei 32 MHz) zu schaffen wäre? >Ich denke mal, dass bei dem die Ein- / Umarbeitung nicht ganz so groß >wäre, wie bei einer komplett anderen Prozessorfamilie. Guck Dir mal diesen Thread an: Beitrag "ATXMega128 - Erste Erfahrungen" >Ich glaube, wenn ich mir so Aufwand und Nutzen anschaue, wäre ich >langsam bereit, mich mit einer Samplerate von 96 kHz zu begnügen, wenn >ich die Daten dadurch besser verarbeiten könnte :/ Du wirst wahrscheinlich sogar mit noch weniger zufrieden sein müssen. 48kHz x 24 Bit in Stereo sind machbar. Die Datenmenge ist für eine SD-Karte im SPI-Modus auch mal eben noch handhabbar.
Hallo travelrec, herzlichen Dank für Dein statement. Habe den Thread durchgelesen, aber keine Anhaltspunkte für eine Performance-Entscheidung gefunden. > Du wirst wahrscheinlich sogar mit noch weniger zufrieden sein müssen. ... schätze, dann werde ich mich eher mit den größeren Brüdern ARM/AVR32 auseinander setzen müssen. Die Einschränkung erscheint mir im Moment (noch?) zu groß. Wäre schön gewesen, eine Einschätzung von jemand zu bekommen, der alle Familien kennt... ... so werde ich wohl selbst ausprobieren müssen, was geht. Gruß Santi
>Habe den Thread durchgelesen, aber keine Anhaltspunkte für eine >Performance-Entscheidung gefunden. Fakt ist, daß auch wenn der Controller schneller ist, die SD-Karte dann langsam den Flaschenhals darstellt. Während 150kBytes/s über SPI-modus noch lässig weggespeichert werden können (12Bit, 48kHz stereo), sieht das bei 300kBytes (48kHz, 24Bit stereo) schon ganz anders aus, ganz zu schweigen von Deinen angestrebten 600kBytes oder gar 1,2MBytes/s. Und dies gilt nur für ein natives Schreiben ohne Dateisystem. Laß Dir das Ganze nochmal durch den Kopf gehen. Vielleicht wäre eine Compact-Flash oder gleich eine kleine P-ATA-Festplatte die bessere Variante.
Hallo Travel Rec. Danke für den Hinweis. > Fakt ist, daß auch wenn der Controller schneller ist, die SD-Karte dann > langsam den Flaschenhals darstellt. An der Ecke bin ich völlig leidenschaftslos. Habe bislang Tests mit einer Asbach-Uralt-MMC-Karte gemacht, sowie mit einem schnelleren USB-Stick. Ich wußte nicht, dass es auf µC-Seite noch Alternativen gibt. Klar, wenn es was schnelleres als SD-Karte gibt und das vom Meeraufwand halbwegs akzeptabel ist, kostet mich das ein Lächeln :) Bin ja noch in der Planungsphase. Wenn der XMega für die Datenrate sowieso zu knapp wird, kann ich ja gleich mit einem USB-Stick als Speichermedium kalkulieren. AVR32 und ARM haben beide bereits USB an Bord, sollte also machbar sein. Bei den USB-Sticks gibt es ja Teile mit über 20Mb/s Schreibrate (meiner hat meines Wissens 13Mb/s Schreibrate, was ja auch reichen würde). Dass die Entwicklung "etwas" mehr kostet ist mir bewußt. Für das Endprodukt peile ich ca. 50 Öre als Materialkosten an und möchte unbedingt im 2stelligen Bereich bleiben. Mal sehen, wo die Reise hingeht :) Gruß Santi
>AVR32 und ARM >haben beide bereits USB an Bord, sollte also machbar sein. Aufpassen die meisten haben nur den Slave Mode. Was du brauchst um deinen USB -Stick anzusteuern ist der Host-Mode sowie er im PC vorhanden ist. Gruss Helmi
Auch nicht ganz unwichtig ist die Tatsache, daß man für 24Bit Auflösung des ADCs ein sehr ordentliches Layout braucht und eine sehr sauber abgesiebte Versorgung des ADCs. Ich will´s nur mal anmerken, nicht daß Du Dich nachher wunderst, weshalb die unteren 8 Bit wild umherzittern und die verwertbare Auflösung bei gerade mal 16 Bit liegt. Gerade größere Controller mit reichlich Pins, hohen Taktraten und reichlich Peripherie (S(D)RAM und ähnliche Späße) erzeugen viel elektrischen Schmutz, den der ADC gerne aufsammelt.
Und vor allen Dingen brauchen die viel Blech drumherum.
Moin wenn ich das datenblatt vom AD wandler richtig überflogen hab hat der doch ein I2S interface oder? Die einlaufenden daten sollten sich dann doch per internen DMA an den entsprechenden speicher weiterleiten lassen. SD - Card über SPI ist nur eine lösung für die SD - Card. es gibt auch eine kontroller mit SD/MMC Card interface. da sollte das dann sicher machbar sein. 4 Datenleitungen bei 25 Mhz macht maximal 100mbit/s wenn die karte das auf dauer mitmacht. Was ist ggf mit NXP? ist ggf bei den LPC2xxx irgend was dabei? Mit dem LPC2888/80 währe das sicher möglich zu realisieren. nur BGA gehäuse mit 0.5 pitch und hat auf dem MMC Interface noch ein paar macken die noch nicht behoben wurden (stepping 2 ist da schon besser) So hab mich mal auf die suche gemacht MCI Multimedia Card Interface für SD und mmc Cards SSC / I2S interface für streaming audio AT91RM3400 MCI SSC RAM ARM7 66 MHz AT91Sam9260 MCI SSC FLASH RAM USB Host/Device/OTG Ethernet on chip ARM9 180 MHz AT91RM9200 MCI SSC RAM USB Device Ethernet ARM9 180 Mhz LPC 2367/68 MCI SSC FLASH RAM USB Device Ethernet on chip ARM7 72Mhz LPC 2460/68 MCI SSC FLASH RAM USB Device Ethernet on chip ARM7 72Mhz RM3400 aufgrund der Fehlenden Flash würde ich ausschliessen. SAM9260 sowie RM9200 find ich etwas over siced Die leistung reicht für embedded linux. peripheral interface läuft nur mit 60Mhz! würden warscheinlich nur mit SD-Ram wirklich Sinn machen. aufwedig zu entflechten. 66MHz buss zwischen MCU und speicherbaustein. nur im BGA version alle pins verfügbar. Ich würde mich zwischen den beiden LPC versionen entscheiden, Ferner nicht andere nicht berücksichtigte kriterien dagegensprechen.
Hallo zusammen, > Was du brauchst um deinen USB -Stick anzusteuern ist der Host-Mode sowie er > im PC vorhanden ist. OK, damit wäre der AVR32 aus dem Rennen. > Auch nicht ganz unwichtig ist die Tatsache, daß man für 24Bit Auflösung > des ADCs ein sehr ordentliches Layout braucht Habe vor Kurzem für einen Bekannten eine Audioplatine geroutet - einfach weil ich Routen lernen wollte und es mir Spaß gemacht hat. Gut, es war kein ADC, sondern der andere Weg, aber es war ein DC-DC-Converter an Board, der imho auch nicht ganz frei von Umwelteinflüssen ist. Laut Feedback war die Platine ok und er hat sie so produziert. > Gerade größere Controller mit reichlich Pins, hohen Taktraten und > reichlich Peripherie (S(D)RAM und ähnliche Späße) erzeugen viel > elektrischen Schmutz, den der ADC gerne aufsammelt. Würdest Du dann lieber den ADC auf einer getrennten Platine unterbringen und per Kabel verbinden? > Und vor allen Dingen brauchen die viel Blech drumherum. Yepp, das ist mir bekannt. > wenn ich das datenblatt vom AD wandler richtig überflogen hab hat der > doch ein I2S interface oder? Das ist korrekt - allerdings muss ich gestehen, dass ich den Vorteil von I2S noch nicht verstanden habe. Wenn ich mir die Timing-Diagramme im Datenblatt anschaue, wird bei I2S dem Datenwert ein leeres Bit vorgeschoben. Gut, für die Bandbreite ist es unerheblich, da die 24Bit in den übertragenen 32Bit vielfältig verschoben werden können - aber für die Auswertung der Daten ist es doch erst wieder mit Arbeit verbunden. Die anderen Modi waren mir eher einleuchtend, so kann man den Wert gleich weiter verarbeiten (oder schluckt der Speicher das leere erste Bit?). > So hab mich mal auf die suche gemacht Was mich am meisten verunsichert hat, war der Vergleichsthread über mega und ARM. Dort steht, dass ein ARM bei IO-Aufgaben dem mega unterlegen ist und teilweise 3-4 Anweisungen für eine Operation braucht. Wenn das so ist, dann bleiben von möglichen 180MHz nicht mehr viel übrig. Wenn ich vom mega ausgehend kalkuliert habe, dass ich ca. 40 MHz bräuchte, dann wird es bei den 66MHz Teilen auch schon knapp, wenn die nur 2 Takte pro IO-Operation brauchen. Der AT91RM9200 (von Atmel) hätte - neben einem Speicherinterface - USB-Host und Ethernet dabei. Wenn ich beide Schnittstellen unterstützen will, würde es Sinn machen, einen Professor zu nehmen, der die Schnittstellen "nativ" unterstützt, oder sind externe/separate Komponenten vorzuziehen? > Was ist ggf mit NXP? Prinzipiell wäre es egal, da ich mich sowieso einarbeiten muss und andere Mütter sollen ja bekanntlich auch schöne Töchter haben ... Nachdem was ich hier so lesen konnte, scheinen die Atmel-Teile etwas besser (bzw. ehrlicher) als die Konkurrenz zu sein. Außerdem gefällt mir der Support des Hauses... ... ansonsten bin ich aber viel zu unbeleckt, um von Erfahrung reden zu können. BGA Gehäuse will ich mir nicht antun. Ich plane ja auf Selbstbau und habe schon mit den Vielfüßlern zu kämpfen. Das reicht mir. In meinem Anwendungsfall geht es ja in erster Linie um IO-Operationen. Rechenleistung oder Unterstützung für ausgefallene Algorithmen dürften kaum eine Rolle spielen. Bislang liebäugle ich mit dem AT91RM9200 von Atmel - aufgrund der IO-Bausteine und dem möglichen Systemtakt. Allerdings hat der keinen Flashspeicher, d.h. ich müsste die Firmware in externem Flash unterbringen?!? Der interne Speicher erscheint mir auch eher knapp, um Transfer-Puffer verwenden zu können. Wahrscheinlich bräuchte ich also externen Flash und SD-Speicher. Wenn die Peripherie nur mit 60 MHz angebunden ist, könnte evtl. ein ARM7 sinnvoller sein? Allerdings haben die keinen USB-Host, sodass sich die Vorteile relativieren. Wie sieht das bei den Befehlssätzen bezüglich IO aus? Ich las, dass manche Befehle beim ARM9 gegenüber dem ARM7 optimiert wurden. Trifft das auch bei IO zu, oder hauptsächlich im 32bit Bereich? > Ich würde mich zwischen den beiden LPC versionen entscheiden ... Wenn ich das so überblicke, haben nur RM9200 und SAM9260 USB Host. Laut der Übersicht bei Atmel hat der SAM9260 auch kein Flash. Scheint zwar etwas neuer als der RM9200 zu sein, aber das Imagesensor-IF brauche ich nicht. Füße haben beide mehr als mir lieb ist, käme also auf den Preis drauf an.
Hallo, bin gerade etwas erschrocken. Habe eine AppNote von Atmel bezüglich SSC gelesen und dort stand als Limit 48kHz bei 16Bit Breite. Im Datenblatt von AT91RM9200 fand ich derlei Einschränkung nicht. Dort fand ich lediglich die Grenze von 30 MHz für PLL-Eingänge (einen ext. Takt könnte man ja darunter sehen?!?), das könnte dann ja reichen. Kann jemand, der den Chip kennt, was dazu sagen? Gruß Santi
Moin das kann durchaus sein, ich hab nur mal durchgeschaut, was alles MCI und SSC / I2S interface hat. der LPC23xx scheidet auch aus auch nur 48 KHz der LPC24xx somit auch da dort nur 96KHz spezifiziert sind. zum RM9200 (für den hab ich schon mal entwichkeln dürfen) Aus dem Erata teil Receiver Speed Limitations – If RF is programmed as input, the maximum clock frequency is MCK divided by 2. – If RF is programmed as output and RK is programmed as input, the maximum clock frequency is MCK divided by 6. 670 1768G–ATARM–29-Sep-06 AT91RM9200 – If RF and RK are both programmed as output, the maximum clock frequency is MCK divided by 4. Es gibt auch Erata zum MCI ggf auch durchlesen was da alles nicht geht. Du wirst wohl nicht nur Flash sondern auch RAM nachrüsten dürfen. bei nur 16K wirst du nicht weit kommen. Wir haben hier den RM9200 mit SD-RAM im einsatz. richtig net das teil. Flash wurde über einen SPI Baustein nachgerüstet. Der RM9200 kann von dort aus auch eine FW in das interne SRAM nachladen und dann ausführen. von daher ggf einfach zu lösen. reduziert halt nur den ram der für variablen zur verfügung steht. Und welcher Ram nun kostengünstiger und besser zum nachrüsten ist, ist halt die Frage. SD-RAM vergleichsweise für die grösse günsig, hat zeitverluste wegen Page adresseierung und so, läuft aber mit bis zu 60Mhz am RM9200, viele Leitungen, ggf aufwendiges routing (emv, ...)SRAM im vergleich zu SD-Ram bei der speichergrösse relativ teuer. und ab 20MHz wird meines wissens auch im vergleich recht teuer, dafür schneller im zugriff. (nur was das betrifft bin ich nicht umbedingt experte. ich darft das ding nur programmieren ) Weitter solltest du dir mal die pinbelegung des PQFP mit dem BGA vergleichen, meines wissens fehlen dem PQFP einige ports! das kann dann trotz Doppelt und Dreifachbelegung der Pins dazu führen, das gewisse funktionen gar nicht erreichbar sind, oder sich gegenseitig ausschliessen. (doppelt heist, das man aus einer der 2 bis 3 funktionen wählen kann) und wieso USB Host? damit die daten auf einem USB - Stick speichern kannst? und du dir den internen speicher für die Daten sparen kannst? gruss
Santiago m. H. wrote: > Das ist korrekt - allerdings muss ich gestehen, dass ich den Vorteil von > I2S noch nicht verstanden habe. Wenn ich mir die Timing-Diagramme im > Datenblatt anschaue, wird bei I2S dem Datenwert ein leeres Bit > vorgeschoben. Gut, für die Bandbreite ist es unerheblich, da die 24Bit > in den übertragenen 32Bit vielfältig verschoben werden können - aber für > die Auswertung der Daten ist es doch erst wieder mit Arbeit verbunden. > Die anderen Modi waren mir eher einleuchtend, so kann man den Wert > gleich weiter verarbeiten (oder schluckt der Speicher das leere erste > Bit?). Dieses eine (oder mehrere) Bit Offset ist nur auf der physikalischen Strecke vorhanden - im Eingangspuffer legt die I/O-Engine die Daten richtig ab, wenn man den standardisierten Modus nimmt.
Hallo, > Receiver Speed Limitations > – If RF is programmed as input, the maximum clock frequency is MCK > divided by 2. Gut, das deckt sich mit der Beschreibung im Kapitel zu SSC. Masterclock sind 80 MHz, also könnten die Daten mit bis zu 40 MHz antrudeln. Das ist auch beim mega analog so. Halber Systemtakt für SPI-Slave-Mode. Vom ADC kommen die Daten mit knapp 13 MHz, würde also locker passen. > Du wirst wohl nicht nur Flash sondern auch RAM nachrüsten dürfen. bei > nur 16K wirst du nicht weit kommen. Die Befürchtung hatte ich ja schon geäußert. > Weitter solltest du dir mal die pinbelegung des PQFP mit dem BGA > vergleichen, meines wissens fehlen dem PQFP einige ports! OK, werde ich machen. Dann kann ich ja gleich die Symbole für Eagle anlegen. Das Problem mit BGA sehe ich darin, dass ich es nicht mehr verarbeiten kann. Die Platine fertigen lassen bringt mir an der Stelle auch nix, da Bestückung ein anderer Dienstleister ist. So wie ich las, sind die Einrichtungskosten nicht ohne - also werde ich mich wohl auf FP-Gehäuse beschränken (müssen). Vielleicht macht es doch Sinn, ein fertiges Board mit dem µC zu kaufen und den ADC auf einer separaten Platine anzubinden?!? > und wieso USB Host? damit die daten auf einem USB - Stick speichern > kannst? und du dir den internen speicher für die Daten sparen kannst? Im Moment geht es noch garnicht um irgendwas zu sparen, sondern ein realisierbares Konzept zu entwickeln. Auf der einen Seite habe ich das ADC, welches einen Datenstrom liefert, auf der anderen Seite habe ich die "Zweigleisigkeit", dass ich (1.) offline/autark min. 5s des ADC-Datenstromes auf einen wechselbaren Datenträger abspeichern können will (Muss-Kriterium) und (2.) zum anderen (optional, wenn's nicht zuviel Mehraufwand ist) die Messdaten synchron an PC's liefern will. Für letzteres würde ich Ethernet bevorzugen, USB ist an der Stelle eine Option, der ich nicht viel Gewicht beimesse. Für Variante 1 sollte der Speicher möglichst problemlos mit dem PC ausgetauscht werden können. So kam ich auf SD-Karten, bzw. jetzt den USB-Stick. PCMCIA ist wohl für Schläppies ganz angenehm, aber nicht für Standard-PCs. Ich habe gelesen, dass es auch IDE-Treiber für den RM9200 gibt, allerdings halte ich ne Wechselplatte für ein Ungetüm. Nicht wirklich der Bringer für den Outdoor-Einsatz (ja, das Teil sollte nicht zu groß werden). > Dieses eine (oder mehrere) Bit Offset ist nur auf der physikalischen > Strecke vorhanden - im Eingangspuffer legt die I/O-Engine die Daten > richtig ab, wenn man den standardisierten Modus nimmt. Habe gerade gelesen, dass dieses Bit (zumindest im SPI-Modus) nicht maskiert wird, d.h. man bekommt es in die Userdaten :( Aber vielleicht klappt das ja in der SSC-Schnittstelle ... Gruß Santi
Aufpassen mit dem Masterclock, der kann zwar bis zu 80MHz, die Port IOs können aber nur 60 MHz. daher solltest du von 60 ausgehen. Beim Externen Speicher Interface ist es das gleiche.
Und noch kurz zu USB. USB Host (Der ist quasi mit dem im pc gleichzusetzen) an dem kanst du devices anschliessen, wie z.B. einen Memory Stick, Tastatur, Maus, Externe Festplatte, .... mit der Beschränkung auf maximal 12 MBit. USB Device ist das gegenstück, damit kannst du dein Gerät am PC anschliessen. z.B. kannst du die daten direckt verschicken, oder über z.B. Massstorage Classe die daten auf dem Internen Massenspeicher auslesen.
Hmm, ich finde man sollte das anders herum angehen: Aufgabenstellung: Ich möchte Audio-Signale aufzeichenen oder analysieren Welche Verfahren will ich benutzen ? ??? Jetzt ergibt sich eine ~ Rechenleistung. Dann mache ich mir Gedanken über die Daten die ich wegspeichern will. Daraus folgt: Ich würde ein Modul bauen oder nehmen (vielleicht kaufen) das erstmal über USB2.0 PC Interface die Daten bereitstellt. Dann kann man erstmal die Daten analysieren, optimieren und flexibel die Probleme anschauen. Wenn ich jetzt das Ganze einigermassen im Griff habe (C-Code; das gewünschte läuft...), würde ich mir Gedanken über ein autarkes Gerät machen, wo ich dann den Prozessor auch auf einen Fall oder mehrere mit Puffer für Rechenleistung und Datenspeicherung auslege. Gruß Sven
Nachtrag: Dann kann man später die Daten einfach vor dem USB Chip parallel abgreifen und weiterverarbeiten. Gruß Sven P.S.: Es gab mal einen Link mit einem USB2.0 Chip an einer Uni, wo analoge Signale analysiert wurden; wenn ich mich richtig erinnere; finde den Link aber gerade nicht....
Hallo, > Und noch kurz zu USB. Hat Helmi bereits hier (Beitrag "Re: Suche Mentor für Entwicklung eines Audio-Messwert-Erfassers") geschrieben. @Sven > Hmm, ich finde man sollte das anders herum angehen So ähnlich habe ich es bereits gemacht. War eine von meinen (selbstgestellten) Einarbeitungsaufgaben. Allerdings mit einem mega. Dort habe ich Messdaten per internem ADC erfasst und via paralleler Schnittstelle zum PC übertragen. Dort hatte ich mir einen Treiber geschrieben, der aus den Daten einen Netzwerkstream erzeugt hat. Die Messdaten habe ich per Kraftsensor erzeugt und per Instrumentenverstärker angebunden. Dazu schrieb ich eine grafische Anwendung, die Messdaten anzeigen kann. Danach konnte ich mich von jedem Rechner bei dem Messdatenstrom anmelden und die Daten mit der Oberfläche anzeigen (auch von mehreren gleichzeitig). Das war die Situation, die mich zu der Überzeugung brachte, dass eine Ethernet-Schnittstelle universeller einsetzbar wäre, als eine USB-Schnittstelle. Dann bräuchte ich das Erfassungsgerät nur am Switch einstecken und alle PCs im Netz könnten die Messdaten abrufen. Das geht per USB natürlich nur auf Umwegen. Jetzt könnte ich natürlich auch USB ganz sein lassen und nur mit SD-Speicher bzw. Flash oder Eprom arbeiten (im standalone-Modus). Die Daten könnte ich ja auch per Ethernet vom PC aus auslesen. Die 5s Messdaten sollten allerdings schon in einem nichtflüchtigen Speicher abgelegt werden. Vielleicht ginge die Variante sogar mit einem kleineren Arm? Ich müsste ja auch nicht die SSC-Schnittstelle verwenden. Die seriellen Daten ließen sich doch auch per SPI o.ä. einlesen?!? Wie ich eingangs schon schrieb, ein paar (Spiel-)Platinen habe ich bereits zum Laufen gebracht. Jetzt geht es um eine "richtige" Anwendung. War mir schon klar, dass der Übergang von Übungsaufgaben zum richtigen Leben ein größerer Schritt wird. Aber so schnell lasse ich mich nicht entmutigen :) Gruß Santi
Die seriellen Daten ließen sich doch auch per SPI o.ä. einlesen?!? Nein, alle 8Bit gibt es eine Pause, in der Du per INT oder Polling das Byte abholen müßtest. Derweil hat Dein ADC schon fleißig weitergesendet, mindestens 2 Bit.
Hallo Travel Rec. herzlichen Dank für Deine Aufmerksamkeit! >> Die seriellen >> Daten ließen sich doch auch per SPI o.ä. einlesen?!? > Nein, alle 8Bit gibt es eine Pause, in der Du per INT oder Polling das > Byte abholen müßtest. Derweil hat Dein ADC schon fleißig weitergesendet, > mindestens 2 Bit. Auch wenn dieser Punkt nur noch von akademischem Interesse ist (mir wurde in dem Beitrag "Re: Vergleich der µCs nach IO-Performance" empfohlen, doch die Schiebereien in externe HW zu verlagern - ein Punkt der mir sofort eingeleuchtet hat), habe ich - zumindest bei Atmel - das Datenblatt anders verstanden:
1 | The system is single buffered in the transmit direction and double |
2 | buffered in the receive direction. This means that bytes to be transmitted |
3 | cannot be written to the SPI Data Register before the entire shift cycle is |
4 | completed. When receiving data, however, a received character must be read |
5 | from the SPI Data Register before the next character has been completely |
6 | shifted in. Otherwise, the first byte is lost. |
Ich hatte das so verstanden, dass man 7 Takte Zeit hätte, ein empfangenes Byte auszulesen. Wenn ich jetzt ein externes Schieberegister mit Latch (z.B. 74HC595) nehme, müsste die Zeit auf jeden Fall reichen. Fehlt mir nur noch eine Idee, den Byte-Trigger für das Latch zu bekommen. Gruß Santi
moin I2S über SPI? einen 3 draht bus über einen 2 Draht buss? I2S hat Clock, Data und Frame Leitung. Ausser der AD Baustein hat einen SPI Mode. so wie ich die AT91er kenne, und denn ssc, hat der sogar eine DMA einheit, du kanst somit sagen, schiebe mir n Byts aus dem SSC an speicherstelle y. Du must somit nicht mehr jedes Byte einzeln von hand durch die gegend schieben ( pollen ob da oder per IRQ). das macht alles der Controller schon für dich. Zweitens sind die aufbauten eines arms nicht immer umbedingt einfach zu verstehen. 4 oder 6 fache AHB Busse; das sind quasi 4 oder 6 paralelle interne busse, auf denen paralel daten vom Flash richtung CPU und Daten vom SSC Richtung RAM laufen können ohne sich gleich gegenseitig zu blockieren. ggf dann noch mehrere interne andere busse. Die Busse sind meist alle 32 bit breit ausgelegt. Es kommt immer auf die Funktionseinheit an, ob 8/16/32 bit transfers möglich sind. ggf haben die einheiten auch noch FIFOs
Hallo Termite, > I2S über SPI? einen 3 draht bus über einen 2 Draht buss? Warum nicht? Die eigentlichen Daten kommen ja über 2 Drähte. Der dritte enthält lediglich Informationen darüber, zu welchem Kanal der übertragene Wert gehört. Bei dem konkreten ADC wechselt der 3. Draht alle 4 Byte seinen Status, d.h. im SPI-Interrupt bräuchte ich nur den Pinstatus abfragen. Da nur 3 der 4 Byte wirklich Daten enthalten, könnte ich das 4. Byte grundsätzlich ignorieren und so z.B. auch RAM-Speicher sparen. > Du must somit nicht mehr jedes Byte einzeln von hand durch die gegend > schieben 25% Speicher sinnlos verbraten kommt mir rel. viel vor. Da würde es für mich schon Sinn machen, die Bytes einzeln zu schaufeln. > Zweitens sind die aufbauten eines arms nicht immer umbedingt einfach zu > verstehen. 4 oder 6 fache AHB Busse; das sind quasi 4 oder 6 paralelle > interne busse, auf denen paralel daten vom Flash richtung CPU und Daten > vom SSC Richtung RAM laufen können ohne sich gleich gegenseitig zu > blockieren. ggf dann noch mehrere interne andere busse. Die Busse sind > meist alle 32 bit breit ausgelegt. Heißt das, dass so ein Datentransfer wirklich ohne CPU-Beteiligung abläuft? Beim AVR gibt es ja nur einen Bus, d.h. es kann keine gleichzeitigen Datenbewegungen geben. Zumindest habe ich das so verstanden. Gruß Santi
Santiago m. H. wrote: > Hallo Termite, > >> I2S über SPI? einen 3 draht bus über einen 2 Draht buss? > > Warum nicht? Weil du dir das Leben unnötig schwer machst. I2S pur ist eine saubere Lösung. > Heißt das, dass so ein Datentransfer wirklich ohne CPU-Beteiligung > abläuft? Indeed! http://de.wikipedia.org/wiki/Direct_Memory_Access > Beim AVR gibt es ja nur einen Bus, d.h. es kann keine gleichzeitigen > Datenbewegungen geben. Zumindest habe ich das so verstanden. Ist ja auch nur Spielzeug ;^)
Der XMega verfügt auch über DMA, ich werde mal testen, ob dies in Verbindung mit dem Event-System dazu in der Lage ist, schnell genug die Daten vom Port zu lesen, die mir der Tiny vom I2S zusammengesetzt hat. Mit Interrupt funktionieren 16Bit/48kHz sauber als Ein- und Ausgabe. Das Datenaufkommen ist für die SD-Karte noch nicht grenzwertig. Wenn alles sauber programmiert ist, reicht mir das als Wave-Recorder für unterwegs völlig aus. Durch die Anbindung von TOSLINK Bausteinen wird eine digitale Überspielung auf und von bspw. einem Computer ohne weitere Verluste möglich.
Hallo Travel Rec. > Der XMega verfügt auch über DMA, ich werde mal testen, ob dies in > Verbindung mit dem Event-System dazu in der Lage ist, schnell genug die > Daten vom Port zu lesen, die mir der Tiny vom I2S zusammengesetzt hat. Nun, wenn der Tiny die I2S-Daten verarbeiten konnte, kann ich mir nicht vorstellen, warum der XMega dann Probleme bekommen sollte. Das Nadelöhr ist doch der Tiny, da der "nur" mit 20 MHz, der XMega hingegen mit 32 MHz getaktet werden kann (deshalb gehe ich auch davon aus, dass der XMega schnellere serielle Daten verarbeiten könnte, als der Tiny). ... und die Daten sind doch bereits um das 8fache verlangsamt worden. Genau wie bei Verwendung eines externen Schieberegisters. > Das Datenaufkommen ist für die SD-Karte noch nicht grenzwertig. Da gehe ich auch von aus. Habe gesehen, dass es SD-Karten mit einer Schreibrate von 20 MByte/s gibt, ich sehe also keine Grund, mit Compactflash-Gefumsel anzufangen (ich halte schon die HW-Schnittstelle für umstritten ;) ). Wenn ich es richtig verstanden habe, gibt es neben dem SPI-Modus auch noch einen "Burst"-Modus oder so, bei dem ganze Blöcke übertragen werden. Mit etwas Speicher könnte man so die Schreibraten auch noch pimpen :) So wie ich Dich im anderen Thread verstanden habe, hat der XMega kein echtes DMA, d.h. während der DMA-Übertragung kann die CPU nix anderes machen. Wenn dem so wäre, wäre es interessant zu untersuchen, was passiert, wenn während der DMA-Übertragung ein Interrupt auftritt, der auch Daten verschieben will. > Durch die Anbindung von TOSLINK Bausteinen wird eine > digitale Überspielung auf und von bspw. einem Computer ohne weitere > Verluste möglich. Meinst Du damit die Verwendung von CS8406 o.ä.? Wenn ich recht informiert bin, bezeichnen TOSLINK nur die optischen Stecker, nicht aber ein Datenformat. SPDIF ist meines Wissens nur bis 48kHz spezifiziert. Gruß Santi
Moin sd card mit 20MByte/s? das aber nur mit HighSpeed Carten. die normalen können rein Theoretisch nur 12.5MByte/s. Die HS 25MByte/s und wie komm ich darauf? SD - Card Interface hat 4 Datenleitungen. Maximale Datenfrequenz ist 25MHz macht somit 12.5MByte/s (bei HS sind 50MHz). Da gehen aber noch die Zeiten für die Kommandos ab; sind zwar auf einer separaten leitung, läuft aber sequenziell ab. weiter braucht die karte nach dem empfangen eines Datenblockes auch noch etwas zeit diesen zu speichern. Ich hab mir mal den SSC vom RM9200 gestern etwas überflogen. Es sieht auf den ersten blick würklich so aus, als würde der aus den 24 eintrudelden bits 32 bits machen. Da die SSC einheit aber keine reine I2S einheit ist, sind da recht viele einstellmöglichkeiten vorhanden. ggf läst sich das über 8bit je datenwort 3 Datenwörter je Frame, etwas triksen. andere möglichkeit währe, das Framesignal durch eine externe schaltung zu manipulieren so das es nur 8 bit lang ist anstelle der 24bit, dann sollte das nach meinem bisherigen verstehen der ssc einheit gehen. ( 8bit je Datenwort, 1 Datenwort start length, 6 Datenworte je Frame ) oder auf 16bit. noch ein hinweis: Schreib bei I2S doch bitte dazu das du 24Bit bei 192Khz haben willst. In dem anderen Thread haben das glaubich noch nicht alle mitbekommen. das ist für I2S schon recht extrem. Allein durch diese angabe fallen schon viele kontroller aus dem Raster, da sie nur 96 oder sogar nur 48 KHz können. Was für reine Audioanwendungen auch ausreichend ist. (48 konsumer elektroniks MP3 Handy, 96 oberes mittelfeld, 192 ist dann somit High end class) RM9200 gibts meines wissens auch als rigel bord. sieht so aus wie eine SO-DIMM mit SD-RAM und Flash on borad. für ca 50 Euros
Hallo Termite, > sd card mit 20MByte/s? Guckst Du hier: http://www.alternate.de/html/product/Speichermedien_Secure_Digital/Sandisk/Secure_Digital_Card/273675/?tn=HARDWARE&l1=Speichermedien&l2=Secure+Digital > Ich hab mir mal den SSC vom RM9200 gestern etwas überflogen. Es sieht > auf den ersten blick würklich so aus, als würde der aus den 24 > eintrudelden bits 32 bits machen. Also beim PCM1804 ist es so, dass bereits 32Bit weggeschickt werden - zumindest verstehe ich das Datenblatt so. Könnte sein, dass I2S eine Framesize von 32Bit vorschreibt?!? Ansonsten kann ich mir nicht vorstellen, warum man so Bandbreite verschwendet. Wie auch immer - ich habe jedenfalls vor, die Framelänge auf 24Bit zu verkleinern. Das Ganze soll dann als WAV-Datei auf der SD-Karte landen. Bei WAV-Dateien kann man ja festlegen, dass die Samplebreite 24Bit beträgt, sollte also möglich sein, standardkonform zu arbeiten. > ggf läst sich das über 8bit je datenwort 3 Datenwörter je Frame, etwas > triksen. andere möglichkeit währe, das Framesignal durch eine externe ... Nun ich denke, dass in meinem konkreten Fall DMA nicht das Mittel der Wahl wäre. Zumindest nicht für die Eingangsdaten. Beim Schreiben auf SD-Karte könnte DMA dagegeben viel Entspannung bringen. Beim Erzeugen des Netzwerk-Datenstroms gehe ich auch davon aus, dass ich die Frames selbst erzeuge, d.h. auch hier wird mir DMA wohl wenig bringen. > Was für reine Audioanwendungen auch ausreichend ist Nun für mich steht die Messtechnik im Vordergrund. Da das Umfeld leichter zu verstehen ist, wenn ich von Audiodaten rede, habe ich es so gemacht ;) ... und unter messtechnischen Aspekten wurde mir empfohlen, Tastbreite und Tastrate möglichst hoch zu wählen, um so einen guten SNR-Wert zu erreichen. Was die Praxis dann dazu sagt, ist ein anders Thema :) > RM9200 gibts meines wissens auch als rigel bord. sieht so aus wie eine > SO-DIMM mit SD-RAM und Flash on borad. für ca 50 Euros Hm, das klingt sehr interessant. Hast Du zufällig eine Bezugsadresse? Gruß Santi
> Also beim PCM1804 ist es so, dass bereits 32Bit weggeschickt werden - > zumindest verstehe ich das Datenblatt so. http://focus.ti.com/lit/ds/symlink/pcm1804.pdf Seite 21: FMT1 FMT0 Master Slave Low High PCM, I2S, 24-bit Yes Yes > Könnte sein, dass I2S eine Framesize von 32Bit vorschreibt?!? Ansonsten > kann ich mir nicht vorstellen, warum man so Bandbreite verschwendet. Nein, http://www.nxp.com/acrobat_download/various/I2SBUS.pdf > ... und unter messtechnischen Aspekten wurde mir empfohlen, Tastbreite > und Tastrate möglichst hoch zu wählen, um so einen guten SNR-Wert zu > erreichen. Theoretisch, ja, praktisch, eher nein. Bei Audio wird SNRrms normalerweise als SNR verkauft (SNR = 6.02 * n + 1.76 (Sinus)). Beim PCM1804 (viel besser sind andere Audio ADCs auch nicht) sind es gerade einmal 111 dB (bei jeder Abtastrate) also 18-Bit oder 18 - 2.72 ~ 15.4 Bit peak-to-peak. Nutzt man das Oversampling mit 192 kHz und "rechnet" das wieder auf 48 kHz runter hätte man 16.4 Bit... Gute Artikel zur Audio-Verarbeitung, Abtastraten und Auflösung http://www.edn.com/index.asp?layout=article&articleid=CA272755 http://www.edn.com/index.asp?layout=article&articleid=CA276213 p.s. um auf den Vorschlag im anderen Thread zurückzukommen Beitrag "Re: Vergleich der µCs nach IO-Performance" der angesprochene Controller bzw. das Dev-Kit hätte alle Voraussetzungen inkl. div. Software-Stacks.
Hallo, >> Also beim PCM1804 ist es so, dass bereits 32Bit weggeschickt werden - >> zumindest verstehe ich das Datenblatt so. > > http://focus.ti.com/lit/ds/symlink/pcm1804.pdf > Seite 21: > FMT1 FMT0 Master Slave > Low High PCM, I2S, 24-bit Yes Yes Also auf Seite 22 sieht man beim I2S Timing Diagram, dass vor den 24Bit "Nutzdaten" ein Bit zum Vorspülen getrunken wird und nach den 24 Bit Nutzdaten wird auf der BCK-Leitung noch lustig weiter gezappelt. Auf Seite 23 kann man schließlich lesen, dass die BCK-Periode 64 Takte dauert (für mich 2x 32 Bit). Unter Fußnote 3 steht, dass die BCK-Periode im Mastermodus immer 64 Takte dauert. > Beim PCM1804 (viel besser sind andere Audio ADCs auch nicht) Ähm - ich dachte, der PCM1804 wäre ein gutes Steinchen. Dein Kommentar liest sich jetzt aber nicht so, als ob Du dem zustimmen würdest ... grübel, grummel, umpf ... ... ach so ja, Danke auch für die Links. Werde mal etwas kwer lesen. Gruß Santi
Hallo Arc Net, ich habe die Links mal überflogen - ich konnte nichts wirklich Neues entdecken. Ich denke, mit dem Unterschied zwischen Theorie und Praxis hat jeder zu kämpfen - insofern betrachte ich derlei Abweichungen als völlig normal. Ursprünglich wollte ich mal mit den internen ADCs des mega anfangen, aber dann riet mir jemand von ab und meinte, dass ich damit auf höchstens 50db SNR käme. Insofern wäre der PCM1804 schon mehr als doppelt so gut (real :) ). Ich habe gerade nochmal die Datenblätter der möglichen Alternativen durchgesehen und keins gefunden, bei dem der SNR-Wert besser als bei dem TI-Steinchen wäre. Gut, bei Cirrus habe ich derlei Werte überhaupt nicht gefunden, weiß also nicht, wie gut die sind. Der AD7765 kommt zwar auf 112db, kann aber nur mit 156k sampeln. Außerdem kostet ein Kanal 30% mehr, als der komplette PCM1804. Für mich bot der PCM1804 das beste Preis-/Leistungsverhältnis im 24Bit-Segment. Wenn ich da falsch liege, würde ich mich über Erleuchtung freuen. > der angesprochene Controller bzw. das Dev-Kit hätte alle Voraussetzungen > inkl. div. Software-Stacks. Danke, aber ich versuche erstmal in der Welt der bekannten 8Bitter zu bleiben (also Atmel, bzw. Microchip). Das kostet mich im Augenblick die wenigste Einarbeitungszeit und das Testboard kann ich selbst machen, bzw. kann lernen es selbst zu machen :D Ich werde sicher auf dem Weg noch genug Geld in den Sand setzen, da muss ich nicht schon mit einem "teuren" Evalboard anfangen. Insbesondere wenn es eine realistische Alternative gibt. Wenn ich merke, dass es mit den Hobbiistenchips absolut nicht zu packen ist, kann ich immer noch Geld ausgeben ;) Ich bin schon froh, dass sich in der Theorie die Prozesskette schließen ließ, bzw. dass mir das Ganze inzwischen als machbar vorkommt. Jetzt geht es ans Umsetzen und ausprobieren. Gruß Santi
Santiago m. H. wrote: > Also auf Seite 22 sieht man beim I2S Timing Diagram, dass vor den 24Bit > "Nutzdaten" ein Bit zum Vorspülen getrunken wird und nach den 24 Bit > Nutzdaten wird auf der BCK-Leitung noch lustig weiter gezappelt. Das "Vorspülen" ist normal, da WS bzw. LRCK immer einen Takt vor den Daten umgeschaltet wird (aus Sicht des Empfängers) > Auf Seite 23 kann man schließlich lesen, dass die BCK-Periode 64 Takte > dauert (für mich 2x 32 Bit). Unter Fußnote 3 steht, dass die BCK-Periode > im Mastermodus immer 64 Takte dauert. Im Mastermodus, sonst gehen auch 48 fs also 2 24 fs > Ähm - ich dachte, der PCM1804 wäre ein gutes Steinchen. und > Ich habe gerade nochmal die Datenblätter der möglichen Alternativen > durchgesehen und keins gefunden, bei dem der SNR-Wert besser als bei dem > TI-Steinchen wäre. Gut, bei Cirrus habe ich derlei Werte überhaupt nicht > gefunden, weiß also nicht, wie gut die sind. Der AD7765 kommt zwar auf > 112db, kann aber nur mit 156k sampeln. Außerdem kostet ein Kanal 30% > mehr, als der komplette PCM1804. > Für mich bot der PCM1804 das beste Preis-/Leistungsverhältnis im > 24 Bit-Segment. Ohne jetzt nachgesehen zu haben, könnte man sich auch noch die Wandler/Codecs von Wolfson und AKM ansehen, aber wie gesagt "viel besser sind andere Audio ADCs auch nicht" ;-) (vllt hätte oben noch hinzugefügt werden können, "wenn überhaupt") Zu SNR, SINAD, THD+N nur kurz soviel: Bei gleicher Signalamplitude und Frequenz/Bandbreite gilt: SNR(dB) = 20 log10(S / N) THD(dB) = 20 log10(S / D) THD+N(dB) = SINAD(dB) = 20 log10(S / (D + N)) ENOB = (SINAD - 1.76 dB) / 6.02 S = Signal, N = Noise, D = Distortion > Danke, aber ich versuche erstmal in der Welt der bekannten 8Bitter zu > bleiben (also Atmel, bzw. Microchip). Das kostet mich im Augenblick die > wenigste Einarbeitungszeit und das Testboard kann ich selbst machen, > bzw. kann lernen es selbst zu machen :D Mal kurz überschlagen: 192 kHz 24 Bits 2 = 1152000 Bytes/s d.h. die minimale Interruptfrequenz sind 384 kHz, der AVR hat bei Interrupts einen Mindestoverhead von 4 + 4 Taktzyklen, käme man mit 16 Taktzyklen für die Interruptroutine aus, wären das schon 9216000 Taktzyklen pro Sekunde
Ich denke mal, daß hier die Abtastrate und Auflösung unnötig hoch gegriffen ist und somit viel zu viele Daten mit viel zu hoher Frequenz durch etwas zu untermotorisierte Controller verarbeitet werden sollen. Das kann nicht gehen. Ich hoffe mal, daß der OP nicht auch Gleichspannungen messen will, denn das geht mit den Audio-ADCs gleich gar nicht. Zumindest die neueren Chips haben digitale Hochpässe, die DC-Anteile aus dem Signal filtern. Ich bastel derweil mal an meinem Wave-Recorder weiter. Ich habe jetzt mal das DMA in Verbindung mit dem Event-System des XMega bemüht, welches mir ein etwas besseres Timing als ein nackter Interrupt beschert. Mehr als 16Bit und 48kHz sind aber trotzdem nicht drin. Der theoretische SNR sollte bei unter -90db liegen. Auf der DAC-Schiene ebenfalls. Praktisch werden etwa -80db zu erreichen sein - ein angeschlossenes Stück kabel rauscht/brummt bereits mehr. Ich verwende Cirrus-Wandler, CS5343 und CS4344 und als Interface CS8406 und CS84016.
Moin, >> Auf Seite 23 kann man schließlich lesen, dass die BCK-Periode 64 Takte >> dauert (für mich 2x 32 Bit). Unter Fußnote 3 steht, dass die BCK-Periode >> im Mastermodus immer 64 Takte dauert. > > Im Mastermodus, sonst gehen auch 48 fs also 2 24 fs Yepp, nur darf man nicht vergessen, im Slave-Modus muss man dem ADC einen Takt liefern. Also für den Dirigenten nochmal die Gegenüberstellung: Sklave: 192 kHz, 25 Bit, 2 Kanal = 9,6 MBit/s oder 1,20 MByte/s Cheffe: 192 kHz, 32 Bit, 2 Kanal = 12,3 MBit/s oder 1,54 MByte/s Bei Atmel braucht der SPI-Receiver 2 Systemtakte um ein Bit zu erfassen, bei Microchip sind es 4 Systemtakte, d.h. für die direkte Verarbeitung gilt für beide: die Sklaven-Variante wäre grenzwertig machbar, für die Herrenversion wird eine fürstlichere Lösung benötigt. Der ADC braucht für die 192er Samplerate einen Systemtakt von 24,576 MHz oder 36,864 MHz. Da ich nicht weiß, wie ich derlei Takte im Sklavenmodus erzeugen soll, lasse ich es lieber und versuche die Herrenversion anzugehen. Das heißt, entweder eine CPU, die die 12,3 MBit/s IO locker wegsteckt, oder ein externes Schieberegister. Mit externem Schieberegister (74HC595) in Verbindung mit einem Frequenzteiler werden die Daten parallel verarbeitet mit 1.536.000 Anweisungen / s ... ... das Ganze per Interrupt getriggert, kostet sogar eine Tina nur ein müdes Lächeln :) Hat den angenehmen Nebeneffekt, dass ich CPU und funktionierendes Testboard bereits besitze, die Toolchain funktioniert und Einarbeitungszeit habe ich bereits hinter mir. > Ohne jetzt nachgesehen zu haben, könnte man sich auch noch die > Wandler/Codecs von Wolfson und AKM ansehen Ich bin da recht pragmatisch. Wenn ich einen Baustein zur Verwendung suche, verwende ich gerne die Shopseiten von Farnell (auch wenn ich dort nicht einkaufen darf). Zum einen bieten die, neben dem Preisvergleich, auch die wichtigsten Eckdaten und zum anderen gehe ich davon aus, dass Teile, die dort nicht im Sortiment sind, eher zu den Exoten gehören. Das gilt natürlich nicht nur für ADCs, sondern auch für CPUs. Auch wenn es die cyans inzwischen zu Farnell geschafft haben, eine Suche im "µC & Elektronik" -Forum liefert genau einen Treffer. Was für mich auch heißt, dass es sich hier um Exoten handelt. Die müssen deshalb nicht schlecht sein, aber wenn ich dort Unterstützung suche, sehe ich vielleicht noch älter aus, als ich schon bin. 100 Tacken als Startgeld sind (für mich) schon eine deutliche Hürde - da will ich dann auch längerfristig was davon haben :) In der Preisklasse macht mich das ATNGW100 am ehesten an. Nachdem sich jetzt herausgestellt hat, dass die dsPICs den Mastermode auch nicht schaffen, will ich versuchen, wie weit ich mit der Variante mit dem externen Schieberegister komme. @Travel Rec. schön von Dir zu lesen :) > Ich denke mal, daß hier die Abtastrate und Auflösung unnötig hoch > gegriffen ist und somit viel zu viele Daten mit viel zu hoher Frequenz > durch etwas zu untermotorisierte Controller verarbeitet werden sollen. Da ich zu den "normalsterblichen" gehöre, die noch auf die XMegas warten müssen, versuche ich auch hier eine Mischung aus durchgeknallt und pragmatisch zu sein :D > Ich hoffe mal, daß der OP nicht auch Gleichspannungen messen will OP wie OPA? - :) also wennste mir meinst, ik wees, dat de Teile einen Hochpass haben und kann gut damit leben. > Praktisch werden etwa -80db zu erreichen sein praktische Erfahrungen würde ich gerne noch mehr mit Dir austauschen. Aber dazu bin ich noch nicht in der Lage. Also noch ein, zwei Lager ... > Ich verwende Cirrus-Wandler, CS5343 und CS4344 und als Interface CS8406 > und CS84016. Yepp, Deine Seiten sind aufschlussreicher/erfreulicher, als die Datenblätter der Cirrusteile :) Da ich noch kein Ossi habe, kann ich kein Kabelbrummen messen. Aber auch das soll sich noch irgendwann ändern. Gruß Santi
Nachtrag, wenn man keine 192 kHz "braucht", sind die UDA1361 recht interessante Kandidaten. Gruß Santi
>Da ich zu den "normalsterblichen" gehöre, die noch auf die XMegas warten >müssen, versuche ich auch hier eine Mischung aus durchgeknallt und >pragmatisch zu sein :D Mußt nicht mehr lange warten - im Herbst soll´s los gehen. >wenn man keine 192 kHz "braucht", sind die UDA1361 recht interessante >Kandidaten. Ich bleibe lieber bei Cirrus. Sind günstig, gut, einfacher zu beschalten und sehr klein ;-). Die 100db SNR von NXP sind sicher auch sehr optimistisch. Schon ein Leiterzug von 3cm und ein Kondensator und die Widerstände am Eingang machen dies zunichte ;-) >Yepp, Deine Seiten sind aufschlussreicher/erfreulicher, als die >Datenblätter der Cirrusteile :) Freut mich, aber ich habe auch alles den Datenblättern und AppNotes entnommen.
Hallo Travel Rec., >>Da ich zu den "normalsterblichen" gehöre, die noch auf die XMegas warten >>müssen, versuche ich auch hier eine Mischung aus durchgeknallt und >>pragmatisch zu sein :D > > Mußt nicht mehr lange warten - im Herbst soll´s los gehen. Yo, wenn dann der Preis auch noch erträglich ist, bin ich dabei. > Ich bleibe lieber bei Cirrus. Sind günstig, gut, einfacher zu beschalten > und sehr klein ;-) Insbesondere mit dem letzten Punkt steh ich auf Kriegsfuß. Habe Wurstfinger und Parkinson ;) Vor der Bestückung hab ich den meisten Mores! >>Yepp, Deine Seiten sind aufschlussreicher/erfreulicher, als die >>Datenblätter der Cirrusteile :) > > Freut mich, aber ich habe auch alles den Datenblättern und AppNotes > entnommen. Hey, damit meinte ich natürlich den Teil, der von Dir stammt :) Gruß Santi
Hallo, > Ich bleibe lieber bei Cirrus. Sind günstig, gut, einfacher zu beschalten ... habe mir den Punkt "einfacher zu beschalten" nochmal angeschaut und kann das nicht nachvollziehen. Beim CS5381 wird der gleiche analoge Eingangspuffer mit 2 OPs + Hühnerfutter (pro Kanal) empfohlen, wie beim PCM1804. Die von Dir verwendeten ADCs haben keinen Differentialeingang, d.h. Du wirst wahrscheinlich sogar einen INA217 o.ä. davor setzen. Rein pekuniär sind das 5,5 Teuronen im Vergleich zu 1,8 - damit ist der Preisvorteil der CS-Teile auch wieder dahin. Bleibt also alles Einstein ;) P.S. habe entdeckt, dass der XMega mit dem Mastermodus auch nicht mit kommt. Wenn's also mit der Schieberei nicht klappen sollte muss ich wohl doch zu den Erwachsenen wechseln.
Angehängte Dateien:
-
CS5343_1.PNG
28 KB
>habe mir den Punkt "einfacher zu beschalten" nochmal angeschaut und kann >das nicht nachvollziehen. Siehe Anhang.
>Die von Dir verwendeten ADCs haben keinen Differentialeingang, d.h. Du >wirst wahrscheinlich sogar einen INA217 o.ä. davor setzen. Nö - für Audio braucht man nicht zwingend einen Differenzeingang. Line-Signale sind unsymmetrisch. >P.S. habe entdeckt, dass der XMega mit dem Mastermodus auch nicht mit >kommt. Wenn's also mit der Schieberei nicht klappen sollte muss ich wohl >doch zu den Erwachsenen wechseln. Deshalb habe ich die Tinys draußen dran. Die sind quasi als Schieberegister mit Parallelausgang und Strobeleitung programmiert und übergeben bzw holen die Daten in einer der beiden I2S-Lücken zwischen Bit24 und Bit32 byteweise in / aus dem XMega. Dieser kann sich auf das Bearbeiten der Daten konzentrieren, nicht auf deren Aufbereitung. Die Tinys sind nämlich zu 80% damit ausgelastet, da sie lediglich 4 Clocks für ein Bit des I2S-Streams Zeit haben.
BTW: Der S/PDIF Ausgang ist gerade fertig geworden und liefert an einem externen D/A (MD-Recorder) ein weitaus besseres Ergebnis, als die internen DACs des XMegas. Ein Tiny2313 bastelt aus 4 Bytes des XMega den I2S-Stream wieder zusammen und sendet diesen an einen CS8406. Hört sich seeehr geil an ;-).
Santiago m. H. wrote: > Wenn der XMega für die Datenrate sowieso zu knapp wird, kann ich ja > gleich mit einem USB-Stick als Speichermedium kalkulieren. AVR32 und ARM > haben beide bereits USB an Bord, sollte also machbar sein. Bei den > USB-Sticks gibt es ja Teile mit über 20Mb/s Schreibrate (meiner hat > meines Wissens 13Mb/s Schreibrate, was ja auch reichen würde). Wenn ich lese wie du so lässig darüber schreibst hier, könnte ich fast nen Hals kriegen. Weißt du überhaupt, was da auf dich zukommt? Da bist du mit Sicherheit mindestens ein halbes Jahr beschäftigt, wenn du jeden Tag daran arbeitest und dich einliest in die ganzen Sachen. Und dann hast du unter Umständen nicht einmal ein zufriedenstellendes Ergebnis.
Travel Rec. wrote: Ich habe jetzt mal das DMA in Verbindung mit dem > Event-System des XMega bemüht, welches mir ein etwas besseres Timing als > ein nackter Interrupt beschert. Irgendwo hier stand, dass das keine echte DMA ist - also dass man neben der DMA nichts anderes mehr laufen lassen kann. Stimmt das? (Sieh' mir bitte nach, dass ich deswegen nicht gerade das Datenblatt wälzen will... ;^) ) > BTW: Der S/PDIF Ausgang ist gerade fertig geworden und liefert an einem > externen D/A (MD-Recorder) ein weitaus besseres Ergebnis, als die > internen DACs des XMegas. Das geht mir beim BF537 auch so - mein Selfmade-S/PDIF-Adapter an einem MD-Recorder als D/A bringt wesentlich bessere Ergebnisse als die On-Board-Wandler vom Evalkit...
>Irgendwo hier stand, dass das keine echte DMA ist - also dass man neben >der DMA nichts anderes mehr laufen lassen kann. Stimmt das? (Sieh' mir >bitte nach, dass ich deswegen nicht gerade das Datenblatt wälzen will... >;^) ) Das stimmt schon - CPU und DMA teilen sich den Datenbus. Wenn aber eine DMA-Anforderung anliegt, beendet die CPU den gerade laufenden Transfer und der DMA-Controller bekommt den Datenbus, bis der DMA-Transfer beendet ist. Die Verzögerung liegt bei 1-2 CPU-Clocks. Das ist, verglichen mit einer Interrupt-Reaktionszeit von 6-8 Clocks immer noch rasend schnell und zeitnah zum eintreffenden Event. >Das geht mir beim BF537 auch so - mein Selfmade-S/PDIF-Adapter an einem >MD-Recorder als D/A bringt wesentlich bessere Ergebnisse als die >On-Board-Wandler vom Evalkit... Der XMega-DAC hat halt nur 12 Bit und sitzt neben einem Sack voll schaltenden Transistoren direkt auf einem Die - externe 16 oder wie hier 24-Bit (wenn auch nur mit 16Bit gefüttert) DACs sind da absolut im Vorteil, was Hintergudrauschen und Genauigkeit angeht.
Travel Rec. wrote: > Das stimmt schon - CPU und DMA teilen sich den Datenbus. Wenn aber eine > DMA-Anforderung anliegt, beendet die CPU den gerade laufenden Transfer > und der DMA-Controller bekommt den Datenbus, bis der DMA-Transfer > beendet ist Also quasi wie eine hardwaremäßig aufgesetzte Kopier- bzw. Transferschleife mit wenig Overhead...putzig. :^) Danke für die Info. > Der XMega-DAC hat halt nur 12 Bit und sitzt neben einem Sack voll > schaltenden Transistoren direkt auf einem Die Herje, dann ist's kein Wunder.
>Also quasi wie eine hardwaremäßig aufgesetzte Kopier- bzw. >Transferschleife mit wenig Overhead...putzig. :^) Danke für die Info. Ja genau. Die einzelnen Kanäle, der XMega hat 4, lassen sich mit den gewünschten Quell- und Zieladressen und den Parametern für Burst-, Block- und Gesamttransfergröße einstellen und auf ein Triggerereignis hin klappert die Mühle los. Schön ist, daß jede Peripherie ihre Register im (virtuellen) SRAM hat und somit von überall nach überall Transfers ausgeführt werden können. >Herje, dann ist's kein Wunder. Naja - das läßt sich nicht vermeiden, wenn man alles auf einem Chip unterbringen will. Nur Analog und Digital dicht nebeneinander verträgt sich nicht soo super gut - da muß man Kompromisse eingehen. Ich sage ja nicht, daß man ADC und DAC gar nicht gebrauchen kann. Für durchschittliche Signalverarbeitungsaufgaben im industriellen und automobilen, sowie für den Hobby-Bereich sind sie durchaus gut.
Hallo, > Wenn ich lese wie du so lässig darüber schreibst hier, könnte ich fast > nen Hals kriegen. Dafür bitte ich Dich um Entschuldigung. Aber wie heißt es so schön:
1 | Humor hat, wer trotzdem lacht. |
... und vom Tanzen weiß ich, je mehr Arbeit man reinsteckt, desto leichter sieht es für andere aus. ein kleiner Schwank aus meiner Vergangenheit: HW ist nicht die erste Disziplin, in der ich erste Gehversuche mache. Beim Schreinern hat es damit angefangen, dass ich ne Kreissäge und ne Oberfräse angeschafft habe und nach kurzer Zeit habe ich mir ne komplette Küche gebaut. Irgendwann hatte ich die Gelegenheit, günstig an ein Schutzgas-Schweißgerät zu kommen. Danach habe ich einige Versuche im Stahlbau gemacht - und mir dann eine demontierbare (Steinmetz-taugliche) Werkbank zusammengeschweißt. Steinmetz-tauglich heißt, dass sie eine Belastung von 2t aushält. Beim Nähen fing es damit an, dass meine Freundin mir ein Foto aus der Vogue brachte und fragte, ob ich ihr sowas machen könne. Daraufhin habe ich mir eine Nähmaschine gekauft, von ihr einen Abguss gemacht und los gings. Ziel war ein Abendkleid aus Seide für eine Hochzeit. Nach der Festivität hat das Kleid eine Schneiderin begutachtet - von innen bekam sie das Grausen, aber der Schnitt hat sie beeindruckt. Ich habe gelernt, dass der erste Schritt der Schwerste ist. Wenn man den Mut erstmal aufgebracht hat, werden die Folgeschritte immer leichter. Dann braucht man natürlich den Mut Fehler zu machen (und zuzugeben) - ansonsten gilt für alles: Toyota :) Wenn ich überlege, dass ich vor nem halben Jahr noch von der ganzen HW-Geschichte keine Ahnung hatte und jetzt bereits ohne Probleme Platinen erstellen kann und viele von denen sogar funktionieren, dann gibt mir das eher noch mehr Mut, weiter zu machen. Wen juckts, wenn ich ein halbes oder ganzes Jahr brauche? Während der Zeit lerne ich neues dazu und mit etwas Glück kommt sogar was Brauchbares bei raus. Wenn ich auf meinem Weg zu neuen Taten Leute verärgere, dann bedaure ich das sehr. Es war zu keinem Zeitpunkt meine Absicht, irgend jemand auf die Füße zu treten. Wenn ich locker über schwierige Dinge rede, dann ist das kein Hochmut, sondern eher kaum zu bremsende Lebensfreue/Tatendrang. Dass ich immer neue Dinge angehe, beinhaltet keinerlei Wertung für andere! Alles was ich schreibe ist grundsätzlich subjektiv und gilt nur für mich, bzw. das was ich gerade mache. Ich stelle mir nunmal gerne schwierige Herausforderungen - der Mensch wächst mit seinen Aufgaben :) In diesem Sinne - nichts für ungut. Ich hoffe, der Ärger hält Dich nicht davon ab, Kritik zu üben (ich liebe echte (!) Kritik). @Travel Rec. >>Die von Dir verwendeten ADCs haben keinen Differentialeingang, d.h. Du >>wirst wahrscheinlich sogar einen INA217 o.ä. davor setzen. > > Nö - für Audio braucht man nicht zwingend einen Differenzeingang. > Line-Signale sind unsymmetrisch. Ok, dann ist das klar. Da kann ich aber nicht mit, deshalb schrieb ich auch im ersten Beitrag, dass es differentielle Eingänge sein sollen. Ich hätte auch schreiben können: als Eingang XLR-Schnittstelle. Meine Messmikros (und die anderen auch) haben nunmal XLR-Schnittstelle und brauchen auch eine Phantomspeisung. Klar könnte ich 2 oder 3 Platinen damit machen - aber wenn es auf eine passt, wäre das doch auch nicht schlecht. > BTW: Der S/PDIF Ausgang ist gerade fertig geworden und liefert an einem > externen D/A (MD-Recorder) ein weitaus besseres Ergebnis, als die > internen DACs des XMegas. Na das fällt mir überhaupt nicht schwer zu glauben. Ich baue mir gerade ein R2R-DAC für eine NT-Regelung mit variabler Bitbreite von 8 - 32 Bit :) > Ein Tiny2313 bastelt aus 4 Bytes des XMega den I2S-Stream wieder zusammen > und sendet diesen an einen CS8406. Das verstehe ich jetzt nicht ganz. Ich hatte Dich so verstanden, dass die Tiny dem XMega vorgeschaltet wäre ... @Arc Net zwischenzeitlich habe ich mir die himmelblauen Vielfüßler mal etwas genauer angeschaut. Teilweise genial, aber in großen Bereichen doch eher verwirrend. Dass die serielle Schnittstelle Daten mit 3facher CPU-Geschwindigkeit verarbeiten können soll, will mir noch nicht so ganz in den Kopf. Bei der I2S-Schnittstelle muss aber selbst der große eCOG1X passen. Dort steht, dass die min. Periode des seriellen Taktes 100ns beträgt - wenn ich das umrechne, komme ich auf 10 MBit/s. Das reicht gerade für die Sklavenvariante. Die Eckdaten der SPI-Schnittstelle konnte ich nicht genau herausfinden. Da empfinde ich das Datenblatt als zu wirr. Ich könnte mir aber schon vorstellen, dass es passt. Unterstützt doch die I2C-Schnittstelle 3,4 MBit/s - das ist schon respektabel! Ob die 70 MHz jetzt reine Werbung sind, oder der wirkliche CPU-Takt konnte ich nicht rausfinden. Immerhin wird das Teil "nur" von einem 10 MHz-Quarz angetrieben. Der AVR32 macht bei 400 kBit/s auch die Grätsche - d.h. das ATNGW100 kann ich mir abschminken. Alles in allem erscheint mir bislang der RM9200 (bzw. der SAM9200) der Einzige, der den Mastermode wirklich ohne Murren wegstecken kann (SPI geht bis 1/4 Masterclock == 80MHz, also bis 20 MBit/s). Vielleicht investier ich doch in Olimex ;) @all > Das stimmt schon - CPU und DMA teilen sich den Datenbus. Wenn aber eine > DMA-Anforderung anliegt, beendet die CPU den gerade laufenden Transfer > und der DMA-Controller bekommt den Datenbus, bis der DMA-Transfer > beendet ist. Wie sieht das denn aus, wenn man per DMA einen Block von 512 Byte übertragen wollte. Wechseln sich CPU und DMA dann im Byte-Takt ab, oder wie soll der DMA-Transfer ablaufen? Ich denke da an den Burst-Modus der SD-Karten. Gruß Santi
>> Ein Tiny2313 bastelt aus 4 Bytes des XMega den I2S-Stream wieder zusammen >> und sendet diesen an einen CS8406. >Das verstehe ich jetzt nicht ganz. Ich hatte Dich so verstanden, dass >die Tiny dem XMega vorgeschaltet wäre ... Ja. Korrekt. Ein Tiny macht I2S->parallel für den Audio-Eingang, einer macht parallel->I2S für den Audio-Ausgang. >Ich baue mir gerade ein R2R-DAC für eine NT-Regelung mit variabler >Bitbreite von 8 - 32 Bit :) 32Bit mit R2R?! Glaub ich erst, wenn ich´s sehe! >deshalb schrieb ich auch im ersten Beitrag, >dass es differentielle Eingänge sein sollen. Ich hätte auch schreiben >können: >als Eingang XLR-Schnittstelle. >Meine Messmikros (und die anderen auch) haben nunmal XLR-Schnittstelle >und brauchen auch eine Phantomspeisung. Deshalb einen ADC mit Differenzeingängen? Nee, das kann ein INA217 in der Tat besser. Verstärken muß man die Mikrosignale sowieso und Differenzeingänge am ADC bedeuten immer Meßfehler x2. >Wie sieht das denn aus, wenn man per DMA einen Block von 512 Byte >übertragen wollte. Wechseln sich CPU und DMA dann im Byte-Takt ab, oder >wie soll der DMA-Transfer ablaufen? >Ich denke da an den Burst-Modus der SD-Karten. Dabei würdest Du nichts gewinnen. Ich übertrage die 512Bytes ordinär mit der CPU über SPI. Bei hier 24Mhz macht sich das kaum bemerkbar. Die Karte braucht mit dem Busy fast länger als die CPU mit dem Datenschippen. Die 48kHz Sampleraten-Interrupte dürfen die SD-Karte beim Schreiben unterbrechen. Das stört nicht.
Angehängte Dateien:
-
p1010122.jpg
51 KB
Hallo Travel Rec., > Ja. Korrekt. Ein Tiny macht I2S->parallel für den Audio-Eingang, einer > macht parallel->I2S für den Audio-Ausgang. Ah jetzt ja, ein Tina-Sandwich :D > 32Bit mit R2R?! Glaub ich erst, wenn ich´s sehe! Oups - ich hatte mich verzählt und Dich angelogen. Sind nur 24Bit. Aber trotzdem (siehe Beilage - zeigt die Unterseite). Wie ich schrieb, ist es noch am werden. Die bereits bestückten 100n Blocker sind 1206er, die anderen Widerständler werden 0805er. Angeschlossen wird jeweils ein halber Port per 10Pin Wanne. Die ersten 8Bit sind fix, danach kann jeweils ein halber Port dazu genommen werden (per Jumper). Die Artefakte rechts stammen vom verkorksten Löthonig. Habe vergällten Spiritus erwischt und das gibt etwas umstrittene Ausfällungen. >>Meine Messmikros (und die anderen auch) haben nunmal XLR-Schnittstelle >>und brauchen auch eine Phantomspeisung. > > Deshalb einen ADC mit Differenzeingängen? Nee, das kann ein INA217 in > der Tat besser. Verstärken muß man die Mikrosignale sowieso und > Differenzeingänge am ADC bedeuten immer Meßfehler x2. Gilt der Messfehler nicht auch beim INA? Die Beschaltung des PCM1804 wie im entsprechenden Evalboard (mit OPA2134) beinhaltet doch auch eine Verstärkung?!? > Die 48kHz Sampleraten-Interrupte dürfen die SD-Karte beim Schreiben > unterbrechen. Heißt das, man kann konfigurieren, wer einen stören darf? Das wäre ja goil ;) Gruß Santi
>Oups - ich hatte mich verzählt und Dich angelogen. Sind nur 24Bit. Ja und welche Toleranz haben Deine Widerstände? Für 24 Bit Auflösung?! >Gilt der Messfehler nicht auch beim INA? Ja schon, aber hier fehlert nur 1 Eingang (Nichtlinearität, Offset und Rauschen). Differenzeingangsstufen auf ADC-Chips sind gegenüber externen Präzisions-OVs fast immer im Nachteil. >Die Beschaltung des PCM1804 wie im entsprechenden Evalboard (mit >OPA2134) beinhaltet doch auch eine Verstärkung?!? Nein. Ist lediglich ein Anti-Alias-Filter (Tiefpaß) und Buffer - nix Verstärkung. Ist für Line-Pegel ausgelegt. BTW: die verwendeten OVs dürften auch etwas rauschen und den theoretischen SNR praktisch nicht erreichen lassen. Im CS5343 ist das Eingangsfilter schon drin und lediglich 2 Widerstände zur Pegelanpassung und ein Kondensator zur Pufferung sind pro Eingang nötig. >Heißt das, man kann konfigurieren, wer einen stören darf? >Das wäre ja goil ;) Ja sicher. Das kommt ganz auf die Gestaltung des Programmes an. Wenn die Clock für die SD-Karte mal kurz ausbleibt, ist das der SD-Karte sowas von Schnurz. Das SPI sorgt dafür, daß immer 8 Bit übertragen werden. Pausen zwischen diesen 8 Bit sind kein Problem. Blöd hingegen wäre, wenn nicht pünktlich alle 48kHz die Sounddaten abgeholt und wegbefördert würden. Das würde absolut "bäh" klingen. Deshalb haben die AD/DA-Wandler obere Priorität.
Hallo Travel Rec., > Ja und welche Toleranz haben Deine Widerstände? Ich wußte nicht, dass es bei SMD auch Unterschiede gibt. Sie haben 1% In dem Anwendungsfall ist das aber irrelevant, da ich den Ausgang messe und entsprechend nachregle. Eine Abweichung würde im Zweifelsfall nur einen Regelschritt mehr bedeuten. >>Gilt der Messfehler nicht auch beim INA? > > Ja schon, aber hier fehlert nur 1 Eingang (Nichtlinearität, Offset und > Rauschen). Differenzeingangsstufen auf ADC-Chips sind gegenüber externen > Präzisions-OVs fast immer im Nachteil. Du schreibst "fast"?!? ... andererseits leuchtet das ein. Hm. Vielleicht müßte ich 2 verschiedene AD-Stufen aufbauen und vergleichen. Ist die Frage, ob man den Vergleich ohne Ossi durchführen kann. Mal Finanzminister fragen tun. >>Heißt das, man kann konfigurieren, wer einen stören darf? >>Das wäre ja goil ;) > > Ja sicher. Ei da habe ich mich wohl mistverständlich ausgedrückt. Ich wollte frachen, ob man beim DMA konfiguieren kann, welcher Interrupt auftreten kann und welcher nicht. Dass man Interrupts im Programm generell zulassen/sperren kann ist klar, ebenso wie die Konsequenzen.
Angehängte Dateien:
-
cy1.png
140 KB
> Teilweise genial, aber in großen Bereichen doch eher verwirrend. > Dass die serielle Schnittstelle Daten mit 3facher CPU-Geschwindigkeit > verarbeiten können soll, will mir noch nicht so ganz in den Kopf. > Bei der I2S-Schnittstelle muss aber selbst der große eCOG1X passen. > Dort steht, dass die min. Periode des seriellen Taktes 100ns beträgt - > wenn ich das umrechne, komme ich auf 10 MBit/s. Das reicht gerade für > die Sklavenvariante. Die 100 ns gelten auch nur dann, wenn die I2S im Slave-Modus betrieben wird, d.h. der Takt würde vom externen ADC vorgegeben. Erzeugt der eCOG1X den Takt, hängt das ganze nur vom eingestellten Takt ab. > Die Eckdaten der SPI-Schnittstelle konnte ich nicht genau herausfinden. > Da empfinde ich das Datenblatt als zu wirr. SPI bzw. ESPI hängen auch nur vom eingestellten Takt ab, im Slave Modus sinds 10 MHz > Ob die 70 MHz jetzt reine Werbung sind, oder der wirkliche CPU-Takt > konnte ich nicht rausfinden. Immerhin wird das Teil "nur" von einem 10 > MHz-Quarz angetrieben. Das ist keine Werbung, das Teil hat zwei Oszillatoren (für 32 kHz Quarze und einen für MHz Quarze) und einen RC-Oszillator, dazu zwei PLLs. Das ganze lässt sich z.B. so einstellen 32 kHz Quarz -> Oszillator -> Low PLL (max. *244) -> High PLL (max. *50) -> 399.769 MHz danach lässt sich aussuchen welcher Takt wie heruntergeteilt wird und welche Peripherie welchen Takt bekommt. Aufgrund der vielfältigen Konfigurationsmöglichkeiten ist es aber wesentlich einfacher das mit der CyanIDE zu machen (die V2 basiert auf Eclipse und ist dementsprechend umfangreich).
Moin, > Die 100 ns gelten auch nur dann, wenn die I2S im Slave-Modus betrieben > wird, d.h. der Takt würde vom externen ADC vorgegeben. Hm, ich dachte das wäre klar. Wenn ich den ADC zur Domina mache, muss der µC zwangsläufig den Sklaven spielen. >> Die Eckdaten der SPI-Schnittstelle konnte ich nicht genau herausfinden. >> Da empfinde ich das Datenblatt als zu wirr. > > SPI bzw. ESPI hängen auch nur vom eingestellten Takt ab, im Slave Modus > sinds 10 MHz OK, damit hat sich das dann auch erledigt. In Summe bin ich schon ernüchtert, dass die 13 MBit/s eine fast unüberwindbare Hürde für's IO darstellen. > Aufgrund der vielfältigen Konfigurationsmöglichkeiten ist es aber > wesentlich einfacher das mit der CyanIDE zu machen (die V2 basiert auf > Eclipse und ist dementsprechend umfangreich). Na, ich denke, wenn die neue Freunde gewinnen wollen, wäre Transparenz und ein besser lesbares Datenblatt sicher der beste Weg. Statt dessen macht man lieber bunte Werbung ... ? @Travel Rec. >>>Gilt der Messfehler nicht auch beim INA? > >> Ja schon, aber hier fehlert nur 1 Eingang (Nichtlinearität, Offset und >> Rauschen). Differenzeingangsstufen auf ADC-Chips sind gegenüber externen >> Präzisions-OVs fast immer im Nachteil. Ich bin immer noch verunsichert. Klar, kann mit den Werten eines INA217 niemand mithalten ... Ich bin extra nochmal auf die Seiten der div. Hersteller gegangen. Warum ist es nahezu durchgängig so, dass ADCs mit Differenzeingang die besseren Werte haben? Da muss ich noch mehr drüber erfahren. Irgendwie bin ich gerade sehr verunsichert :/ Gruß Santi
>> Die 100 ns gelten auch nur dann, wenn die I2S im Slave-Modus betrieben >> wird, d.h. der Takt würde vom externen ADC vorgegeben. > Hm, ich dachte das wäre klar. Wenn ich den ADC zur Domina mache, muss > der µC zwangsläufig den Sklaven spielen. Der PCM1804 braucht sowieso einen externen Sampletakt von min. 128 * fs also 192 kHz * 128 = 24.576 MHz, also kann das auch der Controller vorgeben oder man braucht noch einen zusätzlichen Oszillator. >>> Die Eckdaten der SPI-Schnittstelle konnte ich nicht genau herausfinden. >>> Da empfinde ich das Datenblatt als zu wirr. >>> >> SPI bzw. ESPI hängen auch nur vom eingestellten Takt ab, im Slave Modus >> sinds 10 MHz > OK, damit hat sich das dann auch erledigt. Was soll denn noch extern als SPI-Master an den Controller angeschlossen werden (Rest s.u.)? > In Summe bin ich schon ernüchtert, dass die 13 MBit/s eine fast > unüberwindbare Hürde für's IO darstellen. Hab noch mal hier in einige ältere Rechnungen bzw. das Datenblatt gesehen, mit der Folge das die Angaben von oben korrigiert werden müssen. Hier noch mal die korrigierten Angaben: DUSART im SPI-Modus Master: Takt des Moduls (TCLK) / 2 d.h. max. Frequenz der HiPLL / 4 also theoretisch 100 MHz (10 ns). Slave: TCLK / 4 ESPI: Master: TCLK / 2 Slave: müsste 50 MHz (10 ns * 2) sein (DS seite 73) I2S: Master: TCLK z.B. HiPLL / 2 Slave: 10 MHz
hallo , ich bin zufällig zu diese seite gestoßen da ich eine Pinbelegungs-plan für meine delta 1010 LT peitsche suche, da die kanal 1 die ja als linke kanal der stereo out der 1010lt gilt kein ton von sich gibt, es laufen alle anderen kanäle ganz normal, auch der kanal 2 die ja hier als Rechts vom Stereo out belegt ist, ich dachte das hier die kabel von innen gerissen sein könnte und habe dann versucht die Kanal 1 kabel zu ziehen um zu sehen ob es gebrochen ist, und zack war es in meinem händen, nun möchte ich eigentlich eine art breakourbox bauen, sprich alle Pins neu mit Hochertigen Kabeln Löten und an einem Klinken Breakout box verbinden, oder zumindest eine neue kabel löten undzwar direkt an die beiden Pins die an der peitschenkopf sind, nun weis ich aber nicht welche der 44 pins zu der ausgang 1 gehören, weis das jemand hier oder kann mir jemand ein tip geben wo ich es finden kann? ich habe M audio besucht und fande hier nicht im homepage. würde mich für jede hilfe freuen . danke.
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.