Neuentwicklung des M366 - Das Musikmodul für den KC85/5

Test1
Test2
Test3
Proto1
Proto2
Proto3
ListGen1
ListGen2
ListGen3
ListGen4
CAOS-MP3P
Schaltplan

Wozu dieses neue Modul für den KC85/4 werden viele fragen, es gibt doch schon ein Klangmodul, das M066.
Das ist sicherlich richtig, jedoch ist das M366 kein Klangmodul, sondern ein vollwertiges Musikmodul, welches in der Lage ist, Audiodateien im Format MP3, WMA, WAV und MIDI abzuspielen. Und der KC85 spielt die zentrale Rolle, da über ihn softwaregesteuert das Abspielen der Audiodateien erfolgt. Darüber hinaus ist die Verwendung des Musikmoduls in eigenen Anwendungen problemlos möglich.
Meine Motivation zur Entwicklung dieses Moduls entspringt jedoch meinem eigenen Unvermögen. Ich war schlichtweg nicht in der Lage, die Melodie von "Kein schöner Land" für das M066 zu komponieren. Rolf Weidlichs KC-Tracker ist ein sehr gutes Programm. Jedoch bin ich nicht talentiert genug, qualitativ gute STC-Dateien zu erzeugen. Die Erstellung sogenannter Instrumente für dieses Dateiformat, welche essentiell für einen guten Klang sind, gelingt mir nicht.

Die Elektronik des Musikmoduls M366 besteht aus mehreren Hauptkomponenten.
Da ist zum einen die herkömmliche Zuweisungs- und Steuerungselektronik, wie sie jedes KC-Modul aufweisen muß, damit es sich problemlos in das Rechnersystem integrieren läßt. Das M366 besitzt das Strukturbyte DFh und verwendet vier E/A-Adressen mit der Basisadresse 4Ch. Diese E/A-Adressen werden von einem PIO benutzt.
Die eigentliche Audiofunktionalität wird durch einen Mikrocontroller und einen Decoder umgesetzt bzw. bereitgestellt. Bei beiden handelt es sich um Kleinstmodule, um zu einen den Platzbedarf und zum anderen den Aufwand beim Aufbau des Moduls niedrig zu halten. Der µC ist ein Atmega128A und der Audiodecoder ein VS1003B.
Als Massenspeicher, auf dem sich die Musikdateien befinden, wird eine Micro-SD-Karte verwendet. Der Kartenslot wird ebenso als Kleinstmodul eingesetzt.
An der Modulvorderseite ist ein 0.96"-OLED-Display angebracht, welches durch den µC gesteuert wird. Es zeigt im "Leerlauf" fortlaufend die vorhandenen Musikstücke an und beim Abspielen das aktuelle Lied. Weiterhin ist eine 3.5-mm-Stereoklinkenbuchse vorhanden. Sollte während der Initialisierung der Firmware ein Fehler beim Einrichten der SD-Karte auftreten bzw. gar keine Karte gesteckt sein, dann erscheint auf dem Display eine Meldung.
Im Inneren des Moduls befinden sich zwei Pfostenstecker. Der eine (6-polig) dient zur Programmierung des Atmega mit einer neuen Firmware (ISP - "in-system"-Programmierung). Die Belegung und Herstellung des entsprechenden Anschlußkabels ist abhängig vom eingesetzten Programmiergerät. Hier im Modul entspricht sie der des STK500. Der zweite Pfostenstecker (4-polig) ist mit dem USB-UART-Konverter CP2102 (Firma Silabs), welcher sich auf dem Controllermodul befindet, verbunden. Damit lassen sich serielle Ein- und Ausgaben verarbeiten bzw. vornehmen. Wird der Atmega über den Pfostenstecker per USB-Kabel mit einem PC verbunden, kann auf diesem ein serielles Terminal verwendet werden, über das dann der Datenaustausch läuft. Damit die Kommunikation zwischen beiden (PC und µC) möglich ist, muß ein betriebssystemabhängiger USB-Treiber für den CP2102 installiert sein. Diese Möglichkeit zur Kommunikation kann bei der Weiter-/Entwicklung der Firmware hilfreich sein, da hiermit beispielsweise Debug-Informationen ausgegeben werden können.
Wie jedes KC-Modul besitzt auch dieses eine Modul-LED. Da das M366 nicht eingeschaltet werden kann, leuchtet dieses LED dauerhaft. Eine zweite, dreifarbige LED dient zur Signalisierung verschiedener Status des Controllers. Leuchtet die LED rot, dann trat während des Firmware-Starts ein Fehler auf und in der Regel ist dann ein Neustart notwendig. Die Farbe Grün signalisiert den "Leerlauf" des Moduls, d.h. es wird kein Lied gespielt und Blau zeigt an, daß ein Lied gespielt wird.

