-         
Seite 3 von 5 ErsteErste 12345 LetzteLetzte
Ergebnis 21 bis 30 von 44

Thema: EEPROM - ausgelesener Wert ist ungenau

  1. #21
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2018
    Beiträge
    315
    Anzeige

    Aber so, wie es ausschaut, gab es kein anderes Problem. Ich denke, das wars.

    @basteluwe weiß mehr, ist sein Projekt.

    Gruß

  2. #22
    Erfahrener Benutzer Robotik Einstein Avatar von HaWe
    Registriert seit
    09.10.2014
    Beiträge
    3.296
    Zitat Zitat von Moppi Beitrag anzeigen
    Aber so, wie es ausschaut, gab es kein anderes Problem. Ich denke, das wars.
    @basteluwe weiß mehr, ist sein Projekt.
    Gruß
    Das kanns nicht gewesen sein, siehe 8820 -> 8800.
    genau deswegen bat ich ja um weitere Informationen von basteluwe.
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  3. #23
    Erfahrener Benutzer Fleißiges Mitglied Avatar von basteluwe
    Registriert seit
    15.11.2012
    Beiträge
    111
    Oh Ha! Hier ging ja noch richtig die Post ab!
    Danke für eure ganzen Beiträge. Ich gebe mal ein Update, um vielleicht etwas Licht in's Dunkel zu bringen.

    Das Problem ist tatsächlich für mich gelöst! Der im Post #14 von mir gezeigte Code funktioniert einwandfrei unter den bei mir gegebenen Bedingungen:

    Die wichtigste Änderung im neuen Code zum ursprünglichen ist der Punkt an dem ich radio.getFrequency() aufrufe. Ursprünglich habe ich das jedes Mal nach einem Scan-Befehl getan. Zum Debuggen hatte ich dann im Terminal die zurück gemeldete Frequenz anzeigen lassen. Die stimmte sehr oft nicht mit der aktuell wiedergegebenen überein. Pausen vor und nach dem Befehl änderten nichts an der Abweichung.
    Schließlich habe ich getFrequency einfach in die Hauptschleife gebaut und über "millis" nur alle 5 Sekunden aufgerufen. Zusätzlich habe ich EEPROM.update entdeckt, das nur bei Änderungen einen neuen Wert in den EPROM schreibt. Mit diesen Änderungen läuft der Code seit Gestern ohne jedes Problem.
    Ich habe aber nach wie vor keine Ahnung warum die Abfrage im ursprünglichen Code teilweise falsche Ergebnisse lieferte, aber egal: Problem solved!

    Ich sollte noch was zu den Bedingungen sagen, die zu der verwendeten Umrechnung geführt haben:

    Sämtliche Sender in unserer Ecke liegen im 100KHz Raster, der frequency-Wert endet also hier IMMER auf 0, niemals auf 5.
    Bei einem Frequenzbereich 87,00 - 108,00 MHz ergaben sich also 210 mögliche frequency-Werte.
    Um von den richtigen Werten (8700 bis 10800) auf byte-Format zu kommen, das EEPROM.put und EEPROM.get verlangt, habe ich die Formel storeFreq=(frequency/10)-825 "erfunden". Damit liegen die Speicherwerte zwischen 45 (87,0 MHz) und 255 (108,0 MHz).

    Mir ist klar, das das nur für meine spezielle Anwendung geht und nicht sehr elegant ist. Es erfüllt aber meinen Zweck, ich bin halt kein Profi-Coder.

    Ich bin wirklich dankbar für Eure Hilfe, das ist schon ein Spitzen-Forum hier!

    Uwe

    - - - Aktualisiert - - -

    Zitat Zitat von HaWe Beitrag anzeigen
    Immerhin scheint es aber jetzt ja auf magische Weise nicht mehr relevant zu sein, daher würde mich schon interessieren, wie was vorher berechnet, gespeichert und zurückgerechnet wurde, als der Fehler beim Zurücklesen/rechnen des Speicherwertes noch auftrat.
    Sorry, die Frage hatte ich überlesen.
    Im ursprünglichen Code gab es keine Umrechnung! Ich hatte get und put für den EEPROM verwendet, weil ich meine, dass die integer handeln können. Also habe ich den Wert aus getFrequency direkt in den EPROM gespeichert.
    Im neuen Code verwende ich für den EEPROM update, das leider nur byte akzeptiert. Daher jetzt die Umrechnung storeFreq = (frequency/10)-825;

    Uwe

  4. #24
    Erfahrener Benutzer Robotik Einstein Avatar von HaWe
    Registriert seit
    09.10.2014
    Beiträge
    3.296
    Ursprünglich habe ich das jedes Mal nach einem Scan-Befehl getan.
    aha, und was macht dieser Scan-Befehl genau, wie lautet und funktioniert er, und warum liefert er falsche oder schwankende Ergebnisse?
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  5. #25
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2018
    Beiträge
    315
    @basteluwe

    wenn radio.getFrequency() nicht immer ein stabiles Ergebnis liefert, hättest Du auch so lange radio.getFrequency() aufrufen und den Wert vergleichen können, bis der stabil ist und erst dann speichern. Irgendwann muss der stabil sein. Jetzt machst Du es anders, da passiert in etwa dasselbe, indem Du alle 5 Sekunden den Wert liest und mit dem im EEPROM abgleichen lässt, der wird im EEPROM solange geändert, bis der sich nicht mehr ändert. Blöd ist dabei, dass Du unnötiger Weise ins EEPROM schreibst. Anders herum ist es eine konsequente Lösung. Wenn Du das andauernd so machst, speichert das Programm immer den letzten Sender, wann immer er verstellt wird. Aber nur solang bis die Schreibzugriffe dem EEPROM zu viel waren Das ist dann auch konsequent. Geplante Obsoleszenz.

    Es gibt ja auch sowas wie Frequenzkorrektur, wenn der Sender abhaut, dass der sich durch Suchen den Sender wieder einfängt. So etwas war schon mal hier geschrieben, dass da noch eine Automatik im Spiel ist/sein könnte. - Spekulation.

    MfG
    Geändert von Moppi (09.10.2018 um 16:38 Uhr)

  6. #26
    Erfahrener Benutzer Robotik Einstein Avatar von HaWe
    Registriert seit
    09.10.2014
    Beiträge
    3.296
    @moppi:
    radio.getFrequency() funktioniert doch wie gewünscht, das Scannen vorher hat nicht funktioniert.
    Daher meine Frage:
    was macht dieser Scan-Befehl genau, wie lautet und funktioniert er, und warum liefert er falsche oder schwankende Ergebnisse?
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  7. #27
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    18.03.2018
    Beiträge
    315
    Wenn er einen Scan-Befehl schickt und ruft radio.getFrequency() auf, solange der Scan nicht beendet ist, wird es von radio.getFrequency() kein stabiles Ergebnis geben.

    Gruß

  8. #28
    Erfahrener Benutzer Fleißiges Mitglied Avatar von basteluwe
    Registriert seit
    15.11.2012
    Beiträge
    111
    Zitat Zitat von HaWe Beitrag anzeigen
    aha, und was macht dieser Scan-Befehl genau, wie lautet und funktioniert er, und warum liefert er falsche oder schwankende Ergebnisse?
    Der Befehl heisst radio.seekDown(); bzw. radio.seekUp();.
    Was er genau macht und wie er funktioniert kann sicher der Programmierer der radio.h beantworten, ich in jedem Fall nicht. Die falschen Werte liefert nicht der Scan-Befehl sondern der radio.getFrequency() in zusammenhang mit dem Scan.
    Ich denke, Moppi hat Recht. Vielleicht war der Scan noch nicht fertig, wenn schon getFrequency beantwortet wurde. Das könnte in der ersten Version den Fehler verursacht haben. Jetzt passiert das ja nicht mehr.
    Der nackte Befehl get.Frequency liefert stabile Ergebnisse. Er wird ja in jeder Hauptschleife für die Anzeige im OLED sowieso abgefragt und die Anzeige steht stabil wie sonstwas!

    Uwe

  9. #29
    Erfahrener Benutzer Robotik Einstein Avatar von HaWe
    Registriert seit
    09.10.2014
    Beiträge
    3.296
    Zitat Zitat von basteluwe Beitrag anzeigen
    Der Befehl heisst radio.seekDown(); bzw. radio.seekUp();.
    Was er genau macht und wie er funktioniert kann sicher der Programmierer der radio.h beantworten, ich in jedem Fall nicht. Die falschen Werte liefert nicht der Scan-Befehl sondern der radio.getFrequency() in zusammenhang mit dem Scan.
    Ich denke, Moppi hat Recht. Vielleicht war der Scan noch nicht fertig, wenn schon getFrequency beantwortet wurde. Das könnte in der ersten Version den Fehler verursacht haben. Jetzt passiert das ja nicht mehr.
    Der nackte Befehl get.Frequency liefert stabile Ergebnisse. Er wird ja in jeder Hauptschleife für die Anzeige im OLED sowieso abgefragt und die Anzeige steht stabil wie sonstwas!

    Uwe
    also, jetzt mal logisch mitgedacht:
    wenn der Befehl radio.getFrequency alleine korrekt funktioniert, dann wird er auch in Verbindung mit anderen Befehlen richtig funktionieren.
    Also auch mit irgendwelchen dubiosen Scan-Befehlen.

    Wenn also bei radio.getFrequency zusammen mit irgendwelchen dubiosen Scan-Befehlen Fehler auftreten, wird es nicht an radio.getFrequency liegen.
    Sondern...? Na...?

    Also wo wird dann wahrscheinlich oder möglicherweise irgendwas schief gelaufen sein?
    ·±≠≡≈³αγελΔΣΩ∞ Schachroboter:www.youtube.com/watch?v=Cv-yzuebC7E Rasenmäher-Robot:www.youtube.com/watch?v=z7mqnaU_9A8

  10. #30
    Erfahrener Benutzer Fleißiges Mitglied Avatar von basteluwe
    Registriert seit
    15.11.2012
    Beiträge
    111
    @Moppi
    Zitat Zitat von Moppi Beitrag anzeigen
    wenn radio.getFrequency() nicht immer ein stabiles Ergebnis liefert, hättest Du auch so lange radio.getFrequency() aufrufen und den Wert vergleichen können, bis der stabil ist und erst dann speichern. Irgendwann muss der stabil sein. Jetzt machst Du es anders, da passiert in etwa dasselbe, indem Du alle 5 Sekunden den Wert liest und mit dem im EEPROM abgleichen lässt, der wird im EEPROM solange geändert, bis der sich nicht mehr ändert. Blöd ist dabei, dass Du unnötiger Weise ins EEPROM schreibst. Anders herum ist es eine konsequente Lösung. Wenn Du das andauernd so machst, speichert das Programm immer den letzten Sender, wann immer er verstellt wird. Aber nur solang bis die Schreibzugriffe dem EEPROM zu viel waren Das ist dann auch konsequent. Geplante Obsoleszenz...
    Das hat mir dann doch keine Ruhe gelassen, also hab ich eine Zählvariable eingebaut, die im Terminal anzeigt, wann und wie oft in den EPROM geschrieben wird.
    Klicke auf die Grafik für eine größere Ansicht

