INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
RTC MCP 7940 geht nach
09.01.2019, 21:15
Beitrag #9
RE: RTC MCP 7940 geht nach
Evtl. kann man auch beides verbinden.
Der ESP8266 holt sich die Zeit z.B. aller 3 Stunden per NTP. In der Zwischenzeit läuft er über die Time-Lib autark. Wenn der Sync erfolgreich war, wird die RTC neu gestellt und kann als Backup dienen, wenn mal länger das Netz ausfällt.

Solche "geheimen Hilfsmittel" kann man ja getarnt unterbringen, wie auch eine DS3231.

Wobei ich die Befürchtungen teile, dass der Steckbrettaufbau für die RTC der Problemfall sein kann. Wenn der Hersteller schon solche konkreten Vorgaben (eigentlich Einschränkungen) macht, dann hat er einen Grund dazu.

Gruß Tommy

"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
10.01.2019, 00:22
Beitrag #10
RE: RTC MCP 7940 geht nach
...genau, so wie Tommy bastel ich gerade mit dem ESP32 rum und da hole ich die Zeit per NTP Abfrage von der Fritzbox 7590 wo ich den NTP Dienst freigegeben habe. Und weil Fritzchen nicht meckern darf weil ich zu oft die Zeit abfrage wird die Zeit vom ESP32 alle 10 Minuten abgefragt....dazwischen übernimmt die Zeitansage die time.h
Nach dem Systemstart ist die Zeit sofort da.
lgbk

1+1 = 10 Angel ...und ich bin hier nicht der Suchmaschinen-Ersatz Dodgy...nur mal so als genereller Tipp..
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
10.01.2019, 12:19
Beitrag #11
RE: RTC MCP 7940 geht nach
Ja, mittlerweile habe ich auch 2 lokale Zeitserver (Fritzbox und ein RasPi, der als Drucker- und Zeitserver läuft). Aber die 3 Stunden habe ich noch drin, weil ich als Reserver noch externe NTP-Server vorbereitet habe. Das genügt auch völlig von der Genauigkeit her. Ich nehme aber den ESP8266, dessen Libgemenge in meinen Augen stabiler ist, als beim ESP32.

Gruß Tommy

"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
10.01.2019, 18:38 (Dieser Beitrag wurde zuletzt bearbeitet: 10.01.2019 19:04 von grobby.)
Beitrag #12
RE: RTC MCP 7940 geht nach
Danke für eure Antworten, aber ein ESP8266 ala Wemos D1 hat ja widerum nix mit DIP zu tun und Zeitsignal per Wlan holen muss auch nicht sein zumal ich schon was zum Stellen der Zeit eingepflanzt hab. Was mir event. noch vorschwebt, einen Anschluss für DCF oder GPS auf die Platine zu setzen.

Nochmal zu eigentlichen Thema, ich habe den Sketch so gestaltet das sich die Ansteuerung der Nixies im Code nach 10 Minuten deaktiviert und mittels PIR wieder aktiviert um eine Schonung der Röhren zu haben. Die Röhren werden zwar über Multiplex angesteuert, ob das nun schonend ist oder nicht scheiden sich die Geister. Jedenfalls 6 Röhren im 3 zu 2 Betrieb mit jeweils 4 Millisekunden Verzögerung. Das 3 mal macht 12 ms, der Rest vom Programm braucht 3ms, also eine Loop dauert ca 15ms. Was ich eigentlich sagen möchte, wenn über Nacht die Röhren deaktiv sind verliert die RTC nur 2-3 Sekunden, sind die Röhren aktiv sind es meist eine halbe bis Sekunde pro Minute. Ich versteh den Zusammenhang nicht warum dies so ist, weil 15ms für den Loop ist doch gut. Allerdings mache ich die Verzögerung von den 4ms mittels delayMicroseconds, da sollte doch aber noch genügend Zeit sein die RTC auszulesen oder? DigitalWrites hab ich durch Portmanipulation ersetzt weil dies ja angeblich viel schneller ist. Denn loop messe ich so
Code:
cycleCount++;
      if (cycleCount >= 1000)
      {
        cycle = ((micros() - cycleTime) / cycleCount);
        Serial.print("Cycle Time: ");
        Serial.print(cycle);
        Serial.println(" microseconds");
        cycleCount = 0;
        cycleTime = micros();
      }