Die Entwicklung des MP3-Moduls wurde mit einem Testaufbau durchgeführt. Wie schon beim M004 wird der Datenaustausch zwischen dem KC und dem Mikrocontroller über einen Z80-PIO vorgenommen. Dazu wurde auf die bewährte Lösung der Verwendung eines M001 zurückgegriffen.
Im Mittelpunkt standen diesmal das Studium des Datenblattes des Audiodecoders und das Verstehen der Datenübertragung per SPI (Englisch "serial peripheral interface"). Es handelt sich hierbei um einen synchronen seriellen Datenbus. Sowohl der Decoder als auch der SD-Flash-Massenspeicher werden über diesen Bus anschlossen. Insbesondere die Funktionsweise des Audiodecoders zu verstehen hat eine sehr lange Zeit gedauert und es kam oft zu Rückschlägen, durch die ich mich aber nicht habe entmutigen lassen.
Letztendlich wurde der Testaufbau nach sehr vielen Wochen erfolgreich in Betrieb genommen. Dazu zählte auch die Software zur Verwendung am KC85.
Nach dem die Versuchsschaltung einen langen Zeitraum stabil lief, begann die Entwicklung des Schaltplans und des Layouts des Prototypen. Leider schlich sich in den Schaltplan ein Fehler ein, welcher später bei der Inbetriebnahme zu großen Problemen führte. In der Schaltung fehlte die Invertierung eines Signals, wodurch das MEO-Signal des KC-Busses fehlerhaft generiert wurde. Dieser Fehler ist mittlerweile behoben und der Prototyp arbeitet stabil und zuverlässig. Es stellte sich jedoch heraus, daß die mittels zweier Widerstände und eines Transistors vorgenommene Signalinvertierung sehr hohen Zeitansprüchen genügen muß. Der zunächst verwendete Transistor BC547 ist schlichtweg ungeeignet, da er zu langsam schaltet. Hinzu kommen die Widerstände, deren Werte nicht zu groß gewählt werden dürfen, um die Signalflanken sauber zu erhalten. Aufgrund der zu großen Schaltzeit konnte das Modul nur im Grundgerät und ohne Zuschaltung eines D002 verwendet werden, da MEO nicht rechtzeitig auf LOW ging. Damit lag an den Ausgängen des Bustreibers immer der Wert FFh an. Durch entsprechende Tests, durchgeführt von Sven Haubold, wurde dieses Manko erkannt und beseitigt. Verwendet werden jetzt ein Transistor BS170 und zwei 1kOhm-Widerstände.
Mittlerweile wurde das Layout der Serienplatine fertiggestellt. Im Vergleich zum Prototyp ergeben sich noch einige kleine kosmetische Änderungen.

Um das M366 seiner Funktion entsprechend einzusetzen bedarf es nicht viel. Die Verwendung gestaltet sich denkbar einfach, denn ich habe dazu zwei Anwendungen entwickelt, die das Modul für den Anwender als "Black box" erscheinen lassen.

Der Mikrocontroller verarbeitet die Audiodateien entsprechend einer vorgeschriebenen Bezeichnungskonvention. Zum jetzigen Zeitpunkt werden ausschließlich MP3-Dateien abgespielt. In einer zukünftigen Firmware-Version ist dann auch der Einsatz von WMA- und WAV-Dateien möglich. Die Dateien müssen fortlaufend numeriert sein und deren Namen dürfen ausschließlich Ziffern enthalten. Hinzu kommt die jeweilige Endung (aktuell nur MP3). Der Hintergrund dieser Vorgabe ist, die Erkennung und Verarbeitung durch den Controller einfach zu gestalten.
Um eine qualitativ gute MP3-Datei von einem Musikstück, welches sich auf einer Audio-CD befindet, zu erhalten, sollten einige Aspekte berücksichtigt werden. Welche das sind und wie diese gehandhabt werden müssen, entscheidet jeder Anwender individuell für sich selbst. Im Internet finden sich zahlreiche einschlägige sehr gute Dokumentationen und Beschreibungen dazu. Als Schlagworte seien hier die Bitrate und VBR (variable Bitrate) genannt.
Bei der Erzeugung der Dateien ist ebenfalls zu beachten, daß sowohl der Audiodecoder als auch die SD-Karte im SPI-Modus arbeiten und vom AVR gesteuert werden. Dieser Modus ist sehr leistungsstark und arbeitet zuverlässig. Der Atmega128 steuert den SPI-Bus mit 4 MHz. Daraus ergibt sich eine Transferrate von ungefähr 2.6 µs pro Byte, was ca. 375 kB/s entspricht. Damit lassen sich in aller Regel sogar verlustfreie WAV-Dateien abspielen.
Was jedoch in diesem Zusammenhang zu beachten ist, das ist die SD-Karte an sich. Da der SPI-Bus keiner genormten Spezifikation unterliegt, kann für das M366 nicht garantiert werden, das jede SD-Karte zum Einsatz geeignet ist. SDHC- und SDXC-Datenspeicher werden von vornherein nicht unterstützt. Das bedeutet, daß nur Karten bis zu einer Größe von 2 GByte verwendet werden können. Doch jeder Hersteller hat sein eigenes Verfahren. Welches Medium letztendlich geeignet ist, kann nur durch Probieren herausgefunden werden. Bei mir haben sich zum einen ganz einfache no-name-Karten mit 512 MByte und Transcend-Speicher mit einem GByte bewährt.