Name:	debug.JPG
Hits:	5
Größe:	32,8 KB
ID:	33695

    Das Bild zeigt das Ergebnis von 30 Betriebsminuten, in denen ich fünf mal die Scan-Funktion aufgerufen habe. Da wird also tatsächlich nur einmal je angefordertem Frequenzwechsel in den EEPROM geschrieben.
    Genau genommen könnte ich die Zeitschleife von 5 Sekunden auch auf eine halbe Minute oder mehr vergrössern. Alles was ich erreichen will, ist ja nur der Neustart mit der gleichen Frequenz, wie beim Ausschalten. Solange ich nicht ausschalte, bevor die Schleife seit dem letzten Scan einmal durch ist, ist alles OK. Das würde sämtliche Scanbefehle dazwischen ignorieren und Schreibvorgänge im EPROM sparen. Wiederholtes Scannen innerhalb der Zeitspanne triggert ja kein neues Schreiben in den EPROM. Die Dauer der Schleife ist dann Ermessensfrage.
    Perfekt wäre nur einmaliges Schreiben direkt beim Ausschalten. Das ginge aber wohl nur durch softwaremäßiges Ein- und Ausschalten.

Seite 3 von 5 ErsteErste 12345 LetzteLetzte

Ähnliche Themen

  1. [ERLEDIGT] I2C Wert nach EEPROM 24C512 schreiben
    Von Bot-Builder im Forum C - Programmierung (GCC u.a.)
    Antworten: 7
    Letzter Beitrag: 13.03.2013, 08:34
  2. Edit: Wie Wert in EEPROM speichern?
    Von Maxxtro im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 24
    Letzter Beitrag: 23.02.2009, 10:03
  3. Bicore - ungenau
    Von boarter im Forum Elektronik
    Antworten: 0
    Letzter Beitrag: 29.06.2008, 01:15
  4. HEX Wert aus EEprom BINär umwandeln PICBASIC
    Von Robbersoft im Forum PIC Controller
    Antworten: 3
    Letzter Beitrag: 19.08.2007, 00:34
  5. Float Wert in EEPROM schreiben
    Von AlexAtRobo im Forum C - Programmierung (GCC u.a.)
    Antworten: 5
    Letzter Beitrag: 26.06.2006, 22:10

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •