[Hank from hell]

Hallo,


ich bräuchte mal Rat zum Thema Microcontroller. Eventuell hat ja der ein oder andere schon damit in einem Amp gearbeitet.

Ich bin gerade dabei einen 3-Kanal Amp zu bauen. Die Kanal und Effektloop Schaltung / Steuerung soll dabei mittels eines Atmega32 Controllers realisiert werden, der LDR-Koppler als Schalter ansteuert. Den Microcontroller brauch ich vor allem um den Effektloop zu schalten, da er sich hier merken muss für welchen Kanal die Effekte aktiviert sind. (Mit Logikgattern oder ähnlichem gehts also nicht, da ich nen Speicher brauche)



Zu meinem Problem:

Der Controller muss sich 4 Sachen merken: Welcher Kanal aktiviert ist und dann jeweils für welchen der drei Kanäle der Effektloop aktiviert ist.

Nun hätte ich gerne, dass der Verstärker nach dem Aus- und wieder Anschalten im selben Zustand ist wie vorher ist, d.h. die oben genannten 4 Variablem muss ich im EEPROM des Controllers speichern und wieder laden.

Ich fände es allerdings wenig sinnvoll bei jedem Kanalumschalten den EEPROM erneut zu beschreiben. Das würde zwar funktionieren, aber ich denke es muss noch sinnvoller gehen. Optimal wäre es, wenn es eine Möglichkeit gäbe kurz vor dem Ausschalten des Microcontrollers / Verstärkers noch den EEPROM zu beschreiben. Leider habe ich dazu im Datenblatt und auch sonst wo im Internet nichts gefunden...

Hat jemand eine Idee wie man so ein "Schreiben beim Beenden" vielleicht realisieren kann? Notfalls müsste ich einen "Store" Schalter an der Frontplatte anbringen, mit dem ich dann die Effektloop Einstellungen speichern würde, dann würde ich diese beim Starten des Amps laden und den Amp einfach im Kanal 1 starten... Diese Lösung will ich aber möglichst vermeiden, da sich der Verstärker eigentlich ganz normal "analog" verhalten soll 


Danke schonmal,


Johannes

[extrem-harter-bass]

Moin.
Ich habe mir dazu grade folgende Möglichkeit überlegt:
Also mein Clavia Nord startet immer auf Bank 1A, und man muss auch alle Einstellungen speichern. (Verhält sich also wie dein Amp)
Der VAmp (ja ja  ) lädt immer die vorher eingestellten Funktionen beim Start, und das jeweilige Preset.
Also: Der VAmp muss einen 2. µC haben, der die noch nicht gespeicherte Einstellung immer sofort speichert, und beim "richtigen" Speichern dann auf den "richtigen" Speicher überträgt.
Ist das sinnvoll?
Gruss, Arno

[stachelsau]

Ich fände es allerdings wenig sinnvoll bei jedem Kanalumschalten den EEPROM erneut zu beschreiben.

Wieso ist das denn nicht sinnvoll?? Das EEPROM verkraftet sicher nen paar tausend Schreibvorgänge das sollte kein Problem sein.

Gruß,
Daniel

[Hank from hell]

Naja, bei jedem Schalten zu schreiben ginge wie gesagt schon. Der EEPROM verkraftet auch über 100.000 beschreibungen (100.000 gibt Atmel glaub ich als Minimum an), aber effizienter und sinnvoller wäre es halt wenn er am Ende einmal schreibt.

Wie gesagt, mir geht es darum ob es nicht doch vielleicht eine Lösung für dieses Problem gibt. Ich will's mir eigentlich nicht einfach aus Unwissenheit einfach machen und bei jedem Schalten schreiben 


Gruß,

Johannes

[hofnar]

Ich sehe da nur 2 Möglichkeiten.
1. Wirklich jedesmal das EEprom beschreiben.
2. Die Versorgung des Controllers so zu bauen, daß im Augenblick des Abschaltens der Controller noch kurtz von nen Elko versorgt wird (Quasi die elkos in der Siebung groß genug wählen). Ein paar msec müssten reichen zum speichern. Natürlich müsste man hier ständig den Powerschalter abfragen (Sobalt Aus dann speichern).

[Hank from hell]