Wie schon erwähnt, geht die Firmware des Atmega von einer festgelegten Konvention aus. Dazu sucht sie im Wurzelverzeichnis der SD-Karte nach einer Datei MP3.LST. Diese Datei enthält die Musikliste, d.h. alle auf der Karte gespeicherten Audiodateien und Informationen zu den Musikstücken. Dazu zählen der Interpret, der Musiktitel und die Spieldauer. Diese Liste muß gleichfalls einem festgelegten Format bzw. Aufbau folgen und weiterhin in einem bestimmten Textformat (Zeichensatz MS-DOS, Codepage 850) gespeichert sein.
Um diese Voraussetzungen zu erfüllen, existiert eine Anwendung, welche zur Erzeugung der Musikliste dient. Es handelt sich um eine MS-Windows-Applikation. Damit ist der Benutzer des M366 in der Lage, eine korrekte Listendatei zu erzeugen. Die Verwendung gestaltet sich intuitiv. Die Applikation beachtet auch die Einschränkung der maximal erlaubten Anzahl der Audiodateien. Diese beträgt zurzeit 32 Dateien. Der Grund dafür ist nicht im Speicherumfang der SD-Karte zu suchen, sondern im zur Verfügung stehenden SRAM des Controllers. Je mehr Dateien erlaubt sind, um so größer wird der benötigte Zeichenkettenspeicher zur Speicherung der Informationen zu den Musikstücken. Ein Atmega128 besitzt 4 KB Hauptspeicher und dieser muß sinnvoll genutzt werden. 32 Audiodateien sind nicht wenig und entsprechen ungefähr zwei Audio-CD mit einer Laufzeit von insgesamt mehr als zwei Stunden.
Ganz wichtig bei der Verarbeitung der MP3-Dateien durch das Programm ist es, daß diese Dateien zunächst ohne VBR erzeugt wurden. Denn nur dann kann das Programm die Laufzeit korrekt ermitteln. Da Audiodateien mit MP3-Kompression unter Umständen - insbesondere trifft dies bei klassischer Musik zu - mit VBR eine höhere Qualität erreichen, bedeutet dies für den Anwender, daß er in einem zweistufigen Verfahren seine Musikstücke erzeugen muß.
Schlager, Pop- oder Rockmusik erfordert in aller Regel keine hohe Bitrate - 192 kbit/s sind vollkommen ausreichend - und auch keine variable Bitrate (VBR). Nur ein sehr empfindliches Gehör wird hier wohl Qualitätsunterschiede feststellen können.
Die erzeugte Musikliste sollte nicht manuell bearbeitet werden. Sie wird vom Programm im Format des MS-DOS-Zeichensatzes (Codepage 850, ASCII 8 Bit) erzeugt. Nur dieses Format kann vom Controller verarbeitet werden.

