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?
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.
Dann hast du zwei Möglickeiten:
anderen DAC nehmen
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?
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.
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.
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.
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.
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?
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.
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?
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.
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?
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.
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.
@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.
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.
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.
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...
