WozuErstellt: 07.07.2020 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...

InErstellt: 30.07.2020 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.

Bitte schauen Sie sich dieses Video an und schalten Sie dabei den Ton ein. Ich hoffe, daß ich Sie damit beeindrucken kann und Sie sich für dieses Modul begeistern werden.

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

DieErstellt: 26.10.2020 Erweiterung der Firmware des µControllers dahingehend, daß auch WAV-Dateien abgespielt werden können, wurde zunächst zurückgestellt, da sich seit der letzten Änderung dieses Kapitels im August diesen Jahres herausgestellt hatte, daß die weiter oben beschriebene Fehlinitialisierung des Audiodecoderschaltkreises nicht im Zusammenhang mit dem Senden eines ungültigen Befehls stand.
Die seitdem vergangenen Wochen bis Mitte Oktober 2020 verbrachte ich mit intensiver Fehlersuche und vor allem dem vollständigen Studieren der Datenblätter und weitergehenden Dokumentation zu den Decoderschaltkreisen VS1003B und VS1053B. Dieses Studium hat sich gelohnt, zumindest was den VS1003B anbelangt.
Beide Schaltkreise erwarten nach ihrer Initialisierung einen leeren Datenpuffer. Um diesen bereitzustellen, bedarf es spezieller Abläufe, die vom Hersteller der IC genau beschrieben sind.
Ich habe mich bei der Implementierung der Funktion zum Leeren des Datenpuffers strikt an diese Herstellervorgaben gehalten. Und seither gibt es mit dem VS1003B tatsächlich keinerlei Probleme mehr. Nicht ein einziges Mal gab es eine Fehlinitialisierung.
Leider trifft das auf den VS1053B nicht zu. Um den Datenpuffer zu leeren, bedarf es bei diesem Schaltkreis des Auslesens zweier Register. Hier ergab sich eine lange Zeit das erste Problem: Das Lesen der Register war nicht möglich. Letztendlich und erst nach der Aufnahme des Schaltplans des µSD-Kartenmoduls stellte sich dieses als Problemverursacher heraus. Die chinesische Massenware ist eben doch nicht das Allheilmittel. Das Modul ist schlichtweg fehlerhaft hergestellt bzw. konzipiert. Durch einen einfach vorzunehmenden Hardware-Patch läßt sich der Herstellerfehler beseitigen und nach dem dies erfolgt war, konnten die Register des VS1053 problemlos ausgelesen werden. Leider war das nur die halbe Miete.
Sowohl der Audiodecoder als auch die µSD-Karte arbeiten über den SPI-Bus. Dabei wird von mir die BASCOM-Funktionalität des gemeinsamen Hardware-SPI verwendet. Dies bedeutet, daß die Daten- und Taktleitungen von beiden Geräten benutzt werden und nur die Chip-Select-Leitungen verschieden sind. Das sollte auch kein Problem darstellen und tut es auch nicht. Jedoch gibt es ganz offensichtlich einen, wenn auch vollkommen unerklärlichen, Zusammenhang zwischen der Initialisierung der µSD-Karte und der Funktion des SPI-Busses über BASCOM gesteuert. Weiter möchte ich an dieser Stelle nicht in die Tiefe gehen. Die Konsequenz dieses merkwürdigen Zusammenhanges ist jedoch, daß nur ein Teil der Speicherkarten, welche mit dem VS1003B allesamt fehlerfrei arbeiten, mit dem VS1053B zusammenarbeiten. Dieser Teil aber arbeitet genauso stabil und ohne Fehlinitialisierungen, wie beim VS1003B.
Dennoch habe ich mich aus diesem Grund heraus entschieden, das Projekt bezogen auf den VS1053B zurückzurufen und einen Kompromiß zum Selbstkauf des Decodermoduls mit dem VS1003B anzubieten. Knapp die Hälfte der ursprünglichen Interessenten hat diesen Kompromiß abgelehnt. Allen anderen möchte ich hier an dieser Stelle für ihr Vertrauen danken.

