www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Suche Mentor für Entwicklung eines Audio-Messwert-Erfassers


Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Santiago m. H.

>Email wäre mir das liebste Medium für den Austausch von braindumps :)

Dann veröffentliche sie doch.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Düsentrieb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mir irgendwie unklar: was soll das ganze denn machen? zweck?

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: meister lampe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gibt es sicher viele Interessenten, mit denen du dich austauschen 
könntest:

http://zora.raetselnasen.de/forum/

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und warum hast du ein Problem damit, deine konkreten Fragen hier im 
Forum zu stellen?

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: meister lampe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver Döring (odbs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Eddy Current (chrisi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :)

Autor: Oliver Döring (odbs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Anonym (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Santiago m. H

Ich wäre interessiert.
Schreib mir mal eine mail auf: a1n2o3n4y5m@gmx.at

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Oliver Döring (odbs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver Döring (odbs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
:)

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und vor allen Dingen brauchen die viel Blech drumherum.

Autor: Termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: T. H. (pumpkin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
The system is single buffered in the transmit direction and double 
buffered in the receive direction. This means that bytes to be transmitted 
cannot be written to the SPI Data Register before the entire shift cycle is 
completed. When receiving data, however, a received character must be read 
from the SPI Data Register before the next character has been completely 
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

Autor: Termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: T. H. (pumpkin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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  ;^)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Termite,

> sd card mit 20MByte/s?

Guckst Du hier: 
http://www.alternate.de/html/product/Speichermedie...

> 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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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&articl...
http://www.edn.com/index.asp?layout=article&articl...

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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag,

wenn man keine 192 kHz "braucht", sind die UDA1361 recht interessante 
Kandidaten.

Gruß Santi

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>habe mir den Punkt "einfacher zu beschalten" nochmal angeschaut und kann
>das nicht nachvollziehen.

Siehe Anhang.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Analog-Eingangsbeschaltung.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-).

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: T. H. (pumpkin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: T. H. (pumpkin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Santiago m. H. (mausschubser)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Autor: Santiago m. H. (mausschubser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Autor: kemal (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.