So, hier ein noch mal deutlich überarbeiteter Schaltplan. Vielen Dank für die guten Hinweise noch mal.
Ich will versuchen, die Schaltung ein bisschen zu erklären:
Links oben haben wir die Stromversorgungen. Neu hinzugekommen ist der Doppel-MOSFET Q1, mit dem ein Ein-/Ausschalten per Tastendruck und/oder Software möglich gemacht wird, so braucht es keine Hardware-Schalter (nur den Taster SW1) und der Elektronik wird nicht unnötig plötzlich der Strom entzogen. Den LM1117 für die 5V habe ich durch einen MCP1702 ausgetauscht, der zieht nur ca. 3 uA Ruhestrom und hat einen noch mal geringeren Drop-Off. So sollten vier AA-Zellen eine gute Weile reichen, wenn nicht, werden es eben fünf oder sechs, das muss ich noch testen.
Der AP7312 dahinter ist einfach ein kombinierter (und guter) LDO für 3.3V und 1.8V. Ich brauche tatsächlich alle drei Spannungen.
Zur Funktionsweise: Nach anlegen einer Spannung bleibt der MOSFET "off", an Pin 6 des IRF7319 kommen also noch keine 5V an. Erst ein kurzer Druck auf SW1 latcht das System auf "on". Zum Abschalten gibt es zwei Möglichkeiten: Entweder man drückt ca. 3 Sek den SW1 (so wird versehentliches Abschalten verhindert), oder der Control-Atmega zieht PWR_OFF auf low. So kann sich Synkino auch selbst abschalten, was Batterie sparen sollte. Zu guterletzt ist das ganze auch vorbereitet für kontrollierteres Runterfahren: Ein kurzer Druck auf SW1 im On-Betrieb togglet PWR_OFF, liegt er an einem Interrupt-Pin könnten die uC sich so kontrolliert runterfahren. Ist aber derzeit noch nicht nötig, zumindest so aber später mal möglich. :)
Darunter ist, recht langweilig, ein bewährter 6-fach Level-Shifter, um zwischen 3v3 und 5V zu übersetzen.
Ganz unten links ist der Control-Atmega, der die Menüs ins Display malt, die Parameter entgegennimmt und verwaltet, die Sounddateien lädt und den Dreh-Encoder (als einziges Bedienelement, yay) ausliest. Die unbenutzten Pins habe ich jetzt noch wie vorgeschlagen an beiden uCs herausgeführt. Dieser uC spricht mit dem anderen (Audio-Atmega) via I2C und ein einfaches, aber effektives Protokoll – im Grunde schreitet man hier nur durch eine Finite State Machine.
An PD7 (zur Zeit nur als Ausgang) leitet wie oben beschrieben die Selbstabschaltung ein. AUD_EN an PD6 sorgt dafür, den rechts daneben liegenden MAX4741 Analogschalter schliessen zu lassen. So werden alle fiesen Popp-, Knack- uns sonstigen Störgeräusche aus dem Audiopfad im Ruhebetrieb sicher eliminiert. Machen wir da im "Audioteil" gleich weiter:
Die drei RC-Glieder an C17, C19 und C21 sorgen für Delta-Sigma-Decoding, damit wir ein sauberes AUX-Signal kriegen. Am kleinen Aktivlautsprecher hörte sich das auch ohne weiteres ganz okay an, ich war aber dann doch irritiert, als ich das Signal auf dem Oszilloskop sah. Man lernt nie aus... Der MAX ist zwar nicht ganz billig (2€ oder so), aber er ist definitiv HIFI-tauglich. Und leider ist das verzögerte Einschalten des Audiopfades nötig, denn sonst ploppt es übel. Grund ist vermutlich der C38 am RCAP Eingang des DSP, der quasi die AREF ist, aber eben kapazitativ eingestellt wird. Die Finnen werden irgendeinen Grund gehabt haben.
Machen wir dadrüber am DSP weiter: Die Beschaltung folgt weitgehend der Application Note. Die GPIOs des DSP sind alle auf Low, der arme hat genug mit dem ständigen Resampling zu tun, da wollen wir ihn nicht noch mit anderen Dingen stören (zumal die IDE wirklich grausig ist). Gefüttert wird der DSP mit Daten von der uSD-Karte durch den Audio-uC, der auch den PID-Regler stellt. Ich erwäge an XTALI noch einen DSS zu hängen (den Si5351 mag ich), damit man statt fester Quarzfrequenz auch mit höheren Takten spielen kann. Damit wären auch Speed-Up Regelungen von 48 kHZ Signalen möglich, oder eben ein größerer Regelbereich bei 44.1 kHz Audio. Da da aber ausserhalb der Spezifikation des DSP ist und das auch anderes Timing stören könnte (SPI etc), wird das eher in einer späteren Version etwas. Wenn es denn überhaupt gebraucht wird.
Was der DSP tut, ist vor allem auf der Softwareseite interessant. Das dokumentiere ich später mal separat, eher wohl auf Github als hier.
Mittig ganz unten werden die Signale der "Augen" von ein paar bewährten Schmitt-Triggern aufbereitet. Die Impulse des "Flackersensors" an Pin 2 der Schraubklemme gehen noch durch einen Tiefpass, denn dieser Sensor wird oft aussen liegen, etwa neben der Motorwelle (die ein oder zwei weisse Punkte aufgeklebt bekommt) oder eben Richtung Leinwand. Tiefpass ist nötig, da LED-Birnen im Raumlicht zum Beispiel sonst gerne überlagern. Hat mich auch eine Weile gekostet, diese Fehlerquelle zu finden...
Der "tartmarken-Detektor" braucht weder Filter noch Verstärkung. Der bemerkt einfach, wenn der weisse Vorspann aufhört und sagt dem uC Bescheid. Die Distanz zwischen Startmarkenauge und Bildfenster speichert man in einem "Projektorprofil" des Synkino ein, damit geht es punktgenau los. So kann man diesen kleinen Sensor zB gut unterm Filmeinlauf montieren, oder wo es eben passt.
Ganz oben rechts ist (langweilig) der uSD-Kartenleser im SPI-Modus. Der darunter liegende uC ist gut damit beschäftigt, Daten von SD zum DSP zu schieben (per ISR), hat aber dank ein paar Optimierungen noch genug Luft, PID-Regler zu spielen, dem DSP neue Samplingraten zuzuwerfen und ein bisschen über I2C zu plaudern. Damit ist er dann aber auch eben echt am Anschlag. Nächstes mal werde ich wohl einen ARM7 bemühen, allerdings habe ich in der ARM-Welt eben noch quasi keinerlei Erfahrungen. Und warum nicht zwei AtMegas...
Beide uC kriegen ICSP und FTDI herausgeführt, damit man bequem flashen und debuggen kann. Die Serielle ist interessant für die Kommunikation im System, aber auch für EEPROM-Dumps... und wenn schon Seriell, dann ruhig gleich FTDI, so kann man den Synkino auch ohne AVR-Programmer ggf. mit neuer, eigener Software füttern.
Ganz unten rechts noch die beiden "Augen" auf Basis des QRE1113, das sind prima verlässliche, sehr kleine Reflexsensoren. Fotodiode anschliessen geht auch, aber dann braucht es noch einen Trans-Impedanz-Verstärker und insgesamt fand ich die kleinen Reflexsensoren viel praktischer. Gabellichtschranken oder Hall-Sensoren sind aber ebenso denkbar, nur eben viel invasiver.
Soweit erstmal zur Hardware – bei Fragen oder weiteren Fehlern bitte unbedingt Bescheid sagen. Ich habe jetzt ein paar Tage Urlaub und hoffe, das Routing der Platine in er Zeit fertig zu kriegen...