SeitErstellt: 08.11.2020 Anfang November 2020 arbeite ich nun an der Thematik "Abspielen von Audiodaten im WAV- und WMA-Format". Jedoch scheint dies wohl ein recht kurzer Schaffensabschnitt zu werden, denn es folgt eine Ernüchterung auf die andere.
Die chinesische Mentalität bei der Herstellung von elektronischen Bauteilen und -gruppen scheint sich ebenfalls zu globalisieren, denn das Produkt des finnischen Herstellers "VLSI Solution oy" VS1003B bzw. VS1053B verspricht laut Datenblatt mehr, als es hält.
Begonnen habe ich mit dem VS1003B und dem Abspielen von WMA-Dateien. WMA ist ein Audio-Codec von Microsoft und er kann auch nahezu verlustlos Audiodaten abspeichern, was ihn vom MP3-Codec unterscheidet. Dieser Umstand macht ihn in Bezug auf das M366 interessant, denn gerade bei klassischer Musik kann es durchaus vorkommen, daß durch die MP3-Komprimierung Frequenzen verloren gehen und daher die Musik nicht wie im Original klingt.
Da ich mich bislang nicht mit anderen Audioformaten außer MP3 und WAV befaßt hatte, war mir beim lesen des Datenblattes nicht aufgefallen, daß der VS1003B das verlustlose WMA-Format nicht unterstützt. Im Prinzip stellt damit die Auflistung des WMA-Codecs in der Formatliste des Herstellers nur eine Kosmetik dar, denn was nützt dieser mit einer Bitrate von 320 kBit/s, wenn dies auch das MP3-Format ermöglicht. Im Datenblatt des VS1053B wird dieser Ausschluß des verlustlosen WMA-Formats nicht mehr erwähnt und so könnte man meinen, dieser Decoder beherrscht es, was er aber mitnichten tut.
Das eigentliche Ansinnen des Moduls 366 ist jedoch das Abspielen von WAV-Dateien (eigentlich RIFF WAVE) im PCM-Format. Auch dieses Format hat als Grundlage eine Entwicklung der Firma Microsoft. Wenn ich "PCM-Format" schreibe, dann ist damit das Datenformat gemeint. PCM ist ein Pulsmodulationsverfahren das bereits in den 30er Jahren u.a. von den Bell Laboratories entwickelt wurde. Es speichert ein zeit- und wertkontinuierliches analoges Signal als ein zeit- und wertdiskretes digitales Signal und das praktisch verlustfrei.
Bevor ich mich entschloß, das M366 mit "MP3/WAV" zu bezeichnen, studierte ich die Datenblätter des VS1003B/VS1053B dahingehend, ob die Audiodecoder das WAV-PCM-Format unterstützen. In beiden Datenblättern wird dies explizit bestätigt bzw. beschrieben. Für den VS1003B hat es sich damit aber auch schon, denn auch dies entspricht nicht der Wirklichkeit. Was sich der finnische Hersteller dabei denkt, bleibt sein Geheimnis und wird ihm letztendlich auch egal sein, denn der Dumme ist wie immer der Endkunde. Nach einiger Recherche im Internet stellte ich fest: Der VS1003B unterstützt WAV, jedoch nur im Datenformat "IMA ADPCM". Dabei handelt es ich um ein stark komprimiertes Format, welches bei der Sprachübermittlung (Telekommunikation) eingesetzt wird. Es ist für Musik vollkommen ungeeignet.
Angeblich soll es der VS1053B besser können. Ob dem so ist, werde ich herausfinden. Aber noch bin ich nicht soweit.

DieErstellt: 28.11.2020 Programmierung der Funktionalität zum Abspielen von WAV-Dateien habe ich zurückgestellt und mich mit der Erweiterung und Verbesserung des CAOS-MP3-Players und der Darstellung auf dem OLED-Display befaßt.
Es ist nun möglich, während des Abspielens eines Titels zum vorherigen oder nächsten Musikstück zu springen. Dazu wurden die Cursortasten <links>/<rechts> eingebunden. Dieses Titelspringen ist in allen Abspielmodi möglich. Im Einzelmodus ist diese Möglichkeit natürlich am interessantesten. Im Automatikmodus/Reihenfolgeabspiel ist es meines Erachtens nur sinnvoll, den nächsten Titel anzuspringen, aber natürlich kann auch zurückgegangen werden. Ist der Zufallsmodus aktiv, dann haben beide Tasten die gleiche Funktion, nämlich zufällig das nächste Stück auszuwählen.
Die Hilfeseite im MP3-Player wurde entsprechend erweitert und zeigt nun auch diese neue Funktion an.
Eine weitere Verbesserung betrifft die Darstellung der Titelliste bzw. des aktuell gespielten Titels auf dem OLED-Display.
Bislang war es so, daß in den beiden Automatikmodi (Reihenfolge und Zufall) zwischen dem Ende eines Liedes und dem Beginn des nächsten Liedesfür eine kurze Zeit die Titelliste wieder eingeblendet wurde. Dies ist nun nicht mehr der Fall. Gleiches gilt auch für die neue Funktionalität des Titelspringens. Hier wird ebenfalls die Anzeige des aktuellen Musikstückes ausgeblendet und sofort die des nächsten Liedes aktiv.
Um diese Verbesserung umzusetzen bedurfte es eines neuen Steuerwortes in der Firmware des µControllers.
Die aktualisierte Dokumentation zum M366 und die neue Software/Firmware befinden sich im Downloadbereich.

