Announcement: there is an English version of this forum on Hallo zusammen, ich habe einige Audio-DAC-Boards mit dem DAC-Chip BB PCM1738 auf Lager, die ich gerne nutzen würde. Ich habe mir jetzt ein Adapterboard gebaut, welches einen CS8416 als Input Receiver beinhaltet und dann die Audiodaten und Takte an das DAC-Board liefert. Grundsätzlich funktioniert das auch, ich bekomme Ton aus dem ganzen heraus. Allerdings nur einen sauberen Ton, wenn der digitale Signalgenerator leise Signale liefert. Ursache ist, dass der PCM1738 by default auf dem Modus "16 bit right justified steht". Den CS8416 kann ich aber neben I²S nur auf right justified 24 bit stellen (left justified ginge auch). Wie kann ich den Betriebsmodus des PCM1738 ändern? Er hat keinen Hardwaremode wie der CS8416. Um seinen mode zu ändern, muss ich also laut Datenblatt das mode control register beschreiben. Und jetzt wirds schwierig für mich, weil ich keine oder wenn dann nur 30 Jahre zurückliegende Erfahrung in der Programmierung mit Controllern habe. Hat irgendjemand eine Idee, wie ich mit möglichst wenig Aufwand diese Inkompatibilität beheben kann? Also am besten den PCM1738 auf I²S umstellen kann? LG Benedikt
Benedikt D. schrieb: > Wie kann ich den Betriebsmodus des PCM1738 ändern? Indem du einen µC deiner Wahl anknüpperst und das entsprechende Register mit dem passenden Wert beschreibst. Datenblatt ab Seite 20 "SERIAL CONTROL INTERFACE". Ist ein SPI Interface mit 16 Bit Datenbreite.
Ich habs befürchtet ;-) Jetzt steh ich wie der Ochs vorm Berg und weiß nicht (mehr) wie das geht.
Benedikt D. schrieb: > Jetzt steh ich wie der Ochs vorm Berg und weiß > nicht (mehr) wie das geht. Dann ist dir nicht mehr zu helfen. Denn gebratene Tauben die einem im Schlaf selbständig in den Mund fliegen gibt's hier leider nicht.
Benedikt D. schrieb: > Ich habs befürchtet ;-) Es ist ja heute auch Freitag, ein ganz besonderer Tag in der Woche hier auf uC.net.
Benedikt D. schrieb: > Ich habs befürchtet ;-) Jetzt steh ich wie der Ochs vorm Berg und weiß > nicht (mehr) wie das geht. Dann hast du zwei Möglickeiten: 1. anderen DAC nehmen 2. lernen wie es geht zu 2. findest du hier Hilfe. Ist aber kein Hexenwerk. Da du nur schreiben willst, reichen 3 GPIO (CS, MC, MDI). Der kleinste µC ist also schon zu groß. Das Wackeln an den Pins kannst du auch in Software machen. Und du mußt das nur einmal nach jeden Einschalten tun. Danach kann der µC schlafen.
Danke vielmals. DAC wechseln kommt nicht in Frage - die Boards sind alle bestückt, und der DAC kostet ja auch ein wenig. Das mit den GPIOs schaue ich mir gerne an, das kenne ich so einigermaßen. Hast du da noch einen Tipp für mich? Gibt es denn was einfacheres als den kleinsten µC?
:
Bearbeitet durch User
Benedikt D. schrieb: > Ich habs befürchtet ;-) Jetzt steh ich wie der Ochs vorm Berg und weiß > nicht (mehr) wie das geht. Naja, lt. "Figure 38. Control Interface Timing" erlaubt das Control-Interface im Prinzip auch das Hineinschieben mit Schaltern / Tastern (sofern entprellt). Sogar extra "Schmitt-Trigger" und "5V-tolerant" steht extra dabei. Genügsamer geht's kaum?! Man schreibt sich das Bitmuster auf und "morst" es hinein. Solange man die Betriebsspannung nicht abschaltet bleibt's drin ... Oder zwei TTL-Schieberegister mit Schaltern dran, das wär' dann die Luxusversion. Mit den allerersten Mikroprozessor-Experimentierboards war das durchaus üblich.
Danke für den Hinweis. Hardwareseitig würde also so ein Pfennigartikel ausreichen: http://ww1.microchip.com/downloads/en/DeviceDoc/ATtiny202-402-AVR-MCU-with-Core-Independent-Peripherals_and-picoPower-40001969A.pdf Der kann SPI und hat auch einen eingebauten Oszillator. Dann müsste ich nur mal das Programmieren eines solchen µC im crash-Kurs lernen oder jemanden finden, der sich damit auskennt ;-) Das mit den Schieberegistern ist interessant, aber am Ende vielleicht doch nicht so praxistauglich...
:
Bearbeitet durch User
Benedikt D. schrieb: > Dann müsste ich nur mal das Programmieren eines solchen µC im crash-Kurs > lernen oder jemanden finden, der sich damit auskennt ;-) > Das mit den Schieberegistern ist interessant, aber am Ende vielleicht > doch nicht so praxistauglich... Die harte Nummer mit den Schieberegistern wird für Dich schwieriger sein als es einfach mit einem ATTINY85 etc. zu lernen und zu machen, obendrein ist das mit den Schieberegistern schaltungstechnisch deutlich aufwendiger und komplexer als einen µC in PDIP8 dafür zu bemühen. Mit einem µC ist man außerdem jederzeit flexibel und kann den Code innerhalb von Sekunden entsprechend umändern, bei solchen Schieberegistern wird es problematisch bis unmöglich, wenn sich herausstellt, dass man doch mehr Daten per SPI hineinpumpen oder sogar herauslesen möchte. Und nur so nebenbei: es ist auch durchaus möglich, dass Deine Annahme bezüglich der Ursache für Deine Audioprobleme falsch ist und gar nicht mit dem, was Du Dir so als vermeintliche Lösung ausgedacht hast, lösbar ist (oder nicht auf diese Weise) – das ist aber nur so ein Gefühl bei dieser ganzen Sache.
:
Bearbeitet durch User
Deinen Nachsatz hab ich auch im Hinterkopf. Aber es würde passen: wenn der Receiver auf I²S steht, macht der Wandler nur bei -100dBFS des Generators einen sauberen, für -100dBFS aber viel zu lauten Sinuston. Weil nur die hintersten Bits des Generators in den Right Justified Rahmen reinfallen. Wenn ich den CS8416 auf "Right Justified" umstelle, kann ich am Generator immerhin ca -50dBFS einstellen, und es kommt ein sauberer, aber immer noch zu lauter Sinuston. Klar, wenn das 24bit-Wort über den 16-bit-Rahmen gelegt wird, geht es in die Hose, sobald das 17. bit angesprochen wird. Müsste man mal nachrechnen, ob das bei ca -50dB auskommt. Aber es erscheint logisch. Vielleicht ist meine Überschlagsrechnung auch falsch, aber jedes Bit steht für eine Verdopplung = 6dB. 8 bit zuviel macht demnach 8x6dB, das würde genau passen.
:
Bearbeitet durch User
Ich bin ein Stück weitergekommen. Hier hab ich gefunden, wie in etwa so ein Programmcode aussehen müsste: https://www.diyaudio.com/community/threads/need-help-with-pcm1738-and-up-code.45618/ Jetzt muss ich schauen, wie ich das am besten umsetze, ob ich mir die dort verwendete IDE "BASCOM" selber zulege oder den Code auf eine andere Umgebung umstricke. Bin mir noch unsicher, was der einfachste Weg wäre.
Benedikt D. schrieb: > Ich bin ein Stück weitergekommen. ... > Jetzt muss ich schauen, wie ich das am besten umsetze, ob ich mir die > dort verwendete IDE "BASCOM" selber zulege oder den Code auf eine andere > Umgebung umstricke. BASCOM ist ein BASic COMpiler. Wenn du dir das antun willst? Außerdem ist der zweite Post berechtigt. BASCOM wird das SPI im 8 Bit Modus betreiben, d.h. es wird die CS Leitung nach 8 gesendeten Bits wieder auf H ziehen. Du willst aber, das es erst nach 16 Bits passiert. Das ist trivial wenn man selber an den Pins wackelt. Ich würde es mit C schreiben. Aber in habe den AVR-gcc schon auf meinem Rechner. Für das bisschen Code würde es auch Assembler tun. Welches Register willst du denn auf welchen Wert setzen?
In dem Beitrag wurde ja auch der Fehler mit den 2x8 bit korrigiert, und zwar indem Spiout Reg18a , 1 Spiout Reg18b , 1 durch SPIOUT reg18(1), 2 ersetzt wird. Alles was ich brauche, ist dass im Register 18 die Bits FMT2 FMT1 FMT0 auf 101 gesetzt werden.
Angehängte Dateien:
-
PCM1738_Reg18.jpg
53 KB
Hier die entsprechende Beschreibung aus dem manual des PCM1738:
Siehe Seite 24 von 48: Also muss man 0x1250 ins Register 18 schreiben, wenn man alle anderen Einstellungen auf Default lassen will.
Ja, das scheint zu passen. 0001001001010000binär = 1250hex Da im manual die Register mit 16,17,18,19,20,21 beschriftet sind, geh ich mal davon aus, dass das noch eine dezimale Angabe ist. Also wäre 0x12 das korrekte Register.
:
Bearbeitet durch User
Aus meinem PCM1796 Projekt etwas modifiziert und bereinigt. Für ATmega88 (aber auch 48, 168 oder 328) Viel Spaß. Gruß Jobst
Danke vielmals. Da steht zwar viel mehr drin als ich brauche, aber ich versuche mal da durchzusteigen und damit weiter zu kommen.
Ich dachte eher an ein kleines C Progrämmchen wie das anhängende. Es ist für einen ATTiny13(A) gedacht. Der läuft auf den Defaults mit 1.2MHz. Compilieren:
1 | ~ $make |
2 | avr-gcc -I. -DDEBUG_LEVEL=0 -Wno-deprecated-declarations -D__PROG_TYPES_COMPAT__ -Wall -Os --std=gnu99 -mmcu=attiny13 -c -o main.o main.c |
3 | avr-gcc -I. -DDEBUG_LEVEL=0 -Wno-deprecated-declarations -D__PROG_TYPES_COMPAT__ -Wall -Os --std=gnu99 -mmcu=attiny13 -o main.elf main.o |
4 | rm -f main.hex main.eep.hex |
5 | avr-objcopy -j .text -j .data -O ihex main.elf main.hex |
6 | avr-size -C --mcu=attiny13 main.elf |
7 | AVR Memory Usage |
8 | ---------------- |
9 | Device: attiny13 |
10 | |
11 | Program: 90 bytes (8.8% Full) |
12 | (.text + .data + .bootloader) |
13 | |
14 | Data: 0 bytes (0.0% Full) |
15 | (.data + .bss + .noinit) |
Die Pinbelegung des ATTiny ist:
1 | .--u--. |
2 | Reset -|1 8|- Vcc |
3 | (frei) -|2 7|- CS \ |
4 | (frei) -|3 6|- MC - zum PCM1738 |
5 | GND -|4 5|- MDI / |
6 | '-----' |
Wenn man sich nicht auf das Power-On Reset verlassen will, kann man Reset des ATTiny mit dem Reset des PCM1738 verbinden und ein Reset Signal generieren. Wahrscheinlich muß man den ATTiny noch ein bisschen schlafen legen, bevor er das Register des PCM1738 schreibt. Also z.B. _delay_ms(100) vor dem ersten write_register(..). Ebenso kann man den ATTiny am Ende in den deep sleep schicken statt in eine Endlosschleife. Aber es ist ja auch nur ein Beispiel.
Danke vielmals. So einen ATTiny hatte ich mir auch schon rausgesucht, weil ich dafür das Programmieradapter auch sicher da habe. Bei dem anderen (Quad Flat Pack) ist das eher ungewiss, müsste ich mal forschen... Und die Datei main.hex ist schon compiliert, die kann ich direkt in den µC reinschreiben?
:
Bearbeitet durch User
Ich habe mal kurz einen Blick auf das ATTINY13-Programm geworfen und meine, mindestens einen Fehler entdeckt zu haben.
Gregor J. schrieb: > und meine, mindestens einen Fehler entdeckt zu haben. Und welche(r) das sind/ist, behältst Du aus Gründen des Jugendschutzes für Dich?
Benedikt D. schrieb: > Und die Datei main.hex ist schon compiliert, die kann ich direkt in den > µC reinschreiben? Im Prinzip ja. Ausprobiert habe ich das Programm allerdings nicht. Es könnte z.B. sein, daß der DAC etwas Bedenkzeit braucht, bevor er Kommunikation akzeptiert. Oder daß ich noch einen Fehler drin habe. Gregor J. schrieb: > Ich habe mal kurz einen Blick auf das ATTINY13-Programm geworfen und > meine, mindestens einen Fehler entdeckt zu haben. Kann schon sein. Ich habe das mehr oder weniger blind runtergetippt. Und überhaupt nicht getestet. Es sollte auch nur eine Anregung für den TO darstellen. Spannst du uns jetzt noch lange auf die Folter?
Axel S. schrieb: > Ich habe das mehr oder weniger blind runtergetippt. Und > überhaupt nicht getestet. Ja, hier war man wenigstens ehrlich, aber erst nachdem es dann doch etwas peinlich wurde. __ > Spannst du uns jetzt noch lange auf die Folter? Was Du als Folter bezeichnest, ist einfach die Suche nach den eigenen Fehlern im Code, was beim Programmieren auch immer dazugehört und quasi das 'täglich Brot' ist – da muss jeder durch, auch Du, sonst bleibt am Ende immer etwas blind Heruntergetipptes stehen. Vereinfacht ausgedrückt: es sind Deine Hausaufgaben, nicht meine.
Erstmal danke an alle. Ich werd dann mal so einen ATTiny bestellen und es ausprobieren. @Gregor: ich fänds schon schön, wenn du einen Fehler auch benennen würdest, dann könnte ich das berücksichtigen.
Gregor J. schrieb: >> Spannst du uns jetzt noch lange auf die Folter? > > Was Du als Folter bezeichnest, ist einfach die Suche nach den eigenen > Fehlern im Code, was beim Programmieren auch immer dazugehört und quasi > das 'täglich Brot' ist – da muss jeder durch, auch Du ... > Vereinfacht ausgedrückt: es sind Deine Hausaufgaben, nicht meine. Ähh. Nein. Mir nützt das Programm nichts. Und vom TO bekomme ich auch nichts dafür. Es ist einfach eine Anregung, wie man so etwas lösen kann. Nicht mehr und nicht weniger. Ich werde da keine Sekunde an Zeit reinstecken, nur weil du behauptest, du hättest einen Fehler darin gefunden. Dein Beitrag zu diesem Thread war nicht hilfreich.
Benedikt D. schrieb: > @Gregor: ich fänds schon schön, wenn du einen Fehler auch benennen > würdest, dann könnte ich das berücksichtigen. Er spinnt wahrscheinlich bloß. Wenn er einen Fehler schon "nach einem kurzen Blick" gefunden hätte, bräuchte er sich nicht so zu winden. Dir zu helfen lag offensichtlich nicht in seiner Absicht. Die Logik, wie man so etwas stricken könnte, geht hoffentlich aus dem Programm hervor. Wenn nicht, frag ruhig.
Thomas Z. schrieb: > if (word & 0x80) ob das so richtig ist? Oops :) Nein. Das ist noch ein Überbleibsel von der Variante, wo jedes Byte einzeln durch die for() Schleife geschoben wurde. Es muß natürlich
1 | if (word & 0x8000) |
heißen. Es wird immer das höchstwertige Bit getestet und MDI entsprechend gesetzt. Und für den nächsten Schleifendurchlauf wird word um ein Bit nach links geschoben. Bleibt noch die Frage, warum Gregor so ein Geheimnis draus machen mußte.
Danke vielmals. Ich verstehe ehrlich gesagt obigen Befehl bislang gar nicht, werde es aber so einsetzen und dann mal ans Testen gehen.
Axel S. schrieb: > Bleibt noch die Frage, warum Gregor so ein Geheimnis draus machen mußte. Ich persönlich glaube, dass er tatsächlich gar nichts gefunden sondern nur behauptet hat. Gruß Jobst
Ich muss den Prozessor jetzt noch bestellen und bin dann mal ne Woche weg. Ergebnisse gibt es also erst nach dem 20.1. Nochmal danke an alle!
Doch noch eine Frage. Ich hab auch keinen C-Compiler auf dem Rechner. Ist sowas dafür brauchbar? https://www.onlinegdb.com/online_c_compiler habs mal probiert: main.c:27:10: fatal error: avr/io.h: No such file or directory Und wozu ist bei deinen drei Dateien das makefile da?
:
Bearbeitet durch User
Hab das hier im Forum gefunden: Beitrag "Befehlsliste für <avr/io.h>" Soll/muss ich mir das so einrichten? Wo bekomme ich das her?
Benedikt D. schrieb: > Doch noch eine Frage. Ich hab auch keinen C-Compiler auf dem Rechner. > Ist sowas dafür brauchbar? > https://www.onlinegdb.com/online_c_compiler > > habs mal probiert: > main.c:27:10: fatal error: avr/io.h: No such file or directory Ich denke nicht. Es muß ein C Compiler für AVR Controller sein. Da sind dann auch die Headerfiles für AVR (wie eben avr/io.h) dabei. Ich habe auf die Schnelle keinen Online-Compiler gefunden. Lies den Artikel AVR-GCC, da steht wie du den Compiler installieren kannst. > Und wozu ist bei deinen drei Dateien das makefile da? Das ist eine Steuerdatei für make. Das brauchst du nicht unbedingt. Du kannst den Compiler auch "von Hand" aufrufen. Compilieren:
1 | avr-gcc -Os --std=gnu99 -mmcu=attiny13 -o main.elf main.c |
main.hex erzeugen:
1 | avr-objcopy -j .text -j .data -O ihex main.elf main.hex |
avr-gcc ist im AVR-GCC Paket. avr-objcopy ist im AVR-Binutils Paket. Wenn es dir um das HEX File für das geänderte main.c geht - ich habe beides angehängt.
Und nochmal das ganze. main.c und die dazugehörige main.hex mit 500ms Bedenkzeit zwischen dem Reset und dem Schreiben des DAC-Registers.
Ok, danke! Die ATTinys sind bestellt. Bin ja mal gespannt.
Angehängte Dateien:
-
Atmel_Studio_-_ATTINY13A.png
120 KB
Benedikt D. schrieb: > Ok, danke! Die ATTinys sind bestellt. Bin ja mal gespannt. Die Hausaufgabe Deines „Betreuers”, der blind Programme schreiben kann und sie nicht zu testen braucht, ist möglicherweise noch nicht fertig gemacht – einen Fehler hat schon jemand aufgezeigt, er selbst bleibt natürlich nach wie vor stur und faul in der Hinsicht, kann aber zumindest „Opps!” schreiben. Du selbst solltest Dir am besten auch endlich einen Ruck geben und z.B. mit dem Lernen der C-Sprache beginnen und nicht immer nur auf fertiggebratene Tauben, die einem auch noch von alleine in den Mund fliegen, warten, denn diese können sich immer auch als vergammelte, weggeworfene Essensreste aus dem Mülleimer entpuppen, die Dir dann schön in den Mund fliegen. Möglicherweise ist das genau der richtige Zeitpunkt und Deine Chance, endlich mit einem µC-Einstieg zu beginnen, und die Du auch nutzen solltest, sonst kann es passieren, dass Du für immer in dieser unglücklichen Lage bleiben wirst, auf andere permanent angewiesen zu sein – in Deinem Fall sogar in Vollpflege. Denn nach der Lösung eines Problems steht man quasi vor der Lösung des nächsten, welches mit Sicherheit in irgendeiner Form kommen wird. Atmel Studio ist kostenlos, die Informationen zum Einstieg in C sind im Netz auch kostenfrei erhältlich und nicht weiter als einen Mausklick entfernt – ATTINY13A wird in dieser IDE unterstützt, auch viele andere AVRs wie z.B. ATTINY85, ATMEGA328P – mit diesem Gespann muss man dann keine Akrobatik mit irgendwelchen Makefiles machen, es wird geschrieben, ggfs. noch das Passende includiert, kompiliert und aufgespielt. Am Anfang kann man auch kurze Programme hineinkopieren, um daraus zu lernen. Die Fuses der µController kann man damit auch wunderbar einstellen. Was Du noch wirklich kaufen musst, ist ein vernünftiger Programmer – an dem sollte man nicht sparen, sonst wird man zweimal kaufen müssen, vorher wird man aber vermutlich einen unendlich langen Thread im Forum eröffnen und viele Tage/Wochen verlieren, um auch zu dieser Erkenntnis zu gelangen; oder auch nicht zu gelangen, denn Sturheit und die Mentalität, immer schön mit dem Kopf durch die Wand zu gehen, gibt es diesbezüglich auch unter der breiten Masse, was man auf µC.net immer präsentiert bekommt. Täglich grüßt das Murmeltier, sozusagen.
Ich habe aus früheren Tagen noch drei Programmiergeräte hier, nutze aber nur noch den TL866 II Plus zum gelegentlichen EPROM-Brennen. Die anderen hießen glaube ich GALEP II und Labtool 48. Das ist aber uraltes Zeuch...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.