STM32F103 ohne Quartz und Mbed

[Florian F. (flof3000)]

Hallo Forum,

ich benutze einen STM32F103C8T6 auf einem selbstgestalteten Board in 
Minimalstbeschaltung - nur Abblockkondensatoren, kein Quartz.

Als Umgebung kommt mBed zum Einsatz (unter platformio),
und das initialisiert irgendwo die Uhr.

Und zwar so, dass der Kontroller mit 36 Mhz läuft,
mBed aber glaubt dass er mit 72 Mhz liefe , und jetzt sind alle meine 
Waits doppelt so lang wie sie sein sollten, und mit meinem 
OneWire-Sensor DS18B20 wird das so natürlich nichts.

Nur: Ich bin zu doof rauszugoogeln wo ich
mBed von einer anderen Frequenz überzeugen kann.
Also, dass mBed dann mit einer anderen F_CPU = x rechnet.

(Die Clock selber anzupassen ist zwar auch noch geplant,
aber das steht ja in RM0008. Soll später mal am Akku laufen,
und braucht keinerlei Rechenleistung.)

Gruss
FloF

[Florian F. (flof3000)]

Korrektur: Er glaubt an 64 Mhz, und es sind 32.

'Einfach' SystemCoreClock in der main() umzusetzen hilft aber auch 
nicht.

[Johannes S. (Gast)]

Der Timer wird vor Eintritt in die main() initialisiert und die 
Takteinstellungen sind fix im init code. Du kannst versuchen das 
nachträglich wieder umzubiegen, vielleicht klappt das hier (ohne 
Gewähr):

in deine main.cpp:

#include <mbed.h>

#include "stm32f1xx.h" 
#include "hal_tick.h"

/******************************************************************************/
/*            PLL (clocked by HSI) used as System clock source                */
/******************************************************************************/
uint8_t SetSysClock_PLL_HSI(void)
{
  RCC_ClkInitTypeDef RCC_ClkInitStruct;
  RCC_OscInitTypeDef RCC_OscInitStruct;

  /* Enable HSI oscillator and activate PLL with HSI as source */
  RCC_OscInitStruct.OscillatorType      = RCC_OSCILLATORTYPE_HSI | RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSIState            = RCC_HSI_ON;
  RCC_OscInitStruct.HSEState            = RCC_HSE_OFF;
  RCC_OscInitStruct.HSICalibrationValue = RCC_HSICALIBRATION_DEFAULT;
  RCC_OscInitStruct.PLL.PLLState        = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource       = RCC_PLLSOURCE_HSI_DIV2;
  RCC_OscInitStruct.PLL.PLLMUL          = RCC_PLL_MUL16; // 64 MHz (8 MHz/2 * 16)
  if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
  {
    return 0; // FAIL
  }
 
  /* Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2 clocks dividers */
  RCC_ClkInitStruct.ClockType      = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2);
  RCC_ClkInitStruct.SYSCLKSource   = RCC_SYSCLKSOURCE_PLLCLK; // 64 MHz
  RCC_ClkInitStruct.AHBCLKDivider  = RCC_SYSCLK_DIV1;         // 64 MHz
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV2;           // 32 MHz
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;           // 64 MHz
  if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_2) != HAL_OK)
  {
    return 0; // FAIL
  }

int main() 
{
    SetSysClock_PLL_HSI();
    HAL_InitTick(0);

    // und ab hier dein Code
}

Das ist natürlich ein übler Hack. Besser ist es die Lib selber zu 
kompilieren und die Änderungen in system_stm32f1xx.c ordentlich 
einzupflegen.

[Florian F. (flof3000)]

Danke!

Stellt sich raus, es ist nicht die die Clock.
Irgendwie wartet wait_us immer mindestens 1 Millisekunde.
Und da meine Pause bei 480us war, sah das aus wie verdopplelt.
Noch dazu dass in der Library auch noch ein wait(2) drin war,
so dass das auch verdopplelt war.

Und fuer ungenaues wait_us findet man dann auch was im Mbed Forum:
https://developer.mbed.org/questions/69346/Wait-function-shows-incorrect-timing-on-/

Danke nochmal,
Gruss
FloF

[Johannes S. (Gast)]

In der Timer Implementierung für den F103 hatte ich auch schon 
vergeblich Fehler gesucht. Ich habe das IRMP für mbed portiert und auf 
dem F103 lief das nicht wegen des Timerfehlers. In der aktuellen mbed 
Version wurde der Timer überarbeitet und sah besser aus, ist aber 
vielleicht noch nicht perfekt.
Das Ur-mbed war ja für die LPC und die haben 32 Bit Timer, da ist die 
Implementierung einfach. Beim STM32F1 wird ein 16 Bit Timer auf 32 Bit 
erweitert und das hat seine Tücken.
Von der Version 129 sind die aktuellen Quellen auch wieder Online (wenn 
du nicht mbed-os verwendest):
https://developer.mbed.org/users/mbed_official/code/mbed-dev/
Auch wenn da vieles gut funktioniert ist es immer gut zu sehen wie die 
Dinge realisiert sind.

[Florian F. (flof3000)]

Well, ich hab's auch nicht hinbekommen.
Die Vorschlaege im Forum machen es besser, aber nicht gut.

Habe jetzt 'ne Funktion auf Basis von Data Watchpoint und Trace 
Registern:

https://kbiva.wordpress.com/2013/03/25/microsecond-delay-function-for-stm32/

Mit dem Salea 'getunt' - muss 3 us von der gewünschten Dauer abziehen,
und dann spricht mein DS18B20 mit mir.

Und ich muss mir keine an Platformio vorbei modifizierte Mbed Variante 
hinlegen.

[Johannes S. (Gast)]

Wird für den DS one wire nicht auch der Ein/Ausgang eines Pins 
umprogrammiert? Da hatte ich gelesen das das auch sehr langsam läuft 
weil es durch den HAL geht und immer ein Init dazwischen ist.

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Wie schon in anderen Threads geschreiben: One-Wire geht auch mit Uart 
oder 2-Kanaltimer und braucht dann kein delay() sondern erzeugt die 
One-Wire Primitive hardwaremaessig. Da One-Wire recht tolerant im Timing 
ist, sollte es auch mit dem internen RC Oszillator gehen.