Compilierung des EU1KY AA unter Linux.

[Markus W. (dl8mby)]

Hallo gcc Experten,

ich möchte die angehängten Sourcen im tgz Archive compilieren.

Ich habe das Makefile den Linux-Gegebenheiten angepasst und
im Prinzip funktioniert alles wie gewünscht.

Jedoch bekomme ich den u.g. Fehler im Zusammenhang mit einer
ISR, da der Type "IVT_INT_RTC" nicht bekannt ist.

Schmeiße ich die RTC routinen raus, kann ich ein Binary
für den STM32 erzeugen.

Kann sich jemand den Fehler mal ansehen und mir auf die Sprünge
helfen.

Das Projekt wird unter Windows mit EMBITZ compiliert und von da
habe ich auch die Sourcen.


Danke für Eure Mühe

Markus


Src/analyzer/rtc/emrtc.c: In function 'RTC_ISR':
Src/analyzer/rtc/emrtc.c:38:1: error: unknown type name 'iv'
 iv IVT_INT_RTC
 ^
Src/analyzer/rtc/emrtc.c:39:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'ics'
 ics ICS_AUTO
 ^
Src/analyzer/rtc/emrtc.c:53:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:79:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:111:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:136:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:194:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:282:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:342:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:372:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:383:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:394:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:458:1: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '{' token
 {
 ^
Src/analyzer/rtc/emrtc.c:475:1: error: expected '{' at end of input
 }

[Rufus Τ. F. (rufus)]

Markus W. schrieb:
> da der Type "IVT_INT_RTC" nicht bekannt ist.

Lies die Fehlermeldung mal genau. Unbekannt ist "iv".

[Markus W. (dl8mby)]

Noch ein kleiner Nachtrag.

Irgenwdie ist die u.g. Funktion für das Problem mit verantwortlich.
./Src/analyzer/rtc/emrtc.c
Mir ist auch ihre Deklaration/Definition nicht ganz klar

void RTC_ISR() iv IVT_INT_RTC ics ICS_AUTO {}

Kann mir jemend bitte die obere Zeile mal erläutern.


void RTC_ISR()
iv IVT_INT_RTC
ics ICS_AUTO
{
    if(get_RTC_second_flag_state() == true)
    {
        update_time = 1;
        clear_RTC_second_flag();
    }

    clear_RTC_overflow_flag();
    while(get_RTC_operation_state() == false);
}


Markus

[Markus W. (dl8mby)]

Hallo Rufus,

leider finde ich in den Sourcev werde unter *.h noch unter *.c was zu 
iv.
Möglicherweise ist es in einer ASM Datei definiert.
Ansonsten fehlt mir wohl noch etwas von den Sourcen.

>find . -name \*.h -exec grep -H " iv " {} \;

