Guten Tag zusammen, aktuell arbeite ich an einem kleinen Projekt in dem ich unter anderem mit einem Milrocontroller Sounds (8 Bit, 8kb/s, WAV) wiedergeben möchte. Da auf einem Atmega328 kaum Platz ist möchte ich diese Dateien verlagern. In dem Projekt wird ebenfalls ein Smartphone Verwendung finden. Ich möchte nun eine Sound Datei vom Smartphone auf den Controller übertragen und diese dann wiedergeben. Die Datenübertragung an sich ist kein Problem, das funktioniert. Was allerdings ein Problem darstellt ist der vergelichsweise kleine RAM des Atmega328. Ich hätte schon gerne mindestens 16kb zum temporären speichern der Sounds bevor diese ausgegeben werden. Kann ich irgendwie mit dem Atmega seinen eigenen Flash beschreiben? Ich habe gelesen, dass sich der Flash-ROM normalerweise nur lesen lässt. Das Wörtchen ,,Normalerweise" weckt ein wenig hoffnung. (https://www.mikrocontroller.net/articles/AVR-Tutorial:_Speicher) Ansonsten bleibt mir nur einen externen Speicher anzubinden. MfG
M. M. schrieb: > Kann ich irgendwie mit dem Atmega seinen eigenen Flash beschreiben? Stichwort: Was macht ein Bootloader?
Ja, kann man, steht im datasheet unter self programming. Besser ist trotzdem externer speicher.
Willst du den Flash als RAM für die Sounddateien nutzen ? Gruß JackFrost
Bastian W. schrieb: > Willst du den Flash als RAM für die Sounddateien nutzen ? > > Gruß JackFrost Jup, so habe ich es mir vorgestellt Flip B. schrieb: > Ja, kann man, steht im datasheet unter self programming. Besser ist > trotzdem externer speicher. Danke! Darf ich fragen warum?
M. M. schrieb: > Bastian W. schrieb: >> Willst du den Flash als RAM für die Sounddateien nutzen ? >> >> Gruß JackFrost > > Jup, so habe ich es mir vorgestellt > > Flip B. schrieb: >> Ja, kann man, steht im datasheet unter self programming. Besser ist >> trotzdem externer speicher. > > Danke! Darf ich fragen warum? Flash kannst du max. 10000 Mal beschreiben (eher die Hälfte davon). twd_Flash ist 4,5ms. Solange braucht auch ein 24xx256 EEPROM und den kannst du mindestens 1000000 Mal beschreiben, also 100 bis 200Mal so viel. Pagesize ist bei beiden 64Byt. Einzig die Geschwindigkeit könnte ein Problem sein.
Dafür dürfte ein AVR zu klein sein. Nimm einen STM32 o.ä., am besten einen M4, der dürfte all deinen Anforderungen gerecht werden und hat sogar genug Power für MP3.
> Ich hätte schon gerne mindestens 16kb zum temporären > speichern der Sounds > Ansonsten bleibt mir nur einen externen Speicher anzubinden. Stattdessen würde ich eher den ATmega1284 nehmen.
Zum KURZZEITIGEN Zwischenspeichern dieser Sounds nimmt man RAM, den gibt es ggf. auch seriell mit SPI. Zur NOT FRAM, der ist sehr RAM-ähnlich (schneller Schreibzugriff, SEHR viele Schreibzugriffe möglich). Wenn die Sounds länger gespeicherst werden sollen, nimmt man serielles EEPROM oder Flash. Das ist nicht nur billiger, sondern auch programmtechnisch DEUTLICH einfacher, als den internen Flash des AVRs zu beschreiben.
Falk B. schrieb: > Wenn die Sounds länger gespeicherst werden sollen, nimmt man serielles > EEPROM oder Flash. Das ist nicht nur billiger, sondern auch > programmtechnisch DEUTLICH einfacher, als den internen Flash des AVRs zu > beschreiben. Und warum da nicht FRAM? 128kBit kosten 2€. Und man hat keine Sorgen wegen Schreibgeschwindigkeit oder kaputtlöschen.
Mein grosses V. schrieb: > Wie kommst du zu dieser fundamentalen Erkenntnis? Kannst du auch was anderes, ausser dumme Fragen stellen ? Obwohl du damit nichts anfangen kannst, aber: Ausprobiert, allerdings waren es M88 - nur eine davon hat knapp 10000 geschafft.
@ H.Joachim Seifert (crazyhorse) >Und warum da nicht FRAM? 128kBit kosten 2€. Und man hat keine Sorgen >wegen Schreibgeschwindigkeit oder kaputtlöschen. Für den Preis kriegt man 4 Mbit Flash. https://www.it-wns.de/themes/kategorie/detail.php?artikelid=668&source=2 Und für den reichlich das doppelte Geld gleich 8-fach Flash. https://www.it-wns.de/themes/kategorie/detail.php?artikelid=667&source=2 Ist aber für ein Hobby und Einzelstück egal. Und kaputtgeschrieben kriegt man den Flash auch nicht so schnell, wenn man ein BISSCHEN drüber nachdenkt und SINNVOLLE Schreibzugriffe macht.
M. M. schrieb: > Flip B. schrieb: >> Ja, kann man, steht im datasheet unter self programming. Besser ist >> trotzdem externer speicher. > > Danke! Darf ich fragen warum? Es hängt von deinem Anwendungsprofil ab. Wenn der Platz ausreicht und man im langfristigen Mittel mit der Größenordnung von einer Soundaktuallisierung am Tag auskommt, so wird das auch Jahrelang halten. Mein grosses V. schrieb: > Marc V. schrieb: >> (eher die Hälfte davon). > > Wie kommst du zu dieser fundamentalen Erkenntnis? Weil er weiß wofür der Wert im Datenblatt bezüglich der Haltbarkeit steht. Die 10.000 bedeuten nicht, daß der Flash nach 10.000 Zyklen plötzlich Schrott ist. Die Eigenschaften verschlechtern sich kontinuierlich von Zyklus zu Zyklus. Die 10.000 bedeuten dann, daß nach 10.000 Zyklen unter Laborbedingungen eine festgelegte Quote an von den Spezifikationen als defekt definierten Chips nicht überschritten wird. Das bedeutet noch nicht einmal daß der Chip wirklich Schrott sein muß. Manchmal überschreiten einzelne Speicherstellen unter bestimmten Betriebsbedingungen die Spezifikationen, z.B. könnten einzelne Datenbits nach "relativ" kurzer Zeit kippen, also vor Ablauf der 20 Jahre bei Lagerung um 85 Grad. Oft sind auch das nur Hochrechnungen, weil man nicht einen vollen Testpool mit der vollen Zyklenzahl über die volle Zeit durchtestet. Umgekehrt können einzelne Chips auch sehr viel früher ausfallen, besonders wenn man im Feld keine idelen Laborbedingungen hat. In einem kleinen Pool kann die Quote durch Varianz/Serienstreuung auch vorzeitig überschritten werden. Im Extremfall kann ein Einzelstück auch schon nach ein paar Zyklen lange vor der 10.000 versagen. Wenn an die Sounds nicht sehr häufig aktualisiert, kann man sie durchaus im internen Flash speichern. Wenn die Häufigkeit grenzwertig wird, kann man, bevor man einen externen Speicher drantackert, auch einen größeren Chip nehmen als nötig und mehr Zyklen realisieren indem man die Schreib/Lösch-Zyklen über den freien Speicher gleichmäßig verteilt(Wear leveling). Das ginge hier leicht mit einem Ringpuffer. Wenn je 16k für Programm und Sound benötigt würde, so würde ein Chip mit 128k Speicher im Schnitt 7 mal so lange halten wie einer mit 32k. Man kann das natürlich noch weiter optimieren, aber noch gibt es keine Informationen über die Regelmäßigkeit der Soundupdates.
@ Carsten R. (kaffeetante) >>> (eher die Hälfte davon). >> Wie kommst du zu dieser fundamentalen Erkenntnis? >Weil er weiß wofür der Wert im Datenblatt bezüglich der Haltbarkeit >steht. Nö, das weiß er nicht. > Die 10.000 bedeuten nicht, daß der Flash nach 10.000 Zyklen >plötzlich Schrott ist. > Die Eigenschaften verschlechtern sich >kontinuierlich von Zyklus zu Zyklus. Ja, aber . . . >Chip wirklich Schrott sein muß. Manchmal überschreiten einzelne >Speicherstellen unter bestimmten Betriebsbedingungen die >Spezifikationen, z.B. könnten einzelne Datenbits nach "relativ" kurzer >Zeit kippen, also vor Ablauf der 20 Jahre bei Lagerung um 85 Grad. Oft >sind auch das nur Hochrechnungen, weil man nicht einen vollen Testpool >mit der vollen Zyklenzahl über die volle Zeit durchtestet. >Umgekehrt können einzelne Chips auch sehr viel früher ausfallen, >besonders wenn man im Feld keine idelen Laborbedingungen hat. In einem >kleinen Pool kann die Quote durch Varianz/Serienstreuung auch vorzeitig >überschritten werden. Im Extremfall kann ein Einzelstück auch schon nach >ein paar Zyklen lange vor der 10.000 versagen. Du hast die Wahrscheinlichkeitsrechung nicht verstanden. Denn genau ANDERS herum wird ein Schuh draus. Wenn gleich es immer extrem seltene Einzelfehler geben kann, so ist die Spezifikation von Halbleitern immer sehr konservativ. D.h. 99,999xyz% der Flashs halten die 20 Jahre Datenerhalt bei 85°C aus und überschreiten diese Zahl deutlich, Faktor 2-3 ist hier kein Problem. Eben um bei den großen Prduktionsmengen ein hohes Maß an Sicherheit der GARANTIERTEN Parameter zu erreichen und die Streuung der Lebensdauer im sicheren Bereich zu halten. Die Hersteller machen sozusagen eine Abwertung der ICs in ihrer Spezifikation, real sind sie meisten ICs deutlich besser (wenn da die böse Statistik nicht wäre). Schau dir bei anderen Parametern die typischen und die GARANTIERTEN Werte an, da sind bisweilen ein Faktor 10-1000 dazwischen. Das liegt bisweilen auch am Meßaufwand in der Massenproduktion. Für ein Hobbyprojekt kann man durchaus die 2-3 fachen Schreibzyklenzahl eines Flash annehmen. Für professionelle Serienprodukte natürlich nicht. >Wenn an die Sounds nicht sehr häufig aktualisiert, kann man sie durchaus >im internen Flash speichern. Kann man, ist aber programmtechnisch ziemlich aufwändig. Das macht man nur, wenn man lange Weile hat oder EXTREMST Platz und Kosten sparen muss.
@Falk Lies es bitte nochmal. Inhaltlich schreiben wir beide das gleiche. Oder präzisiere was bei mir falsch ein soll. Falk B. schrieb: > Kann man, ist aber programmtechnisch ziemlich aufwändig. Das ist nicht wirklich aufwändiger als einen externen Flash anzubinden, aber man spart sich den Hardwareanbau. Ich denke da weniger an die Kosten in Serie, sondern mehr an die Platine bzw den Drahtverhau (übertrieben) bei Prototypen.
@Carsten R. (kaffeetante) >Lies es bitte nochmal. Hab ich. > Inhaltlich schreiben wir beide das gleiche. Oder >präzisiere was bei mir falsch ein soll. Du bzw. Marc V. behaupten, daß man nur die Hälfte der im Datenblatt angegebenen Schreibzyklen real erreicht. Ich behaute das Gegenteil, man erreicht meistens das Doppelte und mehr. >Das ist nicht wirklich aufwändiger als einen externen Flash anzubinden, Aber sicher. Den internen Flash kann man nur aus der Bootloadersection heraus beschreiben. Das ist keine sooo einfache Sache, erst recht nicht für Anfänger. Ich wüßte spontan auch nicht, wie es im Detail geht, hab ich noch nie gemacht. >aber man spart sich den Hardwareanbau. Ich denke da weniger an die >Kosten in Serie, sondern mehr an die Platine bzw den Drahtverhau >(übertrieben) bei Prototypen. Ach herje, eine 8pol IC anbinden wird zum Staatsakt.
Nicht ganz, sondern daß man bei kleinen Stückzahlen mit einer geringeren Zyklenzahl rechnen muß um auf das gleiche Restrisiko die Fehlerquote zu überschreiten zu kommen. Zumindest was mich betrifft. ;-) 100 Prozentige Garantien gibt es ja nicht. Aber damit schweifen wir vom Thema ab. Das war von Anfang an eine Randbemerkung. Das sollten wir in einem Anderen Thread klären. Praktischerweise kommt hier entgegen, daß ein hoher Verschleiß aber auch bedeutet, daß die Daten wahrscheinlich nicht lange gespeichert werden müssten und Bitfehler in Sounddaten, die nur abgespielt und nicht zurückgelesen werden, speziell Rohdaten, in der Regel eher unkritisch sind. Das hört man oft nicht einmal. Man muss beim externen Flash auch erst ins Datenblatt schauen um die Befehlssequenzen zu implementieren. Mit einem einzelnen Befehl ist es nicht getan. Einen Staatsakt stellt die Hardware nicht dar, aber wissen wir was benutzt wird? Arduino ohne Lötkolben und bestenfalls ein Breadboard? So gesehen wäre es bei hoher Updaterate der Sounds wirklich besser dem Vorschlag zu folgen und einen passenden Chip mit externem Ram zu nehmen, sofern es kein Problem darstellt, daß die Töne ohne Strom verloren gehen. Den Speicher könnte man dann direkt ansprechen. Wenn wir nur mehr über den geplanten Aufbau und die Anwendung wüssten...
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.