Soundausgabe unter Bascom - Brainstorming

Von vielen wird ja ein Modul gewünscht mit dem man unter Bascom selber aufgenommen Sound ausgeben kann.
Das Optimum wäre was mit auswechselbarer SD-Karte, so dass man seine WAV-Files bequem am PC erstellen kann.
Leider scheint es für Bascom nichts in der Art zu geben. Das Ansprechen des SD-Karte ist offensichtlich mit Basic zu langsam. Mit Assembler und C geht es wie einige Beispiele zeigen.
Jetzt habe ich gedacht wir starten hier mal ein kleines Brainstorming mit dem Ziel am Schluß ein funktionsfähiges Modul und ein entsprechendes Programm zu bekommen.
Das Thema Verstärker würde ich jetzt mal außen vor lassen. Darum kann man sich kümmern wenn alles andere steht.

Folgende Funktionen sollte das Modul/die Module mindestens beherrschen:
[*]Verwendung von (Micro-)SD-Karten die man am PC mit WAV-Files bespielt.
[*]Anzahl und Länge der WAV-Files nur durch die Größe des Speichers begrenzt.
[*]Wählbare Sampling-Rate der Soundfiles
[*]Abspielen der Soundfiles kann jederzeit unterbrochen werden
[*]Wahlfreier Zugriff auf die Soundfiles

Hier meine ersten Ideen. Vielleicht hat ja schon jemand ein paar Antworten darauf.
[*]Eventuell eine Assembler-Subroutine für das Auslesen der SD-Karte in das Basic-Programm integrieren.
[*]Könnte man statt der SD-Karte nicht ein I2C-EEprom oder Flash-Rom verwenden? Wie sieht es hier mit der Zugriffsgeschwindigkeit unter Bascom aus?
[*]Beim Einsatz eines externen EEproms oder Flash-Roms könnte man die Platine aufteilen. Eine Platine mit dem SD-Karten-Leser. An diese wird dann die Rom-Platine angedockt und die Daten können überspielt werden (das kann auch langsamer erfolgen). Die Rom-Platine wird dann an das eigentliche Soundmodul angesteckt und von diesem gesteuert.

Dann haut mal in die Tasten und schreibt Eure Ideen dazu.

Na da storme ich mal los - auch wenn ich bei dem Titel erst dachte: so ganz ist das jetzt nichts für mich.

Windi schrieb:

Leider scheint es für Bascom nichts in der Art zu geben. Das Ansprechen des SD-Karte ist offensichtlich mit Basic zu langsam.

Zum Vergrößern anklicken....

Mit Hinweis auf Deine Frage weiter unten: ist ungefähr klar, was an Basic zu langsam ist? Wenn es z.B. daran liegt, dass sich der Compiler selbst zu viele Ressourcen krallt (Timer, IRQs, etc.), könnte es mit einer Subroutine selbst auch schwierig bis unmöglich werden. Wenn hingegen der vom Compiler erzeugte Code zu langsam ist (warum eigentlich?), sähe es anders aus.

Windi schrieb:

[*]Verwendung von (Micro-)SD-Karten die man am PC mit WAV-Files bespielt.
[*]Anzahl und Länge der WAV-Files nur durch die Größe des Speichers begrenzt.

Zum Vergrößern anklicken....

Thema Dateisystem würde Bascom abdecken, oder müsste da auch was eigenes ran?

Windi schrieb:

[*]Abspielen der Soundfiles kann jederzeit unterbrochen werden

Zum Vergrößern anklicken....

Ist echter IRQ-Betrieb denkbar?

Windi schrieb:

[*]Wahlfreier Zugriff auf die Soundfiles

Zum Vergrößern anklicken....

Das wäre IMO nur eine Frage des Dateisystems.

Windi schrieb:

[*]Eventuell eine Assembler-Subroutine für das Auslesen der SD-Karte in das Basic-Programm integrieren.

Zum Vergrößern anklicken....

Siehe oben: ist klar, wo der Flaschenhals liegt?

Windi schrieb:

[*]Könnte man statt der SD-Karte nicht ein I2C-EEprom oder Flash-Rom verwenden? Wie sieht es hier mit der Zugriffsgeschwindigkeit unter Bascom aus?

Zum Vergrößern anklicken....

Bei I²C würde ich mal pauschal denken, dass es langsamer ist und auch das Ansprechen des Flashroms wird sich IMO ähnlich aufwendig gestalten wie das einer SD-Card.

Windi schrieb:

Dann haut mal in die Tasten und schreibt Eure Ideen dazu.

Zum Vergrößern anklicken....

Ok, waren erstmal eher Fragen als Ideen, aber vielleicht hilft es ja doch etwas.