SeitErstellt: 10.12.2020 der letzten Aktualisierung Ende November 2020 habe ich das Programm zur Erzeugung der Musikliste überarbeitet.
Dank der tatkräftigen Unterstützung von Rolf Weidlich ist es nun auch möglich, die Spieldauer von MP3-Dateien mit variabler Bitrate (VBR) zu berechnen. Rolf Weidlich hat dazu eine DLL (Windows-Bibliothek) bereitgestellt. In 99% aller Fälle ist diese Berechnung exakt. Für das restliche eine Prozent kann die Spieldauer manuell eingetragen bzw. korrigiert werden.
Als kleines Schmankerl ist, quasi als Hörprobe, das Abspielen der ausgewählten Datei möglich. Dies geschieht über den Windows-Mediaplayer, falls dieser installiert ist.

Des weiteren wurde die Darstellung und Farbgebung der Lautstärkeanzeige des CAOS-MP3-Players verändert, was auf zwei Bildern zu sehen ist.

Wer ein gutes Gehör besitzt, dem ist bei der Verwendung des Audiomoduls sicherlich aufgefallen, daß beim Beenden eines Liedes mit der "S"-Taste oder beim Wechsel zwischen den Titeln mit den <links>/<rechts>-Cursortasten ein Geräusch auftritt, was eigentlich nicht da sein dürfte. Tatsächlich handelt es sich um einen Teil des gerade gespielten Titels. Dieses Geräusch kann als störend empfunden werden. Auf einem Bild ist zu erkennen, daß die Dauer des Geräusches zirka 3 Hundertstel Sekunden beträgt und zirka 100 ms nach dem Stopsignal auftritt. Diese Aufnahme wurde von Rolf Weidlich angefertigt, der die Problematik damit manifestierte, denn ich selbst ging von einem normalen Verhalten aufgrund des abrupten Beendens des Liedes aus.
Durch eine Anpassung der µController-Firmware tritt dieses Störgeräusch nun nicht mehr auf, was ein weiteres Bild zeigt.