>find . -name \*.c -exec grep -H " iv " {} \;
./Src/analyzer/FreqCounter.c:void vRTCWakeupISR(void) iv 
IVT_INT_RTC_WKUP ics ICS_AUTO {

Markus

Für *.s oder *.S gibt es auch keine Treffer.

>find . -name \*.s -exec grep -H " iv " {} \;

>find . -name \*.S -exec grep -H " iv " {} \;

Irgend eine Idee?

Markus

[Markus W. (dl8mby)]

Hallo Habe in dem o.g. Zusammenhang das gefunden:


Interrupt Handling

For the sake of interrupt handling convenience, new keyword, iv, is 
introduced. It is used to declare IVT address for a defined interrupt 
routine :

void interrupt() iv IVT_ADDR_ET0 ics ICS_OFF {
  // Interrupt service routine code
}

where :

    iv - reserved word that informs the compiler that it is an interrupt 
service routine.
    IVT_ADDR_ET0 - appropriate Interrupt Vector.
    ics Interrupt Context Saving; Interrupt Context Saving can be 
performed in several ways :
        ICS_OFF - No context saving
        ICS_AUTO - Compiler chooses whether the context saving will be 
perfomed or not.

Now it is possible to explicitly declare interrupt routine address :

void Timer0_Interrupt() org 0x600 iv IVT_ADDR_ET0 {  // Interrupt 
routine will be placed on the address 0x600
   asm nop;
}

For the sake of backward compatibility, user may write also :

void Timer0_Interrupt() org IVT_ADDR_ET0 {
   asm nop;
}

which is equivalent to :

void Timer0_Interrupt() iv IVT_ADDR_ET0 {
   asm nop;
}

Is is recommended that interrupts are handled in this way for the sake 
of better readability of the user projects.





Somit scheint es sich um Compiler-Direktiven bzw. Compiler-Schwitches
zu handeln. Jetzt gilt es nur die gcc Entsprechungen zu finden.

Markus

[Jim M. (turboj)]

Markus W. schrieb:
> Somit scheint es sich um Compiler-Direktiven bzw. Compiler-Schwitches
> zu handeln. Jetzt gilt es nur die gcc Entsprechungen zu finden.

Und die gibt es nicht.

Denn bei den ARM Cortex-M sind die Interrupt Handler "normale" 
Funktionen ohne jede Sonderbehandlung im C Compiler. Die Hardware (im 
Zusammenspiel mit der C ABI) sorgt von allein dafür das die 
entsprechenden Register gesichert und wiederhergestellt werden.

In die Verktor Tabelle kommen die üblicherweise über den normalen 
Funktionsnamen.

Im Übrigen dürfte das nicht die einzige Hürde bei der Portierung von 
Code einer fremden Architektur sein. Man muss da eigentlich jede Zeile 
Code erstmal anschauen ob die so funktioniert. Mögliche Probleme sind da 
zum Bleistift sizeof(int) oder Alignment beim Cortex-M0 (armv6-m).

[Markus W. (dl8mby)]

Hallo Jim,

an sich läuft die SW bereits auf dem STM32F746x (Disco-Dev-Board).
Siehe auch Thread Beitrag "Antennenanalysator nach EU1KY".
Ich habe durch Deaktivierung der RTC den Code bereits vor zwei
Wochen erfolgreich kompiliert.
Jetzt wollte ich noch die RTC-Funktionen zum Laufen bringen und bin
jetzt etwas in die Tiefe der Sourcen vorgedrungen und auf das
genannte Problem gestoßen.

Es muss ja eine Entsprechung für die iv und ics Tags geben, da das
Makefile für Dos "Makefile.dos" siehe tgz-Archive, auch einen
normalen "arm-none-eabi-gcc"-Compiler unter EMBITZ verwendet und
der Compiliervorgang klappt da ja auch.

Markus

[Markus W. (dl8mby)]

Hallo Forum,

hat niemand eine Idee, wie ich das u.g. Konstrukt beim
arm-none-eabi-gcc (Version s.u.) umgehen könnte?

void RTC_ISR() iv IVT_INT_RTC ics ICS_AUTO {}

Oder wie man die iv und ics Compiler-Direktiven
beim o.g. Compiler aktivert oder vergleichbare
Pragmas verwendet?


>arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/arm-none-eabi/5/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --libdir=/usr/lib64 --libexecdir=/usr/lib64
--with-sysroot=/usr/arm-none-eabi 
--with-python-dir=share/arm-none-eabi/gcc/5
--with-pkgversion='openSUSE 5.x' 
--with-bugurl=https://bugs.opensuse.org/
--target=arm-none-eabi 
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
--enable-multilib --enable-multiarch --enable-interwork --enable-plugins
--disable-decimal-float --disable-libffi --disable-libgomp 
--disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-libstdcxx-dual-abi --disable-libstdcxx-verbose --disable-nls
--disable-shared --disable-threads --disable-tls --with-gnu-as 
--with-gnu-ld
--with-gmp --with-mpfr --with-mpc --with-isl --with-libelf
--enable-gnu-indirect-function --with-host-libstdcxx='-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-languages=c,c++ 
--enable-gold
--enable-target-optspace --enable-lto --without-headers --with-newlib
--with-system-zlib
Thread model: single
gcc version 5.x (release) [ARM/embedded-5-branch revision 237715]
(openSUSE 5.x)

Danke für sachdienliche Infos, die mir weiter helfen.

Markus

[Dr. Sommer (Gast)]

Markus W. schrieb:
> hat niemand eine Idee, wie ich das u.g. Konstrukt beim
> arm-none-eabi-gcc (Version s.u.) umgehen könnte

Wahrscheinlich kannst du es komplett weglassen. Du brauchst nur einen 
Interrupt Vector mit den entsprechenden Einträgen. Der findet sich in 
vielen Beispiel Projekten, suche einfach eines für deinen Controller.

[Markus W. (dl8mby)]

@Dr. Sommer

ich habe den u.g. Code.

Wenn ich die "iv IVT_INT_RTC" und "ics ICS_AUTO" Struktur auskommentiere
und weiter unten NVIC_IntEnable() mit der Adr. der Funktion RTC_ISR
befülle, so könnte es möglicherweise funktionieren.

Ich nehme an, dass NVIC_IntEnable() eine Adr. in eine IVT für den
zugehörigen Interrupt hinein schreibt, die dann aufgerufen wird.

Sehe ich das so richtig?

Markus


void RTC_ISR()
/*
iv IVT_INT_RTC  <==================== auskommentiert
ics ICS_AUTO
*/
{
    if(get_RTC_second_flag_state() == true)
    {
        update_time = 1;
        clear_RTC_second_flag();
    }

    clear_RTC_overflow_flag();
    while(get_RTC_operation_state() == false);
}


unsigned char RTC_init()
{
    unsigned char timeout = 0;

    if(BKP_DR1 != rtc_access_code)
    {
        enable_power_control_module(true);
        enable_backup_module(true);

        disable_backup_domain_write_protection(true);
        set_backup_domain_software_reset(true);
        set_backup_domain_software_reset(false);

        bypass_LSE_with_external_clock(false);
        enable_LSE(true);
        while((LSE_ready() == false) && (timeout < 250))
        {
            timeout++;
            delay_ms(10);
        };

        if(timeout > 250)
        {
            return 1;
        }

        select_RTC_clock_source(LSE_clock);
        enable_RTC_clock(true);

        while(get_RTC_operation_state() == false);
        while(get_RTC_register_sync_state() == false);
        enable_RTC_second_interrupt(true);
        while(get_RTC_operation_state() == false);

        set_RTC_configuration_flag(true);
        set_RTC_prescalar(32767);
        set_RTC_configuration_flag(false);
        while(get_RTC_operation_state() == false);
        BKP_DR1 = rtc_access_code;
        disable_backup_domain_write_protection(false);

        set_RTC(cal_year, cal_month, cal_date, cal_hour, cal_minute, 
cal_second);
    }

    else
    {
        while(get_RTC_register_sync_state() == false);
        enable_RTC_second_interrupt(true);
        while(get_RTC_operation_state() == false);
    }

    /* NVIC_IntEnable(IVT_INT_RTC); */
    NVIC_IntEnable(RTC_ISR);  <========================== Adr. der RCT 
Funktion

    return 0;
}

[neuer PIC Freund (Gast)]

MikroC PRO for ARM:

void NVIC_IntEnable(const unsinged long ivt);

Mit gcc gemixt?

[Dr. Sommer (Gast)]

Markus W. schrieb:
> Ich nehme an, dass NVIC_IntEnable() eine Adr. in eine IVT für den
> zugehörigen Interrupt hinein schreibt, die dann aufgerufen wird.

Unwahrscheinlich, denn der Interrupt Vector befindet sich im Flash. Der 
wird normalerweise im Startup-Code angelegt. NVIC_IntEnable wird den 
Interrupt einfach nur im NVIC aktivieren. Wo das jetzt aber herkommt 
weiß ich nicht; ich kenne nur "NVIC_EnableIRQ" aus der CMSIS, was eben 
genau das macht. Warum EMBITZ da vom ARM-Standard abweicht und das alles 
anders macht ist schleierhaft. Das hat mit den Compilern sowieso nichts 
zu tun, sondern nur mit der verwendeten Library!

Ich kenne das so:

void RTC_WKUP_IRQHandler () {
  ...
}

unsigned char RTC_init () {
   ...
   NVIC_EnableIRQ (RTC_WKUP_IRQn);
}

Die Funktion RTC_WKUP_IRQHandler wird hier über ihren Namen gefunden. 
Der muss in deiner startup_xxx.S auftauchen. Allerdings ist noch die 
Frage, ob die RTC des gewünschten Controllers überhaupt so einen 
Sekunden-Interrupt hat?

[Markus W. (dl8mby)]

@Gäste,

ausgehend von dem DOS Makefile, welches im Source-Zip Archive
enthalten war, ging ich davon aus, das EMBIT auch einen GNU-ARM
Toolschain verwendet.

CC      = arm-none-eabi-gcc
OBJCOPY = arm-none-eabi-objcopy
SIZE    = arm-none-eabi-size

Ob das wirklich der Fall ist, ist mir Mangels Kenntnis von EMBIZ
nicht klar.

Nachdem ich aber den Code, wie im vorhergehenden Posting
geschrieben, geändert habe, rasselt es weitere Fehlermeldungen
beim Kompilieren.

Somit stimmt an den Sourcen noch was nicht?
Ich habe die u.g. Definitionen nirgends gefunden.

Markus


Src/analyzer/rtc/RTC.h:45:89: error: 'RTC_CRL' undeclared (first use in 
this function)

Src/analyzer/rtc/emrtc.c:44:9: error: 'update_time' undeclared (first 
use in this function)

Src/analyzer/rtc/emrtc.c:85:14: error: '_LCD_CLEAR' undeclared (first 
use in this function)

Src/analyzer/rtc/emrtc.c:86:14: error: '_LCD_CURSOR_OFF' undeclared 
(first use in this function)

Src/analyzer/rtc/GPIO.h:124:90: error: 'RCC_APB2ENRbits' undeclared 
(first use in this function)

Src/analyzer/rtc/GPIO.h:46:145: error: 'GPIOA_CRL' undeclared (first use 
in this function)

Src/analyzer/rtc/GPIO.h:46:198: error: 'GPIOA_CRH' undeclared (first use 
in this function)

Src/analyzer/rtc/GPIO.h:106:98: error: 'GPIOA_ODR' undeclared (first use 
in this function)

Src/analyzer/rtc/GPIO.h:47:145: error: 'GPIOB_CRL' undeclared (first use 
in this function)

Src/analyzer/rtc/GPIO.h:47:198: error: 'GPIOB_CRH' undeclared (first use 
in this function)

Src/analyzer/rtc/emrtc.c:139:8: error: 'BKP_DR1' undeclared (first use 
in this function)

Src/analyzer/rtc/BACKUP.h:84:81: error: 'RCC_APB1ENRbits' undeclared 
(first use in this function)

Src/analyzer/rtc/BACKUP.h:53:81: error: 'PWR_CRbits' undeclared (first 
use in this function)

Src/analyzer/rtc/RTC.h:74:81: error: 'RCC_BDCRbits' undeclared (first 
use in this function)

Src/analyzer/rtc/RTC.h:84:89: error: 'RCC_BDCR' undeclared (first use in 
this function)

Src/analyzer/rtc/RTC.h:31:89: error: 'RTC_CRL' undeclared (first use in 
this function)

Src/analyzer/rtc/RTC.h:29:81: error: 'RTC_CRHbits' undeclared (first use 
in this function)

Src/analyzer/rtc/RTC.h:34:81: error: 'RTC_CRLbits' undeclared (first use 
in this function)

Src/analyzer/rtc/RTC.h:51:84: error: 'RTC_PRLL' undeclared (first use in 
this function)

Src/analyzer/rtc/RTC.h:51:98: error: 'RTC_PRLH' undeclared (first use in 
this function)

Src/analyzer/rtc/emrtc.c:202:15: error: 'RTC_CNTH' undeclared (first use 
in this function)

Src/analyzer/rtc/emrtc.c:204:16: error: 'RTC_CNTL' undeclared (first use 
in this function)

Src/analyzer/rtc/BACKUP.h:84:81: error: 'RCC_APB1ENRbits' undeclared 
(first use in this function)

Src/analyzer/rtc/BACKUP.h:53:81: error: 'PWR_CRbits' undeclared (first 
use in this function)

Src/analyzer/rtc/RTC.h:34:81: error: 'RTC_CRLbits' undeclared (first use 
in this function)

Src/analyzer/rtc/RTC.h:61:84: error: 'RTC_CNTL' undeclared (first use in 
this function)

Src/analyzer/rtc/RTC.h:61:98: error: 'RTC_CNTH' undeclared (first use in 
this function)

Src/analyzer/rtc/RTC.h:31:89: error: 'RTC_CRL' undeclared (first use in 
this function)

Src/analyzer/rtc/GPIO.h:88:98: error: 'GPIOA_IDR' undeclared (first use 
in this function)

Src/analyzer/rtc/GPIO.h:88:98: error: 'GPIOA_IDR' undeclared (first use 
in this function)

Src/analyzer/rtc/emrtc.c:463:25: error: 'IVT_INT_RTC' undeclared (first 
use in this function)

[Dr. Sommer (Gast)]

Markus W. schrieb:
> Ich habe die u.g. Definitionen nirgends gefunden.

Gehören vermutlich zu irgendeiner Library von Embitz. Du musst also 
entweder die Library da heraus kopieren (Urheberrecht...?) oder den Code 
umschreiben.

Markus W. schrieb:
> ausgehend von dem DOS Makefile,

DOS? Sicher dass man denn GCC unter DOS starten kann?!

[Markus W. (dl8mby)]

@Dr. Sommer,

"DOS" war etwas unglücklich formuliert.
Meinte die gnu-toolchain unter Windows.

Habe mal den rtc Ordner des Projekts gezipped
und als Anhang dran geheftet.

Vielleicht kannst Du ja mal rein schauen, ob Dir
was an den includes auffällt.

>find ./rtc -name \*.h -or -name \*.c -exec grep -H include {} \;
./rtc/STM32F7RTC.c:#include <stdint.h>
./rtc/STM32F7RTC.c:#include <stdio.h>
./rtc/STM32F7RTC.c:#include <string.h>
./rtc/STM32F7RTC.c:#include <ctype.h>
./rtc/STM32F7RTC.c:#include <stdlib.h>
./rtc/STM32F7RTC.c:#include "stm32f7xx_hal_rtc.h"
./rtc/STM32F7RTC.c:#include "stm32f7xx_hal_rtc_ex.h"
./rtc/STM32F7RTC.c:#include "STM32F7RTC.h"
./rtc/emrtc.c:#include "RTC.h"
./rtc/emrtc.c:#include "GPIO.h"
./rtc/emrtc.c:#include "BACKUP.h"
./rtc/DS3231.c:#include "DS3231.h"

Danke schon mal für die Hilfe.

Markus

[Dr. Sommer (Gast)]

Markus W. schrieb:
> Src/analyzer/rtc/emrtc.c:86:14: error: '_LCD_CURSOR_OFF' undeclared
> (first use in this function)

Kommt wohl daher:
https://download.mikroe.com/documents/compilers/mikroc/pic/help/lcd_library.htm

Interessant, dass hier ein Bezeichner benutzt wird, der in keinem 
inkludierten Header vorkommt. Vermutlich macht mikroE es den Leuten 
"einfach", indem die Header per "-include" zwangsinkludiert werden, 
damit der Code besonders "logisch" wird.

Der Code ist eh wunderschön:

#define true 0x1
#define false 0x0

in der GPIO.h? Was hat das mit GPIO zu tun? Warum nicht stdbool.h ?

Und überhaupt, Makros noch und nöcher... Wozu hat C eigentlich 
Funktionen.

[Markus W. (dl8mby)]

Wie gesagt/geschreiben,

wenn ich den RTC-Teil ganz auskommentiere
und die Sourcen und Includes aus dem
Makefile herausschmeiße, kann ich das .bin
File für den MC, in diesem Fall für den
STM32F746 auf dem Disco-Dev-Board, erzeugen.

Die FW läuft auch soweit zufriedenstellend.
Man muss halt nur beim Einschalten des Gerätes
die Uhr neu stellen, wenn man die Messungen
entsprechend mit aktuellen Zeitstempeln versehen
will.

Diesen Zustand wollte ich anpassen und hänge
jetzt etwas.

Braucht halt seine Zeit, bis man alles soweit
verstanden hat, das man sich behelfen kann.

Ich hoffe weiterhin auf nützliche Hinweise.
Eventuell auf Verweise zu Header-Files, wo ich
mir entsprechende defines und zugehörige
Makros ansehen kann.

Markus

[Dr. Sommer (Gast)]

Markus W. schrieb:
> Eventuell auf Verweise zu Header-Files, wo ich
> mir entsprechende defines und zugehörige
> Makros ansehen kann.

Dr. Sommer schrieb:
> Kommt wohl daher:
> https://download.mikroe.com/documents/compilers/mikroc/pic/help/lcd_library.htm

Ich würde dazu raten, den RTC-Teil einfach neu zu programmieren mit der 
STM32 HAL. Dann ist er unabhängig von Embitz und basiert auf dem 
De-Facto-Standard.

[DPA (Gast)]

Ich hab bisher noch nichts mit bare-metal auf ARM gemacht. Eventuell 
hilft eins davon:
https://vivonomicon.com/2018/04/20/bare-metal-stm32-programming-part-2-making-it-to-main/

Das im makefile angegebene Linkerfile ist Src/Sys/STM32F746NGHx_FLASH.ld
Darin ist die erste flash section .isr_vector, im Link oben wäre das 
equivalent zu .vector_table im dort verlinkten script.

.isr_vector ist in _/Src/Sys/startup_stm32f746xx.s definiert.

Dort gibt es 2 RTC spezifische interrupt handler,  RTC_WKUP_IRQHandler 
und RTC_Alarm_IRQHandler. Die haben weak symbols, und sind referenziert 
im interrupt vektor. Gib der Funktion, die den Interrupt behandeln soll, 
den selben Namen wie dem entsprechenden Interrupt Handler, um den 
default handler zu überschreiben. Ein Strong symbol einer Funktion wird 
einem weak symbol bevorzugt (ausser in gewissen umständen, wenn man 
statische libraries verwendet, aber kein -Wl,-whole-archive), deshalb 
wird dann deine Funktion referenziert, statt dem default handler mit dem 
weak symbol.

[Markus W. (dl8mby)]

@DPA,

den .isr_vector

habe ich im Linkerscript "STM32F746NGHx_FLASH.ld" und auch
im ASM File "startup_stm32f746xx.s" bei meiner Suche gefunden.

Mir ist auch soweit bekannt, dass die STM32 MC's und wahrscheinlich
auch andere ARM MC's mittels solcher ASM Files beim Bootvorgang
konfiguriert werden.

Allerdings bin ich in diesem Zusammenhang noch nicht sehr geübt und
sattelfest um die Zusammenhänge im Detail zu verstehen.

Werde aber Deinen Vorschlag versuchen umzusetzen, vielleicht klappt
es ja auf Anhieb.

Ich habe auch den CMSIS-master unter GitHub von EMBITZ
nach den diversen defines "RCC_BDCR,RTC_CRL, RTC_CRHbits" sowie den
"IVT_INT_RTC, iv, ics" Tags zu durchsucht, aber bin dort nicht
fündig geworden.

Möglicherweise sind die Definitionen direkt im EMBITZ Packet enthalten.

Leider komme ich auf www.embitz.org nicht drauf!

http://www.embitz.org/
This server is during a Ubuntu 14 upgrade to Ubuntu 18 crashed
and the backups are lost, we are trying to recover the original
data but nothing is sure.

Melde mich wenn ich wieder zum Kompilieren anfange, nachdem ich
den RTC-Code angepasst habe.

Werde erst einmal nur die RTC-Funktionsrümpfe als Dummies nachbauen
und schauen ob ich einen erfolgreichen Kompilerdurchlauf schaffe.


Danke an alle für die Hilfe bis hierher.

Markus

[Markus W. (dl8mby)]

@DPA,

danke für den Link zu vivonomicon.
Habe mir Part 1-8 der "Bare Metal" Programmierung zum STM32
heruntergeladen. Schön gemachtes Tutorial. Werde es mal durch
arbeiten.

Markus

[DH1AKF W. (wolfgang_kiefer)]

Hallo Markus,
Du jagst hier offenbar einem Phantom nach!
Die von dir genannten Programmteile werden nämlich überhaupt nicht 
verwendet. Als RTC dient der externe Baustein mit DS3231. Warum? - Weil 
die STM- Baugruppe keine getrennte Stromversorgung für die on board 
befindliche RTC anbietet.
Du brauchst also nur "DS3231.c" und die Header- Datei einzubinden. Und 
schon läuft die Uhr...
73, Wolfgang

p.s. Habe den Thread erst heute zufällig gefunden. Du hättest mich ja 
auch direkt fragen können...