Hallo Leute.
Wie ihr der Überschrift entnehmen könnt, möchte ich diverse (kurze)
Sounds mit Hilfe der PWM wiedergeben.
Ich habe 3 Soundfiles (8Bit) als .h Dateien und möchte diese jetzt, je
nach Bedarf, wieder geben.
Mein Mikrocontroller ist ein Atmega16, 1Mhz Taktrate.
Ich habe leider keine Ahnung, wie ein entsprechendes Programm dafür
aussehen könnte und hoffe auf eure Hilfe. Am besten so einfach wie
möglich realisiert ;)
@Alex (Gast)
>Wie ihr der Überschrift entnehmen könnt, möchte ich diverse (kurze)>Sounds mit Hilfe der PWM wiedergeben.
Das ist leicht.
>Ich habe 3 Soundfiles (8Bit) als .h Dateien
Solche Arrays gehören in .c Dateien, dort gehören Definitionen hin. In
.h stehen nur Deklarationen.
>Mein Mikrocontroller ist ein Atmega16, 1Mhz Taktrate.
Warum so wenig? Man sollte wenigstens 8 MHz nutzen.
>Ich habe leider keine Ahnung, wie ein entsprechendes Programm dafür>aussehen könnte und hoffe auf eure Hilfe. Am besten so einfach wie>möglich realisiert ;)
Einen 8 Bit Timer mit möglichst hoher Frequenz aufsetzen. Dort kann man
PWM und Nachladen gleichzeitig machen. In jedem Overflow-Interrupt muss
man einen neuen Wert in das PWM-Register schreiben.
http://elm-chan.org/works/sd20p/report.html
Geht auch ohne SD-Karte.
Danke für deine schnelle Antwort!
Der Atmega läuft standartmäßig auf einem MHz; aber den auf 8 MHz zu
setzen ist auch kein Problem. Es war nur als Hintergrundinfo gedacht.
Ich werd mich dann mal ans lustige umsetzen der idee machen...
Falk B. schrieb:> Solche Arrays gehören in .c Dateien, dort gehören Definitionen hin. In> .h stehen nur Deklarationen.
und wenn ich einen Sound in verschiedene Projekte einbinden möchte ist
doch ein
1
#include"sound.h"
die bessere Wahl als das jedes mal das Array in prg1.c, prg2.c usw. zu
kopieren.
@Joachim B. (jar)
>und wenn ich einen Sound in verschiedene Projekte einbinden möchte ist>doch ein>#include "sound.h">die bessere Wahl als das jedes mal das Array in prg1.c, prg2.c usw. zu>kopieren.
Nö. Denn du musst ja so oder so die Datei in dein Projektverzeichnis
kopieren, damit sie übersetzt wird. Headerdateien (.h) können und werden
unbegrenzt in anderen Dateien per #include eingebunden werden.
Quelldateien (.c) eigentlich niemals, auch wenn dich keiner daran
hindert.
Falk B. schrieb:> Nö. Denn du musst ja so oder so die Datei in dein Projektverzeichnis> kopieren, damit sie übersetzt wird. Headerdateien (.h) können und werden> unbegrenzt in anderen Dateien per #include eingebunden werden.
weiss ich doch und dann würde ich das Array als Header einbinden, wo
steht das ein Array in ein C-File gehört?
> Quelldateien (.c) eigentlich niemals, auch wenn dich keiner daran> hindert.
Beim AVR Studio kein Problem, in der Arduino IDE ist *.h einbinden
leichter, da gibts nämlich kein Projekt wo man C rüberschubsen kann, ist
schon ne Krücke, aber mit allen fertigen LIBs und ohne IPS Gehampel auch
wieder liebenswert, ach mal hasse ich Arduino, mal mag ich es, je nach
Aufgabenstellung und Tageslaune.
Mein Vorschlag wäre, die Daten weder in ein *.h File, noch in ein *.c
File zu packen. Technisch gesehen spielt es nicht die große Rolle,
compiliert werden müssen sie so oder so. Nur haben *.h bzw. *.c Files
eine implizite Bedeutung, was in ihnen enthalten ist. Bei derartigen
Dingen benenne ich die Datei mit den eigentlichen Daten (in ihrer
compilierbaren Form) meistens als *.inc Datei um eben anzudeuten, dass
es sich dabei weder um den klassischen Inhalt einer Header Datei noch um
ein für sich allein stehendes C-File handelt.
Dem Präprozessor ist es ja sowieso wurscht, wie das File heisst, welches
er einbindet.
Joachim B. schrieb:> Beim AVR Studio kein Problem, in der Arduino IDE ist *.h einbinden> leichter, da gibts nämlich kein Projekt wo man C rüberschubsen kann,
Ein Array kann auch in eine *.cpp gestopft werden.
Nichts kann dich in der Arduino IDE daran hindern, in deinen
Projektordner, da wo die *.ino liegt, auch eine Array.h und eine
Array.cpp rein zu werfen.
Das ist dann eine saubere Lösung und funktioniert perfekt.
Ulrich F. schrieb:> Nichts kann dich in der Arduino IDE daran hindern, in deinen> Projektordner, da wo die *.ino liegt, auch eine Array.h und eine> Array.cpp rein zu werfen.
weiss ich doch und ob die array.cpp oder array.c heisst ist doch egal.
Ich fand array.h aber besser, der Vorschlag vom Karl-Heinz mit array.inc
hat aber auch Charme.
Joachim B. schrieb:> weiss ich doch und ob die array.cpp oder array.c heisst ist doch egal.> Ich fand array.h aber besser, der Vorschlag vom Karl-Heinz mit array.inc> hat aber auch Charme.
Beides finde ich bedenklich....
Beides mit unlösbaren Problemen verbunden.
Was machst du, wenn du in verschiedensten Dateien Wissen um das Array
haben muss?
Ulrich F. schrieb:> Was machst du, wenn du in verschiedensten Dateien Wissen um das Array> haben muss?
hmm, das Problem hatte ich noch nicht, innerhalb eines Projektes wirds
nur in einer aufruf.C verwendet und dort includet, die aufruf.C hat ihr
aufruf.H und alle können die Nutzen. Die beispielsweise wav.inc wird ja
nur einmal in die aufruf.C #includet und die aufruf.C weiss damit
umzugehen.
du hast ja möglicherweise Recht, aber ich kann auch Probleme
konstruieren wo keine sind (denke ich).
Ulrich F. schrieb:> Was machst du, wenn du in verschiedensten Dateien Wissen um das Array> haben muss?
Diese Informationen kannst du doch in die Datei, die das Array enthält,
mit reinschreiben. Damit wird sie gemeinsam mit dem Array includiert.
Oder spricht da was dagegen?
Gut, dann fange ich es von einer anderen Seite an.....
Das Prinzip der geringsten Verwunderung!
Was man an einer Stelle so tut, tut man überall so.
(bis man eines Besseren belehrt wird)
Seit über 30 Jahren ist das aufteilen in *.h und *.c, in neuerer Zeit
auch *.cpp, gängige Praxis.
Ich sehe keinen Grund davon abzuweichen.
Ein universelles Prinzip.
Jeder angehende Programmierer lernt es genau so, und nicht anders.
Jede Library in der C/C++ Welt ist so geschrieben.
Joachim B. schrieb:> du hast ja möglicherweise Recht, aber ich kann auch Probleme> konstruieren wo keine sind (denke ich).
Man kann auch ohne jede Not von altbewährten Pfaden abweichen.
Und damit andere(und sich selber) in Verwirrung/Probleme stürzen.
Im Anhang ein Arduino Beispiel, wie ich es machen würde.
Um hier noch mal das eigentliche Thema aufzugreifen.
Ich hab meine Soundwiedergabe mit einem PWM Signal jetzt hinbekommen,
aber die 8Bit Sounds hauen mich nicht wirklich um.
Jetzt ein neuer Denkansatz; Besteht die Möglichkeit diese auch als 16Bit
zu formatieren und dann wiederzugeben oder wäre das mit der PWM
nichtmehr machbar?
-Wenn jemand eine passende Software zum wandeln von wav nach 16Bit Text
kennt darf er es gerne Posten, denn ich finde nichts passendes.
@ Alex (Gast)
>Ich hab meine Soundwiedergabe mit einem PWM Signal jetzt hinbekommen,>aber die 8Bit Sounds hauen mich nicht wirklich um.
Welche Samplerate? Welche PWM-Frequenz? Welcher Ausgangsfilter?
>Jetzt ein neuer Denkansatz; Besteht die Möglichkeit diese auch als 16Bit>zu formatieren und dann wiederzugeben
Kann man machen, aber . . .
> oder wäre das mit der PWM>nichtmehr machbar?
Dann brauchst du eine 16 Bit PWM. Das ist mit dem einfachen Ansatz nicht
möglich.
>-Wenn jemand eine passende Software zum wandeln von wav nach 16Bit Text>kennt darf er es gerne Posten, denn ich finde nichts passendes.
Ich hatte mal ein kleines Programm geschieben, ist hier in den Untiefen
des Forums als Anhang verschollen.
Aha, Google findet alles wieder.
Beitrag "Re: PWM Tonhöhe und Lautstärke"
Dort geht es sogar um das gleiche Thema!
Einfach wäre ja auch zu schön gewesen ;)
Samplerate könnte ich mit meinem jetzigen Programm anpassen/ändern wie
ich es brauche. Momentan hab ich als Basis 44kHz.
-Für ein 16Bit Sound brauche ich also 16Mhz Controllertakt (externer
Quarz) oder mache ich da einen Gedankenfehler?
Für die jetzige umsetzung habe ich das erst auf Mono und dann 8Bit
konvertiert.
Als PWM Frequenz habe ich momentan den Mikrocontrollertakt von 8 MHz.
PS:
Ich arbeite mich grade durch deine Super Anleitung.
Da blicke selbst ich als Einsteiger durch *Daumen hoch!*
Hab die vorher bei der suche nicht gefunden "Asche über mein Haupt"
Alex schrieb:> Einfach wäre ja auch zu schön gewesen ;)>> Samplerate könnte ich mit meinem jetzigen Programm anpassen/ändern wie> ich es brauche. Momentan hab ich als Basis 44kHz.> -Für ein 16Bit Sound brauche ich also 16Mhz Controllertakt (externer> Quarz) oder mache ich da einen Gedankenfehler?
Wie hast du das gerechnet?
Für eine 16 Bit PWM brauchst du logischweise einen Timer, der von 0 bis
65535 zählt. Und das 44tausend mal pro Sekunde.
Also 65536 * 44000 = ca 2.8 Gigahertz(!)
Mit der Frequenz müsstest du einen Timer ansteuern, damit der eine 16
Bit PWM machen kann, deren Wert du 44tausend mal pro Sekude verändern
kannst.
Aber: brauchst du wirklich eine Ausgangsspannung, die du in 65536
Schritten abstufen kannst? Ich würde mal sagen: nicht wirklich.
@Alex (Gast)
>Samplerate könnte ich mit meinem jetzigen Programm anpassen/ändern wie>ich es brauche. Momentan hab ich als Basis 44kHz.
Das reicht.
>-Für ein 16Bit Sound brauche ich also 16Mhz Controllertakt (externer>Quarz) oder mache ich da einen Gedankenfehler?
Das reicht nicht.
>Als PWM Frequenz habe ich momentan den Mikrocontrollertakt von 8 MHz.
Nein, das ist dein PWM (Eingangs)Takt. Damit wird der PWM-Zähler
hochgezählt. Bei 8 Bit Auflösung dauert ein PWM Zyklus 256 Takte, bei 8
MHz hier 31,25 kHz.
Alex schrieb:> Um hier noch mal das eigentliche Thema aufzugreifen.>> Ich hab meine Soundwiedergabe mit einem PWM Signal jetzt hinbekommen,> aber die 8Bit Sounds hauen mich nicht wirklich um.
Mangelnde Klangqualität muss nicht unbedingt an der Quantisierung
liegen. Viele alte Synthesizer und Drumcomputer hatten auch keine 16 Bit
Auflösung und klingen trotzdem gut.
Wie gibt Du die Töne aus? Ist ein Filter dazwischen? Oder ein
Operationsverstärker? Oder gar nichts?
Siehe auch hier:
http://www.fpga4fun.com/PWM_DAC_3.html
@ Mark Brandis (markbrandis)
>liegen. Viele alte Synthesizer und Drumcomputer hatten auch keine 16 Bit>Auflösung und klingen trotzdem gut.
EBEN! Man denke an die gute, alte Amiga- und Atari-Zeit (seufz)
Mark B. schrieb:> Alex schrieb:>> Um hier noch mal das eigentliche Thema aufzugreifen.>>>> Ich hab meine Soundwiedergabe mit einem PWM Signal jetzt hinbekommen,>> aber die 8Bit Sounds hauen mich nicht wirklich um.>> Mangelnde Klangqualität muss nicht unbedingt an der Quantisierung> liegen.
Und dann erhebt sich ja auch noch die Frage, was man unter 'haut mich
vom Hocker' verstehen soll.
22khz/8Bit ist jetzt sicherlich nicht soweit HiFi, dass man das Atmen
des 2. Violinisten der Wiener Philharmoniker soweit hören kann um damit
eine Lungendiagnose stellen zu können, aber für den Hausgebrauch um
damit ein paar Töne mit besserer als der Telefonqualität der 60-er Jahre
des letzten Jahrhunderts abzuspielen, langt es allemal.
Karl H. schrieb:> ...nicht soweit HiFi, dass man das Atmen> des 2. Violinisten der Wiener Philharmoniker soweit hören kann um damit> eine Lungendiagnose stellen zu können...
:-)))
Herr Vorragend!
MfG Paul
Ein Timer für die Samplingrate und ein weiterer für das PWM/die
Analogwerte.
Die Timer oben sind für einen ATMEGA32U2 mit einem 16MHz Quarz
ausgelegt.
So einfach kann die Welt sein.
@Joachim B. (jar)
>> Man denke an die gute, alte Amiga- und Atari-Zeit (seufz)>eben, Axel F. auf dem Atari Soundchip war doch Wahnsinn
Buhhhh!!! Amiga rulez!!!
Karl H. schrieb:> 22khz/8Bit ist jetzt sicherlich nicht soweit HiFi, dass man das Atmen> des 2. Violinisten der Wiener Philharmoniker soweit hören kann um damit> eine Lungendiagnose stellen zu können
:-)
Falk B. schrieb:> @Joachim B. (jar)>>>> Man denke an die gute, alte Amiga- und Atari-Zeit (seufz)>>>eben, Axel F. auf dem Atari Soundchip war doch Wahnsinn>> Buhhhh!!! Amiga rulez!!!
Liegt Amiga tot im Keller, war Atari wieder schneller.
@Karl Heinz (kbuchegg) (Moderator)
>Zwar nicht Atari, aber haut mich auch heute noch vom Hocker :-)>Youtube-Video "IBM 5155 Playing the Secret of Monkey Island Theme Song"
Ach du SCH*****! In Bernsteinfarben und mit PC Pieper! Das ist ja mal
voll krass!!!
https://www.youtube.com/watch?v=aykuVMf4uIQ
Das war der HAMMER in den letzten Jahren des Amiga, mittlerweile fast 20
Jahre her 8-0
For all the you players out there.
Die Kiste namens Amiga 500 hatte damals 1 MB Ram (hatte jeder ne
Speichererweiterung) und einen 7,x MHz Prozessor. Ja MHz, nicht GHz. Die
Power kam aber in 1. Linie von den 3 Spezialchips für Audio, Video und
den restlichen Kram. Die waren das Geheimnis des Amiga. RIP!
Falk B. schrieb:> @Karl Heinz (kbuchegg) (Moderator)>>>Zwar nicht Atari, aber haut mich auch heute noch vom Hocker :-)>>Youtube-Video "IBM 5155 Playing the Secret of Monkey Island Theme Song">> Ach du SCH*****! In Bernsteinfarben und mit PC Pieper! Das ist ja mal> voll krass!!!
Gute Musik ist eben zeitlos :-)
Kann mich noch gut erinnern, als ich das zum ersten mal gehört habe. Zum
damaligen Zeitpunkt war das unvorstellbar, dass auf dem PC-Speaker so
was möglich gewesen wäre. Gegen eine Soundblaster kann das natürlich
alles nicht anstinken. Aber auch die ersten Soundblaster waren technisch
ja noch meilenweit von dem entfernt, was heutzutage in jeder Hausklingel
verbaut wird. Und mit einer Soundblaster klang Monkey Island dann schon
richtig gut.
@Bülent C. (mirki)
>> Power kam aber in 1. Linie von den 3 Spezialchips für Audio, Video und>Und Paula hieß glaub ich der Soundchip?!
Jup!
https://youtu.be/HKNVIgsbYrA
Bülent C. schrieb:> Hat der Alex es nun geschafft ein 8Bit Sound auszugeben?
Ja, aber der Sound haut ihn nicht vom Hocker. Ob dieser extrem klaren
"Fehler"beschreibung befragen wir alle eifrig unsere Glaskugeln. ;-)
Falk B. schrieb:> @Bülent C. (mirki)>> Power kam aber in 1. Linie von den 3 Spezialchips für Audio, Video und>> Und Paula hieß glaub ich der Soundchip?!>> Jup!>> Youtube-Video "EEVBlog #438 - Amiga 500 Retro Computer Teardown"
Eine Schande das einige Atari St Jünglinge den Amiga als Türstopper
mißbraucht hatten.
Andreas schrieb:> Eine Schande das einige Atari St Jünglinge den Amiga als Türstopper> mißbraucht hatten.
Eine Schande, dass einige Atari-ST-Jünglinge den Amiga als Türstopper
missbraucht hatten.