Die Röhrenansteuerung so
Code:
void setOutputs(byte digit1, byte digit2) {

  byte val1 = digit1 << 2;         // Store number 1 in value 1, shift bits 2 places left (Move BCD value on last 4 bits to middle 4 bits)
  byte val2 = digit2 << 6;         // Put least 2 bits of Number 2 into upper 2 bits of Value 1
  byte val3 = digit2 >> 2;         // put highest 2 bits of Number 2 into lowest 2 bits of Value 2

  PORTD &= B00000000;              // Turn pins 0-7 off
  PORTB &= B00100000;              // Turn pins 8-12 off

  PORTD |= val1;            // Set pins 2-5 to match BCD number held in middle 4 bits of Value 1

  PORTD |= val2;            // Set pins 6 & 7 to match highest 2 bits of value 1 which is lowest 2 bits of num2
  PORTB |= val3;            // Set pins 8 and 9 to lowest 2 bits of value 2 which is highest 2 bits of num2
}

void setBanks(byte bank) {

  byte val1 = (1 << (bank + 2));   // Choose which bit is needed to control the bank pins 10-13
  // The bank selection is middle 4 bits, so the number needs to be shifted over by 2 bits

  PORTB |= val1;                  // Turn the appropriate pin (10-12) for the bank
}

void DisplayFadeNumberString()
{

  if (active == true) {
    // Nixie setup..
    // NOTE: If any of the bulbs need to blend then it will
    // be in time with the seconds bulbs. because any change only happens
    // on a one second interval.



    if (slotmachine == false && crossfade == true && settime == false) {

      // 1 (0,3)
      setOutputs(currNumberArray[0], currNumberArray[3]); setBanks(0);
      delayMicroseconds(NumberArrayFadeOutValue[0]);
      setOutputs(NumberArray[0], NumberArray[3]); setBanks(0);
      delayMicroseconds(NumberArrayFadeInValue[0]);

      // 1 (1,4)
      setOutputs(currNumberArray[1], currNumberArray[4]); setBanks(1);
      delayMicroseconds(NumberArrayFadeOutValue[1]);
      setOutputs(NumberArray[1], NumberArray[4]); setBanks(1);
      delayMicroseconds(NumberArrayFadeInValue[1]);

      // 1 (2,5)
      setOutputs(currNumberArray[2], currNumberArray[5]); setBanks(2);
      delayMicroseconds(NumberArrayFadeOutValue[2]);
      setOutputs(NumberArray[2], NumberArray[5]); setBanks(2);
      delayMicroseconds(NumberArrayFadeInValue[2]);
      setOutputs(10, 10);

    } else {

      // Anode channel 1 - numerals 0,3
      setOutputs(currNumberArray[0], currNumberArray[3]); setBanks(0);
      delayMicroseconds (brightness);

      // Anode channel 2 - numerals 1,4
      setOutputs(currNumberArray[1], currNumberArray[4]); setBanks(1);
      delayMicroseconds (brightness);
      // Anode channel 3 - numerals 2,5

      setOutputs(currNumberArray[2], currNumberArray[5]); setBanks(2);
      delayMicroseconds (brightness);
      setOutputs(10, 10);
    }

    if (slotmachine == false && crossfade == true && settime == false) {

      // Loop thru and update all the arrays, and fades.
      for ( uint8_t i = 0 ; i < 6 ; i ++ )
      {
        if ( NumberArray[i] != currNumberArray[i] )
        {
          NumberArrayFadeInValue[i] += fadeStep;
          NumberArrayFadeOutValue[i] -= fadeStep;

          if ( NumberArrayFadeInValue[i] >= fadeMax)
          {
            NumberArrayFadeInValue[i] = 0.0f;
            NumberArrayFadeOutValue[i] = fadeMax;
            currNumberArray[i] = NumberArray[i];
          }
        }
      }
    }
    else
    {
      for ( int i = 0 ; i < 6 ; i ++ )
      {
        currNumberArray[i] = NumberArray[i];
      }
    }
  }
}