Hallo,

Ich sehe da nur 2 Möglichkeiten.
1. Wirklich jedesmal das EEprom beschreiben.
2. Die Versorgung des Controllers so zu bauen, daß im Augenblick des Abschaltens der Controller noch kurtz von nen Elko versorgt wird (Quasi die elkos in der Siebung groß genug wählen). Ein paar msec müssten reichen zum speichern. Natürlich müsste man hier ständig den Powerschalter abfragen (Sobalt Aus dann speichern).

Die 2. Methode ist auch das einzige gewesen was mir bisher eingefallen ist, allerdings wüsste ich nicht wie man die Versorgungsspannung ohne allzu großen aufwand "überprüfen" kann, d.h. ob sie unter nem bestimmten Schwellenwert liegt und dann speichern.



Gruß,

Johannes

[NOS]

Hallo,

Anodenspannung runterteilen, AD-wandeln und beim Übergang nach Null abspeichern?

Setzt natürlich einen Standby + dessen Benützung voraus...

mfg NOS

[hofnar]

Ich würde es sogar eher über nen Optokopplermachen. Bin was ängstlich mit den hohen Spannungen.

[MetalBasti]

Hi,

Genau dafür gibt es doch externe Interrupts oder?
Sobald die Betriebsspannung absinkt löst man einen Interrupt aus. Das ließe sich mit einem Transistor und ein paar passender Z-Dioden realisieren.
Der µP sollte mehr als genug Zeit haben um den aktuellen Status im EEProm zu speichern.

Genaueres kann ich dir jetzt nicht sagen, weil ich selbst so gut wie keine damit habe, aber vielleicht klappts

Gruß Basti

[Hank from hell]

Hallo,

Genau dafür gibt es doch externe Interrupts oder?
Sobald die Betriebsspannung absinkt löst man einen Interrupt aus. Das ließe sich mit einem Transistor und ein paar passender Z-Dioden realisieren.
Der µP sollte mehr als genug Zeit haben um den aktuellen Status im EEProm zu speichern.

Genaueres kann ich dir jetzt nicht sagen, weil ich selbst so gut wie keine damit habe, aber vielleicht klappts Smiley

So werde ich es auch mal versuchen (hab noch nen kleinen Tip bekommen ). Also vor meinem Spannungsregler (µC bekommt die Betriebsspannung über die Heizwicklung) mit Hilfe eines Widerstands und ner Zenerdiode die Betriebsspannung überwachen, dann damit nen externen Interrupt auslösen.

Der µC wird dann bei abgeschalteter Betriebsspannung noch mit der Restspannung aus nem Kondensator gespeist (per Diode von der restlichen Spannung getrennt). Wenn der Interrupt auslöst werden alle Ausgänge abgeschaltet (Stromverbrauch senken...) und dann wird gespeichert. Ich hoffe nur, dass das ganze so funktioniert und dass das Beschreiben des EEPROMs schnell genug geht bzw. die Restspannung aus dem Kondensator lange genug hällt.



Gruß,

Johannes

[Andy]

Hi,

ich würde dem µC einen dicken Elko verpassen, damit er etwas "nachläuft" und als "Trigger" die Heizspannung hernehmen - alle 0,5s mal gucken und wenn weg, dann speichern...


Gruß

Andy

[Hank from hell]

Hallo,

ich würde dem µC einen dicken Elko verpassen, damit er etwas "nachläuft" und als "Trigger" die Heizspannung hernehmen - alle 0,5s mal gucken und wenn weg, dann speichern...