Die zweite Anwendung ist ein CAOS-Programm, ein MP3-Player.
Viele Eigentümer meines Klangmoduls M066 kennen sicherlich die STC- und PT3-Player von Rolf Weidlich. Ich maße mir keinesfalls an zu behaupten, daß mein MP3-Player die gleiche Komplexität besitzt, wie die Player von Rolf Weidlich. Jedoch erfüllt er seinen Zweck und ein klein wenig stolz auf diese Entwicklung bin ich schon.
Auch hier gestaltet sich die Benutzung recht einfach und hoffentlich intuitiv. Beim Programmstart wird vom AVR die Musikliste angefordert. Diese ist eine Voraussetzung für den Start. Eine zweite Voraussetzung ist das Einlesen der Konfiguration des Atmega. Sind beide Voraussetzungen erfüllt, dann kann über den KC85 MP3-Musik abgespielt werden. Im Programm ist eine Hilfeseite integriert. Wird in der "Leerlauf"-Ansicht die Taste "H" gedrückt, dann wird diese Seite angezeigt. Ich hoffe, daß die Beschreibung selbsterklärend ist.
Eine undokumentierte Funktion ist der Neustart des MP3-Players. In der Hauptansicht (main view) kann durch das Drücken der Taste "N" sowohl ein "Reboot" des Mikrocontrollers als auch ein erneuter Start des KC-Programms vorgenommen werden. Dies ist zum einem hilfreich, wenn zum Beispiel die Verbindung des AVR über SPI zum Audiodecoder oder zur SD-Karte verloren gegangen ist. Elektronische Komponenten arbeiten zwar in aller Regel fehlerfrei, jedoch ist dies nicht garantiert. Zum anderen ist es möglich, die SD-Karte zu wechseln, und in dem Fall muß die Musikliste neu eingelesen werden.

Bleibt noch zu erwähnen, daß ich Wert darauf gelegt habe, daß alle Bauteile einfach erhältlich sind. Das betrifft insbesondere die vier Fertigkomponenten (LCD, Audiodecoder, SD-Kartenmodul, Controllermodul).

Sobald die Serienplatine bestückt ist und - so Gott will - fehlerfrei arbeitet, geht es hier an dieser Stelle weiter...

Serie
SBetrieb1
SBetrieb2
MP3Player1
MP3Player2
MP3PlayerConfig
MP3PlayerHelp

In den beiden letzten Wochen des Juli/2020 habe ich die Serienplatine in zweifacher Ausfertigung aufgebaut und beide Module funktionierten sofort fehlerfrei.
Ein Modul ist für Maik Trompter, welcher sich, wie schon bei allen Modulen zuvor, bereit erklärt hat, die Frontblende anzufertigen.
Bei der Inbetriebnahme des Serienmoduls stellte sich heraus, daß es offensichtlich Unterschiede bei der Fertigung der OLED-Displays gibt, obwohl sie rein äußerlich identisch erscheinen. Die von mir verwendeten Displays von diymore haben eine sehr lange Karenzzeit. Dies äußert sich darin, daß nach dem Anlegen der Betriebsspannung mindestens 2.5 Sekunden vergehen müssen, bevor das Display initialisiert werden kann. Wird die Initialisierung zu früh vorgenommen, erscheint keine sichtbare Anzeige auf dem OLED. Ich besitze noch ein einziges Display eines anderen Herstellers. Dessen Wartezeit liegt bei unter 250 Millisekunden. In der Firmware des Atmega128 sind jetzt 3 Sekunden eingestellt und diese Zeit hat sich im Langzeittest als ausreichend erwiesen.

Die Front des Serienmoduls hat sich im Vergleich zum Prototyp etwas verändert. Die beiden Mini-USB-Buchsen sind weggefallen. Deren Anschlüsse befinden sich nun im Inneren als Stiftleisten. Sie dienen ausschließlich der Entwicklung der Firmware.

Während der Verwendung und des Tests des Moduls fiel mir immer mal wieder auf (in ganz seltenen Fällen), daß nach dem Anlegen der Betriebsspannung und der Initialisierung des Audiodecoders aus den Lautsprechern Geräusche ertönten, obwohl noch gar keine Daten von der SD-Karte zum Decoder übertragen wurden. Hier half nur ein Neustart der Controller-Firmware und somit eine erneute Initialisierung des VS1003B.
Warum mir erst nach einiger Zeit auffiel, daß in der Firmware ein Überbleibsel meiner Testphase enthalten war, weiß ich nicht. Auf jeden Fall wurde an den Decoder ein ungültiger Befehl gesendet und offenbar ist der Schaltkreis in aller Regel so tolerant, daß dieser Befehl nicht dazu führte, daß die Initialisierung fehlschlug. Nach dem Entfernen des Befehls trat das Problem nie mehr auf.

Als nächstes werde ich die Firmware des Atmega dahingehend erweitern, daß auch die Verwendung von WAV-Dateien möglich ist. Es geht also weiter ...

M366-MP3/WAV
M366 - MP3/WAV
M004-Weather
M004 - Weather
SRNSCHAU
Kein schöner Land
M066-KLANG
M066 - KLANG
M041-2x16 KB EEPROM
M041 - EEPROM
ENDIM622
XY-Schreiber Endim
Drucker K6304
Drucker K 6304
M030-Eprommer
M030 - Eprommer
CF-Kartenleser
CF-Kartenleser
M051-Scanner
M051 - Scanner