Was spricht eigentlich gegen einen in Assembler oder C programmierten Tiny, der nur das Abspielen übernimmt und von einem zweiten, in Bascom programmierten Tiny angesteuert wird? Ich frage deshalb: wenn man eine in Assembler programmierte Subroutine nutzt, müsste man den ganzen Assembler ja sowieso auf den Rechner packen, dann kann man auch gleich einen Tiny damit programmieren (analog C).

Viele Grüße,
Thomas(_st)

- Mal schauen, ob es einen gut verfügbaren und preiswerten Chip gibt, der einfach nur mit der SD-Karte verbunden werden muß und z.B. über I²C gesteuert werden kann und sich um das Abspielen kümmert.

Ich denke das wird neben der Geschwindigkeit in erster Linie am Speicher scheitern...
Schon das extrem schlanke C-Programm von Chan (siehe ELM-Link oben) mit den Petit-FATFs-Modul und ohne irgendwelche Features außer "Play" und "Skip" hat kompiliert und optimiert 6kB.
Was ähnlich schlankes in Bascom hinzukriegen dürfte ein Ding der Unmöglichkeit sein (und wenn, dann sowieso nur mit der Vollversion funktionieren), aber nett wär´s natürlich...

Thema Dateisystem würde Bascom abdecken, oder müsste da auch was eigenes ran?

Zum Vergrößern anklicken....

Was vergleichbares zum Petit-FatFS gibt´s glaube ich nicht...

In "groß" gibt´s schon was, u.a. eine komplette Application Note: AN #134 - FAT32 WAVE Player, aber die nutzt mal eben einen Atmega 162 mit einer 32k Ram-Erweiterung (im Gegensatz zu ´nem Attiny85 mit 512Byte Ram)


Ich glaub da ist es doch um Welten einfacher, sich die gewünschten Zusatzfunktionen (Reaktiv-Funktion, Outputs, whatever) in C zu basteln und in den ELM-Player zu integrieren.

Achso - oder natürlich einfach die Variante "ugly" nehmen: Einfach den ELM-Player mit einem weiteren Tiny koppeln und da dann wie gewohnt mit Bascom rumfuschen

qByter schrieb:

Schon das extrem schlanke C-Programm von Chan (siehe ELM-Link oben) mit den Petit-FATFs-Modul und ohne irgendwelche Features außer "Play" und "Skip" hat kompiliert und optimiert 6kB.

Zum Vergrößern anklicken....

Mein reaktives Audio in C kommt mit weniger als 2kB aus (passt in einen ATtiny24).

Dateisystem braucht man für solche Anwendungen übrigens nicht, ist nur unnützer Ballast. Einfach SD-Karte frisch formatieren (FAT) und dann die PCM-Dateien draufspielen. Die sind dann unfragmentiert auf der Karte, alles was man barucht ist eine Tabelle mit Startsektoren und Längen der Dateien (kann man leicht mit einem Hex-Disk-Editor bestimmen).

Ich vermute auch, dass Basic schnell genug wäre die SD-Karte in angemessener Zeit auszulesen. Die Samplerate wird im wesentlichen durch den Chip vorgegeben, viel Spielraum hat man da nicht, jedenfalls wenn man bei den billigen ATtinys bleibt.

Dateisystem braucht man für solche Anwendungen übrigens nicht, ist nur unnützer Ballast.

Zum Vergrößern anklicken....

Nunja, Komfort ist nicht unbedingt Ballast finde ich (siehe auch die Ursprungs-Anforderungen von Windi)...
Ehrlich gesagt war das mit dem Sektor-Gesuche einer der Gründe, warum ich Deinen Player bisher nicht nachgebaut hab (war wahrscheinlich etwas engstirnig und ein Fehler ) und den ELM-Player auf Anhieb sympatischer fand und dachte: "das probierste mal". Einfach irgendeine SD-Karte in den Rechner, irgendein Wav-File draufkopieren, fertig. Kann man sogar schön benennen und dann nach Filenamen selektiert abspielen... Klar, ist Luxus, aber durchaus praktisch
Rücksicht auf das Format braucht es auch nicht, solange es nicht mehr als 48kHz bei 16bit hat...

Aber Du hast schon recht - ob das nun 4kB mehr wert sind...

Zurück zu Bascom...

Kleine Erinnerung: Beim Brainstorming ("using the brain to storm a problem") werden in der Phase eins nur Ideen gesammelt, es erfolgt keine Wertung oder Diskussion. Das geschieht in der zweiten Phase.

Das Problem bei Bascom ist, dass es den Code recht weit aufbläst und in der freien Version auf 4 kB begrenzt ist.
Hier kann man das erkennen.
Was man machen könnte, den kritischen Code in C oder in Assembler schreiben und dann damit Bascom-Funktionen zu basteln. Dann kann der normale Programmierer einfach auf die fertigen Funktionen zugreifen und braucht kein bisschen von deren Funktion zu wissen. Man müsste sich dann halt nur auf die Parameter einigen, die Sinnvoll sind.