NachErstellt: 29.01.2021 Weihnachten habe ich wieder begonnen, mich mit der Thematik des Abspielens von WAV-Dateien zu beschäftigen und dies in den vergangenen Wochen stark intensiviert. Das Ergebnis kann sich meines Erachtens sehen lassen.
Die schon getroffene Feststellung, daß der VS1003B dieses Audioformat nicht abspielen kann, wurde bestätigt, daher bezieht sich das nachfolgend Geschriebene ausschließlich auf den VS1053B.
Im vergangenen Verlauf wurde diese Variante des Audiodecoders aufgrund von Problemen im Zusammenhang mit der Verwendung der µSD-Karten als nicht tauglich für das M366 befunden. Aber auch diese Probleme wurden nach langer Fehlersuche beseitigt und die Firmware für den VS1053B entsprechend angepaßt - es ist unglaublich, welche Feinheiten beim SPI-Bus auftreten können und berücksichtigt werden müssen. Damit können sowohl der VS1053B als auch der VS1003B uneingeschränkt verwendet werden und meine Empfehlung ist nun ganz klar, das Audiodecodermodul mit dem VS1053B einzusetzen.
Ich habe diese "Anstrengungen" unternommen, weil ich bestrebt bin, das M366 als universelles Audiomodul zu bezeichnen, und dazu gehört meiner Meinung nach auch, daß verlustlose Audioformate, wie zum Beispiel "RIFF/WAV PCM", abgespielt werden können.
Leider ist das ausgerechnet beim WAV-Format mit den Gegebenheiten des M366 nicht möglich. Nicht der eingesetzte µController stellt hierbei den "Flaschenhals" dar, sondern die verwendete Bibliothek zur Ansteuerung der µSD-Karte. Da ich BASCOM als Programmiersprache verwende, bin ich auch auf die BASCOM-Bibliothek zur Ansteuerung der Karte angewiesen. Und diese Ansteuerung ist leider nicht so performant implementiert, daß sie die Möglichkeiten zum Lesen der Daten in vollem Umfang ausnutzt. Mit dem Atmega selbst wäre theoretisch eine Übertragungsrate von rund 3.6 Mbit/s möglich. Messungen beim Lesen von der µSD-Karte ergaben eine Geschwindigkeit von rund 1.6 Mbit/s. Damit bleibt für den Transfer der Audiodaten zum Decoder eindeutig zu wenig Zeit, um die Gesamttransferrate von 1.411 Mbit/s für verlustfreie WAV-Dateien zu erreichen. Mit diesem Manko habe ich mich zunächst einmal abgefunden und bin auf der Suche nach Alternativen auf den "Free Lossless Audio Codec" (FLAC) gestoßen, den auch, so daß Datenblatt, der VS1053B beherrscht. Und er kann es tatsächlich, aber nur, wenn seine Firmware während der Initialisierung mit einem Patch abgeändert wird. Dieser Umstand ist jedoch zu verschmerzen, wenn man bedenkt, daß das M366 damit in der Lage ist, ein verlustfreies Audioformat abzuspielen.
Die Mikrocontroller-Firmware wurde an die Gegebenheiten der FLAC-Dateien angepaßt und wird ab sofort mit der Versionsnummer 5xx weiterentwickelt. Gleiches gilt für den CAOS-MP3-Player. Beide Versionen sind nicht mehr kompatibel zum VS1003B, dessen Soft-/Firmware-Versionen weiter mit 0xx bezeichnet werden - jedoch werden beide Versionen des MP3-Players auch in Zukunft funktional und visuell identisch sein. Da das Laden des FLAC-Patches (Größe zirka 17 kB) einige Sekunden in Anspruch nimmt, benötigt die Initialisierung der Hardware des M366 rund 5 Sekunden. Dieser Umstand wird vom MP3-Player mit einer entsprechenden Wartezeit berücksichtigt und visuell auch dargestellt, was auf einem der neuen Bilder zu erkennen ist.
Im Zuge der Weiterentwicklung der µController-Firmware wurden auch noch alle Codecs mit aufgenommen, die vom VS1053B unterstützt werden. Dies sind: AAC, OGG, WAV (maximal 22.05 kHz) und WMA (WMA-lossless und WMA-professional werden nicht unterstützt).
Um diese Dateien abspielen zu können, müssen sie einfach der Musikliste (MP3.LST) mit der entsprechenden Dateiendung hinzugefügt werden. Für FLAC-Dateien wird die Endung "FLC" erwartet. Das Windows-Programm zur Erzeugung der Musikliste berücksichtigt die neuen Audioformate. Es ist aber darauf zu achten, daß für den VS1003B weiterhin nur MP3-Dateien verwendet werden können.

Neben der Firmwareerweiterung habe ich auch den MP3-Player für CAOS weiterentwickelt. Dadurch wurde die Anzahl der Audiodateien auf einer µSD-Karte von 32 auf 320 erhöht. Natürlich kann ich nicht zaubern und den zur Verfügung stehenden Speicher des AVR vergrößern, aber eine normale SD-Karte kann bis zu 2 GB Speicher umfassen und es spricht nichts dagegen, mehrere sogenannte Musikalben auf einer Karte abzulegen.
Sowohl die Firmware als auch der MP3-Player sind nun in der Lage maximal 10 Alben zu verwalten. Jedes Album besitzt auf der µSD-Karte einen eigenen Ordner mit einer Nummer von 0 bis 9 und in jedem Ordner können bis zu 32 Audiodateien gespeichert werden. Somit können 10 einzelne Karten auf einer zusammengefaßt werden und das Kartenwechseln und der Programmneustart fallen weg.
Beim Start des MP3-Players wird immer das Album mit der Nummer 0 geladen. Danach kann durch drücken der Taste <A> in der "main view" in die Albumauswahl gewechselt werden. Jedes Album kann mit einem Titel bezeichnet werden. Dazu wird eine Datei "VOL.LST" im Albumverzeichnis gesucht und deren erste Zeile als Titel interpretiert. Ist die Datei nicht vorhanden, wird der Titel mit "Unknown album" bezeichnet.
Auf einigen Fotos ist die Ansicht zur Albumauswahl dargestellt. Schwarze Ordnerzahlen signalisieren ein nicht vorhandenes Album (der Ordner existiert nicht auf der µSD-Karte). Das aktuell ausgewählte Album ist mit einer weißen Zahl markiert (nach dem Programmstart ist es immer das Album 0). Gelbe Zahlen bedeuten, daß diese Alben existieren und ausgewählt werden können; und wird eines dieser Alben ausgewählt, wechselt die Farbe der Zahl zu Grün und der entsprechende Albumtitel wird angezeigt. Das Einlesen des Albums geschieht dann mit der Taste <C>.
Der Windows-Musiklistengenerator folgt natürlich der Erweiterung und legt sowohl die entsprechenden Ordner der Alben als auch die Albentitel an. Einige Fotos verdeutlichen dies.
Zumindest das Album mit der Ordnernummer 0 muß existieren, ansonsten ist der Start des MP3-Players nicht möglich.

