Hallo, also ich habe eigentlich ein einfaches Ziel, ich möchste mit einem AVR Geräusche für die Modelleisenbahn erzeugen z.B. das Fahrgeräusch oder das Pfeifen einer Dampflok. Da gibt es ja als erstes das Platzproblem ... das ließe sich vielleicht lösen, aber das Speicherplatzproblem ist größer, denn im Idealfall hat ein AVR wenn überhaupt 0,5kB EEPROM. Also entweder noch ein EEPROM oder anderer Controller, der dann aber vielleicht nimmer so schön zu programmieren ist. Fällt jemanden eine andere Effiziente Lösung ein? Ausgeben mit PMW oder DAC is mir mehr oder weniger klar, allerdings ham die AVRs doch gar keinen DAC oder? Besten Dank vorab. Gruß Jens
Nimm doch ein Atmel Dataflash (4, 8, 16, 32 MBit), die lassen sich via SPI ansteuern und dürften genug Platz bieten :)
ok, vom Speicherplatz sind se bestimmt geeignet, aber die sind ja doch sehr arg winzig ... aber ne Idee ist es, was kostet da s n Teil und wo kriegt mans her? ... größerer Speicher ist ja nur eine Möglichkeit ... könnte man die Daten nicht auf eine einfache Weise komprimieren?
Nimm M25Pxx von ST, sind billiger als der Dataflash (ca. 6 für 32MBit). Die gibts bei Digikey.
Du kannst natürlich auch serielle EEPROMs nehmen, die gibts von Atmel mit bis zu 512kBit (evtl. mehrere kaskadieren?). Diese Teile sind definitiv nicht teuer. Was die Dataflashs angeht, so habe ich die mal bei Ineltek gesehen. Einzelstücke sind recht teuer, aber ne VPE geht dann vom Preis. Weiß allerdings nicht mehr, wie groß die VPEs waren.
Digikey? 18 Versandkosten, Mindestbestellwert 100 sonst 13 Mindermengenzuschlag, Bezahlung per Kreditkarte. Tolle Alternative...
Nimm einen Mega32 und gib die Daten mit 4 Bit Genauigkeit aus. Bei 8000 Samples pro Sekunde reichen dann die 32KByte Flash für 8 Sekunden aus.
Hi! Wenn noch Platz für einen Extrachip ist, dann nimm doch gleich einen ISP 1416 oder größer! Die haben alles drauf was man für die Soundaufzeichnung und Wiedergabe benötigt, sind in der SMD-Form schön klein und können sehr gut mit nem AVR gesteuert werden. Kosten auch net viel, so um die 6-15 je nach Größe. Bei mnachen kann man über 4 Minuten aufzeichnen. mfg Fasti
Also das mit dem Sprachspeicher find ich nicht gut, weil ich da ja nicht sagen kann ich würde jetzt gerne Geräusch an der Stelle 3s abspielen, sondern das immer von ganz vorn nach ganz hinten nuddelt. Die Daten ins Flash zu schreiben, gut da hats mehr Platz aber der Sound ist dann immer Teil des Programms. Ideal wäre ein Chip, ähnlich wie in den Speichersticks - wobei 1MB ja locker reichen würde, der wäre dann sicher auch klein nur sollte er 1. halt auch käuflich sein und 2. obendrein nicht zu teuer
Versuch doch mal, ob man das monotone Geräusch eines Zuges nicht mit einem Algorithmus auch erzielen könnte. Rechenzeit hat man mit nem AVR schließlich genug, und 4 Bit (oder auch 8) sollten da ja voll ausreichend sein.(8000 Hz -> 2000 Takte/Sample) Dass kriegt man dann mit sogut wie jedem Chip hin (Tiny bei 4/8/16 MHz je nach Algorithmus). Hab auch schonmal einen für eine "Big-Ben" Klingel gesehen (weiß aber nimmer wo). Einfach mal das Geräusch analysieren, und los gehts ...
Wie sieht denn das mit ner Speicherkarte aus? Es gibt ja schon einige sehr gute Einbindungen von SD-Karten für die Atmels. Oder gibts da Geschwindigkeitsprobleme mit dem Datendurchsatz? Greetz KMT
also ne 8 oder 16 MB speicherkarte reicht und die krigste sogar in manchen geschäften geschenkt oder für 1 weil die eh ned mehr gebraucht werden
Also das Geräusch mit Fourie zu analysieren und dann den Chip rechnen lassen geht auch, allerdings muß man für jeden neuen Sound neu rechnen und außerdem war diese Technik noch nie mein Fall. Geschenkte Speicherkarten? ... unglaublich :) ... gegen einen Karte Spricht eigentlich nix, außer deren Größe und Bauform, weil wenns klappt wie ich mir das Vorstelle, könnte ich schon ein paar der Geräte gebrauchen.
1. "Der Sound ist immer Teil des Programms": Nö. Du reservierst einen Teil des Flash für das Programm. Ein üblicher, selbstprogrammierender Controller kann diesen Teil dann auch mit neuen, über Schnittstelle empfangenen Sounddaten überschreiben. Kein Problem. 2. Man kann sehr einfache Verfahren schreiben, wie man sehr kompakt Audiodaten niederer Qualität ablegen kann, die man in Echtzeit auf einem kleinen µC dann wieder in echte Daten umsetzt. 3. Für Modellbahngeräusche (Pfeifen, Zischen, Tschtschtsch, vielleicht einmal Bimmeln) brauchst Du nur ganz wenige als Audiodaten vorliegende Fragmente, die Du dann realistisch kombinieren kannst.
also ich hab schon 8MB Karten geschenkt gekrigt...naja egal. Was haltet ihr von einem SRAM????
1. ... stimmt soweit hatte ich noch nicht gedacht 2. ... wie könnte denn so ein Verfahren aussehen, hat jemand mal irgendwie n Beispiel gesehen? 3. ... ja gut, sich das ganze zusammenzubasteln ginge natürlich, aber selbst da müßte man ja ins Flasch ausweichen, weil mit 500 Werten im EEPROM kommt man selbst so nicht weit SRAM - verliert das nicht die Lust, äh den Inhalt wenn der Strom weg is?
hat keiner ne Idee oder ein Beispiel für einen cleveren Wiedergabe bzw. Komprimierungsalgorythmus?
Du könntest nicht die Samples selbst, sondern immer nur die Differenz zum Vorgängersignal übertragen. Da die Differenzen oft kleinere Werte als die Samples haben, braucht man weniger Bit zur Kodierung. Macht man das ganze adaptiv und erweitert es ein bischen, dann nennt sich das ADPCM. Für Details Google fragen. Sehr viel mehr kann man wohl nicht machen. Das Problem an der Stelle ist, daß die wirklich guten Codecs (GSM-Codec oder MP3) so viel Rechenzeit brauchen, daß sich das mit den kleinen Microcontrollern (AVR) nicht machen läßt und große Microcontroller oder extra Chips mehr kosten als ein größerer Speicher. Markus
ADPCM bringt eine Reduzierung um etwa die Hälfte. Es geht zwar auch mehr aber dann hört es sich schrecklich an. ADPCM lohnt sich nur, wenn man viel Rechenleistung hat. Die einfachste Lösung ist immer noch Tiny15L mit HighSpeed PWM Ausgang und ein seriellem Flash dran. Sowas läuft bei mir seit Monaten mit einer 3V Lithiumknopfzelle aus einem Mainboard. Auf Knopdruck wird ein Text (in recht guter Qualität) abgespielt. Da der tiny15L aber kein SPI hat, und nur mit 1,6MHz läuft hat er viel zu tun um die Daten seriell einzulesen. Viel mehr als 11kHz Samplerate sind da nicht drin. Dafür ist alles aber klein und einfach.
gut, wieder was gelernt ... wobei wenn man die Daten um die Hälfte reduziert bringt mich das nur bedingt weiter, weil angenommen ich hab 5s Sound und ich taste mit 8KHz ab, bräuchte ich 40000 Speicherplätze reduziert auf die Hälfte macht ca. 20kB ich hatte mir derweil überlegt ... vielleicht läuft das aufs Selbe hinaus ... mal einen Sound zu sampeln (Software dafür hab ich im Internet ausgebuddelt) und mir dann mal die Werte, die dabei herauskommen, anzugucken - vielleicht macht es ja Sinn den Wert und seine Gültigkeitsdauer zusammenzufassen wobei das für austauschbare Sounds auch doof sein wird, denn ich müßte mir eine PC-Software schreiben, die Zuordnung Meßwert und Gültigkeitsdauer für mich erledigt und ich kann doch gar nicht programmieren für Windows :( und eine neue Frage hat sich auch aufgeworfen, wie bekommt man es denn hin, daß der Sound immer gleich schnell ist, wenn sich die Prozessorgeschwindigkeit ändert, gibts da ne Norm?
> und eine neue Frage hat sich auch aufgeworfen, > wie bekommt man es denn > hin, daß der Sound immer gleich schnell ist, wenn sich die > Prozessorgeschwindigkeit ändert, gibts da ne Norm? Dafür verwendet man Timer. Du kannst aber nicht erreichen, dass der Sound immer gleich schnell abgespielt wird, wenn der Prozessor nicht mitbekommt, dass sich die Geschwindigkeit geändert hat. Du musst also dem Programm immer mitteilen wie schnell der Prozessor läuft. Aber wozu willst du die Geschwindigkeit ändern? Lass ihn einfach mit voller Speed laufen und schick ihn schlafen, wenn er nicht gebraucht wird.
>>ADPCM lohnt sich nur, wenn man viel Rechenleistung hat. Im Gegenteil, ADPCM lohnt sich insbesondere dann wenn man sehr wenig Rechenleistung hat. Suche mal bei Dallas in deren AN's für PIC's. Dort ist ein ADPCM Source erklärt und man sieht wie wirklich einfach die De-/Kodierung ist. Die nötigen Resourcen sind sehr gering, sowohl im zusätzlich benötigten Speicher wie auch in den nötigen Rechenoperationen. Im Vergleich zu dieser Einfachheit sind 50% Komprimierungsrate in einem Livestream wohlgemerkt schon eine sehr gute Komprimierungsdichte. Vergleiche dies mal mit bekannten Verfahren wie Huffman/LZW auf den gleichen binären Sounddaten. Gruß Hagen
Hi Jens! Du solltest dir die ISPs genauer anschaun, da kannst du nicht nur von vorn bis hinten durchspielen sondern die sind voll adressierbar, d.h. du kannst erstens mehrer Sounds einspeichern und auch in den samples herumspringen was du willst und ersparst dir somit das ganze ADPCM oder sonstwas Zeugs. PS: Ich hab nur einmal auf submit gedrückt, wieso das dreimal dasteht ist mir ein Rätsel...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.