STM32F103 Blue Pill Board: Verwendung der RTC mit 32khz

[Christian J. (Gast)]

Hallo,

bei diesen kleinen Boards ist etwas strubbelig mit der RTC in den 
Beispielen der StdPeriphLibs.

Der unten stehende Code ist von mir ergänzt worden um die Möglichkeit 
den EXTERNEN Quarz zu verwenden statt den internen RC Oszillator. Nur 
klappt es eben nicht. Vor allem verstehe ich nicht wieso die den 
Prescaler auf 40000 setzen.

Lasse ich die Befehle weg, die den internen RC betreffen startet der 32 
Bit Counter nicht und er hängt ewig in der WaitForSycro Schleife fest.

Hat da jemand funktionierenden Code?

Gruss,
Christian

void Init_RTC()
{
      /* Enable PWR and BKP clocks */
      RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);

      /* Allow access to BKP Domain */
      PWR_BackupAccessCmd(ENABLE);

      /* Enable the LSI OSC */
      RCC_LSICmd(ENABLE);
      RCC_LSEConfig(RCC_LSE_ON);

      /* Wait till LSI is ready */
//      while (RCC_GetFlagStatus(RCC_FLAG_LSIRDY) == RESET) {}
      while (RCC_GetFlagStatus(RCC_FLAG_LSERDY) == RESET) {} // TEST!!!

      /* Select the RTC Clock Source EXTERNAL 32Khz */
//      RCC_RTCCLKConfig(RCC_RTCCLKSource_LSI);
      RCC_RTCCLKConfig(RCC_RTCCLKSource_LSE); // TEST!!!

      /* Enable RTC Clock */
      RCC_RTCCLKCmd(ENABLE);

      /* Wait for RTC registers synchronization */
      RTC_WaitForSynchro();

      /* Wait until last write operation on RTC registers has finished */
      RTC_WaitForLastTask();

      /* Enable the RTC Second */
      RTC_ITConfig(RTC_IT_SEC, ENABLE);

      /* Wait until last write operation on RTC registers has finished */
      RTC_WaitForLastTask();

      /* Set RTC prescaler: set RTC period to 1sec */
      RTC_SetPrescaler(40000);

      /* Wait until last write operation on RTC registers has finished */
      RTC_WaitForLastTask();

      NVIC_InitTypeDef NVIC_InitStructure;

      /* Enable the RTC Interrupt - 1 x 1s */
      NVIC_InitStructure.NVIC_IRQChannel = RTC_IRQn;
      NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 15;
      NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
      NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
      NVIC_Init(&NVIC_InitStructure);

}

[Erdowahn (Gast)]

Christian J. schrieb:
> Vor allem verstehe ich nicht wieso die den
> Prescaler auf 40000 setzen.

Verstehe ich auch nicht, denn in einem funktionierenden Code steht da 
bei mir:

  /* Set RTC prescaler: set RTC period to 1sec */
  RTC_SetPrescaler(32767); /* RTC period = RTCCLK/RTC_PR = (32.768 KHz)/(32767+1) */

[Christian J. (Gast)]

Und wie sieht der ganze funktionierende Code aus?

Mit 32768 läuft sie zu schnell und wird wahrscheinlich auch von der RC 
angetrieben, denn von der LSE kriege ich sie nicht zum rennen :-(

[Christian J. (Gast)]

Grundsätzlioch bin ich nach diesern schönen Anleitung vorgegangen.

http://embedded-lab.com/blog/stm32s-internal-rtc/

Nur leider rennt der Weckker einfach nicht los, sobald ich auf LSE 
schalte.
Das Board in der Doku ist genau das gleiche wie ich es habe. Sein Code 
ist sehr umständlich, das Gleiche geht viel einfacher mit 4 Zeilen, wenn 
man mit der Funktion struct tm *localtime(const time_t *timer) aus der 
time.h Lib arbeitet, die aus der Epoch Time direkt einen struct füllt, 
der das römische Datum hat.

struct tm {
   int tm_sec;         /* seconds,  range 0 to 59          */
   int tm_min;         /* minutes, range 0 to 59           */
   int tm_hour;        /* hours, range 0 to 23             */
   int tm_mday;        /* day of the month, range 1 to 31  */
   int tm_mon;         /* month, range 0 to 11             */
   int tm_year;        /* The number of years since 1900   */
   int tm_wday;        /* day of the week, range 0 to 6    */
   int tm_yday;        /* day in the year, range 0 to 365  */
   int tm_isdst;       /* daylight saving time             */  
};

[Erdowahn (Gast)]

Christian J. schrieb:
> Und wie sieht der ganze funktionierende Code aus?

Tja, Du mußtest leider ein bisserl warten, war auf Arbeit.

void NVIC_Configuration(void) {
  NVIC_InitTypeDef NVIC_InitStructure;
#ifdef  VECT_TAB_RAM  
  /* Set the Vector Table base location at 0x20000000 */ 
  NVIC_SetVectorTable(NVIC_VectTab_RAM, 0x0); 
#else  /* VECT_TAB_FLASH  */
  /* Set the Vector Table base location at 0x08000000 */ 
  NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0);   
#endif

  /* Configure one bit for preemption priority */
  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_1);