Als nächsten Schritt möchte ich die verwendete BASCOM-Bibliothek zur Ansteuerung der SD-Karte austauschen, um zu sehen, ob sich damit eine Erhöhung der Datentransferrate erreichen läßt.

DerErstellt: 19.02.2021 Austausch der BASCOM-Bibliothek bringt zwar eine Erhöhung der Transferrate, jedoch nur eine Marginale, so daß WAV-Dateien mit 44.1 kHz weiterhin nicht abgespielt werden können. Es erscheint mir aber mittlerweile auch nicht mehr erstrebenswert, diesen Dateityp zu unterstützen, denn ausgiebige Tests FLAC-kodierter Dateien haben gezeigt, daß deren Qualität der von WAV-Dateien nicht nachsteht. Durch den Umstieg auf den Audiodecoder VS1063A ist das Laden eines Firmware-Patches nicht mehr notwendig, um FLAC-Dateien abspielen zu können.

Der CAOS-MP3-Player wurde weiterentwickelt bzw. verbessert. Die Hilfeseite wurde überarbeitet und listet nun alle Funktionen auf. Neu ist die Möglichkeit mit der Taste <V> Informationen zur Soft- und Firmware-Version anzeigen zu lassen. Weiterhin wurde die Albumauswahl optimiert (funktional und farblich). Die Taste <O> übernimmt die Funktion der Taste <C>, mit welcher nun ein Album geladen und der Auswahldialog danach verlassen wird. Die aktualisierten Fotos im vorherigen Kapitel zeigen diese Verbesserungen. Dabei ist zu erkennen, daß neben dem Albumnamen jetzt auch die Anzahl der Titel und die Gesamtspieldauer (in Stunden) des Albums angezeigt werden. Die Berechnung dieser Spieldauer übernimmt der µController.
In der Hauptansicht des MP3-Players wird das aktuell ausgewählte Album jetzt ebenfalls angezeigt.
Weiterhin wurden die Spielmodi überarbeitet. Im Reihenfolgemodus ab der Titelnummer 1 kann nun nicht mehr zwischen den Titeln gewechselt werden. Dafür gibt es einen weiteren Modus, welcher mit der Taste <F> aktiviert wird. Dieser spielt die Titel ebenfalls in aufsteigender Reihenfolge, aber ab dem aktuell ausgewählten Titel. In diesem Modus kann zwischen den Titeln vor- und zurückgegangen werden und er läuft endlos. Gleiches gilt nun für den Zufallsmodus. Auch dieser muß explizit beendet werden. Für alle drei Modi wurde gleichfalls die Ansicht nach dem Beenden überarbeitet. Die Titelliste bleibt an der Position stehen, die beim Beenden aktuell war. Dadurch ergibt sich eine wesentlich ruhigere Ansicht für das menschliche Auge. Dieser Aspekt wird jetzt auch beim Titelwechseln während des Spielens berücksichtigt. Die Anzeigen bleiben dabei erhalten und werden nicht mehr wie bisher kurzzeitig aus- und wieder eingeblendet. Der aktuelle Spielmodus wird links neben dem Fortschrittsbalken mit einem Symbol dargestellt.

Fortsetzung folgt ...