void fillNixies(uint8_t digit5, uint8_t digit4, uint8_t digit3, uint8_t digit2, uint8_t digit1, uint8_t digit0) {

  NumberArray[5] = digit5;
  NumberArray[4] = digit4;
  NumberArray[3] = digit3;
  NumberArray[2] = digit2;
  NumberArray[1] = digit1;
  NumberArray[0] = digit0;

  DisplayFadeNumberString();
}
Erkennt da jemand vielleicht nen Fehler?

Zitat:Im Datenblat des MCP 7940 auf Seite 14 FIGURE 5-3 gibt es Vorgaben des Herstellers wie man den Oszillator von der Leiterbahnführung und Geometrie aufbauen soll. Diese Vorgaben gäbe es nicht wenn sie Bedeutungslos wären. So wie es aussieht ist damit auch ein SMD Quarz vorgegeben.
Möglicherweise werden im DB auch Angaben zum Typ der zu verwendenden Lastkondensatoren gemacht. (vielleicht NPO ?)

mh, also wenn man im Netz nach ferigen MCP7940 Modulen sucht, sieht man nur normale 32Khz Quarze, also scheint ein SMD kein muss.

Zitat:Ein Steckbrettaufbau wird beim Oszillator vermutlich nicht die Vorgaben erfüllen.
Wo deine plötzlichen Zeitabweichungen her kommen kann man aus der Ferne kaum beurteilen. Auch das Steckbrett hat Kapazitäten und u.U. schwankende Übergangswiderstände.

Da hast du natürlich vollkommen Recht, aber den Quarz hab ich direkt unter die PINs des RTC geklemmt und die LastKondis auf kürzestem Weg nach Masse verbunden.

Hab nun nochmal den Library Sketch zum MCP7940 der nur die Zeit ausliest und mittels Seriellen Monitor ausgibt, das läuft nun schon 20 Minuten und auf die Sekunde genau. Scheint also irgendwo ein bug in meinem Sketch?! Aber warum läuft der manchmal genau und weicht dann ab?? versteh ich nicht so recht.

Grobby
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
10.01.2019, 21:28
Beitrag #13
RE: RTC MCP 7940 geht nach
Auf der einen Seite machst Du Portmanipulationen, weil das schneller ist und Du ein paar wenige µs sparst, auf der anderen Seite nutzt Du delayMicroseconds(???) mit einem mir unbekannten Wert und vergeudest diese wieder.
Meinst Du nicht, dass das ein Widerspruch in sich ist?

Für was ist das Fading gut?
Mein Vorschlag wäre:
Nimm den Sketch mit Serial.print, der stabil läuft.
Baue nur das Notwendigste rein, um die Nixies anzusteuern.
Lass die Seriellen Ausgaben drin und schaue, was passiert. Evtl. läuft auch nur die Nixie-Anzeige aus dem Ruder.

Den Sketch auf Papier nachzuvollziehen wird sich keiner antun und die Hardware hast nur Du.
So einen minimalen Sketch kann man sich auch mal anschauen aber mit dem ganzen Fading kannst Du das keinem zumuten.

Gruß Tommy

"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
11.01.2019, 15:35
Beitrag #14
RE: RTC MCP 7940 geht nach
Hi,

Zitat:Auf der einen Seite machst Du Portmanipulationen, weil das schneller ist und Du ein paar wenige µs sparst...

Ich schrieb weil angeblich Portmani schneller ist. In einem anderen Forum hab ich gelesen das es ca 100x schneller sei als das ganze mit DigitalWrite zumachen. Anfangs hatte ich das auch alles mit DigitalWrite umgesetzt und gemerkt das die Uhr lahmte. Dann hatte ich umgestellt und erst wenig später mal die loopzeit gemessen, komisch nur das beides nahezu identisch schnell ist, wie du schon schriebst handelt es sich um µS.

