www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie I2S Datenstrom mit AVR M88 einlesen


Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich suche eine Möglichkeit ein I2S Signal mit einem AVR Mega88 
einzulesen.
Ich will nur den Signalpegel auswerten und über LEDs anzeigen.

Gibt es eine Möglichkeit, ausser die Pin's abzupollen?
Also sowas wie SPI, SIO in irgend einem Modus oder sonst eine Hardware 
unterstützung?

Viele Grüsse,
Peter

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Glaube das wird nicht gehen.
Der M88 kann doch nur mit 24MHz arbeiten und SPI braucht schon >4 Takte 
um was zu empfangen. Pollen wird auch nicht gehen.
I2S ist recht flott, je nach Signal kommen da schon mal 26MHz zusammen.

Ein externes Schieberegister könnte gehen oder ein Prozessor mit I2S 
Eingang.

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erst mal musst du was zur Signalgeschwindigkeit sagen, vorher ist alles 
Rätselraten.
Woher kommt das Signal, wie schnell ist es, Auflösung?

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bis 96kHz/24Bit sollte SPI noch mitmachen. Allerdings kann es sein, daß 
Du Dir noch ein paar clock-Signale erzeugen musst ... Dies ist auch der 
Grenzfall und damit schon sehr Zeitkritisch.

Bei CD (44.1/16) sollte es aber keine Probleme geben.



Gruß

Jobst

Autor: X- Rocka (x-rocka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:
> Bis 96kHz/24Bit sollte SPI noch mitmachen.

sicher? I2S läuft mit 32bit, 2 kanäle => 6.144MHz hat dann die SCLK.
gewagt, gewagt...

ich würde auch ein externes Schieberegister nehmen, oder ein CPLD.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

I2S läuft nicht immer mit 32Bit. Aber ich habe auch mit diesem Fall 
gerechnet. Dann läuft der uC mit 24.576MHz das ist leicht ausserhalb 
seiner Specs. Allerdings sollte der Takt aus dem Datensignal generiert 
werden.
Das dies Grenzwertig ist, habe ich aber geschrieben.

Abgesehen davon, würde ich das Ganze analog machen.

Wenn es unbedingt digital sein muss, kann er ja einen SRC davor 
schalten.


Gruß

Jobst

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Infos.

Ich habe zur Zeit 32Bit mit maximal 12,xxx MHz auf dem I2S Bus (192KHz 
128FS).
Das kann aber sein das ich noch schneller werden muss.
Nun eine reine Software Lösung schließe ich jetzt auch aus.
Der Einwand mit der SPI habe ich nachgelesen und wird wohl auch nicht 
gehen.

Bleibt wohl nur ein Schieberegister oder ein kleiner ARM Prozessor.
Dumm nur das ich mich mit den ARM Prozessoren nicht auskenne und auch 
keine Tools dafür habe. Was gibt es denn vernünftiges dafür?

Eine AVR Lösung wird mit einem Schieberegister aber auch schwer. Ich 
muss den Inhalt ja abholen bevor das nächste Bit rein kommt. Oder gibt 
es da entsprechende Bausteine die das Ergebnis zwischen speichern?

MfG Peter

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

Nimm nen ARM.
Ein AT91SAM7S256 z.b. hat direkt eine I2S Schnittstelle inkl. DMA 
On-Board.
Damit wird I2S zur Nebensache. Einem AVR würd ich ohnehin nicht zutrauen 
I2S Deserializing zu machen (es sei denn er macht NUR das), von der 
Verarbeitung mal ganz abgesehen. Jedenfalls nicht wenns CD Qualität 
aufwärts sein soll. 8kHz 16Bit mono bekommt man mit einem AVR sicherlich 
noch hin. Und da wäre auch wohl Verarbeitung noch evtl drin. Aber alles 
was darüber geht ... wenig Chancen.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will die Daten nur einlesen und den Pegel anzeigen (LEDs).
Wenn es geht, auch noch als 8Bit Wert über I²C bereitstellen.

Das ein ARM7 das packt ist mir auch klar, aber den kenne ich nicht.

MfG, Peter

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn du dir den RMS Wert anzeigen lassen willst ist es noch etwas 
zu tun bis dahin ...

Du mußt jedes Sample (also jedes empfangene Datenwort) quadrieren, 
aufsummieren, am Ende der Summation (alle x Werte, wobei x deine 
Fenstergröße vorgibt) dann durch x teilen, die Wurzel daraus ziehen und 
dann kannst du den Wert in dB umrechnen.
Bei CD-Qualität ist der Aufwand (wenn man nicht gravierende 
Vereinfachungen macht) für einen AVR nicht zu schaffen.

Lösung a) :
  - nur 8 von den 16 bzw 24 Bits verarbeiten.
  - Fenstergröße fest auf 2'er Potenz
  - Wurzelfkt. stark optimieren (Tabellen usw)

Lösung b) :
  - I2S nach analog Wandeln, analog filtern und mit dem ADC des AVR's 
einlesen

Wenn du es rein digital machen willst denke ich kannst du das vergessen.
Quadrieren von 24 bzw 32 Bit. Teilen einer 32 bzw 64 Bit Zahl durch 16 
bzw 32 Bit. Wurzelziehen aus einer 32 Bit Zahl. Und das alles in 10-20µs 
(200-400 Takte bei 20MHz pro Sample). Sehr sportlich.

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

Bewertung
0 lesenswert
nicht lesenswert
Habe ich mal gemacht. Dabei taste ich nicht den kompletten Datenstrom 
ab, sondern immer nur Stichproben, damit noch Zeit zum Rechnen und für 
die Darstellung bleibt. Für eine LED-Anzeige gar kein Problem. Hier 
waren die 12.288Mhz MasterClock auch gleich die Taktfrequenz für den 
Controller, so daß man 4 Takte pro Samplebit zur Verfügung hat. Über 
LRCLK wurde der Frame synchronisiert, wenn ich mich recht erinnere, habe 
ich 16Bit/48kHz ausgewertet, logarithmiert und auf 2x10 LEDs angezeigt. 
Nettes Gimmick ist eine Peak-Hold-Funktion. Das Projekt läuft in einer 
digitalen DI-Box, Controller ist ein Mega16, der auch für die Akkuladung 
zuständig ist.

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

Bewertung
0 lesenswert
nicht lesenswert
TheMason schrieb:
> Wenn du es rein digital machen willst denke ich kannst du das vergessen.
> Quadrieren von 24 bzw 32 Bit. Teilen einer 32 bzw 64 Bit Zahl durch 16
> bzw 32 Bit. Wurzelziehen aus einer 32 Bit Zahl. Und das alles in 10-20µs
> (200-400 Takte bei 20MHz pro Sample). Sehr sportlich.

Es gibt auch LookUp-Tables, die im oben beschriebenen 
Stichproben-Betrieb schnell genug sind. Es kommt hier nicht auf 100,000% 
Genauigkeit an. Es soll habwegs glaubhaft blinken und bei der Findung 
des optimalen Pegels helfen (nehme ich an).

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@travelrec

Einverstanden. Ich bin (leider) davon ausgegangen es so akkurat wie 
möglich zu machen, und hab natürlich die wichtigsten 
Optimierungsmöglichkeiten ausgelassen. Scheiß Perfektionismus :-)
Aber so gesehen lässt sich da schon was machen.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Travel Rec.

Das ist genau das was ich machen will.
Existiert das Projekt noch?
Und ist der Code Öffentlich?

MfG Peter

Autor: Jörg H. (idc-dragon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch zuversichtlich, daß der Mega88 das kann.
Ich habe gerade das Umgekehrte gebaut, eine I²S Ausgabe, 48 kHz Stereo 
16 Bit. Und die Samples muß der arme Controller auch noch errechenen 
(DDS mit nachgeschalteter linearer Interpolation zwischen den 
Tabellenwerten).

Nimm nicht den SPI, sondern den USART im synchronen Modus. SPI hat beim 
Mega88 leider keine Doppelpufferung, USART schon.

Ein weiterer "Trick" in meinem System war, nested Interrupts zuzulassen, 
um die Latenz klein zu kriegen. Und die Codierung der Haupt-ISR in 
Assembler...

Jörg

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

Bewertung
0 lesenswert
nicht lesenswert
Naja, leider kann man den synchronen UART nur als Master-SPI gebrauchen, 
was bei der vorliegenden Anwendung keine Vorteile bringt.

Hier der betreffende Codeabschnitt, es werden keine Hardware-Interfaces 
benutzt. Engegen meiner Annahme werden nur je 8 obere Bits für den 
linken und rechnten Kanal benutzt, was für 10 LEDs aber ausreicht.
;reads I2S data, 8 MSB for each channel
GetSoundADC:
 cli
 
_GSA1:
 sbic  PinC, LRCK                  ;syncronize to LRCK
 rjmp  _GSA1

_GSA2:
 sbis  PinC, LRCK
 rjmp  _GSA2
 
 nop
 clr  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN    
 sec
 rol  Temp

 brcc  _TCLeft        ;convert 2s complement to positive value
 neg  Temp

_TCLeft:
 sts  LeftLow, Temp


_GSA4:
 sbic  PinC, LRCK 
 rjmp  _GSA4

 nop
 clr  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp
 clc
 sbic  PinC, SDIN
 sec
 rol  Temp

 brcc  _TCRight      ;convert 2s complement to positive value
 neg  Temp

_TCRight:
 sts  RightLow, Temp
 
 sei
 ret


Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke an alle.

Nun versuche ich mal das alles umzusetzen.
Melde mich wieder, wenn ich was neues berichten kann.

Peter

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

Bewertung
0 lesenswert
nicht lesenswert
Ja, mach mal. Die erhaltenen Daten mußt Du eigentlich nur maximieren 
(Peak detection) und diesen Maximalwert relativ langsam (10% 
Laufbandlänge /100ms) herunterzählen. Neue Peaks werden sofort 
übernommen. Das sieht dann optisch schon gut aus. Aufwerten läßt sich 
das durch ein Peak-Hold, bei dem die Spitzenpunkte 2s lang auf der 
Anzeige bleiben, bevor sie mit kleineren Werten geladen werden. Dabei 
kann dann die Release-Zeit des Gesamtbandes wieder etwas zügiger sein, 
so daß man schnellere Reaktionen sieht. Viel Spaß beim Proggen! Ich mach 
mal gelegentlich ein Filmchen von meinen Anzeigen ;-)

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

Bewertung
0 lesenswert
nicht lesenswert

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.