Hier ist noch ein Projekt (Bascom), das ähnlich wie Eigengott´s Reaktiv-Audio ohne Dateisystem arbeitet, mit MMC : MMC card based WAV player

Kompiliert hat das zugehörige Programm etwas unter 3kB schon mit ein paar Zusatzfunktionen (Vor- und Zurückspulen und Pause wenn ich das richtig sehe)... Ohne FAT wär´s also auch in Bascom machbar.

Ich bestell mir jetzt mal ein paar Flash-Roms und experimentiere ein wenig.

Kann man auch einen USB-Stick mit einem Tiny koppeln?
Preislich dürften die güsntiger liegen als SD-Karten...

Falls es eine Lösung mit einem dedizierten "Sound-Tiny" wird: Unbedingt einen Ausgang für "Soundsample fertig abgespielt" vorsehen, für ein Handshaking mit dem steuernden Prozessor.

Kappler schrieb:

Kann man auch einen USB-Stick mit einem Tiny koppeln?
Preislich dürften die güsntiger liegen als SD-Karten...

Zum Vergrößern anklicken....

Da USB-Sticks im allgemeinen USB-Slaves sind (gibt es da Ausnahmen?), müsste der Tiny die Rolle des Host-Controllers übernehmen, was normalerweise der Rechner macht. Dass das in einem Tiny zu realisieren ist, glaube ich eher nicht. Preislich mag es günstiger sein (Ist das wirklich so? SD-Cards werden einem doch auch überall nachgeschmissen) aber der Aufwand wird IMO immens.

Kappler schrieb:

Falls es eine Lösung mit einem dedizierten "Sound-Tiny" wird: Unbedingt einen Ausgang für "Soundsample fertig abgespielt" vorsehen, für ein Handshaking mit dem steuernden Prozessor.

Zum Vergrößern anklicken....

Für die Steuerung des MP3-Tinys würde sich IMO I²C anbieten. Noch eine Interruptleitung über die er den steuernden Tiny allgemein von Änderungen seines Status unterrichten kann (Fertig abgespielt, Fehler, Soundausgabe beginnt, ...) und fertig wäre ein relativ universell einsetzbarer Aufbau.

Viele Grüße,
Thomas(_st)

Am einfachsten wäre es, man verwendet MMC-Karten und schreibt sich eine Player-Subroutine in C in der man die Befehle für den Bascom definiert, z.B. Play[File1], Play[File2] ect...
Zur Zeit habe ich leider relativ wenig zeit, sonst hätte ich mir das ganze mal genauer angeschaut.
theoretisch wären am tiny24/44 (mein standart uc) sogar noch 4 Ports frei für z.B. Taster oder LDR´s

thomas_st schrieb:

Kappler schrieb:

Kann man auch einen USB-Stick mit einem Tiny koppeln?
Preislich dürften die güsntiger liegen als SD-Karten...

Zum Vergrößern anklicken....

Da USB-Sticks im allgemeinen USB-Slaves sind (gibt es da Ausnahmen?), müsste der Tiny die Rolle des Host-Controllers übernehmen, was normalerweise der Rechner macht. Dass das in einem Tiny zu realisieren ist, glaube ich eher nicht.

Zum Vergrößern anklicken....

Und wenn man sich die Klimmzüge eines V-Usb anschaut um einem Atmel das USB-Slave protokoll beibringen zu können will man den Hostcontroller erst gar nicht. Mal so als Hinweise zum Nachdenken: Der Atmel will mit 12 Mhz Quarz befeuert werden, so hat er bei 1,5 Mhz Taktfrequenz noch 8 Takte (also 8 Assembler-Befehle!) um ein Bit zu lesen oder schreiben. Ein Hostcontroller muß regelmäßig den Bus nach neuen Devices abklopfen, und außerdem regelmäßig alle bisher angeschlossenen Devices nach neuen Infos fragen. Das ganze USB ist ja rein host-zentriert, die ganzen angeschlossenen geräte dürfen von sich aus gar nichts machen.

Übrigens wäre es wohl eher möglich den Flash-Baustein im Stick direkt zu beschalten, soweit ich weiß haben auch die Flashbausteine eine JTAG-Möglichkeit. Man kann also mit wenigen Leitungen ein Flash programmieren oder auslesen (natürlich mit ziemlich schlechter performance, aber was braucht schon eine Soundausgabe? Und außerdem spart das kostbare I/O-Leitungen.). Bei Linuxbasierten DSL-Routern (openwrt etc. ) wird ja auch das flash per JTAG wieder neu beschrieben falls das Update komplett in die Binsen ging.