//...

  /* Enable the RTC Interrupt */
  NVIC_InitStructure.NVIC_IRQChannel = RTC_IRQn;
  NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 1;
  NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
  NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
  NVIC_Init(&NVIC_InitStructure);
}

void init_RTC(void) {
  volatile uint16_t i;

  /* Enable PWR and BKP clocks */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);

  /* LSI clock stabilization time */
  for(i=0;i<5000;i++) { ; }

  if (BKP_ReadBackupRegister(BKP_DR1) != 0xA5A5) {
    /* Backup data register value is not correct or not yet programmed (when
  the first time the program is executed) */

    /* Allow access to BKP Domain */
    PWR_BackupAccessCmd(ENABLE);
  
    /* Reset Backup Domain */
    BKP_DeInit();
  
    /* Enable LSE */
    RCC_LSEConfig(RCC_LSE_ON);

    /* Wait till LSE is ready */
    while (RCC_GetFlagStatus(RCC_FLAG_LSERDY) == RESET) { ; }
  
    /* Select LSE as RTC Clock Source */
    RCC_RTCCLKConfig(RCC_RTCCLKSource_LSE);
  
    /* Enable RTC Clock */
    RCC_RTCCLKCmd(ENABLE);
  
    /* Wait for RTC registers synchronization */
    RTC_WaitForSynchro();
  
    /* Wait until last write operation on RTC registers has finished */
    RTC_WaitForLastTask();

    /* Set RTC prescaler: set RTC period to 1sec */
    RTC_SetPrescaler(32767); /* RTC period = RTCCLK/RTC_PR = (32.768 KHz)/(32767+1) */
  
    /* Wait until last write operation on RTC registers has finished */
    RTC_WaitForLastTask();

    /* Adjust time */
    Time_Adjust();
  
    /* Allow access to BKP Domain (Time_Adjust disables the access) */
    PWR_BackupAccessCmd(ENABLE);
  
    BKP_WriteBackupRegister(BKP_DR1, 0xA5A5);

    /* Lock access to BKP Domain */
    PWR_BackupAccessCmd(DISABLE);

  } else {

    /* Wait for RTC registers synchronization */
    RTC_WaitForSynchro();

  }

  /* Enable the RTC Second */
  RTC_ITConfig(RTC_IT_SEC, ENABLE);
  /* Wait until last write operation on RTC registers has finished */
  RTC_WaitForLastTask();

#ifdef RTCClockOutput_Enable
  /* Enable PWR and BKP clocks */
  RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR | RCC_APB1Periph_BKP, ENABLE);

  /* Allow access to BKP Domain */
  PWR_BackupAccessCmd(ENABLE);

  /* Disable the Tamper Pin */
  BKP_TamperPinCmd(DISABLE); /* To output RTCCLK/64 on Tamper pin, the tamper
                                 functionality must be disabled */

  /* Enable RTC Clock Output on Tamper Pin */
  BKP_RTCOutputConfig(BKP_RTCOutputSource_CalibClock);
#endif

  /* Clear reset flags */
  RCC_ClearFlag();
}

Ich hoffe, ich habe nichts vergessen.

[Christian J. (Gast)]

Hi,

das sieht ja fast aus wie meines, sogar die Kommentare sind identisch. 
Nur halt, dass da noch eine Zahl im BKUP RAM abgespeichert wird, um 
Doppel Inits zu vermeiden. Und das läuft auch?

 /* Wait for RTC registers synchronization */
    RTC_WaitForSynchro();