Ich werds wie gesagt etwa so machen wie MetalBasti das auch gemeint hat (das hier kommt ja auch auf's selbe raus). Als "Trigger-Spannung" werde ich die mittels Zener-Diode auf 5V begrenzte Heizspannung nehmen (nur die Spannung die zum µC geht wird begrenzt...).

Die Überprüfung an sich werde ich aber per Interrupt machen. Beim Atmega32 kann ich den externen Interrupt 2 (INT2) dafür nehmen, den hab ich noch frei und der lässt sich so einstellen, dass er auf fallende Flanken reagiert. Somit sollte mein Speichermechanismus ziemlich direkt ansprechen (ich glaube 4 Takte dauert es bis alles auf dem Stack liegt und die Interrupt Routine "anspringt" ).

Problematisch könnte es nur noch werden, wenn die Spannung zu schnell abfällt, so dass der externe Interrupt die fallende Flanke nicht mehr erkennt, dann müsste ich auf INT0 oder INT1 (die anderen externen Interrupts) umverkabeln, die können auch Zustandsgesteuert reagieren. Aber das halte ich für eher unwahrscheinlich...

Softwäremäßig hab ich schon alles am Laufen. Ich werde es halt mal so ausprobieren und dann mal schreiben was bei raus gekommen ist




Gruß,

Johannes

[Stephan G.]

Hi, Folks!

Ehrlich gesagt kann ich nicht nachvollziehen, wieso Du lieber in Hardware investierst, die zusätzliche Interrupt-Programmierung auf Dich nimmst, nur um das direkte Speichern zu umgehen?!!!

Ich sage Dir einen 20 mal höheren Aufwand voraus - inklusive der Ungewissheit, ob Deine Hardware-Interrupts so funktionieren, wie Du es Dir vorstellst ... Vergiss es!!!

Stell den Kanal ein, speicher die Daten im EEPROM und gut iss. Außerdem kann Dir die Kiste dann ruhig mal unkontrolliert abschmieren, ohne dass Du "Datenverlust" hast... 

Dafür gibts ja das EEPROM - darin sollen minimale Datenaufkommen gesichert werden können!!
Wenn eine Speicherung en Block gewünscht wäre, wärs ja ein Flash ...

PLAY LOUD!! 

[Andy]

Außerdem entgehen Dir noch die "Show"-Effekte beim Einschalten, mit denen man immer so gut das "noch-am-Leben-Sein" des µCs überprüfen kann...

[Hank from hell]

Hallo,

Ehrlich gesagt kann ich nicht nachvollziehen, wieso Du lieber in Hardware investierst, die zusätzliche Interrupt-Programmierung auf Dich nimmst, nur um das direkte Speichern zu umgehen?!!!

Ich sage Dir einen 20 mal höheren Aufwand voraus - inklusive der Ungewissheit, ob Deine Hardware-Interrupts so funktionieren, wie Du es Dir vorstellst ... Vergiss es!!!

Stell den Kanal ein, speicher die Daten im EEPROM und gut iss. Außerdem kann Dir die Kiste dann ruhig mal unkontrolliert abschmieren, ohne dass Du "Datenverlust" hast...  Wink

Ich will die Einstellungen allein deshalb nicht bei jedem Schalten im EEPROM speichern, weil für jede Zelle nur 10.000 Beschreibungen garantiert sind... Gut, jetzt kann man sagen, dass reicht ja dicke, aber ich mag den Gedanken nicht, dass der EEPROM irgendwann verschlissen ist, nur weil ich zu oft am Taster rumgedrückt hab   Wenn man die Zellen des EEPROM natürlich nach 10.000x schreiben immer durchwechselt könnte man das umgehen. Aber das ist irgendwie auch sinnlos. Außerdem finde ich es wie gesagt sehr ineffizient dauernd in den Speicher zu schreiben, wo eine Beschreibung doch genugen würde. Hoffe jetzt kannst du's nachvollziehen


Ein hoher Hardware Aufwand ist das ja auch nicht... Als "Überwachungsspannung", die ich in meinen Interrupt speise, nehme ich ja die runtergeregelte Heizspannung. Das ist blos eine Z-Diode und ein Widerstand mehr. Dann noch ein Kondensator der die µC Versorgungsspannung liefert wenn die Heizspannung weg ist. Das wäre alles an Hardware.

Softwaremäßig ist es genauso einfach. Gut, ich sollte vielleicht erwähnen, dass ich das ganze in C mache und nicht direkt in Assembler. Im Simulator funktioniert meine Interruptroutine auch wunderbar, und ich sehe keinen Grund warum es auf der Hardware nicht auch so funktionieren soll (zumal es im Datenblatt auch alles so beschrieben ist wie ich's gemacht hab).


Ob's tatsächlich geht wird sich zeigen. Aber wenn ja, dann war's viel einfacher als gedacht


Gruß,

Johannes