Soundausgabe unter Bascom - Brainstorming

Windi

Geoguru
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.
 

thomas_st

Geowizard
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.
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.
Thema Dateisystem würde Bascom abdecken, oder müsste da auch was eigenes ran?

Windi schrieb:
[*]Abspielen der Soundfiles kann jederzeit unterbrochen werden
Ist echter IRQ-Betrieb denkbar?

Windi schrieb:
[*]Wahlfreier Zugriff auf die Soundfiles
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.
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?
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.
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)
 

radioscout

Geoking
- 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.
 

qByter

Geocacher
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?
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) :roll:


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. ;)
 

qByter

Geocacher
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 :D
 

eigengott

Geowizard
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.

:eek: 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.
 

qByter

Geocacher
Dateisystem braucht man für solche Anwendungen übrigens nicht, ist nur unnützer Ballast.
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... :D
 

radioscout

Geoking
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.
 

huzzel

Geowizard
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.
 

qByter

Geocacher
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.
 
OP
Windi

Windi

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

Kappler

Geowizard
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.
 

thomas_st

Geowizard
Kappler schrieb:
Kann man auch einen USB-Stick mit einem Tiny koppeln?
Preislich dürften die güsntiger liegen als SD-Karten...
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.
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)
 

Marcel123

Geocacher
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
 

stonewood

Geowizard
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...
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.
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.
 
Oben