Hier ist bei mir nämlich Schluss, da hängt er sich endlos auf. Dass 
diese blauen Boards nicht ok sind glaube ich eigentlich nicht. Der 
kleine schwarze Kasten ist ein 32khz Oszillator oder Quartz. Das hätte 
natürlich Auswirkungen, wennn das ein Oszillator ist, da man dann die 
Verstärker Mimik nicht aktivieren darf, sondern das als external Clock 
betrachten muss. Die 40.000 kommen daher, dass die RC intern mit 40khz 
angegeben wird, bzw. zwischen 30 - 60 khz.

Nicht vergessen darf man, dass die RTC Mimik erst durch den RC Clock 
getrieben wird, völlig unabhängig von dem Rest ist. Vielleicht muss man 
ja doch erst RC aktivieren und danach umschalten auf LSE? Bei den alten 
LPC21xxx ARM TDMI war das so.

Im Netz gibts dazu so gut wie nichts, die RTC scheint wenig beliebt zu 
sein.

PS: Sehe grad, dass ich keinen reset der BKP Domain habe und das 
Reference Manual das ausdrücklich fordert.

The RTCCLK clock source can be either the HSE/128, LSE or LSI clocks. 
This is selected by programming the RTCSEL[1:0] bits in the Backup 
domain control register (RCC_BDCR). This selection cannot be modified 
without resetting the Backup domain.

Insgesamt finde ich diese RTC einen echten Krampf, Gatter sparen um 
jeden Preis :-(

Gruss,
Christian

[Erdowahn (Gast)]

Den Code habe ich seinerzeit von Martin Thomas stm32_chan_fat-Projekt 
geklaut.
Die entsprechenden Dateien habe ich mal angehängt.

Gruß und viel Erfolg.

[Christian J. (Gast)]

Was soll ich sagen ? DAS SCHEISS DING GÄÄÄÄÄHT :-)

das war es: BKP_DeInit(); Ohne das geht es nicht. Und jetzt nicht mehr 
anfassen, alles so stehen lassen und freuen :-)

[Oje (Gast)]

Auch wenn gleich einer den Knüppel rausholt: Bluepill RTC mit CubeMX 
generierten Code (HAL) geht auf Anhieb.

[Christian J. (Gast)]

Komm ich nicht mit klar. Selbst bei der Clock Config ist alles 
ausgegraut und ich weiss nicht wie ich das umstellen soll. Diese ganze 
Klickerei hat mit Programmieren eher nichts mehr zu tun.

Sagt mir wenig... ich nutze keine HAL. Das Bewährte funktioniert ja..

/* RTC init function */
void MX_RTC_Init(void)
{
  RTC_TimeTypeDef sTime;
  RTC_DateTypeDef DateToUpdate;

    /**Initialize RTC and set the Time and Date 
    */
  hrtc.Instance = RTC;
  hrtc.Init.AsynchPrediv = RTC_AUTO_1_SECOND;
  hrtc.Init.OutPut = RTC_OUTPUTSOURCE_NONE;
  HAL_RTC_Init(&hrtc);

  sTime.Hours = 0x1;
  sTime.Minutes = 0x0;
  sTime.Seconds = 0x0;

  HAL_RTC_SetTime(&hrtc, &sTime, FORMAT_BCD);

  DateToUpdate.WeekDay = RTC_WEEKDAY_MONDAY;
  DateToUpdate.Month = RTC_MONTH_JANUARY;
  DateToUpdate.Date = 0x1;
  DateToUpdate.Year = 0x0;

  HAL_RTC_SetDate(&hrtc, &DateToUpdate, FORMAT_BCD);

}

[pegel (Gast)]

Ich habe mit meinen Board und HAL auch so einige Probleme.

Die LSE Startzeit habe ich schon von 5000 auf 10000 ms hoch gesetzt.
Reicht aber nicht wenn das Board längere Zeit ohne Strom war.
Bleibt dann auch im LSE Ready oder im oben genannten RTC_WaitForSynchro 
hängen.

Dann muss ich nach ein paar Minuten Betrieb noch einmal Reset drücken 
und alles läuft. Getestet gegen Funkuhr ergab sich auch nach 4 Stunden 
dann keine Abweichung. Falsche C werden es dann nicht sein, oder?

Wenn ich nur max ein paar Minuten den Strom kappe, läuft alles wieder 
sauber an. Ein einfaches Reset setzt die Uhrzeit minus der Reset Zeit 
fort.