Zitat:auf der anderen Seite nutzt Du delayMicroseconds(???) mit einem mir unbekannten Wert
[/code]

Auch schrieb ich was von 4ms Verzögerung durch delayMicroseconds, was aber doch eher nicht ins Gewicht fällt bei einer loop von max 15ms, oder ist mein Messcode falsch und es ist doch höher?

Das Fading ist dazu gedacht das eine Ziffer eingefadet wird, während die andere ausfadet. Ob nun Fading an oder der Code nach "else" aktiv ist spielt keine Rolle, es stimmt die Zeit nicht.

Wie gesagt korrigiert mich wenn ich falsch liege.

Grobby
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
11.01.2019, 15:50
Beitrag #15
RE: RTC MCP 7940 geht nach
Ich habe Dir ja aufgezeigt, auf welchem Weg Du Dich der Lösung nähern kannst.

Gruß Tommy

"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
13.01.2019, 15:01
Beitrag #16
RE: RTC MCP 7940 geht nach
Hallo,

also nach Ausklammern von Codeteilen führte auch dies nicht zum Erfolg.
Was ich vergessen hatte zu erwähnen, den Sketch hatte ich auf einem Arduino Pro Mini mit 8 MHz erstellt, mit DigitalWrite ging die Uhr nach, deshalb hatte ich auf Portmani umgestellt weil die Uhr somit genau lief.
Wie schon erwähnt will ich eine Platine mit DIP Packages, also besorgte ich einen 328 Atmel in DIP und hauchte ihm einen Boodloader ein und stellte ihm einen 16 Mhz Quartz zur Seite. Dann wechselte ich im Steckbrett vom Arduino zum Atmel (Beschaltung wie bem Nano) und flashte den Sketch. Die Uhr lief somit aber bei einer Zeitmessung musste ich dann eben feststellen das die RTC nicht stimmt (Threadtitel).
Ich bin nun wieder zurück zum Arduino gewechselt und siehe da die RTC läuft auch nach Stunden genau und das auch mit 22pF Lastkondis am RTC Quartz und Trimmung gleich 0.
Hab ich vielleicht was vergessen beim Bootloader flashen des Atmel? Als Vorbild hatte ich einfach den NANO gewählt.

Grobby
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Möglicherweise verwandte Themen...
Thema: Verfasser Antworten: Ansichten: Letzter Beitrag
Tongue GSM Modul - Nur erste SMS geht raus Haukini 1 176 04.03.2019 23:27
Letzter Beitrag: hotsystems
  Nichts geht mehr... AnFi 4 294 25.02.2019 14:23
Letzter Beitrag: Tommy56
  Messwert auf OLED 0,96" SSD1306 darstellen geht nicht alpenpower 8 1.607 17.09.2018 10:56
Letzter Beitrag: alpenpower
  Das geht mir auf den Zeiger Sasch600xt 44 3.284 06.09.2018 15:33
Letzter Beitrag: Sasch600xt
  Leonardo macht keinen Auto-Reset (je nach Sketch) SebastianM 5 648 01.09.2018 07:49
Letzter Beitrag: amithlon
  LED an Pin13 geht nicht aus. uweq 7 871 24.08.2018 12:31
Letzter Beitrag: uweq
  include *.txt-File ? -- geht nicht :-( uweq 27 2.993 10.08.2018 20:33
Letzter Beitrag: uweq
  OneButton geht im loop() nicht uweq 4 959 09.08.2018 21:29
Letzter Beitrag: uweq
  328P geht nicht mehr [gelöst] Harry 37 6.188 04.03.2018 19:57
Letzter Beitrag: Harry
Question Arduino Due nach dem 2. Start Fehlermelddung beim flashen juergen001 2 895 03.03.2018 09:07
Letzter Beitrag: juergen001

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste