Hallo Leute, ich arbeite an einem Projekt das mich als Einsteiger etwas überfordert. Vielleicht könnt Ihr mir etwas unter die Arme greifen. Was mir derzeit Kopfzerbrechen bereitet, ist das speichern eines Arry´s ins EEPROM und das suchen eines Wertes aus EEPROM. Ausserdem bin ich mir nicht sicher, ob ich das mit der Speichergröße richtig verstanden habe? Ich möchte den Wert eines Potentiometers via ADC einlesen und diesen einer 5 Stelligen Zahl zuordnen. Z.B. Zahl 14100 soll zum ADC Wert 123 zugeordnet und im EEPROM gesichert werden. Da der ADC mit 10 Bit Auflösung 1024 Werte ausgeben kann, soll mein Array dann auch 1024 Zeilen haben, jeder ADC Wert von 0 bis 1024 soll dann eine Zeile im Array darstellen und eine 5 Stellige Zahl speichern. Zum Thema Speichergröße (EEPROM) Z.B. der ATmega 32 hat 1 KByte EEPROM also 1024 Byte. Wenn ich alles richtig verstehe, hat eine Zahl alleine 1 Byte? ich kann also nur 1024 Zahlen abspeichern? Dann würde ich bei den Daten einen Kompromiss eingehen und einem ATmega 128 nehmen, der hat 4 KByte EEPROM. Noch habe ich kein Programm geschrieben, um es hier zu posten, daher nur mein Ziel, für all jene, die wissen wollen, was ich vor habe: Ich möchte ein Steuergerät für eine Antenne bauen (die Antenne ist eine Magnetic Loop). Die Antenne muss mit einem Drehkondensator abgestimmt (eingestellt) werden. Da die Antenne nicht in greifbarer nähe aufgebaut werden kann, muss dieser Drehkondensator per Elektromotor gedreht werden. Dieser Teil ist bereits vorhanden, ausserdem ist der Drehkondensator mit einem Potentiometer gekoppelt, der dann die Position des Kondensators ermitteln soll. Den Wert des Potentiometers würde ich gerne mit dem ADC einlesen. Nun möchte ich aber die Frequenz auf der die Antenne gerade eingestellt ist mit dem ADC Wert abspeichern. Wenn ich die Antenne später wieder auf diese frequenz einstellen möchte, gebe ich die Frequenz vor und der AVR muss aus dem EEPROM den dazugehörigen ADC Wert "ermitteln". Dann soll per PWM der Motor in die richtige Richtung bewegt werden bis der gespeicherte und der gemessene ADC übereinstimmen. All das kriege ich hin, nur hab eich bisher nichts mit dem EEPROM gemacht! Ich weis nicht wie ich dort ein Array ablegen kann, und wie ich daraus Daten abrufen kann? Hat vielleicht jemand hierfür ein Beispiel für mich? Bin lieder noch "Anfänger". Bisher habe ich schon ein GLCD angesteuert, mit ADC Werten experimentiert, PWM benutzt, DCF77 decodiert. Zwar meistens mit Librarys, die öffentlich verfügbar sind, jedoch habe ich auch zum Großteil verstanden, was ich gemacht habe. Würde mich riesig freuen, wenn mit jemand helfen kann. Besten Dank fürs Lesen und noch mehr Dank im Voraus für alle Hilfe :-) Gruß Taner
Mal ne blöde Frage Gibt es keine Formel, die den von dir gewünschten Zusammenhang repräsentiert?
Hallo Karl Heinz, wie kann man sich eine Formel in diesem Fall vorstellen? Es soll nur ein ADC Wert einer Zahl zugeordnet werden, keine Berechnungen damit gemacht werden! Später muss nach dieser Zahl im EEPROM gesucht werden können und dann der ursprüngliche ADC Wert ausgegeben werden. Beispiel: Frequenz = 14100, ADC = 123 Frequenz = 24200, ADC = 345 Nun die Abfrage Freuenz = 14100, was ist der ADC Wert? Und hier muss dann 123 ausgegeben werden. eigentlich eine ganz simple anforderung. Gruß Taner
Und wenn es keine Formel gibt (es gibt immer eine), die Zuordnung aber "fest" ist, dann kannst du das Array ja auch im Flash ablegen.
Taner Ögretmen wrote: > Hallo Karl Heinz, > > wie kann man sich eine Formel in diesem Fall vorstellen? Das weis ich nicht. Ich kenne deine Zahlen ja nicht. Hast du schon mal versucht, die Zahlen in einem Diagramm darzustellen. Da sieht man am schnellsten ob eine einfache Formel existiert. Liegen alle Wertpaare zb. auf einer Geraden, dann hat man eine lineare Gleichung. > Es soll nur ein ADC Wert einer Zahl zugeordnet werden, keine > Berechnungen damit gemacht werden! Die frage war ja, ob es eine Formel gibt, so dass man mit dem ADC Wert hineingeht und mittels dieser Formel die Kondensatorstellung rauskriegt. Wenn 1 Apfel 5 Euro kostet, 2 Äpfel 10 und 3 Äpfel 15 Euro, dann kannst du dafür natürlich eine Tabelle aufstellen. Du kannst aber auch ganz einfach rechnen: Preis = Anzahl_Äpfel * 5 Und genau das ist die Frage: gibt es so einen Formlezusammenhang?
Also die Frequenz wird von einem externen Gerät (Funkgerät) quasi "vorgegeben". nun muss die Antenne vom Benutzer manuell eingestellt werden, wenn die Einstellung "passt", wird z.B. mittels Taster der aktuell gemessene ADC Wert und die eingestellte Frequenz abgespeichert, um später wieder abgerufen zu werden. Da der ADC Wert bei dieser Frequenz nicht immer der selbe sein muss (z.B. wenn die Antenne voller Schnee ist!), muss der Wert des ADC evtl. überschrieben werden können! D.h. man stellt die Antenne dann neu ein und speichert dann den neuen ADC Wert ab. Und das geht nicht im Flash, man kann den Wert vermutlich auch niemals berechnen? Zumindest gäbe es dort zu viele unbekannte Faktoren, die eine Berechnung unmöglich machen. Deshalb soll ja auch einfach nur die Frequenz auf Knopfdruck im EEPROM abgespeichert werden. Die "Zeile" soll identisch mit dem ADC Wert sein, somit würde nur ein eindimensionales Array benötigt, ADC Wert 123 wäre dann die "Zeile" 123 im Array, die die dazugehörige Frequenz abspeichern soll. Gruß Taner
Die lösung hast du ja schon fast. Jetzt die Frequenz als UL speichern (4 Byte) in Hertz. Bei einer vorgegebenen Frequenz dann die AD-Werte/Adressen von 0-1023 absuchen und auf Gleichheit prüfen. Der Zähler ist dann der gesuchte AD-Wert. Was die Speichergröße betrifft, schau mal bei den externen EEProms z.B. 24LC64 Microchip. Für die Anwendung ist der I²C schnell genug, zumal das lesen ohne Wartezeiten geht. Der Speicher ist dann Auswahlsache. gruß hans
Hallo Hans, ja, nur fehlt mir das nötige Wissen, Arrays in ein EEPROM zu schreiben und zu lesen. Und das war eigentlich auch mein Ausgangsposting. Externe EEXPROMS mit I²C würde ich auch gerne komplett aussen vor lassen, da es sie Sache für einen "Anfänger" wie mich nicht einfacher macht ;) Die Schaltung würde dadurch auch komplizierter werden. Daher würde ich mich auf ein Mega128 mit 4 KB EEPROM begnügen, was gerade so reichen müsste. Nur wie schreibe ich da Daten rein, wie suche ich danach? Hat jemand ein "Codebeispiel" für mich, wo ich mich reinarbeiten könnte? Gruß Taner
Das interne EEProm ist im Tutorial gut beschrieben. gruß hans
Taner Ögretmen wrote: > > Hat jemand ein "Codebeispiel" für mich, wo ich mich reinarbeiten könnte? Wie so oft, ist das AVR gcc Tutorial die Anlaufstelle der ersten Wahl. Abschnitt: EEPROM schreiben/lesen http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
> ja, nur fehlt mir das nötige Wissen, Arrays in ein EEPROM zu schreiben > und zu lesen. Und das war eigentlich auch mein Ausgangsposting. Dann schau Dir mal im Datenblatt die EEP-Register an (EEARL, EEARH, EEDR, EECR) und drösele Dein Array in Adresse (Index) und Wert (EEP-Inhalt) auf. > Daher würde ich mich auf ein Mega128 mit 4 KB EEPROM begnügen, was > gerade so reichen müsste. Schau Dir aber bitte vorher mal den Mega644 an. ;-) Und prüfe auch mal, ob Deine "5-stellige Zahl" unter 65536 liegt, dann reichen nämlich zwei Bytes (uint). KH
Hallo! Du solltest Dein Konzept grundsätzlich noch mal in Frage stellen. Die von Dir beschriebene Zuordnung ist unsinnig! Du ordnest einem Drehwinkel eine Frequenz zu. Es ist doch gerade umgekehrt. Zu einer Frequenz soll ein bestimmter Winkel gehören. D.h. der Winkel 37 Grad kann bei 14100, 6900, 23345 oder noch mehr Frequenzen richtig sein. Optimal ist deshalb ein zweidimensionales Array: die Frequenz und dazu der AD-Wert. Wenn man bei der Frequenz mit Integer auskommt sind das jeweils 4 Byte. Mit dem internen EEPROM von 1024 Bytes kann mann so 256 verschiedene Frequenzen mit den zugehörigen Winkeln ablegen. Das sollte wohl für'n Anfang reichen.
Hallo Route_66, da muss ich dir leider wiedersprechen. Der ADC Wert darf nur für eine Frequenz richtig sein! Er kann niemals für mehrere Werte zutreffen! Es kann nur sein, dass der ADC Wert "wandert", in diesem Fall wäre aber der zuvor gespeicherte ADC Wert NICHT MEHR KORREKT! Dieser muss dann gelöscht und der neue ADC Wert abgespeichert werden, aber zu diesem Zeitpunkt ist dann nur diese eine Frequenz mit diesem ADC Wert korrekt! Die Frequenz wird sich durch Witterungseinflüsse nur wenig verändern, nicht um mehere hundert KHz oder gar MHz. Somit bin ich nach wie vor überzeugt, dass mein Konzept i.o. ist. Darüber habe ich mir ausreichend Gedanken gemacht. Nur über das Handling mit dem EEPROM bin ich keinen Schritt weiter, obwohl ich dieses Posting aus diesem Grund gestartet habe. Das AVR Tutorial habe ich vor meinem Posting schon auch angeschaut, doch wie ich schon schrieb bin ich noch Anfänger und bin eben an dieser Stelle hängengeblieben. Vielleicht kann mir hier doch noch jemand weiterhelfen, würde mir sehr helfen... Gruß Taner
Ich gehe mal davon aus, daß du AVR-GCC benutzt.
1 | #include <avr/eeprom.h> |
2 | |
3 | #define ARRAY_SIZE 512;
|
4 | |
5 | uint16_t freq_adc[ARRAY_SIZE]; |
6 | |
7 | void save_to_eeprom() |
8 | {
|
9 | eeprom_busy_wait (); |
10 | eeprom_write_block(&freq_adc, 0, sizeof(freq_adc)); |
11 | }
|
12 | |
13 | void read_from_eeprom() |
14 | {
|
15 | eeprom_busy_wait (); |
16 | eeprom_read_block(&freq_adc, 0, sizeof(freq_adc)); |
17 | }
|
So in etwa. Ich habe das jetzt nicht ausprobiert.
Taner Ögretmen wrote: > Somit bin ich nach wie vor überzeugt, dass mein Konzept i.o. ist. > Darüber habe ich mir ausreichend Gedanken gemacht. Nur über das Handling > mit dem EEPROM bin ich keinen Schritt weiter, obwohl ich dieses Posting > aus diesem Grund gestartet habe. Wo liegt denn das Problem? Du willst das EEPROM doch als großes Array auffassen, das bei EEPROM Startadresse 0 beginnt. Also liegt der n-te Eintrag in diesem Array an der Adresse n * Länge eines Eintrags. Und damit hast du die Adresse, die du eeprom_read_word (oder was auch immer am besten passt um einen Eintrag aus dem Array zu lesen) übergibst und die Funktion holt dir die Werte von dieser Position. Fertig.
Hallo hdadhgdag, ich habe mir schon so viel Wissen in C angeeignet, dass ich mein gesamtes Projekt in C realisieren kann (ADC, PWM, LCD). Nur EEPROM nicht. Ich denke, noch mal ganz von vorne anfangen in Bascom mach deshalb auch wenig Sinn... Gruß Taner
Wenn der Mega32 zu klein ist: Es gibt pinkompatibel dazu den Mega644(P) mit 2KB EEPROM.
Taner Ögretmen wrote: > Hallo hdadhgdag, > > ich habe mir schon so viel Wissen in C angeeignet, dass ich mein > gesamtes Projekt in C realisieren kann (ADC, PWM, LCD). Nur EEPROM > nicht. > > Ich denke, noch mal ganz von vorne anfangen in Bascom mach deshalb auch > wenig Sinn... > > Gruß Taner Und wenn du einfach einen externen EEPROM-Baustein AT24CXX benutzt? Werden über TWI angesprochen, das macht imo alles sehr einfach, da es dazu von Peter Fleury eine schöne Library gibt...
Sorry habe das "abstimmen" überlesen. Ich bin von einer Antennen-DREH-Anlage ausgegangen, wo die Himmelsrichtung gespeichert werden soll. Das Prinzip bleibt aber das gleiche. Da für den Drehko nicht 1024 Winkelpositionen in Frage kommen, sondern schon mit 256 eine genügend feinfühlige Abstimmung erfolgt, passt es mit 1024 Byte internem EEPROM erst recht.
Hallo Route_66, auch da muss ich dir wiedersprechen. Es handelt sich um einen Jennigs Vakuum Drehkondensator. Dieser benötig 14 Umdrehungen von minimaler zur maximalen Kapazität! ich habe das mechnisch ziemlich aufwendig mit einem linearen Schiebe Potentiometer koppeln müssen (untersetzt), damit ich die gesmaten 14 Umdrehungen "auswerten" kann. Ich möchte schon gerne die möglichen 10 BIT Genauogkeit des ADCs nutzen können, um die korrekte Position des Kondensators anfahren zu können. @ Justus Skorps Das mit dem externen EEPROM hatten wir weiter oben, ich bin schon mit der Handhabung des interenen EEPROMS überfordert ;) Ich wäre ja schon froh, wenn ich 3 Werte im EEPROM abspeichern und nach bestimmten Kriterien wieder finden würde... Gruß Taner
Taner Ögretmen wrote: > Ich wäre ja schon froh, wenn ich 3 Werte im EEPROM abspeichern und nach > bestimmten Kriterien wieder finden würde... Tja. Wieder: Wo liegt das Problem? Nachdem du weißt, wie du einen bestimmten Wert auslesen kannst, nämlich den an Position n: Du gehst in einer Schleife alle für n möglichen Werte durch (0 bis 1024), liest den zugehörigen Eintrag aus dem EEPROM, vergleichst ihn anhand deiner Kriterien ob es der ist den du brauchst und fängst im Erfolgsfall zu jubeln an :-) Wie würdest du den deine Aufgabenstellung lösen, wenn du sie händisch mit Papier und Bleistift machen müstest (und als Erschwernis über deinem Notizpapier noch ein Paspartout liegen hast, welches dir immer nur Zugriff auf eine einzelne Zeile deiner Notizen erlaubt)? Überleg, welche Strategie du in so einem Fall machen würdest und genau das ist dann deine Strategie für das Programm. Programmieren kann man nur dann etwas, wenn man dasselbe Problem auch im richtigen Leben mit Papier und Bleistift lösen könnte. (wobei 'lösen durch scharfes hinschauen' nicht gilt)
Taner Ögretmen wrote: > > @ Justus Skorps > Das mit dem externen EEPROM hatten wir weiter oben, ich bin schon mit > der Handhabung des interenen EEPROMS überfordert ;) sorry, hab ich überlesen...aber ich bin trotzdem der Meinung, dass ein externen EEPROM einfacher anzusprechen ist, da man genau sagen kann, an welche Adresse ein Wert geschrieben werden soll oder welche Adresse gelesen werden soll...nix mit Array definieren etc...und es ist mehr Platz vorhanden...
Justus Skorps wrote: > aber ich bin trotzdem der Meinung, dass ein > externen EEPROM einfacher anzusprechen ist, da man genau sagen kann, an > welche Adresse ein Wert geschrieben werden soll oder welche Adresse > gelesen werden soll... Ähm. Und wo ist da jetzt der Unterschied zum internen EEPROM? Du mögest dir doch bitte mal die Parameter von eeprom_read_word und Konsorten ansehen. Genau dort gibst du eine Adresse an! Rate mal was das wohl für eine Adresse ist. Der einzige Unterschied besteht darin, dass du dem gcc per Schlüsselwort sagen kannst, dass du eine 'Variable' im EEPROM haben willst. Der gcc übernimmt dann insofern die Verwaltung des EEPROM, dass er dafür sorgt, dass diese 'Variablen' im EEPROM sinnvoll angeordnet werden und es zu keinen Adressüberschneidungen kommt. Aber der Zugriff erfolgt nachwievor, indem man den EEPROM Funktionen die Adresse übergibt, von der gelesen bzw. geschrieben werden soll. Ich hab 'Variable' unter Hochkomma gesetzt, weil es eben keine richtigen Variablen sind, sondern einfach nur die Variablenverwaltung des gcc zur Adressvergabe und Zuordnung mitbenutzt wird.
Karl heinz Buchegger wrote: > Ähm. Und wo ist da jetzt der Unterschied zum internen EEPROM? > Du mögest dir doch bitte mal die Parameter von eeprom_read_word und > Konsorten ansehen. Genau dort gibst du eine Adresse an! Rate mal was das > wohl für eine Adresse ist. grmpf..mist..sorry, bei internen EEPROM denk ich immer zuerst an sowas http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM-Variable_auf_feste_Adressen_legen das das auch direkt über Adressen geht verdränge ich irgendwie immer...
Taner Ögretmen wrote: > Wenn ich alles richtig verstehe, hat eine Zahl alleine 1 Byte? ich kann > also nur 1024 Zahlen abspeichern? Das ist so nicht richtig. Ein Byte hat 8 Bit. Ein Bit kann entweder "An" oder "Aus" sein (oder "1" bzw "0", oder "high" bzw "low", es ist egal wie du es nennst, es ist immer das gleiche gemeint). Wichtig ist nur, dass ein Bit genau zwei Zustände hat. Wenn man 8 Bit, also ein Byte, nimmt, ergeben sich folglich 256 verschiedene Zustände (alle Bits 0, erstes Bit 1 Rest 0, erstes Bit 1 und zweites Bit 1 Rest 0, usw... kannst ja mal durchzählen ;) , oder du rechnest einfach 2^8: Zwei mögliche Zustände hoch 8 Stellen (Bits)). Die 256 verschiedenen Zustände in einem Byte werden für gewöhnlich den Zahlen 0 bis 255 zugeordnet. D.h. also, mit einem Byte kannst du eine Zahl darstellen, solange sie nicht größer als 255 ist. Wenn du größere Zahlen darstellen willst, brauchst du mehr Bits. Da es die normalerweise immer im 8-er Pack gibt, nimmst du also ein zweites Byte hinzu. Jetzt hast du also insgesamt 16 Bit, macht 2^16=65536 verschiedene Zustände bzw. die Zahlen von 0 bis 65535. Dein EEPROM hat 1024 Byte. Du kannst darin also entweder 1024 Zahlen speichern, die nicht gößer als 255 sind, oder 512 Zahlen, die nicht größer als 65536 sind. Da du mit dem ADC einen Wert von einem mechanischen Bauteil (Poti) misst, macht es kaum Sinn, alle 1024 Werte des ADC zu benutzen. Du wirst für eine bestimmte Position des Potis bei mehreren aufeinanderfolgenden Messungen immer leicht abweichende Werte erhalten, also z.B. 245, dann 244, nochmal 244, dann wieder 245. Du kannst den Wert, den du vom ADC bekommst also getrost durch zwei teilen und mit 512 verschiedenen Werten arbeiten. Das ist genau genug. Und zufällig passen ja auch genau 512 16-bit-Zahlen in ein EEPROM mit 1024 bytes... ;) Gruss Andreas
Hallo Oliver, habe ich deinen Beitrag übersehen? Das hilft mir als Einstieg bzw. "roter Faden" erstmal weiter! VIELEN DANK! Mehr wollt eich doch garnicht :-) Gruß Taner Oliver Döring wrote: > Ich gehe mal davon aus, daß du AVR-GCC benutzt. > > > >
1 | > #include <avr/eeprom.h> |
2 | >
|
3 | > #define ARRAY_SIZE 512; |
4 | >
|
5 | > uint16_t freq_adc[ARRAY_SIZE]; |
6 | >
|
7 | > void save_to_eeprom() |
8 | > { |
9 | > eeprom_busy_wait (); |
10 | > eeprom_write_block(&freq_adc, 0, sizeof(freq_adc)); |
11 | > } |
12 | >
|
13 | > void read_from_eeprom() |
14 | > { |
15 | > eeprom_busy_wait (); |
16 | > eeprom_read_block(&freq_adc, 0, sizeof(freq_adc)); |
17 | > } |
18 | >
|
> > > > So in etwa. Ich habe das jetzt nicht ausprobiert.
Hallo Andreas, auch die ein herzliches DANKESCHÖN! Als gelernter Radio- & Fernsehtechniker kenne ich eigentlich alles was du mir geschrieben hast in und auswendig, verstehe jedoch meine eigene Denkweise nicht :-) Irgendwie habe ich mich darauf fixiert, dass ein zeichen 8 Bit benötig (trifft das auf die ASCII Zeichen zu? vielleicht deshalb)... Da ich tatsächlich nur Zahlen bis max 30000 benutzen werde, reichen somit 2 Bytes! Jetzt bin ich glücklich und werde versuchen das in der Praxis umzusetzen. Nochmals vielen vielen Dank Gruß Taner Andreas Vogt wrote: > Taner Ögretmen wrote: >> Wenn ich alles richtig verstehe, hat eine Zahl alleine 1 Byte? ich kann >> also nur 1024 Zahlen abspeichern? > Das ist so nicht richtig. > Ein Byte hat 8 Bit. Ein Bit kann entweder "An" oder "Aus" sein (oder "1" > bzw "0", oder "high" bzw "low", es ist egal wie du es nennst, es ist > immer das gleiche gemeint). > Wichtig ist nur, dass ein Bit genau zwei Zustände hat. Wenn man 8 Bit, > also ein Byte, nimmt, ergeben sich folglich 256 verschiedene Zustände > (alle Bits 0, erstes Bit 1 Rest 0, erstes Bit 1 und zweites Bit 1 Rest > 0, usw... kannst ja mal durchzählen ;) , oder du rechnest einfach 2^8: > Zwei mögliche Zustände hoch 8 Stellen (Bits)). > Die 256 verschiedenen Zustände in einem Byte werden für gewöhnlich den > Zahlen 0 bis 255 zugeordnet. > D.h. also, mit einem Byte kannst du eine Zahl darstellen, solange sie > nicht größer als 255 ist. Wenn du größere Zahlen darstellen willst, > brauchst du mehr Bits. Da es die normalerweise immer im 8-er Pack gibt, > nimmst du also ein zweites Byte hinzu. Jetzt hast du also insgesamt 16 > Bit, macht 2^16=65536 verschiedene Zustände bzw. die Zahlen von 0 bis > 65535. > > Dein EEPROM hat 1024 Byte. Du kannst darin also entweder 1024 Zahlen > speichern, die nicht gößer als 255 sind, oder 512 Zahlen, die nicht > größer als 65536 sind. > > Da du mit dem ADC einen Wert von einem mechanischen Bauteil (Poti) > misst, macht es kaum Sinn, alle 1024 Werte des ADC zu benutzen. Du wirst > für eine bestimmte Position des Potis bei mehreren aufeinanderfolgenden > Messungen immer leicht abweichende Werte erhalten, also z.B. 245, dann > 244, nochmal 244, dann wieder 245. Du kannst den Wert, den du vom ADC > bekommst also getrost durch zwei teilen und mit 512 verschiedenen Werten > arbeiten. Das ist genau genug. Und zufällig passen ja auch genau 512 > 16-bit-Zahlen in ein EEPROM mit 1024 bytes... ;) > > Gruss > Andreas
Hallo Taner, Du bist erstaunlich beratungsresistent! Aus Deiner Herangehensweise kann man deutlich ablesen, wie Du es früher gemacht hättest. Du stellst Dir die Auflösung des AD-Wandlers als Skala vor, die z.B. 1024 Millimeter lang ist. An bestimmten "Strichen" schreibst Du dann Frequenzen "ran". Aus Deiner Erfahrung musst Du allerdings wissen, dass solche "analogen" Skalen nie ganz genau sind und Du sagst ja auch dass Du mit Drift rechnest. Deshalb sollen ja auch Werte neu gespeichert werden können. Die Analogie zu mechanischen Skalen führt natürlich dazu, nicht an jeden "Millimeter" auch eine Frequenz anzutragen. Je nach Nichtlinearität von Skalen müssen nur einzelne Stützstellen (Striche) gespeichert werden. Die können auch über die 1024 mm unterschiedlich dicht verteilt werden. Zwischen diesen Stützstellen kann deann linear interpoliert werden. Genau wie das menschliche Auge auf einer "gemalten" Skala! Von Zeit zu Zeit können diese Stützstellen nachgeeicht werden. Das ist bei wenigen "Strichen" auf der Skala einfacher, als wenn an jedem Millimeter eine Frequenz steht. So wie Du es vor hast, kann irgenwann auftreten, dass die Frequenzen so stehen: 14100, 14093,14101,14098,14095,14097.... Programmiertes Chaos! Das werte dann bitte aus! Das Ergebnis eines Entwurfes in irgendeine Programmiersprache zu giessen ist zum Schluss dann nur noch Handwerk. Wichtig ist der SINNVOLLE Entwurf. "Geht auch so" ist manchmal Mist und rächt sich.
Hehe, sooo alt bin ich noch nicht, dass das alles schon lange her wäre! Bin "gerade erst" 31. Vielmehr liegt es daran, dass ich noch nicht so fit in Sachen Programmierung und AVR bin. Ich versuche mein "Steuergerät" so präzise wie möglich zu konzipieren, daher meine Intension alle 1024 möglichen Werte des ADC zu nutzen... Aus Fehlern lernt man :-) Wenn ich nicht jeden einzelnen AVR Wert nehmen soll, der möglich ist, sondern jeden zweiten, wie soll ich das sinnvoll interpolieren? Da gehen für mich dann die nächsten Probleme los... An das Chaos das du geschildert hast, habe ich auch schon gedacht, weil mir die Ungenauigkeit des ADC durchaus bekannt ist. Ich habe mir gedacht, dass ich dann alle unplausiblen Werte löschen muss... Daher: ich bin noch Anfänger :-) Gruß Taner
O.K. nichts für ungut. Die letztlich resultierende Kurve der Abstimmkennlinie ensteht durch viele Unbekannte. Es gibt die reine Winkel-Kapazität-Frequenz-Kennlinie, die ja auch von der Plattengeometrie und den parasitären Kapazitäten abhängt. Weiterhin hast Du die Poti-über-Deine-Mechanik-AD-Wandlung-Kennlinie. Dazu kommt der Nachgleichbedarf durch Alterung / Wand- Aufstellungs- Handkapazitäten. Es ist also mit einer recht komplexen Kurve / Funktion zu rechnen. Das hast Du ja bereits gepostet. Dennoch kann von einem kontinuierlichen Zusammenhang ohne Sprünge ausgegangen werden. Du stimmst ja eine Loop ab und steuerst nicht ein Antennenabstimmgerät wo zusätzlich auch Spulen(anzapfungen) umgeschaltet werden. Diese Abstimmkurve kann in viele lineare Linienstücke zerlegt werden. Je nachdem wie stark die "Krümmung" in einem Bereich ist, braucht man viele oder wenige Stützstellen. Die Werte dazwischen kann ein Controller leicht errechnen. Ich würde die Abstimmkurve mal per hand aufnehmen, um ein Gefühl für den Verlauf zu bekommen. Danach die Stützstellen bestimmen und diese zum Abspeichern vorsehen. Man sieht der Kurve ja an, ob alle 5, 10 oder 100kHz die Werte sich annähernd linear ändern. Da braucht man vielleicht nur die Werte für 14100 und 14200 kHz speichern, für 14165 kann man dann rechnen.
Für einen Einsteiger / Anfänger ist natürlich die Hürde viel zu hoch gelegt. Da die gesamte Problematik über Software anpassbar ist, solltest Du die Aufgabe so angehen wie Du sie schrittweise überblickst (und auch Fehler finden kannst). Aus Erfahrung kann ich sagen, dass gewisse Hardwarezwänge (z.B. begrenztes EEPROM) oft zu ungewöhnlichen Lösungen führen.
Mit Herausforderungen wächst man :-) Ansonsten stimmt ad schon, dass das Ziel für mich recht hoch gesetzt ist... Werde mein bestes geben! Mal sehen, was am Ande dabei rauskommt... Gruß Taner
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.