Das Board muss wohl genug kosmische Strahlung sammeln um starten zu 
können ;)

Bei einem anderen China Board mit LCD und Uhrenquarz ist alles i.O.

[Christian J. (Gast)]

Meins tut es noch, habe auch nix mehr dran angefasst und die Gnauigkeit 
ist echt super, seit 2 Wochen keine s Abweichung. Ganz ohne Trimmen.

Toi, toi....

[pegel (Gast)]

Na dann lass mal nicht den Strom ausfallen :)

Trotz dem ist die F103 RTC im Gegensatz zu anderen STM32 nur eine 
abgespeckte Version. Nicht mal automatische Schaltjahre bzw. 
Monatskorrektur.

[Christian J. (Gast)]

Wofür? Ich schreib da die Unix Epoch Time rein und alles anderen 
erledigt localtime() für mich. Wirklich alles :-) In time.h ist ja alles 
drin:
zb:

struct tm
{
  int  tm_sec;
  int  tm_min;
  int  tm_hour;
  int  tm_mday;
  int  tm_mon;
  int  tm_year;
  int  tm_wday;
  int  tm_yday;
  int  tm_isdst;
#ifdef __TM_GMTOFF
  long  __TM_GMTOFF;
#endif
#ifdef __TM_ZONE
  const char *__TM_ZONE;
#endif
};

oid RTC_IRQHandler(void)
{
   #define MEZ +1

   struct tm *ptr;      // Zeiger auf Zeit Strktur
   time_t value;        // 32 Bit Unixzeit

  if (RTC_GetITStatus(RTC_IT_SEC) != RESET)
  {
        /* Unixzeit aus RTC lesen */
        RTC_WaitForSynchro();
        value = (time_t)RTC_GetCounter();

        /* UTC +1h dazu addieren */
        value = value + (MEZ * 3600);

        /* In Normalzeit UTC hh:mm:ss umwandeln */
        ptr = localtime(&value);

        /* Prüfe auf Sommerzeit */
        if (IsSummertime(ptr))
        {
            /* Zeit nochmal umrechnen SZ = +1H */
            value = value + 3600;
            /* In Normalzeit UTC hh:mm:ss umwandeln */
            ptr = localtime(&value);
            ptr->tm_isdst = true;
        }

        /* In eigene Struktur kopieren */
        memcpy((void*)&mytime,ptr,sizeof(struct tm));  // mytime <- localtime Buffer

        /* Jahr richtig schreiben */
        mytime.tm_year += 1900;

        /* Berechne Sonnenzeiten  */
        CalcSonnenAufgang((struct tm*)&mytime, (SunTimes_t*)&SunTimes);

        // Sonne untergegangen ?
        f_SunDown = (( ConvZeit2Float((struct tm*)&mytime) > SunTimes.Down.fpoint) ||
                     (ConvZeit2Float((struct tm*)&mytime) > SunTimes.Rise.fpoint));

        /* Zeitflags setzen, Minute, Stunde */
        f_sekunde = true;
        if (mytime.tm_sec == 0)
            f_minute = true;
        if (mytime.tm_min == 0)
            f_stunde = true;

        /* Clear Interrupt pending bit */
        RTC_ClearITPendingBit(RTC_FLAG_SEC);
  }
}

[pegel (Gast)]

Wau. Der IRQHandler hat gut zu tun.
Aber es ist wie immer: viele Wege führen nach ...

[Christian J. (Gast)]

Der IRQ wird alle 1s aufgerufen .... hier führt nur ein Weg nach Rom: 
Wenn ich nur einen 32 Bit Zaehler habe muss alles andere per Software 
laufen und dafür gibt es fertige Libs. Der RTC Int ist bei mir 
niedrigste Prio, alles andere bügelt drüber.

[Jan A. (fathi69)]

Ich weiss, dass das Thema hier schon etwas älter ist, aber vielleicht 
hilft es noch jemanden etwas. Auch ich hatte grosse Probleme mit der RTC 
auf einem STm32F103 Blue Pill Board. Folgendes Verhalten war zu 
beobachten:

- 12V Netzteil, nichts weiter angeschlossen -> RTC läuft nicht an
- selbes Netzteil mit Uart-Adapter am Rechner, oder STLink am Board, 
oder USB -> alles Ok
- selbes Netzteil mit LC-Filter (verschiedene Werte, egal ob vor oder 
nach Schaltwandler auf Platine) -> RTC läuft nach ca. 4 Sekunden 
ungefähr halb so schnell an.
- selbes Netzteil, nichts angeschlossen, professionell Finger an Plus 
oder Minus (egal ob 12v oder 3,3v) -> alles Ok (was macht so ein 
Finger?)
- selbes Netzteil, Finger in die Mitte vom Schaltregler -> Prozessor 
platzt auf (riecht genau wie ein atmel)
- Labornetzteil (analog), nichts weiter angeschlossen -> alles Ok

und noch ein paar andere Tests (verschiedene Netzteile usw).
Die Lösung, zumindest für das RTC-Problem bei mir, stand dann hier:

http://stefanfrings.de/stm32/index.html

Die Pins (bei mir) PC14 und PC15 entfernen (gehen zm Quarzoszillator) 
und alles funktioniert.
Ich habe kein Oszi und könnte wahrscheinlich damit auch nicht richtig 
umgehen. Kontrolliert habe ich es, indem ich die LED an PC13 per 
Interrupt (1sek) habe blinken lassen. Über die jetzt erzeugte 
Genauigkeit kann ich noch nichts sagen, denn jetzt ist erstmal der i2c 
dran, der ist ja auch ganz komisch, aber das ist ein anderes Thema.


Gruß
Jan

[Stefan F. (Gast)]

> Die Lösung, zumindest für das RTC-Problem bei mir, stand dann hier

Eigentlich wurde die Lösung hier im Forum vor wenigen Tagen diskutiert 
und daraufhin habe ich meine Homepage aktualisiert.

[Jan A. (fathi69)]

Die habe ich dann leider nicht gefunden, aber trotzdem vielen Dank für 
die Informationen!

Gruß
Jan

[Stefan F. (Gast)]

Wie genau läuft die Uhr bei deinem Bluepill Board eigentlich? Würdest du 
sie empfehlen, oder ist sie inakzeptabel schlecht?

[Jan A. (fathi69)]

Das kann ich (noch) nicht sagen, ich setze die Uhr mit dem ESP über ntp. 
Ist mein erster Versuch mit einem STM32. Ich werde mal messen, wird aber 
einen Augenblick dauern. Erwarten tue ich allerdings nach dem Anfang 
nicht so viel.

Gruß
Jan

[Boah Eyy (Gast)]

Stefan U. schrieb:
> Wie genau läuft die Uhr bei deinem Bluepill Board eigentlich? Würdest du
> sie *empfehlen*

Sorry aber das ist eine "dumme" Frage, denn die Genauigkeit der
Uhr (auch allgemein) hängt nicht von der Uhr-Hardware ab (das
ist, primitiv betrachtet, nur ein Zählbaustein) sondern vom Quarz
und davon wie genau der Quarz durch die Umgebungs-Beschaltung
getrimmt ist. Und darin unterscheidet sich die Schaltung in keiner
Weise von den meisten anderen üblichen Uhr-Schaltungen.

Daher hättest du deine Frage auf jeden Uhren-Baustein mit externem
Quarz oder eingebauten Uhren auf jedem anderen Mikrocontroller
Board mit externem Quarz beziehen können.

Was soll also an einer Uhren-Hardware mehr oder weniger
"empfehlenswert" sein?

[Jan A. (fathi69)]

Ich glaube aber genau das gesamte Umfeld der Uhr war gemeint.

Gruß
jan

[Boah Eyy (Gast)]

Jan A. schrieb:
> Ich glaube aber genau das gesamte Umfeld der Uhr war gemeint.

Boah Eyy schrieb:
> Und darin unterscheidet sich die Schaltung in keiner
> Weise von den meisten anderen üblichen Uhr-Schaltungen.

[Jan A. (fathi69)]

In diesem konkreten Fall aber doch, denn wenn ich die Pins von der 
Bluepill am Uhrenquarz dran lasse (unbeschaltet), passieren die oben 
beschriebenen Effekte. Ohne läuft sie zwar scheinbar, aber wie genau 
haben ich eben auch noch nicht geprüft.

Gruß
Jan

[Boah Eyy (Gast)]

Jan A. schrieb:
> denn wenn ich die Pins von der
> Bluepill am Uhrenquarz dran lasse (unbeschaltet), passieren die oben
> beschriebenen Effekte.

Das weiss unser Stefan Us aber schon längst und begründet
nicht die "dumme" Frage.

[Stefan F. (Gast)]

Mir ist schon klar, daß die Genauigkeit vom Quarz und der Beschaltung 
abhängt. Die ist aber durch das konkrete BluePill Board bereits 
vorgegeben. Die Pins, die zum Quarz führen, sind entfernt, also kann das 
sonst nichts weiter dran hängen.

> Daher hättest du deine Frage auf jeden Uhren-Baustein ... beziehen können.

Nein, mich interessier jetzt gerad diese BluePill Board.

> In diesem konkreten Fall aber doch, denn wenn ich die Pins von der
> Bluepill am Uhrenquarz dran lasse

Ja aber die sind jetzt ab, und genau diese Variante interessiert mich.

Ich habe den Jan A gefragt, weil er genau die Konfiguration vorliegen 
hat, die mich interessiert. BluePill Board, Pins entfernt, auf 
Lochraster, mit externem Spannungsregler.

Wenn ich einen Kunden im Backschop frage, wie ihm der Apfelkuchen 
schmeckt, den er gerade verspeist, dann sagt der auch nicht "kommt drauf 
an, woher die Äpfel kommen, in welchem Laden du den Kuchen gekauft hast 
und was du vorher im Mund hattest."

Also: keine blöde Frage.

[Stefan F. (Gast)]

Also Jan, die Frage war ernst gemeint. Ich würde mich wirklich freuen, 
wenn du die Uhr mal ein Wochenende ohne NTP Anbindung laufen lässt und 
danach schaust, wie viel (oder wenig) sie falsch gelaufen ist.

[Boah Eyy (Gast)]

Stefan U. schrieb:
> Ja aber die sind jetzt ab, und genau diese Variante interessiert mich.

Warum testest du nicht eines deiner eigenen Boards (sind sie dir
zu teuer daraum herumzumachen, oder schaffst du das nicht? Zwei
linke Hände?)?

Warum fragst du jemand hier im Forum ob die Boards "empfehlenswert"
sind wo du doch vermutlich seine Fachkompetenz überhaupt nicht
kennst? Darf man dann annehmen dass du jede Empfehlung hier dann
als relevant für deine Entscheidung nimmst etwas nach diesen
Kriterien zu verwenden?

[Stefan F. (Gast)]

> Warum testest du nicht eines deiner eigenen Boards
> ... oder schaffst du das nicht?

Auf Faulheit.

Na klar schaffe ich das selber. Werde ich auch tun, es sei denn, jemand 
beantwortet meine Frage schneller.

> Warum fragst du jemand hier im Forum ob die Boards "empfehlenswert"
> sind wo du doch vermutlich seine Fachkompetenz überhaupt nicht
> kennst?

Weil ich mich für Jans Meinung interessiere. In diesem Fall ist mir die 
Fachkompetenz nicht wichtig.

Du bist heute echt ein Meckerfritze. Was hat man Dir angetan?
Wenn du die Frage blöd findest, dann halte dich doch einfach heraus. 
Niemand hat Dich aufgefordert, unsere Kommunikation störend zu 
unterbrechen.

[Boah Eyy (Gast)]

Stefan U. schrieb:
> Niemand hat Dich aufgefordert, unsere Kommunikation störend zu
> unterbrechen.

Deine dumme Frage provoziert einfach kolossal. Und du bestätigst
es auch noch durch deine Faulheit.

Wenn du nicht gestört werden willst dann kommuniziere mit deinem
Gesprächspartner per PN. Das ist möglich, scheinst du aber noch
nicht zu wissen.

Hier ist jedenfalls öffentlich.

Stefan U. schrieb:
> In diesem Fall ist mir die Fachkompetenz nicht wichtig.

Das zeichnet dich aus .... für die Zukunft.

[Jan A. (fathi69)]

Stefan U. schrieb:
> Also Jan, die Frage war ernst gemeint. Ich würde mich wirklich freuen,

Werde ich tun, aber geht erst ab Montag, also bitte etwas Geduld.

Boah Eyy schrieb:
> Stefan U. schrieb:
>> In diesem Fall ist mir die Fachkompetenz nicht wichtig.
>
> Das zeichnet dich aus .... für die Zukunft.

Na ja, ich mache das nur als Hobby und kann mich mit den meisten Leuten 
die hier schreiben nicht messen (sieht man ja auch auf meinem Bild 
oben), aber ich bin zuversichtlich, dass ich eine Uhr stellen und wieder 
ablesen kann (+-1 Sekunde) ;). Das Ergebnis ist dann auch nur auf den 
Einzelfall anwendbar, aber wenn mehrere Ergebnisse irgendwo beschrieben 
werden, ergibt das für die Suchenden immerhin eine Tendenz.

Gruß
Jan

[Boah Eyy (Gast)]

Jan A. schrieb:
> Das Ergebnis ist dann auch nur auf den Einzelfall anwendbar

Yes, sehr scharfsinnig erkannt.

Den (Un-)Nutzen für sich selbst scheint unser Stefan
aber selbst noch nicht zu erkennen.

Doch kaum messen hundert Leute an ihren Bluepills herum und
tun die Messergebnisse kund, schon weiss man viel mehr und
kann Rückschlüsse auf sein eigenes BluePill ziehen.

[Stefan F. (Gast)]

> Werde ich tun, aber geht erst ab Montag, also bitte etwas Geduld.

Vielen Dank. Lass Dir Zeit. Ich brauche mein einziges Board gerade für 
andere Experimente und warte sehnsüchtig auf das ZehnerPack aus China.

[Stefan F. (Gast)]

> Das Ergebnis ist dann auch nur auf den Einzelfall anwendbar

Das reicht mir erst mal. Noch baue ich nichts ernsthaftes mit den 
Dingern, ich bin da noch in der Evaluierungsphase.

[Stefan F. (Gast)]

Ich habe inzwischen einen kurzen Test bezüglich der Genauigkeit der RTC 
gemacht. Mein Nucleo64 Board läuft 4 Sekunden pro Tag zu schnell. Das 
hat mich ein bisschen enttäuscht. Aber immerhin kann man den Oszillator 
kalibrieren.

[Chris J. (Gast)]

Stefan U. schrieb:

> Ich habe inzwischen einen kurzen Test bezüglich der Genauigkeit der RTC
> gemacht. Mein Nucleo64 Board läuft 4 Sekunden pro Tag zu schnell. Das
> hat mich ein bisschen enttäuscht. Aber immerhin kann man den Oszillator
> kalibrieren.

Also bei meinen Blue Pills habe ich das auch gemacht und die laufen 
erstaunlich genau mit der LSE. Mit LSI sind die nur Schätzeisen, die 
taugt nur für grobe Takte. Man kann die RTC aber nur statisch 
kalibrieren über das BKP_RTCCR Register. Und bei Tempschwankungen zieht 
die trotzdem weg bzw müsste dyn. kalibriert werden. Die zieht mit K = 
–0.040 ppm/°C weg.

http://www.st.com/content/ccc/resource/technical/document/application_note/ff/c1/4f/86/4e/29/42/d1/CD00167326.pdf/files/CD00167326.pdf/jcr:content/translations/en.CD00167326.pdf

[Stefan F. (Gast)]

Ich wiederhole jetzt meinen Genauigkeits-Test mit einem Bluepill Board 
auf einem Steckbrett. Angeschlossen ist nur ein USB Kabel zum Laptop 
zwecks Stromversorgung, sowie ein USB-UART Kabel für Debug Meldungen.

Zunächst lief mein 32kHz Oszillator mit unregelmäßiger Geschwindigkeit, 
man konnte es mit bloßem Auge an der LED sehen, die im Sekundentakt 
blinken sollte. Jetzt habe ich den Stift von PC14 entfernt, der 
Oszillator läuft nun richtig.

In ein paar Tagen melde ich mich mit dem Testergebnis.

[Stefan F. (Gast)]

Die Uhr meines Bluepill Boardes hat nach 2 Stunden bereits 2 Sekunden 
Abweichung. Ich habe jetzt zusätzlich noch den Pin PC15 entfernt. Mal 
sehen, ob sie dann besser läuft.

[Chris J. (Gast)]

Stefan U. schrieb:
> Ich habe jetzt zusätzlich noch den Pin PC15 entfernt. Mal
> sehen, ob sie dann besser läuft.

Ich schrieb hier mal, dass ich damit die größte Glaubenskrise hatte als 
die Uhr halb so schnell lief wenn ich sie an Wände hielt. Erst als ich 
beide Pins komplett entfernt hatte, also auch das was auf der Platine 
war lief sie richtig. Allerdings kriege ich die Zeit immer vom Master 
und das ist ein F407, den ich in wochenlanger Kleinarbeit kalibriert 
habe... nach Gefühl, mal mehr mal weniger Takte addiert oder 
subtrahiert.

Grad geschaut: F407 hat aktuell 2s Abweichung nach ca 6 Wochen....

Die einfachste Kiste ist die, den Quarz mit einem 10pf Drehko zu ziehen, 
der in den Kreis eingebracht wird. Den Takt auf einen Pin bringen und 
dann solange drehen bis ein Freq-zähler genau die 32768 anzeigt. Dann 
spart man sich den ganzen Softwarekram.

[Holm T. (Gast)]

Pins ab hin oder her...überall im Netz ist zu lesen das es eine Blöde 
Idee ist die LED an PC13 zu nutzen, weil der Ausgang genau einer von 
denen ist, die nicht mit hohem Strömen belastet werden sollten..und 
direkt an der RTC Stromversorgung innerhalb des Chips hängt. Also klemmt 
bitte die LED wo anders an.

Gruß,

Holm

[Stefan F. (Gast)]

Da hat jemand das Datenblatt nicht richtig gelesen und nun wird dieser 
Unfug überall zittiert. Die drei Pins PC13, PC14 und PC15 dürfen 
zusammen 3mA sinken aber keinen Gleichstrom sourcen. Diese Bedingung 
wird bei dem Bluepill Board eingehalten.

Mein Test auf dem Bluepill Board läuft jetzt seit etwa 12 Stunden und 
zeigt eine Sekunde Abweichung. Damit ist es bereits genauer, als das 
Nucleo-64 Board von STM, bei dem diese LED nicht vorhanden ist.

Die Pins müssen ab, weil sie vor allem zusammen mit dem Steckbrett eine 
zusätzliche Kapazitive Belastung darstellen. Außerdem sind sie 
empfänglich für Radiowellen. Dieser RTC Oszillator arbeitet nur mit sehr 
wenig Energie, da machen diese Details viel aus.

[Chris J. (Gast)]

Holm T. schrieb:

> Pins ab hin oder her...überall im Netz ist zu lesen das es eine Blöde
> Idee ist die LED an PC13 zu nutzen, weil der Ausgang genau einer von
> denen ist, die nicht mit hohem Strömen belastet werden sollten..und
> direkt an der RTC Stromversorgung innerhalb des Chips hängt.

Die RTC  hängt bei mir an einer Backup Batterie und die LED ist eine 
blaue, die schon hell leuchtet mit 0,5 mA. Ich benutze die auch als 
Indikator und habe nie Probleme damit gehabt. Die Pins PC14 und PC15 
müssen aber unbestückt bleiben, defintiv. Es reicht deine Hand denen zu 
nähern und die Uhr läuft nur noch halb so schnell.

Den Code kennt hoffentlich auch jeder.....

/* JTAG Interface abschalten, SWD einschalten (PB3, PB4 freimachen) */
   RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOB | RCC_APB2Periph_AFIO, ENABLE);
   GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);

[Stefan F. (Gast)]

Mein Genauigkeits Test mit dem Bluepill Board ist beendet. Nach 23 
Stunden hatte die Uhr 1 Sekunde Abweichung. Ich bin zufrieden.

[Stefan F. (Gast)]

> Den Code kennt hoffentlich auch jeder.....
> JTAG Interface abschalten

Was hat das mit der RTC zu tun?

[Holm T. (Gast)]

Chris J. schrieb:
> Holm T. schrieb:
>
>> Pins ab hin oder her...überall im Netz ist zu lesen das es eine Blöde
>> Idee ist die LED an PC13 zu nutzen, weil der Ausgang genau einer von
>> denen ist, die nicht mit hohem Strömen belastet werden sollten..und
>> direkt an der RTC Stromversorgung innerhalb des Chips hängt.
>
> Die RTC  hängt bei mir an einer Backup Batterie und die LED ist eine
> blaue, die schon hell leuchtet mit 0,5 mA. Ich benutze die auch als
> Indikator und habe nie Probleme damit gehabt. Die Pins PC14 und PC15
> müssen aber unbestückt bleiben, defintiv. Es reicht deine Hand denen zu
> nähern und die Uhr läuft nur noch halb so schnell.
>
[..]

Hmm..."schließ keine LED an PC13 an" "..mach ich doch nicht denn meine 
LED ist blau"

Mach doch was Du willst...

Gruß,

Holm